The MPLS WG Archive[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
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 > > > > >
|
|