Subject: RE: RSVP-TE : bandwidth decrease

From: Gopalkrishna Panicker <[email-masked]>
Date: Thu, 23 May 2002 13:22:39 -0700 (PDT)

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" <[email-masked]> 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:[email-masked]]
> > Sent: Thursday, May 23, 2002 11:29 AM
> > To: [email-masked]
> > 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

---

From: David Charlap <[email-masked]>
Date: Thu, 23 May 2002 16:57:12 -0400

Gopalkrishna Panicker wrote:
> 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.

The purpose of make-before-break is for situations where the LSP is
being rerouted independantly of the routing table - like when the ERO
changes.  An in-line change of the ERO creates transient instability in
the LSP that will result in a temporary loss of connectivity on the data
plane.  In a service provider network, that is completely unacceptible.

I'm not sure what the specific rationale for make-before-break is when
the LSP is not rerouting.  I think it's in order to prevent a loss of
the LSP.

In the case of a bandwidth-increase, if you just change the TSPEC, some
node may be unable to increase the reservation.  The resulting PathErr
may cause the LSP to be torn instead of reverted to the smaller
reservation.  This would be a very bad thing.

So instead, we create a new LSP.  If the new one fails, the old one is
not affected.

When doing a bandiwdth decrease, this shouldn't be a concern.  If a
switch is capable of modifying the bandwidth of an existing LSP in the
first place, I would assume that a bandwidth decrease will always
succeed.

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

That would be mu gut feeling, but I wouldn't implement such a feature
without further study.  I don't trust gut feelings when making a
decision that may seriously affect interoperability if I'm wrong.

Personally, since make-before-break is required for rerouting and
bandwidth-increase, I see no strong reason not to use it for all
changes.  Once the mechanism is developed, it's simpler to just use it
everywhere.

-- David

---

From: "Feng, Mark" <[email-masked]>
Date: Thu, 23 May 2002 12:15:30 -0700

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

> From: Gopalkrishna Panicker [mailto:[email-masked]]
>    bandwidth of 20 units. A is the ingress and C is
>    the egress.
> 
>  Now A decides to reduce the bandwidth to 10 units.
>  bandwidth to be allocated. Since SE style is being 
>  used, the merged flowspec sent in the resv message
>   to delete the 10 units of bandwidth reservation ?
>   
>   Should B on rely on the tspec stored in the PSB ? 
> 
>