The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <20021114160822.U28745-100000@maroon.jnpr.net>, Jim Boyle writes:
> 
> Sorry for the strange subject on the last email, had to have someone
> forward me Curtis's email. The subject is corrected here.
> 
> On Thu, 14 Nov 2002, Jim Boyle wrote:
> 
> >
> >
> > > On 13 Nov 2002 19:53:16 GMT, Curtis wrote:
> > >
> > > To:      Der-Hwa Gan <dhg@juniper.net>
> > > cc:      "Gray, Eric" <egray@celoxnetworks.com>, mpls@UU.NET
> > > From:    curtis@fictitious.org (Curtis Villamizar)
> > > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)
> > >
> > >
> > >  <snip - dhg's email>
> > >
> > > If we can't agree that one approach is better, then we are stuck with
> > > the current situation.  The ingress can either change the LSP-ID or
> > > not change the LSP-ID and just decrease the bandwidth.
> > >
> > > <snip - state differences trivial>
> > >
> > > If we still have two methods available to the ingress, then we have to
> > > make sure the midpoints can handle both.  If so, then the only thing
> > > that we should add is (currently implied if the ingress can do it)
> > > that the midpoint LSR must be prepared to handle a decrease in
> > > bandwidth on an LSP.
> > >
> > > Curtis
> > >
> >
> > Curtis, this sounds like the best approach.
> >
> > Is this the consensus?  How do we proceed?
> >
> > regards,
> >
> > Jim Boyle



Jim,

> Is this the consensus?

Probably.  If so ...

> How do we proceed?

We have a hypothetical brand A, B, and C.  A and B interoperate.  A
and C interoperate.  B and C don't due to B decreasing bandwidth in a
way that C can't handle.

One option is just let customer U continue to try to beat up C.  Or
maybe they are beating up both B and C.  Not important.

The only other option is insist that for RFC3209 to go from PS to DS a
paragraph needs to be added to "2.5. Rerouting Traffic Engineered
Tunnels" at the very end stating something like:

   The same technique is used to accomplish a smooth reroute of a
   tunnel when bandwidth increases or when no bandwidth change occurs
   but the path changes or any other change which may result in a
   denial of the changed resource request.  If there is no path change
   and a bandwidth decrease a make-before-break reroute can be done.
   Alternately, for no path change and a bandwidth decrease or any
   other change which is certain to pass resource admission tests, the
   bandwidth request can be reduced without changing the
   SENDER_TEMPLATE.  Midpoint and egress routers MUST be able to
   handle either case.

Now all we have to do is get this past one of the authors of this RFC
who works for brand C.  You can lead the battle from here.  After all
B and C are the ones who have to settle this.

Curtis

ps - no one could possibly guess who A, B, C, and U are.