Subject: Re: [Idr] [sidr] BGP4 MIB module

From: heasley <[email-masked]>
Date: Wed, 21 Mar 2012 17:38:23 +0000

Tue, Mar 20, 2012 at 04:28:15PM +0100, Bert Wijnen (IETF):
> 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.

I'm disappointed in the speed at which this draft has progressed.  I do
understand that mibs are often partially gated for/by trial implementation
(or so I've been told), but I have the impression its pace is wholly due to
the complexity of the proposed mib.  I also feel that there is a fair
amount of fluff that we find unnecessary for network management and would
be better suited to a separate mib; the RIBs, for example.  bgp4-mibv2
("lite"), bgp4-ribs, etc; or some approach that would allow the necessities
of peer state, nlri counts, and the like to progress without the fluff and
thus be more timely.

As such, I am unsure why its been brought to the sidr list, but I am hoping
that no attempt will be made to add SIDR-related stuff to this mib and
further delay adoption.

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 20 Mar 2012 16:28:15 +0100

Below is out discussion.

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

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

>>
>>>
>>> W.r.t.
>>> 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"
>>>
>>> I thought you were going to do them as comments in a DESCRIPTION clause?
>>
>> I'm sorry, I've lost track of what we may have discussed with regard to a description update.
>>
> I saw in your other email that you found it.
> WIll check if/when you send new mib module.
>

OK, seems fixed in rev 13.

> And again, our discussion probably should be copied to wg list.
> If you agree, I can just copy our conversation to it.
>
> Bert
>> -- Jeff
>>
>>
>