The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Oct> msg00168



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Decreasing TE-LSP bandwidth, "interoperability issue"

  • From: Curtis Villamizar <curtis@workhorse.fictitious.org>
  • Date: Thu, 31 Oct 2002 17:09:24 -0500
  • cc: "Gray, Eric" <egray@celoxnetworks.com>, mpls@UU.NET


In message <200210312108.QAA07578@bifocal.cisco.com>, George Swallow writes:
> > 	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.
> 
> 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


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