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
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
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
