Subject: Re: Comments to <draft-swallow-rsvp-bypass-label-01>

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Apr 2001 16:06:03 -0400

In message <[email-masked]>, 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

---

From: George Swallow <[email-masked]>
Date: Tue, 03 Apr 2001 17:50:31 -0400

Francis, Curtis -

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

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

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

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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Apr 2001 20:28:18 -0400

> to use the identical Session object.

The backup and the primary should merge at some point and that point
would be the egress of the backup.  If so, then there is no common
link and no opportunity to share.  The backup can serve as backup for
as many primary LSP as need route around the failure on that path.

I had envisioned sharing backup bandwdith using the techniques
described in draft-kini-* but that too is out of scope for
draft-swallow-rsvp-bypass-label-01 and orthogonal to it.

> state during a reroute operation.  But that isn't all that useful so I

Good.  I thought it was me being dense again.

> tunnels happen to have identical sender objects.

Dumb question.  Never mind.  I was considering the case where the join
occurs exactly one logical hop away and uses a platform label.  You
don't have to signal an inner tunnel, just the shared outer tunnel and
use the platform label from the primary tunnel.  That may not be a
behavior endorsed by the draft.

If you have a shared outer tunnel and signaled inner backup tunnels,
then copying the LSP_ID to the inner tunnel would be fine.  You
increase the signaling load but you still save on labels since only
the labels for the shared outer tunnel is needed on the physical
backup hops.  What you describe is needed if you want to use interface
labels and need to take one extra hop along the primary path before
the final POP so that the primary path label shows up on the same
interface.

Curtis

ps- Sorry for the dumb question.  This draft is a bit old and it was a
while ago that we thought this stuff through.  Still makes sense.

---

From: Francis Arts <[email-masked]>
Date: Wed, 04 Apr 2001 09:43:25 +0200

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.

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

> example.  I'll add some text to make that clearer.

Ok.

> IP address that you use in the Sender Object, but there's nothing

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

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

> state during a reroute operation.  But that isn't all that useful so I

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.