The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] DT's review of draft-ietf-mpls-telink-mib-04.txt
>-----Original Message----- >From: Dave Thaler [mailto:dthaler@windows.microsoft.com] >Sent: Wednesday, October 22, 2003 6:28 PM >To: tnadeau@cisco.com; 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: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 >> > >
|
|