Skip to main content

IP Forwarding Table MIB
RFC 4292

Revision differences

Document history

Date Rev. By Action
2012-08-22
07 (System) post-migration administrative database adjustment to the Yes position for Bert Wijnen
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Alex Zinin
2006-04-14
07 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2006-04-14
07 Amy Vezza [Note]: 'RFC 4292' added by Amy Vezza
2006-04-11
07 (System) RFC published
2004-02-23
07 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-02-20
07 Amy Vezza IESG state changed to Approved-announcement sent
2004-02-20
07 Amy Vezza IESG has approved the document
2004-02-20
07 Amy Vezza Closed "Approve" ballot
2004-02-20
07 Thomas Narten State Changes to Approved-announcement to be sent from IESG Evaluation::Revised ID Needed by Thomas Narten
2004-02-19
07 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to Yes from No Objection by Bert Wijnen
2004-02-19
07 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Discuss by Bert Wijnen
2004-02-11
07 Alex Zinin [Ballot Position Update] Position for Alex Zinin has been changed to No Objection from Discuss by Alex Zinin
2004-02-11
07 (System) New version available: draft-ietf-ipv6-rfc2096-update-07.txt
2004-01-29
06 (System) New version available: draft-ietf-ipv6-rfc2096-update-06.txt
2003-12-04
07 Amy Vezza Removed from agenda for telechat - 2003-12-04 by Amy Vezza
2003-12-04
07 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2003-12-04
07 Alex Zinin
[Ballot discuss]
2. inetCidrRouteDiscards

    The text says:

>    inetCidrRouteDiscards OBJECT-TYPE
>        SYNTAX    Counter32
>        MAX-ACCESS …
[Ballot discuss]
2. inetCidrRouteDiscards

    The text says:

>    inetCidrRouteDiscards OBJECT-TYPE
>        SYNTAX    Counter32
>        MAX-ACCESS read-only
>        STATUS    current
>        DESCRIPTION
>                "The number of entries in the inetCidrRouteTable 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."

    What does this counter really represent?
    Are discarded entries still reported in inetCidrRouteTable, but
    are not present in the actual FIB, or are they also not present
    in the inetCidrRouteTable? In other words, discarded by whom
    and at what point?
   
    Also, is it supposed to count both v4 and v6 discarded routes
    or discarded routes in that instance, whatever it includes?

3. inetCidrRoutePolicy

    The text says:

>    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
>                default policy or if no particular policy applies." 
>        ::= { inetCidrRouteEntry 4 }

    2096 had ToS-based policy description that wasn't really used.
    What is this description trying to define? Policy of next-hop
    selection in the ECMP case or route arbitration when multiple
    protocols provide a route to the same prefix?

    Also, which "policy" is meant here:

>    inetCidrRouteEntry OBJECT-TYPE
>        SYNTAX    InetCidrRouteEntry
>        MAX-ACCESS not-accessible
>        STATUS    current
>        DESCRIPTION
>                "A particular route to a particular destination, under a
>                particular policy.
   
  4. inetCidrRouteIfIndex

    The text:

>    inetCidrRouteIfIndex OBJECT-TYPE
>        SYNTAX    InterfaceIndex
>        MAX-ACCESS read-create
>        STATUS    current
>        DESCRIPTION
>                "The ifIndex value which identifies the local interface
>                through which the next hop of this route should be 
>                reached."
>        ::= { inetCidrRouteEntry 7 }
 
    I assume that this MIB would be used by vendors to report the
    routing table as well, not strictly the forwarding table. In this
    case, it would be possible to have routes with only next-hop
    addresses, but no ifIndex, e.g. BGP or static routes. Should
    the description say that value 0 means no interface specified?
