The MPLS WG Archive

["Manikantan Srinivasan" <manis@futsoft.com>]

Dear David

Thanks for your mail. 

I used the Tunnel/LSP interchanged and hence I used
Tunnel ID equal with LSP ID. I believe, between an ingress 
and an egress, a LSP/Tunnel can be uniquely identified and 
it is called as LSPID/Tunnel ID.

>From the RSVP-TE definitions, I agree, a Tunnel can contain
several LSP-IDs. A Tunnel ID is different from LSP IDs,
and hence we need both Tunnel ID and LSP ID to uniquely identify
the LSP.

Regarding Extended Tunnel ID (in SESSION object), I agree from your
clarification, that this need not be the ingress address. Might be zero.
But if this is non-zero, can we assume that it will be sender IP Address?

I assume that the extended Tunnel ID is either zero or the sender IP
Address.

If the extended tunnel id is same as sender IP address, then we don't 
require this right? 

Does the LSP Sub object in draft-vijay-mpls-rsvpte-lspsubobject-00.txt
be extended to contain the 5 tuples you have mentioned?

As you rightly said, the current MIBs does not have the support for
the 5 tuples to determine a unique LSP in RSVP-TE context. Do you
think it as worthwhile to add these in the MIB for total solution?

best regards
mani

> -----Original Message-----
> From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of David
> Charlap
> Sent: Monday, October 14, 2002 2:17 PM
> To: IETF MPLS List
> Subject: Re: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt
> 
> 
> Manikantan Srinivasan wrote:
>  >
>  > 3) Can you explain why do we need both TunnelID and LSPID in the LSP
>  >    sub object? The Ingress, Egress Addresses and the TunnelID is
>  >    sufficient to uniquely identify a tunnel.
> 
> It is not sufficient.  In order to uniquely identify an RSVP-TE LSP, you
> need no fewer than five values:
> 	Tunnel endpoint (egress) address (in SESSION object)
> 	Tunnel ID (in SESSION object)
> 	Extended Tunnel ID (in SESSION object)
> 	Sender (ingress) address (in SENDER_TEMPLATE/FILTER_SPEC object)
> 	LSP ID (in SENDER_TEMPLATE/FILTER_SPEC object)
> 
> Any implementation that makes assumptions about these values is broken.
> The existing MPLS MIBs (LSR and TE) do not contain enough information
> to cover all of RSVP-TE's capabilities.  For instance, the extended
> tunnel ID does not have to match the sender address (it could also be
> zero).  And one tunnel (defined by the three values in the SESSION
> object) may contain multiple LSPs, each with its own separate LSP ID.
> 
> If you don't permit one tunnel to have separate LSPs, then you
> effectively eliminate SE style and all of the useful features that it
> offers.  You also drasticly reduce the maximum number of LSPs that can
> be created between two endpoints.
> 
> -- David
> 
>