Re: [Idr] [sidr] BGP4 MIB module

[Bill Fenner <[e-mail]>]

[sidr list removed, since this is just about BGP4V2-MIB]

On Tue, Mar 20, 2012 at 11:28 AM, Bert Wijnen (IETF)
<[e-mail]>wrote:

> So I had been in discussion with Jeff in order to see
> if we could get the BGP4-mibv2 module in good shape.
>
> Below is out discussion.
>
> Those who are interested in this MIB module at all
> may want to take a look to make sure they agree with
> the changes being proposed.
>
> The most modules we're discussion are:
>
> - drafts/draft-ietf-idr-bgp4-**mibv2-13.txt
> - drafts/draft-ietf-idr-bgp4-**mibv2-tc-mib-03.txt
>
> In fact I had below discussion on bgp4-mibv2-12.txt,
> which resulted in revision 13.
>
> On 3/13/12 9:46 PM, Bert Wijnen (IETF) wrote:
>
>> On 3/11/12 7:36 PM, Jeffrey Haas wrote:
>>
>>> Bert,
>>>
>>> On Jan 17, 2012, at 9:28 AM, Bert Wijnen (IETF) wrote:
>>>
>>>  First, should we have this discussion on the SIDR list?
>>>> Maybe we can get folk motivated to move this forward
>>>> that way?
>>>>
>>>
>>> I'm massively behind on SIDR, but will be looking at it today.
>>>
>>>  I had to get a new SMICng key first.
>>>>
>>>
>>> Thanks for doing that.
>>>
>>>
>>>> With the new MIB modules I get:
>>>>
>>>> C:\bw\smicng\work>smicng bgp4v2.inc
>>>> E: f(bgp4v2.mi2), (176,5) Item "bgp4V2PeerLocalAddrType" has invalid
>>>> value for
>>>> MAX-ACCESS
>>>> E: f(bgp4v2.mi2), (185,5) Item "bgp4V2PeerLocalAddr" has invalid value
>>>> for
>>>> MAX-ACCESS
>>>> W: f(bgp4v2.mi2), (1015,13) Row "bgp4V2NlriEntry" does not have a
>>>> consistent
>>>> indexing schem
>>>> e - index items from current table must come after index items from
>>>> other tables
>>>> W: f(bgp4v2.mi2), (1516,13) Row "bgp4V2AdjRibsOutEntry" does not have a
>>>> consistent indexing
>>>> scheme - cannot specify an index item from additional "base row"
>>>> bgp4V2NlriEntry, since ca
>>>> n have only one "base row" which is bgp4V2PeerEntry
>>>> E: f(bgp4v2.mi2), (1627,16) OBJECT-TYPE "bgp4V2PeerLocalAddr" is not in
>>>> a
>>>> MANDATORY or cond
>>>> itional group for module "BGP4V2-MIB"
>>>> E: f(bgp4v2.mi2), (1635,16) OBJECT-TYPE "bgp4V2PeerRemoteAddr" is not
>>>> in a
>>>> MANDATORY or con
>>>> ditional group for module "BGP4V2-MIB"
>>>> E: f(bgp4v2.mi2), (1643,16) OBJECT-TYPE "bgp4V2NlriPrefix" is not in a
>>>> MANDATORY
>>>> or conditi
>>>> onal group for module "BGP4V2-MIB"
>>>>
>>>> *** 5 errors and 2 warnings in parsing
>>>>
>>>> C:\bw\smicng\work>
>>>>
>>>> W.r.t.
>>>> E: f(bgp4v2.mi2), (176,5) Item "bgp4V2PeerLocalAddrType" has invalid
>>>> value for
>>>> MAX-ACCESS
>>>> E: f(bgp4v2.mi2), (185,5) Item "bgp4V2PeerLocalAddr" has invalid value
>>>> for
>>>> MAX-ACCESS
>>>>
>>>> You have
>>>> INDEX {
>>>> bgp4V2PeerInstance,
>>>> bgp4V2PeerRemoteAddrType,
>>>> bgp4V2PeerRemoteAddr
>>>> }
>>>>
>>>> So why are the LOCAL addrtype and addr not-accessible?
>>>> Or should they be part of the index?
>>>>
>>>
>>> At one point the local address items were part of the index for the
>>> table. After some discussion with implementors, they preferred
>>> that it be left as it is in the existing BGP-4 MIB case. While this is
>>> unfortunate, it makes sense.
>>>
>>> In BGP, it is typically the case that you'll have a single peering
>>> session to a given destination peer address. However, there are
>>> some corner case peering scenarios where two local addresses on a given
>>> router may peer with the same destination address from the
>>> same instance. This is a *very* uncommon case and it lead to some minor
>>> tweaks in the BGP language when RFC 4271 was published.
>>>
>>> The problem with putting the local address into the key is that it
>>> removes the determinism from the index. If the local address is
>>> not configured, as may be the case for ebgp peering, you may not know
>>> what it would be. In the case of some ibgp, it's also
>>> possible the local address may change based on what TCP decided it
>>> needed. Instead of catering to these uncertain cases, it was
>>> cleaner to remove the local address from the index.
>>>
>>> I have changed these back to read-only.
>>>
>>>
>> good.
>>
>>
>>>> W.r.t.
>>>> W: f(bgp4v2.mi2), (1015,13) Row "bgp4V2NlriEntry" does not have a
>>>> consistent
>>>> indexing schem
>>>> e - index items from current table must come after index items from
>>>> other tables
>>>>
>>>> You have:
>>>>
>>>> INDEX {
>>>> bgp4V2PeerInstance,
>>>> bgp4V2NlriAfi,
>>>> bgp4V2NlriSafi,
>>>> bgp4V2NlriPrefixType,
>>>> bgp4V2NlriPrefix,
>>>> bgp4V2NlriPrefixLen,
>>>> bgp4V2PeerRemoteAddrType,
>>>> bgp4V2PeerRemoteAddr,
>>>> bgp4V2NlriIndex
>>>> }
>>>> ::= { bgp4V2NlriTable 1 }
>>>>
>>>> So pls explain to me that indexing so I can form an opinion if that is
>>>> OK or
>>>> not. Besides the warning from SMICng, I also wonder why
>>>> NlriIndex is the last index column, while it is the first column in the
>>>> table.
>>>>
>>>
>>> The above up to nlri-index is a natural order walk for BGP. It's also
>>> largely what is used in the existing 4273 MIB:
>>>
>>> bgp4PathAttrEntry OBJECT-TYPE
>>> SYNTAX Bgp4PathAttrEntry
>>> MAX-ACCESS not-accessible
>>> STATUS current
>>> DESCRIPTION
>>> "Information about a path to a network."
>>> INDEX { bgp4PathAttrIpAddrPrefix,
>>> bgp4PathAttrIpAddrPrefixLen,
>>> bgp4PathAttrPeer }
>>> ::= { bgp4PathAttrTable 1 }
>>>
>>> Thus, walk all of a given instance. There's no guarantee that 10/8 in
>>> one instance is the same as another, especially since the
>>> instance may map to a VPN VRF.
>>> Walk a given prefix and peer, as it is in the older table. The prefixes
>>> are walked on a per afi/safi basis since the families are
>>> also incomparable. You then want to see the prefix from all peers.
>>>
>>> The nlriindex covers two cases: Multiple routes in RFC 3107 (which I
>>> don't believe anyone implements) and BGP add-path. You want
>>> to see all routes from a given peer and the nlri index lets you see more
>>> than one
>>>
>>> Hopefully the ordering makes sense in the index.
>>>
>>> I now see what you mean about the fact that the object for nlriindex
>>> precedes things like the afi and safi. It's mostly just been
>>> this way for a while. If you feel strongly that it should be re-ordered,
>>> we could probably do that since we haven't hit RFC, but
>>> it will have impact on anyone that may have an in-flight implementation
>>> of this. Thus far our fixes have had only minor impact.
>>>
>>>
> The above is still a warning I get in the revision 13.
> Would be good to have some comments from (other) implementers
> or those who plan to implement
>

The contents of the index make sense:

BGP Instance (although I would have done this with SNMP contexts, but that
ship has sailed)
AFI/SAFI
Prefix
Peer
Instance of this prefix from this peer

The reason that smicng is getting heartburn is that the MIB uses the
instance and peer values from the peer table, even though we're not
augmenting/expanding that table.  This is presumably done based upon
RFC2578's statement, "Note that objects specified in a conceptual row's
INDEX clause need not be columnar objects of that conceptual row".

I can't find a clear prohibition of reusing INDEX objects from other tables
even though you're not following the structure of that table.  In fact,
RFC2578 section 7.8.1 seems to encourage this reuse:

7.8.1.  Relation between INDEX and AUGMENTS clauses

(3)  Otherwise, **if no existing objects have the required syntax and
     semantics**, then auxiliary objects should be defined within the
     conceptual row for the new table, and those objects should be used
     within the INDEX clause for the conceptual row.

 Since there *are* existing objects with the desired syntax and semantics,
it feels like this clause is telling us to use them, even though this
particular use doesn't really match what I understand the original intent
to be (which is to have the INDEX of table A be a prefix of the INDEX of
related table B).


>>>
>>>> W.r.t.
>>>> W: f(bgp4v2.mi2), (1516,13) Row "bgp4V2AdjRibsOutEntry" does not have a
>>>> consistent indexing
>>>> scheme - cannot specify an index item from additional "base row"
>>>> bgp4V2NlriEntry, since ca
>>>> n have only one "base row" which is bgp4V2PeerEntry
>>>>
>>>> You have:
>>>> INDEX {
>>>> bgp4V2PeerInstance,
>>>> bgp4V2NlriAfi,
>>>> bgp4V2NlriSafi,
>>>> bgp4V2NlriPrefixType,
>>>> bgp4V2NlriPrefix,
>>>> bgp4V2NlriPrefixLen,
>>>> bgp4V2PeerRemoteAddrType,
>>>> bgp4V2PeerRemoteAddr,
>>>> bgp4V2AdjRibsOutIndex
>>>> }
>>>> ::= { bgp4V2AdjRibsOutTable 1 }
>>>>
>>>> Pls explain indexing scheme, so I can form an opinion.
>>>>
>>>
>>> The scheme is identical to the prior explanation. The primary difference
>>> is since this is sending routes rather than receiving
>>> them, we may advertise different routes on egress, hence an OutIndex
>>> instead of the prior NlriIndex.
>>>
>>>  Same question here
>

Same answer, really.  The index is:

BGP Instance
AFI/SAFI
Prefix
Peer
Instance of prefix being sent to this peer

smicng is being upset because items 1 and 4 are coming from the peer table
and items 2 and 3 are coming from the nlri table, and it is envisioning
this world where table A's INDEX is supposed to be a prefix of table B's.

If we wanted to pacify smicng, the types of the objects in the INDEX would
stay the same - they would just be redefined (e.g., redefine the instance
and peer in the NLRI table).  Is smicng just expressing a view of how this
kind of object reuse is normally done, or is it a rule?

  Bill