The MPLS WG Archive

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

Going back to RFC1213...
   (5)  To avoid redundant variables, it was required that no
        object be included that can be derived from others in the
        MIB.
[...]
   MIB-II, like its predecessor, the Internet-standard MIB, contains
   only essential elements.  There is no need to allow individual
   objects to be optional.  Rather, the objects are arranged into the
   following groups:
      - System
      - Interfaces
      - Address Translation (deprecated)
      - IP
      - ICMP
      - TCP
      - UDP
      - EGP
      - Transmission
      - SNMP

   These groups are the basic unit of conformance: This method is as
   follows: if the semantics of a group is applicable to an
   implementation, then it must implement all objects in that group.
   For example, an implementation must implement the EGP group if and
   only if it implements the EGP.


It sounds like you're saying you are interested in a scenario where
a device has IP addresses but is not compliant with RFC 1213
which requires that it implement both the ipAddrTable and the ifTable.
Is that correct?

-Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Wednesday, October 22, 2003 3:23 PM
> To: Dave Thaler; 'Martin Dubuc'
> Cc: 'Bert Wijnen'; 'Sudheer Dharanikota'; 'Jonathan Lang'; 'Loa
> Andersson'; 'Mpls (E-mail)'
> Subject: RE: DT's review of draft-ietf-mpls-telink-mib-04.txt
> 
> 
> 	Because it is possible that the others are not
> implemented.  Because of the minimal duplication,
> this seems reasonable.
> 
> 	--Tom
> 
> 
> >-----Original Message-----
> >From: Dave Thaler [mailto:dthaler@windows.microsoft.com]
> >Sent: Wednesday, October 22, 2003 2:02 PM
> >To: Martin Dubuc
> >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
> >
> >
> >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
> >