The MPLS WG Archive

["Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>]

Yuan,
The LSP Identifier for RSVP-TE is considered to be a 5 tuple  -
ingressLSRID+egressLSRID+tunnelid+lspid+ Extended tunnel ID.

Though the extended tunnel ID is usually zero or the ingress LSRID, it could
be any IP address of the ingress LSR. Discussions on this have happened in
this list.

Regards,
Vijay 

-----Original Message-----
From: Yuan Gu [mailto:YuanGu@ipinfusion.com]
Sent: Saturday, October 19, 2002 12:53 AM
To: jcucchiara@mindspring.com; Thomas D. Nadeau; cheenu@paramanet.com;
arun@force10networks.com; hans@ipunplugged.com
Cc: mpls group
Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt


Joan:

Thanks for you reply.

For LspID which is defined in XC table, it's still worth to have it because
some vendors might not support TE mib and want to show which LSP makes the
cross connection. The problem is that the current MplsLSPId definition can't
uniquely identify an LSP for RSVP-TE case. Then, we need to extend MplsLSPId
concept to make it not limited by lspid defined in SenderTemple of RFC3209.
For RSVP-TE case, I believe we can define MplsLSPId as
ingressLSRID+egressLSRID+tunnelid+lspid (similar as CRLDP definition). By
this way, LSR mib will have a unique identification of LSP which makes
insegment, XC and outsegment entries.

Please let me know your thought.

Regards!
Yuan

-----Original Message-----
From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
Sent: Friday, October 18, 2002 11:59 AM
To: Yuan Gu; Thomas D. Nadeau; cheenu@paramanet.com;
arun@force10networks.com; hans@ipunplugged.com
Cc: mpls group
Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt



Hi Yuan,

At 01:56 PM 10/17/02 -0700, Yuan Gu wrote:
>
>>Although, it may be necessary to clarify this a tad, I don't
>>believe there is a conflict.  Perhaps, this description
>>should simply state:
>>For RSVP, the MplsLSPId is the "LSP ID" as defined in RFC3209.
>
>Then for RSVP-TE, what's the sense to define LSP ID in XC table? This two
>bytes LSPID can't identify an unique LSP. Don't need to mention transit
>node, even within single ingress node it's not unique right?
>

Okay, I think I see your point.
The object does allow an operator to configure the
LSP-ID, (and show the LSPID in the transit situation).
Also, this object is optional so doesn't need to be supported by
the agent.

Do you think this object is not worth having in this table at all,
even optionally?

 Thanks, Joan