The MPLS WG Archive

[Gopalkrishna Panicker <gopanicker@yahoo.com>]

Mark,

Thanks. That was helpful. 
I was just browsing the RSVP-TE spec. In light
of this discussion I find it interesting that 
the spec always refers to "bandwidth-increase" 
instead of say a "bandwidth-modify".  

I am wondering if make-before-break mechanism should
be used when bandwidth is to be decreased.

IMO make-before-break was devised to solve the 
double-counting issues which we don't have here. 

As mentioned in one of David's earlier emails on the 
subject, We could simply change the Sender Tspec 
and wait for a new updated Flowspec from the egress to
take effect.

 
Cheers
Gopal

--- "Feng, Mark" <m_feng@trillium.com> wrote:
> IMO, the exact behavior depends on the
> implementation, though the end result
> should be the same.
> 
> In one behavior, when B receives the PTear, it would
> remove the reference to
> sender1 in PSB and RSB; but leave the allocation
> unchanged (i.e. 20 units).
> When C receives the PTear, it would generate a new
> Flowspec of 10 units,
> since sender1 is removed. When the new Resv message
> has been propagated back
> to Ingress, the desired allocation is in place.
> 
> B could try to guess what the new allocation is,
> based on the Tspec, before
> receiving the new Flowspec. IMO, that's entirely up
> to the implementation.
> 
> Hope this helps.
> 
> - Mark
> 
> > -----Original Message-----
> > From: Gopalkrishna Panicker
> [mailto:gopanicker@yahoo.com]
> > Sent: Thursday, May 23, 2002 11:29 AM
> > To: mpls@UU.NET
> > Subject: RSVP-TE : bandwidth decrease
> > 
> > 
> > Hello,
> > 
> > Consider the following topology
> > 
> > 
> >    A-----------B----------C
> > 
> > Let us say
> > 1. we are using make-before-break and therefore
> >    using SE style.
> > 2. LSP1 with Sender1 has been signalled with a  
> >    bandwidth of 20 units. A is the ingress and C
> is
> >    the egress.
> > 
> >  Now A decides to reduce the bandwidth to 10
> units.
> >  A ceates a new sender template (Sender2) and 
> >  Tspec. A then sends the path message towards C. 
> > 
> >  After receiving the path message, C computes the
> >  bandwidth to be allocated. Since SE style is
> being 
> >  used, the merged flowspec sent in the resv
> message
> >  from C to B will  continue to say a bandwidth of 
> >  20 units. 
> >  The only reason the resv  makes it back
> >  to A is because of the new filterspec (Sender2).
> > 
> >  I assuming this is correct.
> > 
> >   Now A issues a path tear for sender1. B will
> >   delete the path state associated with sender1. 
> >   B will also delete the corresponding filter spec
> >   from the resv state. 
> >  
> >   Now to my question. How does B know that it has
> >   to delete the 10 units of bandwidth reservation
> ?
> >   
> >   If my understanding is correct, the resv message
> >   from C had carried a merged flowspec and set of
> >   filterspecs (Sender1, Sender2). How does B 
> >   determine the orginal flowspec associated with
> >   the filterspec (in this case Sender1) ?
> >   
> >   Should B on rely on the tspec stored in the PSB
> ? 
> > 
> > 
> >  Obviously I am missing something.
> > 
> >  Thanks
> > 
> >  Cheers
> >  Gopal
> > 
> > 
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > LAUNCH - Your Yahoo! Music Experience
> > http://launch.yahoo.com
> > 




__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com