The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Apr> msg00152



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Comments on Bypass Label draft

  • From: "Wadhwa, Sanjay" <SWadhwa@unispherenetworks.com>
  • Date: Tue, 10 Apr 2001 18:14:27 -0400

>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