The MPLS WG Archive

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Hi Curtis,

At 16:19 31/10/2002 -0500, Curtis Villamizar wrote:

>In message 
><1117F7D44159934FB116E36F4ABF221B0267EC45@celox-ma1-ems1.celoxnetwor
>ks.com>, "Gray, Eric" writes:
> > Curtis,
> >
> >       I don't disagree with your points with one caveat:
> > if a new specification requires implementations to support
> > multiple approaches for interoperability with existing
> > implementations, it will effectively encourage multiple
> > approaches in all future implementations.  I assume you
> > would not argue that the specification should require
> > implementations to discriminate between existing and new
> > implementations by requiring newer implementations to
> > support fewer options.
> >
> > Eric W. Gray
> > Systems Architect
> > Celox Networks, Inc.
> > egray@celoxnetworks.com
> > 508 305 7214
>
>
>Eric,
>
>In the ABSENSE of guidance from the spec, all possibilities have to be
>covered.
>
>What I suggested was the we add guidance.
>
> > > I prefer make-before-break reroute and therefore favor explicitly
> > > disallowing the tspec change (but our implementation is OK either way).
> > > I think the change should go in a future iteration of rfc3209.
>
>The guideance we add is:
>
>   1.  Do a make-before-break rather than change tspec.  Put this
>       requirement (recommendation?) in rfc3209.
>
>   2.  If you want to play it safe regarding older or buggy
>       implementations anticipate arbitrary change to the PATH.  In any
>       case do something reasonable, like don't crash.

I fully support your position here.

JP.

>So exactly what do you disagree with?  Or was it unclear what I was
>suggesting since I started by explaining the current situation?
>
>Curtis
>
>btw- You'll still need to handle priorities and bandwidth being
>different among LSP that are part of the same Tunnel (sharing).  That
>is just a fact of life unless you think that it is just fine to drop
>the old LSP and start a new one (without make-before-break) if you
>change priorities using the CLI.
>
>
> > > -----Original Message-----
> > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> > > Sent: Thursday, October 31, 2002 11:52 AM
> > > To: Amir Birjandi
> > > Cc: mpls@UU.NET; najam.ahmad@wcom.com; juzer.kopti@wcom.com;
> > > plahiri@UU.NET; blaine.christian@wcom.com
> > > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue"
> > >
> > >
> > > In message <3.0.32.20021030142549.027cb8b0@pop.wcomnet.com>, Amir 
> Birjandi
> > > writ
> > > es:
> > > >
> > > > Hi,
> > > >
> > > > There are straight guide lines for increasing TE-LSP bandwidth in rfc-
> > > 3209,
> > > > however there are ambiguities in rfc3209 and rfc2205 for decreasing the
> > > > TE-LSP bandwidth.
> > > >
> > > > It seems vendors can follow the spc if they change the LSP-ID or not
> > > change
> > > > the LSP-ID, after the LSP bandwidth has been decreased.
> > > >
> > > > This ambiguity may causes some intereoperabilty issues.
> > > >
> > > > Perhaps verdors or authors "3209 or 2205 "should address this issue so
> > > > every one comply to the same standard.
> > > >
> > > > Thanks
> > > >
> > > > A.
> > >
> > >
> > >
> > > Amir,
> > >
> > > As Markus pointed out, this is yet another case where it is wise for
> > > the implementor to "be conservative in what you send and liberal in
> > > what you accept".  This has always been good advice to an implementor.
> > >
> > > As an ingress anytime anything changes, priority, bandwidth, color
> > > restrictions (if signaled), request for FRR, do a make-before-break
> > > reroute.  Don't try to send a modified PATH message.  It is important
> > > that an implementation not just change the LSP-id but also keep the
> > > SESSION object unchanged so that make-before-break reservation sharing
> > > works (as specified in rfc3209, section 2.5).
> > >
> > > As a midpoint be prepared for anything to change in the PATH message.
> > > Be prepared for priority to change or bandwidth to change.  Be
> > > prepared for color restrictions to change.  Be prepared for FRR to be
> > > added, dropped, or modified.  Also be prepared to "share" bandwidth
> > > among more than two LSPs and for the possibility for those LSPs to
> > > have different priorities (otherwise how do you make-before-break
> > > reroute on a change in priority).  Be sure to "get it right" when
> > > making a change or combining shared bandwidths on the CAC decision and
> > > in the bandwidth accounting (the remaining reservable bandwidth
> > > amounts that get reflooded).
> > >
> > > There is existance proof that this can be accomplished, yielding
> > > interoperabilty with two major MPLS implementation that do this
> > > differently.
> > >
> > > Of course, you are not an implementor and find yourself with one
> > > router that has not been sufficiently conservation in what it sends
> > > and another which has not been sufficiently liberal in what it
> > > accepts.
> > >
> > > The remaining question is if a spec is changed should changing the
> > > tspec bandwidth in PATH messages for MPLS/TE be explicitly allowed or
> > > explicitly disallowed.  Or both, require that it not be sent by the
> > > ingress and require that it be accepted by the midpoint so in the
> > > future we still cover older or slightly buggy implementations.
> > >
> > > I prefer make-before-break reroute and therefore favor explicitly
> > > disallowing the tspec change (but our implementation is OK either way).
> > > I think the change should go in a future iteration of rfc3209.
> > >
> > > Curtis
> >