Subject: [Idr] Question regarding bgpM2AsPath4byteTable in BGP4 MIBv2

From: "Kalpesh Zinjuwadia" <[email-masked]>
Date: Mon, 17 Dec 2007 10:39:58 -0800

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. 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...
 
Thanks,
Kalpesh
 
Extract from draft-ietf-idr-bgp4-mibv2-05
. . .
bgpM2AsPath4bytePathPresent OBJECT-TYPE
        SYNTAX     TruthValue
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION
            "This value may only be true if this BGP Speaker
             is functioning as a router between ASs that
             are in 2-byte and 4-byte AS space.  If this
             value is true, then the NEW_AS_PATH attributes
             are present and the 4-byte versions of the
             appropriate path attributes are in this row.
 
             If this value is false, then the following values
             will be present in the row:
 
             bgpM2PathAttrAggregatorAS - zero (0).
             bgpM2AsPathCalcLength - zero (0).
             bgpM2AsPathString - zero (0) length string.
             bgpM2AsPathIndex - zero (0)."
        ::= { bgpM2AsPath4byteEntry 1 }
 
_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 Dec 2007 17:25:52 -0500

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:
> 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

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

---

From: "tom.petch" <[email-masked]>
Date: Tue, 18 Dec 2007 16:39:16 +0100

Jeff

Camping onto a related topic ....

Geoff Huston has picked up and developped the
draft-michaelson-4byte-as-representation
I-D that was last called here a year ago, and this now says that the
representation MUST be asdot ie a decimal number below 65536, or x.y when it
would be above 65535.  This is gaining some traction in RIPE.  If and when a
standard is adopted, then I think that there should be a TC in this MIB with an
appropriate DISPLAY-HINT (I cannot recall seeing anything like it anywhere).

Tom Petch

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Dec 2007 14:32:00 -0500

Tom,

> appropriate DISPLAY-HINT (I cannot recall seeing anything like it anywhere).

This MIB makes use of InetAutonomousSystemNumber from INET-ADDRESS-MIB.

I'd like to say "when that MIB is updated, all will be well".  However,
the mapping of a DISPLAY-HINT for INTEGER dervied object types won't do
"the Right Thing".  DISPLAY-HINTs for INTEGER, by their nature, can't do
math.

There is a strong push to make use of the textual conventions defined in
the INET-ADDRESS-MIB when possible.  If the goal is to make use of the
display representation in that draft, the wider SNMP community has a
problem, not just the BGP MIBv2.

I would strongly suggest that this issue be raised to the OPS group
directly.  I believe any changes to the BGP MIBv2 will fall out from
there. 

A weak hack would be to partition an AS Number into a "top half" and a
"bottom half" and leave the DISPLAY-HINT to be "d".  However, that won't
give you your dotted notation, it'll simply give you two objects.  From
a MIB perspective, that's not a problem since the AS numbers are not
part of an INDEX.  I think it's a poor solution.  I'd rather punt this
issue to the OPS group. :-)

-- Jeff