Re: [Idr] Question regarding bgpM2AsPath4byteTable in BGP4 MIBv2

[Jeffrey Haas <[e-mail]>]

Kalpesh,

draft-ietf-idr-bgp4-mibv2-06 was issued prior to the last IETF.  The
major focus of that re-issue was to clean up all of the previously
raised issues for the MIBv2 and also start the integration work into the
previously released BGP MIB.  Unless you have some internal motivation
to support the old version of the mib as documented in -05, I'd consider
working on -06.  

-06 starts with the premise that 4 byte AS numbers are directly
supported.  This does hide some of the internals of RFC 4893 when
operating in a 2 byte / 4 byte mode.  There was no solid consensus as to
how much 2/4 byte detail to expose in the MIB when -05 was issued.

In the context of the -06 MIB, if the details of the 2 / 4 byte mode
need to be exposed, it would be via an extension MIB similar to the
communities MIB documented in draft-jhaas-idr-bgp4-mibv2-community-00.txt

Feedback from the IDR working group on the need for the extension MIB
for the additional objects for 2/4byte interaction would be helpful.

In the context of the -05 draft:

On Mon, Dec 17, 2007 at 10:39:58AM -0800, Kalpesh Zinjuwadia wrote:
> I had a question regarding how to fill up bgpM2AsPath4byteTable table as
> described in BGP4 MIBv2 (draft-ietf-idr-bgp4-mibv2). If a BGP speaker
> supports 4-byte AS space as described in RFC 4893 and stores the AS-PATH
> and AGGR attributes w/ 4-byte ASN, there won't be AS4-PATH and AS4-AGGR
> attributes in its RIB. It'll generate these attributes, if required,
> while advertising update to other speakers.

One way to consider RFC 4893 is that if you're a 4 byte capable speaker,
and are participating in 4 byte peering sessions, you'll probably be
storing the AS Paths natively in 4 byte format.  In that particular
case, the 4byte objects would have been absent.  That detail wasn't
clear in the -05 draft.

In the case of a 2-byte only speaker that implemented this MIB, or a
4-byte capable speaker operating in 2-byte-only mode, the internal
versions of the ASes would be in 2 byte format and the additional path
attributes would be stored. 

After receiving a little feedback after -05 was issued, this seemed to
not be how people would be implementing this portion of the MIB.  If the
BGP speaker was 2-byte-only, then it would likely treat the 4-byte
attributes as "unknown" and it would show up in the table for unknown
path attributes.

> BGP4 MIBv2 has
> bgpM2AsPath4bytePathPresent entry in bgpM2AsPath4byteTable table. It's
> description says that it's true if a NEW speaker is functioning between
> 2-byte and 4-byte AS space. It further says that the AS4-PATH and
> AS4-AGGR are present in this NEW speaker. My question is - for
> implementation mentioned above, how to fill up this table as AS4-PATH
> and AS4-AGGR are not present and generated on need basis? Let me know if
> I'm missing something here...

You haven't missed anything here.  In essence, there are 3 potential
things to display in a MIB that could represent a 2-byte/4-byte
interaction:

1. What is being used internally.
2. Received 2-byte managed objects
3. Received 4-byte managed objects as NEW_ Path attributes.

Given that a common criticism of the BGP MIB is that is too unwieldy to
start with, the -06 version of the MIB simply chooses #1.  While #2 and
#3 could be represented in an extension MIB, the primary benefit would
seem to be for debugging 2byte/4byte interaction issues.  MIBs seem to
be a particularly poor way to do this.

My personal inclination would be to not include such a table as part of
the IETF standards, however I will yield to the consensus of the WG
should we wish one.

-- Jeff

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr