Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue"

From: "Gray, Eric" <[email-masked]>
Date: Thu, 31 Oct 2002 14:00:30 -0500

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.
[email-masked]
508 305 7214

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Thursday, October 31, 2002 11:52 AM
> To: Amir Birjandi
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue"
> 
> 
> In message <[email-masked]>, 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

---

From: George Swallow <[email-masked]>
Date: Thu, 31 Oct 2002 16:08:18 -0500

> implementations by requiring newer implementations to

As far as I know, all implementations deal with changing the LSP-ID at
the midpoint.  At the head-end all change the LSP-ID on increase.
Some change the LSP-ID on decrease and some (one?) don't.  If that one
did then we'd all be in sync.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Oct 2002 17:09:24 -0500

> did then we'd all be in sync.

George,

If all of the implementations handled a decrease in bandwidth without
changing the LSP-ID we wouldn't be having this discussion.

Otherwise we have no interoperability problems.  We simply have some
doing make-before-break reroute on bandwidth decrease, which works and
has to be done for bandwidth increase, and some just sending a new
PATH message with a changed tspec.  If so, we can just drop the
discussion.

Using the make-before-break reroute will always work so we intend to
continue to use it.  I thought we were doing that since we had seen
interoperability problems doing otherwise but I don't know how long
ago that was.

Just out of curriousity, do you also plan to change to numerically
higher holding priority (same or lower bandwidth) via change to the
PATH message, since CAC could not reject that either?  We do
make-before-break reroute as an ingress on that too but we rerun
admission at midpoint and allow any acceptable change.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Oct 2002 16:19:09 -0500

In message <[email-masked]
> implementations by requiring newer implementations to

Eric,

In the ABSENSE of guidance from the spec, all possibilities have to be
covered.

What I suggested was the we add guidance.

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

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.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Thu, 31 Oct 2002 18:38:19 -0500

Hi Curtis,

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

>In message 
><[email-masked]

I fully support your position here.

JP.