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

From: "Houck, David J (David)" <[email-masked]>
Date: Wed, 6 Nov 2002 11:33:15 -0500

I have a question about the "build the new then tear down the old" approach for decreasing TE-LSP bandwidth.  If a link in the path is at capacity, then wouldn't the "build new" request be denied.  If so, it would be a lot easier just to decrease the bandwidth on the existing TE-LSP.

Dave Houck 
732-949-1290 

-----Original Message-----
From: George Swallow [mailto:[email-masked]]
Sent: Wednesday, November 06, 2002 10:18 AM
To: David Allan
Cc: George Swallow; Der-Hwa Gan; Gray, Eric; [email-masked];
[email-masked]
Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)

> I was envisioning a case where a bandwidth change was not a separate tunnel
> setup, the LSP ID changed without any interruption or change in the
> conntectivity of the path . If there is build the new then tear down the
> old, then there is no gap in any monitoring case.
 
If you change the LSP-ID, that changes the sender-template.  Ipso
facto a new setup.

> As for TTSI, it's simply a node specific LSP Identifier that allows for an
> IPv4/v6 LSR ID and 32 bits for an LSP identifier. The assumption is that the
> originating LSR most usefully administers LSP-IDs independently of the
> individual control protocol used. The initial draft of Y.1711 was focused on
> P2P ER-LSPs which meant RSVP-TE or CR-LDP, hence the stipulation that the
> first two bytes of the LSP-ID were padded with zeros to align with LSP-ID as
> defined in the signalling protocols. If there is a problem with this, it is
> not leaping out at me....

As we use it, an (RSVP-TE) LSP-ID is *only* unique to the tunnel.  We
just use it as an instance number and increment it when we reroute or
change bandwidth.  If I setup five tunnels they will have five
different tunnel-IDs, but they can *all* have the same LSP-ID.

To uniquely identify a TE-Tunnel LSP. you need *all* of the fields in
the session and sender-template objects.  That why we carry those in
LSP ping.

...George

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

---

From: George Swallow <[email-masked]>
Date: Wed, 06 Nov 2002 16:27:04 -0500

> I have a question about the "build the new then tear down the old"
> approach for decreasing TE-LSP bandwidth.  If a link in the path is at
> capacity, then wouldn't the "build new" request be denied.  

No.  Suggest you read RFC3209 section 4.6.4.

...George

---

From: David Charlap <[email-masked]>
Date: Wed, 06 Nov 2002 16:47:22 -0500

Houck, David J (David) wrote:
 > approach for decreasing TE-LSP bandwidth.  If a link in the path is
 > at capacity, then wouldn't the "build new" request be denied.  If so,
 > it would be a lot easier just to decrease the bandwidth on the
 > existing TE-LSP.

Not if the LSP is signaled using RSVP SE-style.  With SE style, the 
reservations for all LSPs in a single session share a common reservation 
which is normally the least-upper-bound of all the individual 
reservations.  So if the new LSP has less bandwidth than the existing 
LSPs, it won't cause new resources to be reserved, and shouldn't fail.

This assumes, of course, that the hardware and software on the router in 
question is capable of properly implementing SE style.  But all of 
make-before-break depends on this.

-- David