Subject: Re: [Idr] BGP MIBv2 implementation

From: Bill Fenner <[email-masked]>
Date: Tue, 17 Jul 2012 14:59:00 -0400

On Wed, Apr 25, 2012 at 8:44 AM, Daniel Cohn <[email-masked]> wrote:

> 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.
>
I had a similar thought about the Adj-RIBS-Out table - it can't represent a
locally-originated route.  I am not sure what you mean by changing the
index to address this, however, since the index as it is makes sense to me.
 Maybe you mean to change the structure of the table to copy all of the
data from the NlriTable, which I disagree with.

One idea on handling this with the current structure is to use the pointer
to point to a row in the IP-FORWARDING-MIB for a locally-originated route.

> -          **Add support for BGP communities (as in your communities
> draft) in the NLRI in/out tables.
>
There is no reason this can't be a future addition, right, in the interest
of getting the base functionality out?

> -          **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
>
If the ports are in the INDEX, how do you ever find a row if one of the
ports is guaranteed to be ephemeral and you don't know a priori who
originated the connection?

If the remote address was first in the INDEX, you could always use getnext
to get a given value independent of the local address, but that's not a
concept that many management systems are familiar with.

An idea that solves both the ports and the unknown-local-address problem is
to use the remote address and an instance identifier.  Peers with a single
connection (the "normal" case) would be only instance 1, but if you had
multiple simultaneous connections to the same remote peer you could use
more values.

  Bill

** **
>
> Feedback is welcome, regards,****
>
> ** **
>
> Daniel****
>
> ** **
>
> *From:* Jeffrey Haas [mailto:[email-masked]]
> *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****
>
> ** **
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 17 Jul 2012 16:01:29 -0400

Bill,

> of getting the base functionality out?

There's also a matter of how you cleanly represent this.  I've had prior
drafts suggesting a structure for such a thing, but not a huge amount of
traction in it.  I'm happy to have the bgp mibv2 hit RFC at this point
before I invest the effort. :-)

> originated the connection?

That was the original problem.  The local address and port was originally
part of the index with some attempt to reflect this case.  It made for quite
the mess and was only really used to cover a small number of really
exceptional edge cases in BGP peer configuration.

> multiple simultaneous connections to the same remote peer you could use

If there's strong consensus, I'm not opposed to adding that.

-- Jeff

---

From: "Daniel Cohn" <[email-masked]>
Date: Sun, 22 Jul 2012 16:53:40 +0300

Hi Bill and all, please see inline with [DC].

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill
Fenner
Sent: Tuesday, July 17, 2012 9:59 PM
To: Daniel Cohn
Cc: Jeffrey Haas; [email-masked]
Subject: Re: [Idr] BGP MIBv2 implementation

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.

I had a similar thought about the Adj-RIBS-Out table - it can't
represent a locally-originated route.  I am not sure what you mean by
changing the index to address this, however, since the index as it is
makes sense to me.

[DC] You're right, that's what I meant. My bad. 

One idea on handling this with the current structure is to use the
pointer to point to a row in the IP-FORWARDING-MIB for a
locally-originated route.

[DC] I don't think that would work, as there is plenty of BGP-specific
information that is not available at the IP forwarding MIB, such as MED,
LOCAL_PREF, or ext communities (actually all the information currently
indexed by bgpM2PathAttrIndex).

What is the problem with expanding the table to include all required BGP
information? If your concern is memory utilization, at the risk of
stating the obvious let me say that MIB structure doesn't necessarily
prescribe the internal database structure, meaning you can always choose
a more efficient internal structure (e.g. using pointers instead of
storing duplicate information) and translate the SNMP queries from/to
the MIB structure.

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

There is no reason this can't be a future addition, right, in the
interest of getting the base functionality out?

[DC] Why should this simple addition hold back progress?

	-          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

If the remote address was first in the INDEX, you could always use
getnext to get a given value independent of the local address, but
that's not a concept that many management systems are familiar with.

An idea that solves both the ports and the unknown-local-address problem
is to use the remote address and an instance identifier.  Peers with a
single connection (the "normal" case) would be only instance 1, but if
you had multiple simultaneous connections to the same remote peer you
could use more values.

[DC] I don't see a problem with using getnext, but a neutral instance is
also acceptable.

  Bill

	Feedback is welcome, regards,

	Daniel

	From: Jeffrey Haas [mailto:[email-masked]] 
	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

---

From: Bill Fenner <[email-masked]>
Date: Wed, 25 Jul 2012 16:21:50 -0700

On Sun, Jul 22, 2012 at 6:53 AM, Daniel Cohn <[email-masked]> wrote:

> Hi Bill and all, please see inline with [DC].****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Bill
> Fenner
> *Sent:* Tuesday, July 17, 2012 9:59 PM
> *To:* Daniel Cohn
> *Cc:* Jeffrey Haas; [email-masked]
> *Subject:* Re: [Idr] BGP MIBv2 implementation****
>
> ** **
>
> On Wed, Apr 25, 2012 at 8:44 AM, Daniel Cohn <[email-masked]> wrote:**
> **
>
> Hi Jeff and all,****
>
>  ****
>
> 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.****
>
> I had a similar thought about the Adj-RIBS-Out table - it can't represent
> a locally-originated route.  I am not sure what you mean by changing the
> data from the NlriTable, which I disagree with.****
>
> ** **
>
> [DC] You’re right, that’s what I meant. My bad. ****
>
> ** **
>
> [DC] I don’t think that would work, as there is plenty of BGP-specific
> indexed by bgpM2PathAttrIndex).****
>
> information? If your concern is memory utilization, at the risk of stating
> the obvious let me say that MIB structure doesn’t necessarily prescribe the
> internal database structure, meaning you can always choose a more efficient
> internal structure (e.g. using pointers instead of storing duplicate
> information) and translate the SNMP queries from/to the MIB structure.
>

Of course the SNMP structure is not necessarily at all related to the
internal data structures.  My understanding is that the reason for the
Rib-OUT table using RowPointer was the [not that well-founded, but still
widespread] concern about the amount of data returned in a full MIB walk.
 (Also, it does concretely reduce the amount of data you need to process if
you're a management system that wants to know all of the RIB-IN plus
RIB-OUTs.)

What about representing locally-advertised routes as being received from a
peer of type unknown, with zero length address?

> ****
>
> -          Add support for BGP communities (as in your communities draft)
> in the NLRI in/out tables.****
>
> of getting the base functionality out?****
>
> ** **
>

It was removed in 2007 because of a lack of consensus about including it.
 Is your sense that that lack of consensus has changed?

> -          Restore local address (and maybe ports) to bgp4V2PeerTable
> draft-ietf-grow-diverse-bgp-path-dist****
>
> originated the connection?****
>
> ** **
>
> concept that many management systems are familiar with.****
>
> ** **
>
> single connection (the "normal" case) would be only instance 1, but if you
> had multiple simultaneous connections to the same remote peer you could use
> more values.****
>
> ** **
>
> [DC] I don’t see a problem with using getnext, but a neutral instance is
> also acceptable.
>

The problem with using getnext is that so many management systems are
"MRTG-like" in that they can graph arbitrary objects if you give them the
whole OID, but can only use GET to do so.  You may say that people
shouldn't use such management systems, but if there's a straightforward way
to accomodate them then why not?

  Bill

 ****
> https://www.ietf.org/mailman/listinfo/idr****
>
> ** **
>