The MPLS WG Archive

[Joan Cucchiara <jcucchia@CrescentNetworks.com>]

Hello Yuan,

Yuan Gu wrote:
> 
> I didn't receive any reply yet. Does anyone have any clue?
> 
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yuan Gu
> 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?

The LSP ID portion of the Session object, does uniquely identify the 
specific Tunnel (see section 2.5 of that same spec).

> 
> 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?

I do not believe it is necessary to give this object a value for LDP.
The conformance statement makes this object optional.

  -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.