The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

At 08:24 AM 11/4/2002 -0500, Yuan Gu wrote:

>>-----Original Message-----
>>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Thomas D. 
>>Nadeau
>>Sent: Sunday, November 03, 2002 6:53 PM
>>To: Yuan Gu
>>Cc: jcucchiara@mindspring.com; jcucchiara@crescentnetworks.com; 
>>cheenu@paramanet.com; arun@force10networks.com; hans@ipunplugged.com; 
>>mpls group
>>Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt
>>
>>
>>
>> > >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?
>>
>>          The MPLS-LSR MIB has to (and does) work for all existing
>>applications of MPLS.  Because of this there may be overlaps between
>>the application-specific MIBs so that the MIB can work on its
>>own. My recollection is that this is probably one of the only cases of
>>that.  In defense of the redundant information, this information is
>>useful on LSRs where the MPLS-TE MIB might not be implemented
>>since one can still see the LSP for the tunnel.
>>
>>          --Tom
>
>Tom:
>
>I agree with you. What I suggested is that use multiple fields ( 
>ingressid+(extended ingress id)+egressid+tunnelid+lspid) to identify a 
>RSVP-TE LSP instead of only 2 bytes LSPID in MPLS-TC mib. Please refer my 
>early emails to Joan.

         What do you propose we do in cases where the LSP is not
a TE LSP?

         --Tom

Success is relative; the more success, the more relatives. -Anonymous