The MPLS WG Archive

[Francis Arts <francis.arts@alcatel.be>]

Hello Rob, George,

Please find included my comments to your
<draft-swallow-rsvp-bypass-label-01> draft.

Regards,

    Francis.

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

1) PHP vs global label space.

The text of section 2 states the following:
  "The penultimate hop of the backup tunnel would
  pop the label for the backup tunnel, revealing the label which M
  expects."

However, when reading your proposal, the use of PHP does not seem
mandatory, even when a global space is used in the merge node M.

Please add an explicit statement to the text whether or not PHP is
mandatory in the global label space case.


2) Bypass tunnel.

The text of section 2 states the following:
   "When a failure occurs and the backup comes into use, a means of
   maintaining the RSVP state is required.  In this simple case the Path

   messages can simply be sent via the backup link or tunnel as the case

   may be."

Refreshing RSVP messages down a bypass tunnel is not described in any
RFC or ID (also not in draft-ietf-mpls-rsvp-lsp-tunnel-08). Therefore,
the mechanism needs to be explained in your draft. e.g. Which value
should be used for the PHOP object when refreshing the PATH message down
the bypass tunnel?

Note: You could consider reusing the signalling mechanisms Kireeti
Kompella has defined for LSPs used as FAs.


3) Local label space.

The text in section 4 states the following:
  "In this case no Path message is sent down the
   bypass tunnel prior to a failure."

Does a similar approach hold when the merge node uses a non-global label
space? That is, when using a non-global label space, is the label
binding **through the bypass tunnel** for the LSPs being protected,
established before or after the failure occurs?

Please make an explicit statement in the text.


4) p.6, section 2, extended tunnel id.

Is it for the purpose of your draft allowed to set the extended tunnel
id to all 0s as well as setting it to an IPv4 address of the ingress
LSR?


5) p.6, section 2, last but one paragraph.

The text states that 'it is thus necessary to properly associate the
LSP_ID of a backup tunnel with the LSP_ID of the tunnel being backed
up'.

However, from the text (p.6, section 2, last but one paragraph) it does
not seem to be necessary to copy the LSP_ID since the 'other LSP'
mentioned in the text, has another 'IPv4 tunnel sender address' in the
SENDER_TEMPLATE. A drawing showing an example, would be useful.