The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <3AC473D7.7A50CB85@alcatel.be>, Francis Arts writes:
> 
> Hello Rob, George,
> 
> Please find included my comments to your
> <draft-swallow-rsvp-bypass-label-01> draft.
> 
> Regards,
> 
>     Francis.


Francis,

Responses inline.  This is my understanding of the draft.  George can
correct me.

Curtis



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


It is not manditory.  If the egress is capable of doing a POP and then
looking at the next label, its allowed to do that.


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


Can we consider that to be out of scope?  That way it doesn't have to
be defined in both the hierarchical draft and in this one.  As long as
there is a defined way to do this.


> 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?


While you are allowed to set this to all 0s, I don't know any reason
to set to all 0s.  Unlike some people I don't assume that all backup
tunnels will have a zero bandwidth reservation and therefore if you
want make-before-break to work, all 0s would be a poor choice.


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


I don't understand the reason for this restriction and how one to many
backup tunnels would be accomodated if the LSP_ID is copied.  George?

Curtis