2003-12-04
07 Alex Zinin [Ballot Position Update] New position, Discuss, has been recorded for  by Alex Zinin
2003-12-04
07 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for  by Allison Mankin
2003-12-04
07 Bill Fenner [Ballot Position Update] New position, Recuse, has been recorded for  by Bill Fenner
2003-12-04
07 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for  by Jon Peterson
2003-12-04
07 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for  by Harald Alvestrand
2003-12-03
07 Steven Bellovin [Ballot comment]
Network map data is useful for far more than denial of service.  I'd just delete that phrase.
2003-12-03
07 Steven Bellovin [Ballot Position Update] New position, No Objection, has been recorded for  by Steve Bellovin
2003-12-03
07 Bert Wijnen
[Ballot discuss]
More or less serious (enough of those to take a DISCUSS):
- For those objects where you have a syntax of InetAddressType/InetAddress
  …
[Ballot discuss]
More or less serious (enough of those to take a DISCUSS):
- For those objects where you have a syntax of InetAddressType/InetAddress
    it seems to me that a value of "dns" or the type does not make sense.
    I discussed this with Mike HEard (who reviewed the MIB before as MIB
    doctor), and he sugegst to add this to the OBJECT-TYPE DESCRIPTION
    clause(s):
        "Only those address types that may appear in an actual routing
          table are allowed as values of this object."
    To then also make that clear in the MODULE-COMPLIANCE, it would
    be good to add all of the InetAddressType objects in this MIB module
    in OBJECT clauses specifying that only ipv4(1), ipv6(2),and in some
    cases unknown(0) address types are required, and further
    that only those address types actually supported by the
    implementation need to be allowed.
    That would then also result in OBJECT clauses to limit the size
    of the InetAddress objects to (0 | 4 | 16).

- The REVISION clause of the MODULE-IDENTITY macro should also
    describe that the version-neutral inetCidrRouteTable replaces
    the IPv4 version-specific ipCidrRouteTable and related object
    groups and conformance statements.
    That is namely a pretty serious change that should be listed.
    It should also be listed in section 7.

- a statement is needed (required by RFC2578) in the DESCRIPTION
    clause of ipForwardCompliance stating that it was deprecated in
    favor of ipForwardFullCompliance and ipForwardReadOnlyCompliance.

- also statements are needed in the DESCRIPTION clause of
    ipForwardCidrRouteGroup stating that it was deprecated in favor
    of inetForwardCidrRouteGroup.

- inetCidrRouteDest and inetCidrRouteNextHop
    The description clause should include something aka:
                  "The type of this address is determined by the value of
                  the inetCidrRouteDestType object."
    That is what RFC3291 prescribes in for uses of TC InetAddress.

- There is a documentation issue as well (as raised by Dan Romascanu,
    another MIB doctor). That is: what does' MIB-II support' mean nowadays.
    This doc talks about RFC1213 mib in bullet 4) in section 3.
    But draft-ietf-ipv6-rfc2012-update-04.txt does much better. In its
    'Relationship with other MIBs' section, it documents the relationship
    with the MIB module ancestors very well. Such a section helps a lot for
    implementers and users of the MIB. It is missing from
    draft-ietf-ipv6-rfc2096-update-05.txt.

Nits (that editors may want to address at same time):
- Margarets contact info is incorrect
- WG mailing list info can be fixed now
- I see in inetCidrRouteDestType
                DESCRIPTION
                "The type of the inetCidrRouteDest address, as defined
                in the InetAddress MIB [RFC3291]."
    Citation within description clause of an OBJECT-TYPE are not good.
    They get lost when the MIB module is extracted.
    Would be OK to do (RFC 3291), but the best way to reference it
    would be a REFERENCE clause.
    It occurs twice I believe.

- I also wonder about inetCidrRouteDest:
                Any assignment (implicit or otherwise) of an instance
                of this object to a value x MUST be rejected if the
                bitwise logical-AND of x with the value of the mask
                formed from the corresponding instance of the
                inetCidrRoutePfxLen object is not equal to x."
    What I wonder about is "Any assignment... of an instance of this
    object.". Cause this object does not get instantiated. It is an index
    object. Similar issue with DESCRIPTION clause of inetCidrRoutePfxLen.
    Maybe it is just my English. If you think the above is OK, then fine.
    My personal text would be the same in both objects, more aka:

                    The values for the index objects inetCidrRouteDest and
                    inetCidrRoutePfxLen must be consistent. When the value
                    of inetCidrRouteDest is x, then the bitwise logical-AND
                    of x with the value of the mask formed from the
                    corresponding index object inetCidrRoutePfxLen MUST be
                    equal to x. If not, then the idex pair is not consistent
                    and an inconsistentName error must be returned on SET or
                    CREATE requests."

