The MPLS WG Archive

[George Swallow <swallow@cisco.com>]

Francis, Curtis -

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

Correct.  The text that you are questioning was only meant as an
example.  I'll add some text to make that clearer.

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

I think the FA draft is beyond the scope.  Some words about PHOP are
in order.  I'll add some.  The important thing is that the PLR node be
able to associate the RESV message with the Path message it sent down
the tunnel.  How the PLR does this is a local matter.  One thing to
note is that the IP address of the orginal outbound interface could in
some cases become unreachable if that link goes down.  So some care
needs to be used here.  I would personnally recommend using the same
IP address that you use in the Sender Object, but there's nothing
mandatory about that.

> > 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.
 
If you're doing SE reservations on the tunnel and the backup tunnel,
then the scope of the sharing is limited by RSVP to senders to the
same session.  So, if you want the reservations shared then you need
to use the identical Session object.
 
> > 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 

I'll remove the text.  It's dangling text that has to do with some
other stuff I took out of the draft before it was ever published
(including draft-00).  The idea was to allow downstream nodes to be
able to associate which back up path state went with which primary
state during a reroute operation.  But that isn't all that useful so I
removed it.

>and how one to many
> backup tunnels would be accomodated if the LSP_ID is copied.  George?

I don't understand the question.  The Session objects differentiate
the many backup tunnels.  It doesn't matter if some of those backup
tunnels happen to have identical sender objects.

> Curtis

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824