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

From: "Thomas D. Nadeau" <[email-masked]>
Date: Sun, 03 Nov 2002 21:53:27 -0500

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

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 04 Nov 2002 14:02:38 -0500

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

>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On Behalf Of Thomas D. 
>>Nadeau
>>Sent: Sunday, November 03, 2002 6:53 PM
>>To: Yuan Gu
>>Cc: [email-masked]; [email-masked]; 
>>[email-masked]; [email-masked]; [email-masked]; 
>>mpls group
>>Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt
>>
>>
>>
>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

---

From: "Yuan Gu" <[email-masked]>
Date: Tue, 26 Nov 2002 18:27:57 -0800

Joan:

Do you have any result of your discussion?

Regards!
Yuan

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 21, 2002 7:18 AM
> To: Yuan Gu; Thomas D. Nadeau; [email-masked];
> [email-masked]; [email-masked]
> Cc: mpls group
> 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
> >
> >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
> >Hi Yuan,
> >At 01:56 PM 10/17/02 -0700, Yuan Gu wrote:
> >>
> >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
> >
> >
> >
> >
> >
>