Re: minutes of RIPv2 meeting in Amsterdam

Fred Baker <fbaker@acc.com> Wed, 04 August 1993 02:05 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16625; 3 Aug 93 22:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16621; 3 Aug 93 22:05 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa24975; 3 Aug 93 22:05 EDT
Received: by atlas.xylogics.com id AA23360 (5.65c/UK-2.1-930726); Tue, 3 Aug 1993 22:05:57 -0400
Received: from SAFFRON.ACC.COM by atlas.xylogics.com with SMTP id AA03471 (5.65c/UK-2.1-930726); Tue, 3 Aug 1993 22:05:42 -0400
Received: by saffron.acc.com (4.1/SMI-4.1) id AA05646; Tue, 3 Aug 93 16:09:58 PDT
Date: Tue, 3 Aug 93 16:09:58 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <fbaker@acc.com>
Message-Id: <9308032309.AA05646@saffron.acc.com>
To: gmalkin@xylogics.com, jch@nr-tech.cit.cornell.edu
Subject: Re: minutes of RIPv2 meeting in Amsterdam
Cc: ietf-rip@xylogics.com

>> > There were two proposed changes to the MIB.  The first was to deprecate
>> > the Routing Domain object.  It has been pointed out that the tables
>> > cannot be indexed correctly unless the Routing Domain object was used
>> > as part of the index.  Given that the Routing Domain field is not well
>> > defined, this change will result in an overall simplification of the
>> > MIB.  The second proposal dealt with handling unnumbered interfaces.
>> > While the RIP-2 protocol does not expressly address them, their
>> > existance does require consideration since the MIB tables cannot be
>> > indexed properly with unnumbered interfaces.  The proposal is to use a
>> > network number of zero and a host number of if_index to create a
>> > suitable IP address for use in indexing tables.  These changes do not,
>> > to the knowledge of those attending the meeting, invalidate any
>> > existing implementations and may therefore be made without requiring
>> > the specification to remain at the Proposed Standard level.
>> 
>> Come on now, this is a hack, the interface index is not an IP address.
>> What if the subnet mask was 30 bits long, but I had 10 interfaces?
>> Interfaces that require an index to identify them do not necessarily
>> have not have an IP address, and I for one would like to see that
>> address.

It is true that 0.0.0.ifIndex is not an IP address; it is precisely this
fact that makes it distinguishable from a numbered link's address. The
point is to have a way to identify the entry associated with the interface
(which is supplied by the IP Address in the other case).

This is only minorly different from what is done in the OSPF MIB, which you
had proposed that we emulate. The "IP Address" in that case is always
0.0.0.0, and a fifth integer contains the ifIndex value for the interface.

>> Why hack something up just to push the MIB through to proposed
>> standard when there are not any implementions.

The approach here is not the acceptance of a hack to save some effort, it
is the definition of a content rather than redoing the MIB in a case where
redoing the MIB is not clearly justified. Do you realy have a device with
more than 2^24 unnumbered interfaces?

Nobody's going to do an implementation unless the thing's a proposed
standard.