The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]
--- Eric Rosen <erosen@cisco.com> wrote: > > Ping> The problem with this approach is: there is no guarantee that > the > Ping> returning path (with or without IP Router Alert) won't go over > an LSP. > Ping> If that LSP is bad, we are in trouble. > > Since tunnels can be nested, isn't is possible that in a traffic > engineered > path <R1, R2, R3, ..., Rn>, R2 and R3, say, are IGP adjacencies > over a > virtual interface that is actually a pair of LSPs (one from R2 to > R3, one > from R3 to R2)? In such a case there is no guarantee that the > control path > (forward and reverse) does not include an LSP. > Sure. But if the reverse LSP (virtual interface) is broken (say due to corrupted label maps along the way), then even the RESVs for the inner LSPs don't make it through, and soon enough the inner LSP will be torn down (So making echo-response live and die with rsvp resv actually will work fine with nested tunnels irrespective of RESV using a reverse LSP or native ip in the reverse direction). -Sanjay __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
|
|