The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Oct> msg00108



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: jcucchiara@mindspring.com
  • Date: Mon, 21 Oct 2002 10:18:08 -0400
  • Cc: "mpls group" <mpls@UU.NET>


Hi Yuan,

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

Thanks, Joan


At 12:22 PM 10/18/02 -0700, Yuan Gu wrote:
>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
>
>
>
>
>