[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: Agenda and Package for December 4, 2003 Telechat

On Thu, 27 Nov 2003, Wijnen, Bert (Bert) wrote:
> If you have time between now and next wednesday (6pm EST),
> pls review (from OPS perspective) the following documents
> on the IESG agenda.
...
>   o draft-ietf-ipv6-rfc2096-update-05.txt
>     IP Forwarding Table MIB (Proposed Standard) - 9 of 14
>     Token: Thomas Narten

Bert, since this MIB module was developed in one of the WGs whose
mailing list traffic you don't normally monitor, and since I
followed the development of this MIB module and did a MIB doctor
review for it, I'll provide a technical summary in support of the
case for advancing this document as it stands to Proposed Standard.

The MIB module in this document provides IP version-neutral
replacement for equivalent IPv4-specific stuff in RFCs 2096 and
2011/1213 and makes some minor technical improvements to some of the
definitions.  The correspondence between the old objects and their
replacements is as follows:

Old Object(s)                    Replacement Object(s)
-------------                    ---------------------
ipCidrRouteNumber (RFC 2096)     inetCidrRouteNumber
ipRoutingDiscards (RFC 2011)     inetCidrRouteDiscards
ipCidrRouteTable  (RFC 2096)     inetCidrRouteTable
 ipCidrRouteDest*                 inetCidrRouteDestType/inetCidrRouteDest*
 ipCidrRouteMask*                 inetCidrRoutePfxLen*
 ipCidrRouteTos*                  inetCidrRoutePolicy*
 ipCidrRouteNextHop*              inetCidrRouteNextHopType/inetCidrRouteNextHop*
 ipCidrRouteIfIndex               inetCidrRouteIfIndex
 ipCidrRouteType                  inetCidrRouteType
 ipCidrRouteProto/ipCidrRouteInfo inetCidrRouteProto
 ipCidrRouteAge                   inetCidrRouteAge
 ipCidrRouteNextHopAS             inetCidrRouteNextHopAS
 ipCidrRouteMetric1               inetCidrRouteMetric1
 ipCidrRouteMetric2               inetCidrRouteMetric2
 ipCidrRouteMetric3               inetCidrRouteMetric3
 ipCidrRouteMetric4               inetCidrRouteMetric4
 ipCidrRouteMetric5               inetCidrRouteMetric5
 ipCidrRouteStatus                inetCidrRouteStatus

In the list above '*' denotes a (pair of) table index component(s).

As should be clear from glancing at this list, the major changes
were to replace the IPv4-specific objects with conceptually
equivalent version-neutral ones using the TCs in RFC 3291.  The
replacement of ipCidrRouteTos (of type Integer32) by
InetCidrRoutePolicy (of type OBJECT IDENTIFIER) was in the same
spirit: TOS as a route policy selector has been deprecated as a
result of the Diffserv effort, and it has been replaced with an
object that is capably of representing arbitrary policy selectors.

There are also a number of minor technical improvements/changes
that are not obvious from the summary list.  These include:

- The inetCidrRouteEntry DESCRIPTION clause now stipulates that
dynamically created rows will survive an agent reboot.

- Previously, ipCidrRouteIfIndex had a SYNTAX of Integer32 and was
allowed to be set to zero to indicate that there was no relevant
ifTable entry (indeed, this was the default, as zero was the
DEFVAL).  That is no longer allowed: inetCidrRouteIfIndex has
a SYNTAX of InterfaceIndex and no longer specifies a DEFVAL.

- In the definition of inetCidrRouteType the semantics of the
value reject(2) were changed to specify that routes of this
type return a notification to the sender when a packet is
discarded, and a new value blackhole(5) was added for routes
that discard traffic silently.

- The definition of inetCidrRouteProto uses the TC
IANAipRouteProtocol in the SYNTAX clause instead of an in-line
enumeration.  This allows values to be added without revising the
MIB module (note that the value dvmrp is a post-RFC 2096 addition).

- The base type of inetCidrRouteAge is now Gauge32 instead of
Integer32 and the DEFVAL of 0 was removed.

- The definition of inetCidrRouteNextHopAS uses the TC
InetAutonomousSystemNumber in the SYNTAX clause instead
of Integer32.

- The DESCRIPTION clause of inetCidrRouteStatus now stipulates that
a row entry cannot be modified when the status is active(1).

It is worth mentioning a couple of points because they required
some discussion in the WG to resolve.

- At one point ipCidrRouteNumber was deprecated without providing
the replacement object inetCidrRouteNumber, on the grounds that
scalars such as this one are difficult to implement in distributed
agents.  It was argued that the difficulty of implementing this
object is not actually very great even for a distributed agent but
that is absence would cause a great burden for management systems.
Hence inetCidrRouteNumber was reinstated.

- There were objections from some people to deprecating
ipRoutingDiscards in favor of inetCidrRouteDiscards, on the grounds
that ipRoutingDiscards (according to its DESCRIPTION clause)
already provides the desired functionality.  However, it was
pointed out that the de-facto practice for implementations of RFC
2465 is to use this object to count only IPv4 discarded routes
because RFC 2465 has the IPv6-specific object ipv6DiscardedRoutes.
In view of the semantic ambiguity that would result from re-use of
ipRoutingDiscards it was conceded that the correct course was to
define a new object with unambiguous semantics.

A copy of the MIB review that I did back in August is attached.

In closing, let me say that I have implemented the old version of
the MIB module in RFC 2096 and I found it to be technically sound.
I think that the new version, being conceptually similar, is equally
sound and that the changes are all reasonable ones.

//cmh
--- Begin Message --- 
Greetings,

I have reviewed draft-ietf-ipv6-rfc2096-update-05.txt, and I believe
that the document is now ready to proceed to IETF last call.  In
particular, I have verified that all requested changes have been
made (both the ones discussed in the presentation slides for the
Vienna IETF and the ones recommended in previous reviews), and I
have gone back through the MIB review checklist (Appendix A of
<draft-ietf-ops-mib-review-guidelines-02.txt>) to make sure that no
new problems have been introduced.  Here are the checklist results:

1.) I-D Boilerplate -- OK

