The MPLS WG Archive

["Dave Thaler" <dthaler@windows.microsoft.com>]

Great.  In that case why have redundant objects at all?

-Dave

> -----Original Message-----
> From: Martin Dubuc [mailto:dubuc.consulting@rogers.com]
> Sent: Wednesday, October 22, 2003 4:32 AM
> To: Dave Thaler
> Cc: Thomas Nadeau; Bert Wijnen; Sudheer Dharanikota; Jonathan Lang; 
> Loa Andersson; Mpls (E-mail)
> Subject: Re: DT's review of draft-ietf-mpls-telink-mib-04.txt
> 
> Dave,
> 
> The TE link MIB makes extensive use of the interface table. Our 
> specification relies on this part of MIB-II.
> 
> I will add text in the DESCIRPTION clause to emphasize the 
> relationship between teLinkLocalIpAddr and ipAddrTable.
> 
> Martin
> 
> ----- Original Message -----
> From: "Dave Thaler" <dthaler@windows.microsoft.com>
> To: "Martin Dubuc" <dubuc.consulting@rogers.com>
> Cc: "Thomas Nadeau" <tnadeau@cisco.com>; "Bert Wijnen" 
> <bwijnen@lucent.com>; "Sudheer Dharanikota" <sudheer@ieee.org>; 
> "Jonathan Lang" <jplang@ieee.org>;
> "Loa Andersson" <loa@pi.se>
> Sent: Tuesday, October 21, 2003 4:12 PM
> Subject: RE: DT's review of draft-ietf-mpls-telink-mib-04.txt
> 
> 
> > -----Original Message-----
> > From: Martin Dubuc [mailto:dubuc.consulting@rogers.com]
> [...]
> > ----- Original Message -----
> > From: "Dave Thaler" <dthaler@windows.microsoft.com>
> > To: <tnadeau@cisco.com>; "Martin Dubuc" 
> > <dubuc.consulting@rogers.com>; "Wijnen, Bert (Bert)" 
> > <bwijnen@lucent.com>; <sudheer@ieee.org>; <jplang@ieee.org>
> > Sent: Monday, October 06, 2003 10:11 PM
> > Subject: RE: DT's review of draft-ietf-mpls-telink-mib-04.txt
> >
> >
> > Sorry for the delay, but I've been reading a bunch of relevant
> documents
> > so I can help resolve the issue.  Besides the mpls-telink-mib and 
> > the tewg-mib, I've now read all of the following in entirety:
> >
> > [RFC2702] "Requirements for Traffic Engineering Over MPLS" [OSPF-TE]

> > "Traffic Engineering Extensions to OSPF Version 2" [LSP-HIER] "LSP 
> > Hierarchy with Generalized MPLS TE" [BUNDLE] "Link Bundling in MPLS 
> > Traffic Engineering" [GMPLS-ROUTING] "Routing Extensions in Support 
> > of Generalized MPLS"
> >
> > as well as some portions of other documents such as 
> > [MPLS-TE-STD-MIB] and [GMPLS-ARCH].
> >
> > Even after all that, the address model was not really cleared up for
> me.
> > [LSP-HIER], [OSPF-TE], and [BUNDLE] all contain language related to 
> > the local and remote IP address.
> >
> > I'm back to my original question about:
> > > it is unclear whether the IP addresses are those used for 
> > > encapsulation (i.e. like MAC addresses from the point of view of 
> > > the teLink interface), or those assigned to the inside. I'm 
> > > assuming the former, since the latter would definitely be
> > redundant
> > > with the inet address table like on any other interface.
> >
> > In the email below I had assumed the former.  After reading the 
> > documents above, I'm more inclined to believe it's the latter. Can 
> > someone confirm this?  Put another way:
> >
> > Q: If you look in the ipAddrTable for the corresponding entry for 
> > the
> IP
> > address in a teLinkLocalIpAddr object on a numbered TE link, what is
> the
> > value of ipAdEntIfIndex?  What is the relationship of that interface
> to
> > the TE link?
> > (e.g. in the example on page 12, is it the ifIndex of the mpls 
> > interface, the teLink interface, or the opticalTransport interface?

> > Previously I had assumed the answer would be the opticalTransport 
> > interface, but
> now
> > I'm more inclined to believe it's one of the others in which case 
> > Thomas' summary of my misunderstanding below would be more or less 
> > accurate. In any case, none of the documents listed above give a 
> > clear answer to this question.)
> >
> > [Martin] You are right, it is the latter. The IP address is the IP
> address
> > of
> > the teLink interface. It is redundant with ipAddrTable, but we would
> like
> > not
> > to have to rely on the presence of ipAddrTable to get access to this

> > information.
> 
> Martin, thanks much for the confirmation.  I'm curious about your last

> statement though.  Are you concerned about implementing this MIB on 
> systems which do not implement MIB-II?
> 
> If you do need redundant objects for some reason, then it would be 
> good for the DESCRIPTION clause to mention that it is in fact 
> redundant, so implementers can ensure both objects have the same 
> value.
> 
> -Dave