[Diffserv] Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)

["C. M. Heard" <[e-mail]>]

[ Note:  [e-mail] and [e-mail] have been bcc'd.
  Please direct followup discussion to [e-mail]  ]

On Thu, 16 Jan 2003, Bob Hinden wrote:
> This is a IPv6 working group last call for comments on advancing the
> following document as a Proposed Standard:
> 
>          Title           : IP Forwarding Table MIB
>          Author(s)       : M. Wasserman
>          Filename        : draft-ietf-ipv6-rfc2096-update-02.txt
>          Pages           : 30
>          Date            : 2002-11-7
> 
> Please send substantive comments to the ipng mailing list, and minor
> editorial comments to the document editor.  This last call period will
> end on January 30, 2003.

Thanks to Margaret Wasserman and Bob Hinden for forwarding this
last-call notice to the [e-mail] mailing list.  There
are three major issues upon which I would like to comment in this
message.  Minor comments (documentation nits and mib-doctor stuff)
will be dealt with in a separate message.

The major technical issues are these:

1.)  Appropriateness of using DSCP (differentiated services code
point) as a forwarding table index.

2.)  Appropriateness of offering only a full compliance statement
when all reported implementations of the predecessor MIB (RFC 2096)
provide just read-only access.

3.)  MIB changes that appear either to be gratuitous (replacing
ipRouteDiscards with inetCidrRouteDiscards) or erroneous
(not providing inetCidrRouteNumber) and which are inconsistent
with the text of Section 8.


Issue #1:  Appropriateness of using DSCP as forwarding table index
---------  -------------------------------------------------------

Synopsis:  I question the appropriateness of using the DSCP field
to represent routing policy, and I recommend replacing the
inetCidrRouteDscp object with a more generic inetCidrRoutePolicy
object.  I suggest that its SYNTAX be OBJECT IDENTIFIER for ease
of administration, but an integer-valued object could in principle
be made to serve the purpose.

Discussion:  in order to exhibit the proposed index structure
for the inetCidrRouteTable and to compare it with that of the
ipCidrRouteTable which it replaces, it is helpful to reproduce
the definition of inetCidrRouteEntry:

  inetCidrRouteEntry OBJECT-TYPE
      SYNTAX     InetCidrRouteEntry
      MAX-ACCESS not-accessible
      STATUS     current
      DESCRIPTION
             "A particular route to a particular destination, under a
              particular policy."
      INDEX {
          inetCidrRouteDestType,
          inetCidrRouteDest,
          inetCidrRoutePfxLen,
          inetCidrRouteDscp,
          inetCidrRouteNextHopType,
          inetCidrRouteNextHop
          }
      ::= { inetCidrRouteTable 1 }

This is intended to replace ipCidrRouteEntry, whose definition is:

  ipCidrRouteEntry OBJECT-TYPE
      SYNTAX   IpCidrRouteEntry
      ACCESS   not-accessible
      STATUS   current
      DESCRIPTION
         "A particular route to  a  particular  destina-
         tion, under a particular policy."
      INDEX {
          ipCidrRouteDest,
          ipCidrRouteMask,
          ipCidrRouteTos,
          ipCidrRouteNextHop
          }
      ::= { ipCidrRouteTable 1 }

The intended mapping is clear:

ipCidrRouteDest    -> <inetCidrRouteDestType, inetCidrRouteDest>
ipCidrRouteMask    -> inetCidrRoutePfxLen
ipCidrRouteTos     -> inetCidrRouteDscp
ipCidrRouteNextHop -> <inetCidrRouteNextHopType, inetCidrRouteNextHop>

It is obvious that ipCidrRouteDest, ipCidrRouteMask, and
ipCidrRouteNextHop are being replaced with generalized objects
that carry equivalent semantics but accomodate both IPv4 and
IPv6 addresses, and I have no issue with that.  The replacement
objects are indeed the "minimal change" replacements that they
were intended to be.

However, I do NOT think that inetCidrRouteDscp can be considered
a semantic equivalent to ipCidrRouteTos.  What ipCidrRouteTos
represented was the now-deprecated 4-bit Type of Service field,
i.e., the DTRC bits (bits 3-6 of the TOS octet) defined in RFC
791 and RFC 1349.  Note that it _excludes_ the three-bit Precedence
field (bits 0-2 of the TOS octet).  The TOS field had special
support in routing protocols, notably early versions of OSPF, and
was specifically intended to be used as a route selector.  The
Precedence field, however, had no such role.  Now, if I correctly
understand what I have read in RFC 2474 Section 4, the role played
by the DSCP field is a generalization of that the Precedence field
and maintains some backward compatibility with it, but it is in no
sense analogous to the old TOS field (DTRC bits).  For this reason
inetCidrRouteDscp does not qualify as a "minimal change" replacement
for ipCidrRouteTos.

