Re: [IETFMIBS] Extending InetAddress(Type) for BGP Multicast VPNs

Jeff Haas <jhaas@juniper.net> Tue, 10 January 2012 14:30 UTC

Return-Path: <jhaas@juniper.net>
X-Original-To: ietfmibs@ietfa.amsl.com
Delivered-To: ietfmibs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B436821F85FD for <ietfmibs@ietfa.amsl.com>; Tue, 10 Jan 2012 06:30:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 A49bbUv6fo6c for <ietfmibs@ietfa.amsl.com>; Tue, 10 Jan 2012 06:30:44 -0800 (PST)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id E76D021F85F8 for <ietfmibs@ietf.org>; Tue, 10 Jan 2012 06:30:43 -0800 (PST)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTwxLhkhMtIVQhCA8nNsDYezMzQG7WBRY@postini.com; Tue, 10 Jan 2012 06:30:44 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 10 Jan 2012 06:28:06 -0800
From: Jeff Haas <jhaas@juniper.net>
To: Brian Haberman <brian@innovationslab.net>
Date: Tue, 10 Jan 2012 06:28:09 -0800
Thread-Topic: [IETFMIBS] Extending InetAddress(Type) for BGP Multicast VPNs
Thread-Index: AczPpBFEW207VPGpRKe7zK6wBjawqA==
Message-ID: <28D0A91D-4C9B-4562-9495-639A38394194@juniper.net>
References: <CBFBAE7D-EFBC-4833-9DD5-C2659C00F419@juniper.net> <20120109234012.GA93650@elstar.local> <52539B15-9568-486D-9E04-5F753DA2BFAC@juniper.net> <20120110105431.GC94367@elstar.local> <4F0C35ED.8060705@innovationslab.net>
In-Reply-To: <4F0C35ED.8060705@innovationslab.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ietfmibs@ietf.org" <ietfmibs@ietf.org>
Subject: Re: [IETFMIBS] Extending InetAddress(Type) for BGP Multicast VPNs
X-BeenThere: ietfmibs@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF MIB Discussion list <ietfmibs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietfmibs>, <mailto:ietfmibs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietfmibs>
List-Post: <mailto:ietfmibs@ietf.org>
List-Help: <mailto:ietfmibs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietfmibs>, <mailto:ietfmibs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2012 14:30:44 -0000

Brian,

Since your response is closest to my intentions, I'll answer here:

On Jan 10, 2012, at 7:58 AM, Brian Haberman wrote:
> I suspect that Jeff wants to introduce 7 new values for InetAddressType
> that allows him to represent these seven types of routes:
> 
>     + 1 - Intra-AS I-PMSI A-D route;
>     + 2 - Inter-AS I-PMSI A-D route;
>     + 3 - S-PMSI A-D route;
>     + 4 - Leaf A-D route;
>     + 5 - Source Active A-D route.
>     + 6 - Shared Tree Join route;
>     + 7 - Source Tree Join route;
> 
> I would have to see a more concrete proposal, but it seems a unwieldy
> given that each of the above types could occur for both IPv4 and IPv6
> addresses.  So that would require more than seven new values for
> InetAddressType.  Unless I am not understanding the referenced draft
> correctly…

You and Juergen are understanding this perfectly fine.

Also, as I expected, you're all not very fond of the idea (using differing wording in the various responses, but it's clear).  That saved having the discussion complicated by providing sample SMI.

What this means is, as the editor of the BGP MIB, I now have to ask and answer a slightly different problem.  I made use of the InetAddress MIB so that we could take advantage of the flexibility to cover both IPv4 and IPv6 reachability for our peering sessions as well as our prefixes.  However, BGP is capable of carrying more reachability than simply IPv4 or IPv6; in the example case, it's MVPN.  We also support things like VPLS.

This seems to suggest that BGP needs to copy and fork InetAddressType/InetAddress (and perhaps the prefix length TC as well) for a BGP specific MIB that can accommodate non-IP prefixes.

I would love an alternate suggestion to doing this since I do not relish the idea of maintaining such a TC MIB indefinitely. :-)

(I also understood that was exactly what I was asking the owners of INET-ADDRESS-MIB to do.)

One property such a BGP-specific MIB should have is to use the same code points as the INET-ADDRESS-MIB where possible.  This would enable code re-use.

Is my logic correct?

-- Jeff