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