The next question to ask is whether inetCidrRouteDscp would, in
fact, be sufficiently useful in the general case to merit its
inclusion as an index in the inetCidrRouteTable.  I'm inclined
to think that it does not.  RFC 3290, Diffserv Informal
Management Model, says this:

  The routing core moves packets between interfaces according to
  policies outside the scope of Diffserv (note: it is possible
  that such policies for output-interface selection might involve
  use of packet fields such as the DSCP but this is outside the
  scope of this model).

In other words, the DSCP field _might_ be used as _one_ of the
criteria for choosing a next hop interface, but there is no
explicit specification of a privileged role for it in route
selection policy (in sharp contrast to the old TOS field).

Last October the following message appeared in the thread
"[ipv6mib] So, where were we?" that seems to suggest a
much better alternative:

On Wed, 9 Oct 2002, Dave Thaler wrote:
> The intermediate solution previously discussed by the ipv6mib
> design team was to add an instance number to the INDEX,
> and have separate mapping tables describe how to interpret
> (or map to) the instance number.  Such mapping tables could
> be part of the same MIB, or part of a proprietary MIB
> (or both).  This is the solution I prefer, modulo my response
> to Margaret's next suggestion below, since it entails only
> a small change from 2096 (just replace TOS field with a more
> generic instance number).

I see in the change log that an inetCidrRouteInstance object
used to exist but was removed 27 Jun 2002 on the grounds that
it was "obviated by new InetAddress types and inclusion of DSCP
index object".  It was not a bad idea to reinstate the InetAddress
(and InetAddressType) objects, but I think that including the DSCP
object was a mistake, and that it should be replaced with a more
generic object, per Mr. Thaler's suggestion above.  Its name
should probably be inetCidrRoutePolicy, and it should either be
a generic intger-valued object, with a definition along the lines
of the (now-obsolete) ipForwardPolicy object, or else an OBJECT
IDENTIFIER object.  The tradeoff is basically one of ease of
administration versus implementation complexity.  Since one of
the stated objectives of this effort is to get something quickly
that can be extended later, I would suggest the OBJECT IDENTIFIER
approach;  it does not require central administration, and allows
proprietary policies to be represented if one so desires.  A first
cut at a definition might be:

  inetCidrRoutePolicy OBJECT-TYPE
      SYNTAX     OBJECT IDENTIFIER
      MAX-ACCESS not-accessible
      STATUS     current
      DESCRIPTION
             "Represents the general set of conditions that would
              cause the selection of one multipath route (set of next
              hops for a given destination) over another (referred to
              as 'policy').  The value { 0 0 } shall be used for the
              the default policy or if no particular policy applies."
      ::= { inetCidrRouteEntry 4 }

Now, when inetCidrRouteDest and inetCidrRouteNextHop represent
IPv6z addresses, they have a maximum length of 20 octets, and
smilint tells me that inetCidrRoutePolicy could then have up to
71 components before the limit of 128 sub-identifiers for instance
OIDs is reached.  So I don't think that the length would be an
issue (one might, however, wish to re-think the current size cap
of 36 octets for inetCidrRouteDest and inetCidrRouteNextHop).

Note that one could accomodate both TOS and DSCP based routing
policies in this scheme by defining an OID prefix (e.g., via
an OBJECT-IDENTITY invocation) and appending the TOS or DSCP
value as the last sub-identifier.  But much more general schemes
could be dealt with as well, and they could be defined later,
when the issues are better understood.  My recommendation would
actually be to NOT define any schemes other than "default", which
would use the null OID { 0 0 };  since the ipCidrTos is zero in
almost all implementations (otherwise we would not have had DSCPs
in the first place), that would probably accomodate all important
uses of the ipCidrRouteTable.


Issue #2:  Appropriateness of offering only a "full" compliance
---------  ----------------------------------------------------

Synopsis:  previous discussions revealed no knowledge of
read-write implementations of the ipCidrRouteTable.  I
don't see that there is any reason to believe that the
inetCidrRouteTable won't have the same fate, so I suggest
that we "take the hint" and write a compliance statement
that allows read-only access and subsetting of the
InetAddressType variables to whatever flavors of IP the
implementation actually supports (since these are indices,
that has to be done via DESCRIPTION clauses).

