Re: [Idr] BGP MIBv2 implementation

["Daniel Cohn" <[e-mail]>]

Hi Jeff and all,

 

Sorry for the delayed response. I think it would be a shame to go
through the hassle of updating the BGP MIB without fully supporting BGP
L3VPN/VPLS (in both RFC 4761 and 6074 flavors). Therefore I support
using a generic NLRI prefix TC that explicitly supports these NLRIs and
can be extended to support future BGP applications. It doesn't seem
consistent to add AFI/SAFI to the MIB while leaving the NLRI as an IP
address.

 

A couple more suggestions for this draft:

 

-          Change the bgp4V2AdjRibsOutTable index to make it the same as
in bgp4V2NlriTable. In its current form (a pointer to the
bgp4V2NlriTable), it doesn't support BGP routes originated by this
speaker (e.g. redistributed from IGP) so it's woefully inadequate.



-          Add support for BGP communities (as in your communities
draft) in the NLRI in/out tables.



-          Restore local address (and maybe ports) to bgp4V2PeerTable
index to support multiple BGP sessions between two speakers as in
draft-ietf-grow-diverse-bgp-path-dist

 

Feedback is welcome, regards,

 

Daniel

 

From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Thu, 15 Mar 2012 14:19:17 
Subject: Re: [Idr] IETF 83 - BGP MIBv2 Update - prefix Textual
Conventions

 

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 (zzhang at
juniper.net) 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