Subject: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt

From: "Yuan Gu" <[email-masked]>
Date: Thu, 17 Oct 2002 11:19:34 -0700

Dear MPLS-TC-MIB authors:

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?

Regards!
Yuan

-----Original Message-----
From: Yuan Gu [mailto:[email-masked]]
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?

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?

Thanks for your reply!

Yuan
IP Infusion

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Monday, October 14, 2002 4:26 AM
To: IETF-Announce:
Cc: [email-masked]
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:
	[email-masked].
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.

---

From: [email-masked]
Date: Thu, 17 Oct 2002 16:49:54 -0400

>Dear MPLS-TC-MIB authors:

Yuan,

Please note my email address has changed and is now:
[email-masked].

>RSVP-TE LSP identification principle. What do you think?

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

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

>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

---

From: "Yuan Gu" <[email-masked]>
Date: Thu, 17 Oct 2002 13:56:37 -0700

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

---

From: [email-masked]
Date: Fri, 18 Oct 2002 14:59:12 -0400

Hi Yuan,

>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

---

From: "Yuan Gu" <[email-masked]>
Date: Fri, 18 Oct 2002 12:22:40 -0700

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: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 18, 2002 11:59 AM
To: Yuan Gu; Thomas D. Nadeau; [email-masked];
[email-masked]; [email-masked]
Cc: mpls group
Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt

Hi Yuan,

 Thanks, Joan

---

From: [email-masked]
Date: Mon, 21 Oct 2002 10:18:08 -0400

Hi Yuan,

I will take your suggestion and discuss it
with the co-authors of the LSR MIB. 

Thanks, Joan