Re: [Idr] Question regarding bgpM2AsPath4byteTable in BGP4 MIBv2

["tom.petch" <[e-mail]>]

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


----- Original Message -----
From: "Jeffrey Haas" <[e-mail]>
To: "Kalpesh Zinjuwadia" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, December 17, 2007 11:25 PM
Subject: Re: [Idr] Question regarding bgpM2AsPath4byteTable in BGP4 MIBv2


> 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


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