- For the ReadOnlyCompliance, this is OK:
              OBJECT inetCidrRouteStatus
              MIN-ACCESS read-only
              DESCRIPTION
                    "Write access is not required."
    But would it would be better to do:
              OBJECT inetCidrRouteStatus
              SYNTAX { active(1) }
              MIN-ACCESS read-only
              DESCRIPTION
                    "Write access is not required."

- Section 7 should probably also say that the inetCidrRouteTable
    retains the logical structure of the table it replaces in order to
    allow easy upgrade of existing IPv4 implementations to the
    version-independent MIB (that's what the "minimal changes" stuff in
    the DESCRIPTION clause of the latest revision means).
2003-12-03
07 Amy Vezza [Ballot Position Update] New position, Discuss, has been recorded for  by Amy Vezza
2003-12-02
07 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie
2003-12-02
07 Ted Hardie [Ballot comment]
I think the Editor's contact info in  ipForward MODULE-IDENTITY and the Author's
addresses section are out of date (right, Margaret?)
2003-12-02
07 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for  by Ted Hardie
2003-12-02
07 Margaret Cullen [Ballot Position Update] New position, Recuse, has been recorded for  by Margaret Wasserman
2003-12-01
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for  by Russ Housley
2003-11-25
07 Ned Freed
[Ballot comment]
Nits:

  No IPR boilerplate

Idle musing:

  This document, like so many other MIB documents, has a largely useless table
  of …
[Ballot comment]
Nits:

  No IPR boilerplate

Idle musing:

  This document, like so many other MIB documents, has a largely useless table
  of contents: There's a few entries for pages 1-7 and 30-33 but nothing for
  the majority of the specification, which of course is the MIB itself.

  I wonder... Wouldn't it be useful to have a way of adding TOC entries for the
  various sections within the MIB itself? Would it be worth a note to see if
  XML2RFC could be extended this way?

  Mind you, I only find TOCs useful when looking at printed versions of the
  document, and the intersection of MIBs and scanning printed specifications
  might be so small as not to be worth it.

  Comments?
2003-11-25
07 Ned Freed [Ballot Position Update] New position, No Objection, has been recorded for  by Ned Freed
2003-11-25
07 Thomas Narten Placed on agenda for telechat - 2003-12-04 by Thomas Narten
2003-11-25
07 Thomas Narten State Changes to IESG Evaluation from Waiting for Writeup by Thomas Narten
2003-11-25
07 Thomas Narten [Ballot Position Update] New position, Yes, has been recorded for Thomas Narten
2003-11-25
07 Thomas Narten Ballot has been issued by Thomas Narten
2003-11-25
07 Thomas Narten Created "Approve" ballot
2003-11-24
07 (System) State has been changed to Waiting for Writeup from In Last Call by system
2003-11-04
07 Amy Vezza Last call sent
2003-11-04
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2003-11-04
07 Thomas Narten State Changes to Last Call Requested from Publication Requested by Thomas Narten
2003-11-04
07 Thomas Narten Last Call was requested by Thomas Narten
2003-11-04
07 (System) Ballot writeup text was added
2003-11-04
07 (System) Last call text was added
2003-11-04
07 (System) Ballot approval text was added
2003-09-11
07 Natalia Syracuse Draft Added by Natalia Syracuse
2003-08-29
05 (System) New version available: draft-ietf-ipv6-rfc2096-update-05.txt
2003-06-30
04 (System) New version available: draft-ietf-ipv6-rfc2096-update-04.txt
2003-06-20
03 (System) New version available: draft-ietf-ipv6-rfc2096-update-03.txt
2002-11-07
02 (System) New version available: draft-ietf-ipv6-rfc2096-update-02.txt
2002-08-28
01 (System) New version available: draft-ietf-ipv6-rfc2096-update-01.txt
2002-07-02
00 (System) New version available: draft-ietf-ipv6-rfc2096-update-00.txt