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

From: Shahram Davari <[email-masked]>
Date: Wed, 6 Nov 2002 08:35:22 -0800

The LSP-ID defined in Y.1711 is essentially a combination of LSP-ID + Tunnel-ID
as defined in RSVP-TE.  

In the current version of Y.1711, 4 bytes are assigned to this. However the current version of Y.1711 sets the first 2 octets of this field to zero for future use. Therefore two methods are possible:

1) Compress the LSP-ID + Tunnel-ID in to 2 bytes 

2) You could use the first 2 octets, and encode the 2-byte RSVP-TE LSP-ID in the first 2 octets of Y.1711 LSP-ID and encode the 2-byte RSVP-TE Tunnel-ID in the last 2 octets of Y.1711 LSP-ID.

Just a question, isn't it possible to change the LSP by changing the Tunnel-ID, rather than LSP-ID?

-Shahram

> -----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:19:43 -0500

Shahram -

> In the current version of Y.1711, 4 bytes are assigned to
> this. However the current version of Y.1711 sets the first 2 octets of
> this field to zero for future use. Therefore two methods are possible:
> 

This uses up all the space.  If RSVP-TE is the only application for
Y.1711 then this would be acceptable.  But since it's called MPLS OAM,
I assume there were other apps in mind as well.

> 2) You could use the first 2 octets, and encode the 2-byte RSVP-TE
> LSP-ID in the first 2 octets of Y.1711 LSP-ID and encode the 2-byte
> RSVP-TE Tunnel-ID in the last 2 octets of Y.1711 LSP-ID.

Not enough space to be future proof.  We already have requests to
support thousands of tunnels.  If I give just 4 bits to LSP-ID that
only leaves 4k tunnels.

> Tunnel-ID, rather than LSP-ID?

You cannot share bandwidth between different RSVP sessions only
between different senders.  The tunnel ID is in the session ID to say
"the various LSPs with this identification all belong to the same
tunnel".

The LSP-ID is in the sender template so that they can be
distingueshed, yet associated via the session and thus can share
bandwidth.

...George

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 06 Nov 2002 17:08:12 -0500

Since George beat me to the punch, I will just
add a few points to his.

>I assume there were other apps in mind as well.

         Yes, for example, what do we do for L2/L3 VPN given
this logic?

>support thousands of tunnels.  If I give just 4 bits to LSP-ID that

         There are several deployments with tens-of-thousands
of tunnels, so this will definitely not work there.

         --Tom

>distingueshed, yet associated via the session and thus can share

Success is relative; the more success, the more relatives. -Anonymous

---

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

Shahram -

> I assume there were other apps in mind as well.

This is not even sufficient for RSVP-TE.  When I set up backup paths,
the means of identification is to keep the same Session_Object, and the
same LSP-ID.  The source_IP address is set to the router setting up
the backup tunnel.  Thats the only change.  

So suppose (a most common situation)

router A has tunnel number 1, LSP number 1.
  this tunnel passes through some other router B

router B has its own tunnel number 1, LSP number 1.

router B sets up a backup to protect tunnel A,1,1.

it would like to ping (i.e. verify connectivity) the backup tunnel
after it is set up to make certain that it is working

It can't set the TTSI to B,1,1 - since that is the ID for his own
tunnel.  He can't set it to A,1,1 because that is the working path and
he wants to check the protect path.

So the TTSI does not seem to be sufficient even for RSVP-TE!

...George