Subject: RE: LSP ID

From: Shahram Davari <[email-masked]>
Date: Thu, 19 Apr 2001 13:51:56 -0700

Hi,

In RSVP-TE, an LSP could be uniquely identified by the combination of Ingress Router ID, which can be found in Session object (Extended Tunnel ID field), and the LSP ID, which can be found in the Session object (Tunnel ID field).

Note: the LSP ID field in the Sender Template object should not be used as this can be changed during the life of the LSP!

Yours,
-Shahram

> -----Original Message-----
> From: Yuan Gu [mailto:[email-masked]]
> Sent: Thursday, April 19, 2001 4:18 PM
> To: mpls
> Subject: LSP ID
> 
> 
> Hello:
> 
> I have some questions about LSP ID of  rsvp-tunnel comparing the one
> defined in cr-ldp:
> 
> In draft-ietf-mpls-cr-ldp-05.txt  section 4.5 LSP ID TLV:
> 
> "LSPID is a unique identifier of a CR-LSP within an MPLS network.
> The LSPID is composed of the ingress LSR Router ID (or any of its own
> Ipv4 addresses) and a Locally unique CR-LSP ID to that LSR."
> 
> It's very clear. I have no doubt.
> 
> But In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt section: 4.6.2.1:
> 
> "LSP ID
> 
>          A  16-bit  identifier  used  in  the  
> SENDER_TEMPLATE  and  the
> 
>          FILTER_SPEC  that  can  be  changed  to allow a 
> sender to share
> 
>          resources with itself."
> 
> My question are:
> Is this LSP ID Locally unique?
> What's mean of  "it can be changed to allow a sender to share 
> resources
> with itself"?
> In RSVP-LSP-tunnel, how can we unique identify a LSP within an MPLS
> network? Is it enough to use  "LSP ID + sender node address" 
> to identify
> it? Is there any specification about it?
> 
> Best Regards!
> Yuan
>

---

From: Yuan Gu <[email-masked]>
Date: Thu, 19 Apr 2001 17:34:48 -0400

Hi, Shahram:

Thanks for your answer.

Could you tell me the specification from which your answer is getten? As far as I understanding, you are talking about identification of a TE-tunnel i.s.o a LSP (please ref rsvp-lsp-tunnel-08, section 2.1). Within one
TE-tunnel(destination address+tunnel ID), we can setup multipul LSPs.
And could you explain in which case the LSP ID will be changed?

Best Regards!
Yuan

---

From: David Charlap <[email-masked]>
Date: Thu, 19 Apr 2001 19:46:19 -0400

Shahram Davari wrote:
> 
> In RSVP-TE, an LSP could be uniquely identified by the combination
> of Ingress Router ID, which can be found in Session object (Extended
> Tunnel ID field), and the LSP ID, which can be found in the Session
> object (Tunnel ID field).

Not quite.

The LSP ID field is only guaranteed unique within a single session.

A single sender may use the same LSP ID for different LSPs in different
sessions.

If all routers use the sender address as extended tunnel-ID, then you
can identify an LSP with the 4-tuple of tunnel-endpoint address, tunnel
ID, sender address and LSP ID.

But you can't ever be certain of this.  It is perfectly legal for
routers to use an extended tunnel ID of zero ("don't care") - making it
possible to share resources with LSPs that originate from multiple
points.  Because of this, you really need the full 5-tuple (the above
parameters plus extended tunnel ID) in order to uniquely identify an
LSP.

-- David

---

From: Senthil Venkatachalam <[email-masked]>
Date: Mon, 23 Apr 2001 18:34:04 -0400

Hi David,

Please see my comments at the end.

> parameters plus extended tunnel ID) in order to uniquely identify an

The MPLS TE MIB describes the Tunnel Ingress LSR ID as follows:

mplsTunnelIngressLSRId OBJECT-TYPE
   SYNTAX        MplsLsrId
   MAX-ACCESS    accessible-for-notify
   STATUS        current
   DESCRIPTION
        "The purpose of this object is to uniquely identity a
          tunnel within a network. When the MPLS signalling
          protoocol is rsvp(2) this value should mimic the
          Extended Tunnel Id field in the Session object.
          When the MPLS signalling protoocol is crldp(3) this
          value should mimic the Ingress LSR Router ID field
          in the LSPID TLV object."
   REFERENCE
        "1. RSVP-TE: Extensions to RSVP for LSP Tunnels,
          Awduche et al, Internet Draft <draft-ietf-mpls-rsvp-
          lsp-tunnel-07.txt>, August 2000.,
         2. Constraint-Based LSP Setup using LDP, Jamoussi,
          Internet Draft <draft-ietf-mpls-cr-ldp-04.txt>,
          July 2000."
   ::= { mplsTunnelEntry 3 }

The MIB clearly indicates that the extended Tunnel ID should be
the same as the mplsTunnelIngressLSRId. Is it still necessary for
the Extended Tunnel ID to be a key?

If this were another key, then shouldn't the mplsTunnelTable have
the Extended Tunnel ID as another index?
(As it stands, mplsTunnelTable is indexed by:
mplsTunnelIndex, mplsTunnelInstance,
mplsTunnelIngressLSRId, mplsTunnelEgressLSRId)

Regards,
Senthil.

--
Senthil K. Venkatachalam     [email-masked]
Off#:, MBox:                 (703) 679-6435 [Off]
Alcatel USA                  (703) 679-6450 [Fax]
__________________________________________________________________

---

From: David Charlap <[email-masked]>
Date: Mon, 23 Apr 2001 18:38:38 -0400

> the Extended Tunnel ID to be a key?

Then there is potential for conflict between the TE MIB and RSVP-TE
itself.  If the extended tunnel ID and sender address do not match, then
there is no way to properly represent the LSP in the MIB table.

RSVP-TE (including the latest drafts) says (section 4.6.1.1):

	Extended Tunnel ID

	A 32-bit identifier used in the SESSION that remains
	constant over the life of the tunnel.  Normally set to all
	zeros.	Ingress nodes that wish to narrow the scope of a
	SESSION to the ingress-egress pair may place their IPv4
	address here as a globally unique identifier.

It is clear that the use of an all-zeros extended tunnel ID is valid. 
It is even documented as the default case.

The fact that the all-zeros value is not commonly used does not change
the fact that it is a legal value.  An RSVP-TE-specific MIB table (which
has not been specified, apparently) must take this into consideration.

> mplsTunnelIngressLSRId, mplsTunnelEgressLSRId)

I can only assume that the TE MIB was based upon the features of RSVP-TE
that are commonly in use, and can not fully accomodate all of its
features.

If someone build a router that supports multipoint-to-point LSPs using
RSVP-TE, the TE MIB will have to be updated, or that implementation will
be unable to properly represent these kinds of LSPs using it.

-- David