The MPLS WG Archive

["Martin Dubuc" <dubuc.consulting@rogers.com>]

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