The MPLS WG Archive

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

In message <200104032150.RAA26300@pilgrim.cisco.com>, George Swallow writes:
> > > 
> > > 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.


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.


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


Good.  I thought it was me being dense again.


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


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.