The MPLS WG Archive

["Philip Matthews" <philipma@nortelnetworks.com>]

Robert, George:

Below are some comments on, and questions about, your bypass label draft.

- Philip


----------------------

* Distinction between "Bypass" and "Backup"
  It seems to me that this draft tries to make a distinction between 
  a "bypass tunnel" (the outer LSP in the many to one case)
  and a "backup tunnel" (the inner LSP in the many to one case,
  as well as the only LSP in the one to one case).
  However, there are some places where it seems to me that this distinction
  is not maintained. For example, in the discussion of the many-to-one case
  in section 2, the word "backup" is used in places where I think "bypass" is meant.
  Is this distinction intentional, or am I reading more into the draft
  than was meant? Am I correct in think that the draft confuses the two
  terms in some places?
  If this distinction was indeed intentional, then may I suggest the distinction
  be described more clearly in section 1?


* SESSION_TEMPLATE for Backup tunnel
  Section 3 states "If the head-end of a tunnel is also acting as the PLR, it must choose an
  IP address different from the one used in the SENDER_TEMPLATE of the original LSP tunnel".
  Why?  Choosing a different address means that the merge point must forward both Path messages
  on to the downstream LSR, rather than sending just one Path message.


* 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.
 

* Second sentence in section 4
  I don't understand the sentence "When using a bypass tunnel, the backed up tunnels 
  are only one LSP hop from rejoining their primary LSPs".
  It seems to me that this section is addressing the case where the backup LSPs
  rejoin their corresponding primary LSP at a point 2 or more LSP hops away.
  (For example, in the figure on page 4, the bypass tunnel runs from R2 to R4,
   so the bypass tunnels rejoin after two LSP hops).


* SESSION_TEMPLATE usage in Section 4 case
  When refreshing the backup tunnels in this case, are the SESSION_TEMPLATE
  objects updated as described in section 3? Or is the original SESSION_TEMPLATE
  used?



=============