Re: [Idr] [sidr] BGP4 MIB module

["Bert Wijnen (IETF)" <[e-mail]>]

Thanks Bill. See my response at bottom

On 7/17/12 8:44 PM, Bill Fenner wrote:
> [sidr list removed, since this is just about BGP4V2-MIB]
>
> On Tue, Mar 20, 2012 at 11:28 AM, Bert Wijnen (IETF) <[e-mail] <mailto:[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?
>

It is not a hard rule. I have often called it a Perkinism.
There is a smicng flag to ignore/suppress the warnings.
But before I use that flag, I want to be sure the indexing is as
intended and has some thought behind it. Your explanations are fine
for me,

Bert
>    Bill