The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Comments on Bypass Label draft
>Robert, George: >Below are some comments on, and questions about, your bypass label draft. >- Philip >* Refreshing a backup tunnel riding a bypass tunnel > I don't understand how the refresh works in this case. > Section 2 states that the Path message for the backup tunnel is sent inside the bypass > tunnel, while section 3 states that the SENDER_TEMPLATE object contains a sender address > that differs from the address used for the primary LSP. So the merge point LSR will create > a new Path State Block and try to send back a Resv message. But where does it send this > Resv to? If the network is as shown in figure on page 4, then it can send the RESV message > on either the link to R3 or the link to R7. However, in either case, R3 or R7 will intercept > the Resv message, and because neither one is expecting a Resv message with this sender > (because neither saw the corresponding Path message), problems ensue. Philip My understanding is that the PHOP in the path message (for the backup tunnel) sent on the bypass tunnel would be one of PLR's (R2's) addresses. Since the interface on which the path arrived on R4 is uni-directional, R4 will have to just unicast route the resv back to the PHOP. So rsvp on R3 or R7 will not be seeing it. Maybe the draft should be more explicit about signalling for backup tunnels. -Sanjay
|
|