2.) Abstract -- OK

3.) MIB Boilerplate -- OK

4.) IPR Notices -- OK

5.) References -- OK

6.) Security Considerations Section -- excellent, statements
of vulnerabilities are well though out.

7.) IANA Considerations Section -- OK (none present and
none required).

8.) Copyrights -- OK

9.) Other issues (i.e., stuff in http://www.ietf.org/ID-nits.html
other than MIB compilation issues) -- OK

10.) Technical content -- the MIB design appears to be sound, and
the MIB compilation results from smilint and smidiff appear to be
satisfactory.  The results from smilint are as follows:

This command (smilint 0.4.2-pre1, as of Tue Aug 05 15:58:53 2003)
has been processed to get the following results:
smilint -m -s -l 6 rfc2096-update-05.mi2

rfc2096-update-05.mi2:1060: [4] {hyphen-in-label} warning: named
number `is-is' must not include a hyphen in SMIv2
rfc2096-update-05.mi2:1061: [4] {hyphen-in-label} warning: named
number `es-is' must not include a hyphen in SMIv2
rfc2096-update-05.mi2:203: [5] {index-element-no-size} warning:
index element `inetCidrRoutePolicy' of row `inetCidrRouteEntry'
should but cannot have a size restriction
rfc2096-update-05.mi2:115: [5] {index-exceeds-too-large} warning:
index of row `inetCidrRouteEntry' can exceed OID size limit by 527
subidentifier(s)
rfc2096-update-05.mi2:517: [5] {index-element-accessible} warning:
index element `ipCidrRouteDest' of row `ipCidrRouteEntry' should be
not-accessible in SMIv2 MIB
rfc2096-update-05.mi2:517: [5] {index-element-accessible} warning:
index element `ipCidrRouteMask' of row `ipCidrRouteEntry' should be
not-accessible in SMIv2 MIB
rfc2096-update-05.mi2:517: [5] {index-element-accessible} warning:
index element `ipCidrRouteTos' of row `ipCidrRouteEntry' should be
not-accessible in SMIv2 MIB
rfc2096-update-05.mi2:517: [5] {index-element-accessible} warning:
index element `ipCidrRouteNextHop' of row `ipCidrRouteEntry' should
be not-accessible in SMIv2 MIB
rfc2096-update-05.mi2:875: [5] {index-element-accessible} warning:
index element `ipForwardDest' of row `ipForwardEntry' should be
not-accessible in SMIv2 MIB
rfc2096-update-05.mi2:875: [5] {index-element-accessible} warning:
index element `ipForwardProto' of row `ipForwardEntry' should be
not-accessible in SMIv2 MIB
rfc2096-update-05.mi2:875: [5] {index-element-accessible} warning:
index element `ipForwardPolicy' of row `ipForwardEntry' should be
not-accessible in SMIv2 MIB
rfc2096-update-05.mi2:875: [5] {index-element-accessible} warning:
index element `ipForwardNextHop' of row `ipForwardEntry' should be
not-accessible in SMIv2 MIB

Most of these diagnostics are from the deprecated parts of the MIB
module and can be safely ignored.  The ones that pertain to the new
parts of the MIB modue are those for lines 115 and 203.  The former
warns that it is theoretically possible for the OIDs of column
instances in inetCidrRouteEntry to exceed the 128 sub-identifier
limit imposed by the SMI and the SNMP by as many as 527
subidentifiers.  This is dealt with by the warning to implementors
in the inetCidrRouteEntry DESCRIPTION clause that the aggregate size
of the index components inetCidrRouteDest, inetCidrRoutePolicy, and
inetCidrRouteNextHop must not exceed 111 components.  The diagnostic
for line 203 is just a warning that the object identifier-valued
index column inetCidrRoutePolicy does not have a SIZE constraint.
Since the SMI does not allow such constraints, this warning can and
should be ignored.  In other words, there are no problems revealed
by the smilint report.

The smidiff report, excluding diagnostics that are merely
informational, is as follows:

rfc2096-update-05.mi2:953 [3] {to-implicit} implicit type for
`ipForwardPolicy' replaces type `Integer32'
rfc2096-update-05.mi2:953 [3] {range-added} range `(0..2147483647)'
added to type used in `ipForwardPolicy'
rfc2096-update-05.mi2:594 [3] {to-implicit} implicit type for
`ipCidrRouteTos' replaces type `Integer32'
rfc2096-update-05.mi2:594 [3] {range-added} range `(0..2147483647)'
added to type used in `ipCidrRouteTos'

The objects in question are index objects that were originally not
explicitly constrained to have non-negative values;  however, this
constraint is implicit, since index objects cannot be negative.
Since these changes do not change the semantics they are considered
to be editorial (see <draft-ietf-ops-mib-review-guidelines-02.txt>
section 4.9).  In other words, there is no problem.

This concludes the review of draft-ietf-ipv6-rfc2096-update-05.txt.

Regards,

Mike Heard

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

--- End Message ---