[sidr] BGP4 MIB module
"Bert Wijnen (IETF)" <bertietf@bwijnen.net> Tue, 20 March 2012 15:28 UTC
Return-Path: <bertietf@bwijnen.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3566C21F85A4; Tue, 20 Mar 2012 08:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.567
X-Spam-Level:
X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evtErvmRfVhv; Tue, 20 Mar 2012 08:28:22 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id CAB2621F85AA; Tue, 20 Mar 2012 08:28:18 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1SA0yu-00064Z-51; Tue, 20 Mar 2012 16:28:18 +0100
Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1SA0yt-0005T3-St; Tue, 20 Mar 2012 16:28:16 +0100
Message-ID: <4F68A20F.5000506@bwijnen.net>
Date: Tue, 20 Mar 2012 16:28:15 +0100
From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Jeffrey Haas <jhaas@juniper.net>, sidr wg list <sidr@ietf.org>, idr@IETF.ORG
References: <0E2C44659B4E4C22A58EDF7E0A834092@BertLaptop> <A0244F66-9C6D-4AC1-A0B9-6BAD839D0DE9@juniper.net> <4F5FB239.7090009@bwijnen.net>
In-Reply-To: <4F5FB239.7090009@bwijnen.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd41cafc88c9eb0867ebd1beb2fb90d88e4
Subject: [sidr] BGP4 MIB module
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2012 15:28:23 -0000
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] BGP4 MIB module Bert Wijnen (IETF)
- Re: [sidr] BGP4 MIB module heasley