Discussion:  Last October the following message appeared in the
e-mail thread "[ipv6mib] So, where were we?", and it gives a hint
as to how the ipCidrRouteTable is actually implemented in practice:

On Wed, 9 Oct 2002, Brian Haberman wrote:
> Margaret Wasserman wrote:
> > 
> > Yes, but none of this really gets us closer to an answer to the
> > really important questions:
> > 
> >         - Do people actually implement RFC 2096 today?
> >                 - If so, are the implementations writable?
> > 
> > [I personally know of several implementations of RFC 2096, but
> > none of them are writable.]
> 
> I do not know any that are writable either.
> 
> > 
> >         - Does anyone actually use RFC 2096 to manage,
> >                 monitor, configure or debug a box?
> >                 - If so, how and for what?
> 
>  From what I have been able to gather, no one with a "large" route
> table ever uses 2096 to pull it down.  This seems to be for
> various reasons[0].
> 
> Some admins will query the table for specific routes to ensure
> they exist.  This is done during problem determination mode.

As it happens, I have implemented the ipCidrRouteTable on a
small end system, and I, too, chose to make it read-only.  Its
only real use on that system was for inspecting the route cache,
and it certainly was not worth the very considerable effort that
it would have taken to implement the machinery necessary to
support add/delete/modify of route cache entries with SNMP.
I strongly suspect that the same thing will be true of a fair
number of implementations of the new inetCidrRouteTable;
certainly, I see no reason for believing that the situation
will be different than it was for the ipCidrRouteTable.

Nonetheless, the compliance statements as written render a
read-only implementation non-conformant, and because there
are no provisions in the index column DESCRIPTION clauses
that allow an implementation to support only a subset of
the InetAddressType values, a full read-create implementation
would technically have to support all possible address types.

The suggested remedy is to add OBJECT clauses to the
ipForwardCompliance2 statement that permit MIN-ACCESS of
read-only to all columnar objects and a SYNTAX of INTEGER
{ active(1) } for the status column, or alternatively to
rename the existing compliance to inetCidrFullCompliance
and add an inetCidrReadOnlyCompliance that has the same
effect.  In either case the DESCRIPTION clauses of the
InetAddressType index index objects need to make clear
that an implementation need only allow values appropriate
to the protocols it supports.


Issue #3:  Gratuitous/Erroneous MIB changes not consistent with text
---------  ---------------------------------------------------------

Synopsis:  the object inetCidrRouteDiscards should be removed since
ipRoutingDiscards (which dates back to MIB-II) already exists in
the IP-MIB and does the same job.  An object inetCidrRouteNumber,
analogous to ipCidrRouteNumber, should be added (or reinstated).
The text in Section 8 describing inetCidrRouteNumber should stay;
the text in Section 8 describing inetCidrRouteDiscards should be
removed (or, possibly, replaced with a mention of ipRouteDiscards).

Discussion:  the following object from the IP-MIB (RFC 2011) and
MIB-II (RFC 1213)

  ipRoutingDiscards OBJECT-TYPE
      SYNTAX      Counter32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
              "The number of routing entries which were chosen to be
              discarded even though they are valid.  One possible reason
              for discarding such an entry could be to free-up buffer
              space for other routing entries."
      ::= { ip 23 }

provides _exactly_ the same functionality as the following object that
(according to the change log) was added on 12 Jul 2001 to replace it:

  inetCidrRouteDiscards OBJECT-TYPE
      SYNTAX     Counter32
      MAX-ACCESS read-only
      STATUS     current
      DESCRIPTION
             "The number of routing entries which were chosen to be
              discarded even though they are valid.  One possible
              reason for discarding such an entry could be to free-up
              buffer space for other routing entries."
      ::= { ipForward 8 }

Defining a new object with semantics identical to an old one is clearly
an unnecessary change.  Therefore, inetCidrRouteDiscards should be
removed, and so should the following paragraph in Section 8:

          2. The object inetCidrRouteDiscards counts the number of valid
             routes that were discarded for any reason.

On the other hand, the following paragraph in Section 8

          1. The object inetCidrRouteNumber indicates the number of
             current routes.  This is primarily to avoid having to read
             the table in order to determine this number.

refers to an object that does not exist.  According to the change log,
it was removed on 02 Nov 2002.  Possibly this was an editing error
and inetCidrRouteDiscards was supposed to have been removed instead;
in any case, inetCidrRouteNumber should be added (or reinstated)
because it would be useful and there is no equivalent object elsewhere.
I would suggest registering it as { ipForward 7 } so that there are no
gaps in the OID assignments to trip up the next maintainer.

//cmh

_______________________________________________
diffserv mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html