The MPLS WG Archive

["Yuan Gu" <yuangu@ipinfusion.com>]

Joan:

Do you have any result of your discussion?

Regards!
Yuan

> -----Original Message-----
> From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
> Sent: Monday, October 21, 2002 7:18 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,
>
> 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
> >
> >
> >
> >
> >
>