The MPLS WG Archive

["Gray, Eric" <egray@celoxnetworks.com>]

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


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