[Idr] IETF 83 - BGP MIBv2 Update - prefix Textual Conventions

[Jeffrey Haas <[e-mail]>]

Working Group,

As per prior plenary discussion on making more effect use of working group
session time, please find my BGP MIBv2 update slides on the proceedings
page:

http://www.ietf.org/proceedings/83/slides/slides-83-idr-0.pdf

The bulk of the presentation is self explanatory.  I'd like to thank 
Bert Wijnen for additional MIB feedback.   I suspect we'll get a bit more
feedback from him since he discovered bugs as part of doing derivative work
for the SIDR MIB.  Draft -13 [1] reflects his comments as of the IETF 83
posting cutoff.

One item I would like to draw the working group's further attention to is
covered on slides 5-7.  As part of analyzing the requirements for the
multicast next-gen VPN [2] MIBs that Jeffrey Zhang ([e-mail]) is
working on, we briefly considered exposing MVPN routing state in BGP via the
BGP MIBv2.  Per prior presentations and discussions on design goals for the
BGP MIBv2, we wanted one MIB that was capable of being re-used for various
types of reachability that was being carried in BGP.  However, the primary
goal was to be able to carry IPv6 reachability.

RFC 6514 can be briefly examined to see the different types of reachability
that are being passed around in BGP.  The reachability is distinguished
within the same AFI/SAFI by a "Route Type" field within the prefix with type
specific encodings following.  

The BGP MIBv2 presents prefixes using the following two objects:
    bgp4V2NlriPrefixType OBJECT-TYPE
        SYNTAX     InetAddressType
        MAX-ACCESS not-accessible
        STATUS     current
        DESCRIPTION
            "The type of the IP address prefix in the
             Network Layer Reachability Information field.
             The value of this object is derived from the
             appropriate value from the bgp4V2NlriAfi field.
             Where an appropriate InetAddressType is not
             available, the value of the object must be
             unknown(0)."
        ::= { bgp4V2NlriEntry 4 }

    bgp4V2NlriPrefix OBJECT-TYPE
        SYNTAX     InetAddress
        MAX-ACCESS not-accessible
        STATUS     current
        DESCRIPTION
            "An IP address prefix in the Network Layer
             Reachability Information field. This object
             is an IP address containing the prefix with
             length specified by bgp4V2NlriPrefixLen.
             Any bits beyond the length specified by
             bgp4V2NlriPrefixLen are zeroed.

             An implementation is required to support IPv4
             prefixes.  In this case, the object length
             is (0..4).

             An implementation MAY support IPv6 prefixes.
             In this case, the object length is (0..16)"
        REFERENCE
            "RFC 4271, Section 4.3."
        ::= { bgp4V2NlriEntry 5 }

The general goal of the "InetAddressType/InetAddress" textual conventions [3]
is to provide a level of generality for MIB objects that are "addresses".
Our initial design guidance for the BGP MIBv2 was to make use of these TCs
to help represent both IPv4 and IPv6 addresses - and it does this well.

As part of investigating encoding MVPN prefixes in the BGP MIBv2, I sent
mail to the ietfmibs mailing list to discuss this possibility.  After a few
exchanges, it was suggested that since the information is BGP specific that
this was not the best fit for the INET-ADDRESS-MIB and that we should
consider a BGP TC specifically for this purpose.

If we were to consider such a TC, we would make it "IANA maintained".  This
would permit us to issue the initial MIB but permit IANA to maintain the
code points as new protocol elements are added.  I.e. we don't have to have
a MIB document stuck as an I-D forever.  The current INET-ADDRESS-MIB is
an example of such a MIB.

After further discussion with Jeffrey Zhang, we determined that there wasn't
a strong incentive to continue the MVPN MIB work as a BGP MIBv2 extension,
We may see future requirements from other BGP-based address families.  

My recommendation would be that we proceed with the work to create a BGP
Prefix TC MIB with an explicit goal of being backward compatible with the
INET-ADDRESS-MIB.  However, the WG may also come to the decision to not
pursue making this MIB completely general purpose and just worry about
IPv4/IPv6.

With regard to standards advancement, the new BGP Prefix MIB shouldn't
unnecessarily hinder the BGP MIBv2.

I would like the WG to come to some consensus as to whether we (very likely,
I) take on the work to make such a prefix TC MIB.

If the discussion becomes interesting enough, Sue and John have agreed to
grant us discussion time at the upcoming IDR session in Paris.

-- Jeff




[1] http://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-13
[2] http://tools.ietf.org/html/rfc6514
[3] http://tools.ietf.org/html/rfc4001