The MPLS WG Archive

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

Curtis, George,

My comments are in-line. Since the subsequent mails exchanged on the subject,
trimmed part of the questions I want to comment on, I use this one.

    Francis.

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

George Swallow wrote:

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

Ok.


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

Comment:
* You state that 'it is a local matter how the RESV message is associated with
the correct PATH message'. However, I don't think this is a local matter: This
is done using the SESSION and FILTER SPEC objects; it does not involve the PHOP
object.
* The idea in the RSVP protocol is to use the IP address of the connection to
the next IP router. In this case this connection is an LSP. Therefore, the
question is which IP address is associated with this LSP. My understanding of
your draft is that no such IP address <==> backup LSP relation is considered
(correct me if I got that wrong). Therefore, I propose to add an explicit
statement to the text that 'when sending the PATH message into the backup
tunnel, the PHOP object can conatin any IP address of the PLR'.




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

Comment to Curtis' statement:
* I agree that it cannot be assumed that the backup tunnel has zero bandwidth.
* As George states the same SESSION object and the SE reservation style are
mandatory to get make-before-break to work. However, if I understand you
correctly, you state that the settings of the extended tunnel id is important
for make-before-break to work. I don't think this is necessary:
Make-before-break can work when extended tunnel id == 0 as well as when extended
tunnel id < >  all 0s. The importance of the extended tunnel id is that SE style
reservations can be shared between different sender nodes (extended tunnel id ==
all 0s) or not (extended tunnel id < > all 0s). This is important when setting
up multipoint-to-point LSPs.
* The sharing of resources happens from the downstream node on where the backup
tunnel and the tunnel being backed up, merge again. [As you indicate in 1 of
your subsequent mails, I agree that there is no resource sharing in between the
PLR and the merge node.]


Comment to George's statement:
* I agree that using identical SESSION objects is mandatory to share
reservations. Therefore, your proposal to copy the SESSION object from the
tunnel being backed up, to the backup tunnel is mandatory: This allows to merge
the backup tunnel again in the downstream node with the original tunnel.


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

Comment:
Please note that also the last paragraph of p.6 ("we therefore propose ...")
needs some updating:
* The text indicates that "the SESSION object and the LSP_ID should be copied
from the LSP tunnel being backed up to the backup tunnel". However, copying the
LSP_ID is then no longer necessary.
* The text states that "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". However, choosing in this case a different IP
address, is no longer necessary: Just choose a different LSP_ID.



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