Subject: RE: DT's review of draft-ietf-mpls-telink-mib-04.txt

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 22 Oct 2003 22:07:32 -0400

>-----Original Message-----
>From: Dave Thaler [mailto:[email-masked]] 
>Sent: Wednesday, October 22, 2003 6:28 PM
>To: [email-masked]; 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
>
>
>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?

	Yes.

	--Tom

>-Dave
>
>> -----Original Message-----
>> From: Thomas D. Nadeau [mailto:[email-masked]]
>> 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:[email-masked]]
>> >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:[email-masked]]
>> >> 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" <[email-masked]>
>> >> To: "Martin Dubuc" <[email-masked]>
>> >> Cc: "Thomas Nadeau" <[email-masked]>; "Bert Wijnen"
>> >> <[email-masked]>; "Sudheer Dharanikota" <[email-masked]>;
>> >> "Jonathan Lang" <[email-masked]>;
>> >> "Loa Andersson" <[email-masked]>
>> >> 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:[email-masked]]
>> >> [...]
>> >> > ----- Original Message -----
>> >> > From: "Dave Thaler" <[email-masked]>
>> >> > To: <[email-masked]>; "Martin Dubuc"
>> >> > <[email-masked]>; "Wijnen, Bert (Bert)"
>> >> > <[email-masked]>; <[email-masked]>; <[email-masked]>
>> >> > 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
>> >
>

---

From: "Dave Thaler" <[email-masked]>
Date: Wed, 22 Oct 2003 15:28:23 -0700

Going back to RFC1213...

-Dave

> >> Cc: Thomas Nadeau; Bert Wijnen; Sudheer Dharanikota; Jonathan Lang;
> >> > so I can help resolve the issue.  Besides the mpls-telink-mib and
"LSP
of
Can
> >> > Q: If you look in the ipAddrTable for the corresponding entry for
> >> > the
> >> IP
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
less
IP
> >> statement though.  Are you concerned about implementing this MIB on