The MPLS WG Archive

[jcucchiara@mindspring.com]

At 11:19 AM 10/17/02 -0700, Yuan Gu wrote:
>Dear MPLS-TC-MIB authors:

Yuan,

Please note my email address has changed and is now:
jcucchiara@mindspring.com.

>
>Could you please give me a clearify of my following questions? From my point
>of view, the MplsLSPID defined in this MIB obvoiusly conflict with the
>RSVP-TE LSP identification principle. What do you think?

I do not believe this conflicts, as I said before.

>
>Regards!
>Yuan
>
>-----Original Message-----
>From: Yuan Gu [mailto:YuanGu@ipinfusion.com]
>Sent: Monday, October 14, 2002 11:11 AM
>To: mpls group
>Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt
>
>
>Hi:
>
>I have two questions of MplsLSPID defined in this MIB:
>
>1. It states in this MIB:
>(MplsLSPId): "A unique identifier within an MPLS network that is assigned to
>each LSP. This is assigned at the head end of the LSP and can be used by all
>LSRs to identify this LSP...For LSPs signaled using RSVP-TE, the LSP ID is
>defined as a 16-bit (2 byte) identifier used in the SENDER_TEMPLATE..."
>My question is: How does a head end LSR assign a "MPLS network unique" LSPID
>for a LSP in case the signaling is RSVP-TE? In RFC3209, it says: "The
>SENDER_TEMPLATE object together with the session object uniquely identifies
>an LSP tunnel." Does MplsLSPId definition conflict with RFC3209?

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.  

The reason that I believe there is no conflict is because if there
is a reroute, a new LSP ID is created by the ingress node and
thus a new SENDER_TEMPLATE.  This new SENDER_TEMPLATE along with the
original SESSION object is used in establishing a new LSP.

>
>2. A "mplsXCLspId" object is defined in XC table of LSR MIB while MplsLSPId
>is only used for CR-LDP and RSVP-TE. My question is: In case of LDP, how do
>we populate mplsXCLspID's value?
>

In the case of LDP it does not apply.  Since the mplsXCLspId object is
optional in the conformance statements, the easiest thing is to not support
this object at all.  Thus, you don't have to worry about a valid value for it.

-Joan


>Thanks for your reply!
>
>Yuan
>IP Infusion
>
>-----Original Message-----
>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
>Internet-Drafts@ietf.org
>Sent: Monday, October 14, 2002 4:26 AM
>To: IETF-Announce:
>Cc: mpls@UU.NET
>Subject: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Multiprotocol Label Switching Working Group
>of the IETF.
>
>	Title		: Definitions of Textual for Multiprotocol Label
>                          Switching (MPLS) Management
>	Author(s)	: T. Nadeau et al.
>	Filename	: draft-ietf-mpls-tc-mib-04.txt
>	Pages		: 18
>	Date		: 2002-10-11
>
>This memo describes Textual Conventions for use in definitions of
>management information for Multiprotocol Label Switching (MPLS)
>networks.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-04.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-ietf-mpls-tc-mib-04.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	mailserv@ietf.org.
>In the body type:
>	"FILE /internet-drafts/draft-ietf-mpls-tc-mib-04.txt".
>
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>