Re: [irs-discuss] Now you're all awake!

Shane Amante <shane@castlepoint.net> Tue, 13 November 2012 15:57 UTC

Return-Path: <shane@castlepoint.net>
X-Original-To: irs-discuss@ietfa.amsl.com
Delivered-To: irs-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBB421F871A for <irs-discuss@ietfa.amsl.com>; Tue, 13 Nov 2012 07:57:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyfXEwkHE0tZ for <irs-discuss@ietfa.amsl.com>; Tue, 13 Nov 2012 07:57:28 -0800 (PST)
Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8426221F86D3 for <irs-discuss@ietf.org>; Tue, 13 Nov 2012 07:57:27 -0800 (PST)
Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 637D220F1 for <irs-discuss@ietf.org>; Tue, 13 Nov 2012 15:57:23 +0000 (UTC)
Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 260E71A4B; Tue, 13 Nov 2012 08:57:22 -0700 (MST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <03ba01cdc19f$daef7760$90ce6620$@olddog.co.uk>
Date: Tue, 13 Nov 2012 08:57:22 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <43A3C76D-E3E8-4EF3-B511-A0DCF918B4DF@castlepoint.net>
References: <03ba01cdc19f$daef7760$90ce6620$@olddog.co.uk>
To: adrian@olddog.co.uk
X-Mailer: Apple Mail (2.1499)
X-DSPAM-Result: Innocent
X-DSPAM-Processed: Tue Nov 13 08:57:23 2012
X-DSPAM-Confidence: 1.0000
X-DSPAM-Improbability: 1 in 98689409 chance of being spam
X-DSPAM-Probability: 0.0023
X-DSPAM-Signature: 50a26de3199631676816196
X-DSPAM-Factors: 27, routers+#+that, 0.40000, draft+white, 0.40000, are+Route, 0.40000, there+#+#+#+on, 0.40000, BGP+#+represents, 0.40000, routers+#+#+#+amount, 0.40000, programmatic+#+#+#+and, 0.40000, offboard+#+but, 0.40000, benefit+#+#+#+cases, 0.40000, problem+#+solve, 0.40000, particularly+for, 0.40000, what+the, 0.40000, back+#+#+at, 0.40000, early+#+#+these, 0.40000, be+#+a, 0.40000, that+case, 0.40000, would+#+#+#+use, 0.40000, Reflectors+in, 0.40000, here+#+an, 0.40000, subset+#+#+elements, 0.40000, case+#+#+will, 0.40000, approaches+#+#+yet, 0.40000, that+are, 0.40000, a+need, 0.40000, those+#+of, 0.40000, it's+#+#+#+that, 0.40000, thorny+#+however, 0.40000
Cc: irs-discuss@ietf.org
Subject: Re: [irs-discuss] Now you're all awake!
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Nov 2012 15:57:28 -0000

On Nov 13, 2012, at 6:07 AM, Adrian Farrel <adrian@olddog.co.uk>; wrote:
> Can we have some constructive discussion about which use cases to include in the
> charter and which ones to exclude.
> 
> I am pretty sure I heard the BoF say that they wanted to reduce the scope by
> cutting down on the use cases, and as I said at the meeting I am worried that
> this just means that each person wants to limit the scope their favorite use
> case. So we will only get victory if there is considerable convergence on what
> the favorite is.
> 
> Thoughts?

I would like to offer potentially narrowing the scope to use cases to those described in:
http://tools.ietf.org/html/draft-keyupate-irs-bgp-usecases-00
... and in Sections 2 through 4 of:
http://tools.ietf.org/html/draft-white-irs-use-case-00
(To be completely fair, draft-white did appear /first/ in the I-D archives, but IMO it's good to see that independent draft authors share similar needs :-).

My reason for suggesting this are as follows:
a)  If one takes a step back and looks at overall "SDN" landscape, Inter-Domain seems to not be visible on the radar (particularly for Openflow), for now.  This makes sense given Inter-Domain is hard problem to solve, given the legitimate concerns that raises wrt authentication/trust boundaries, etc.  Furthermore, the use cases described in I-D's, above, are about reading, digesting and then manipulating BGP characteristics /inside of/ one AS (sidestepping those thorny issues) ... however, clearly once information is injected into BGP it will get carried across AS boundaries, whose properties are already understood.  IMO, this solves a need that other SDN approaches have not (yet, if ever).
b)  When looking at BGP, as a whole, it seems like there may be a few different dimensions of the BGP protocol that might be a useful starting place for the initial scope of the I2RS work.  Namely, BGP is a protocol whose operation depends on policies -- specifically, routing policies that are largely defined offboard routers, but that need to be applied consistently across the _entire_ network of routers.  As one example, think of the need to classify some set of interfaces as belonging to "customers" vs. "peers" and, after that, applying different routing policies against those classes of BGP sessions.  Another example is here:
http://tools.ietf.org/html/draft-keyupate-irs-bgp-usecases-01#section-4.3
... where an operator needs to know which subset of routers are "Route Reflectors" in order to apply appropriate policy consistently on all of them, (in that case: defining RT's to filter routes send toward legacy PE's).  IMO, getting an early start on these routing policies and defining the semantics of how/where they apply to a subset of network elements in the network is extremely valuable and, ultimately, would benefit all future use cases of I2RS.
c)  Finally, as I noted in my presentation at IETF 85, BGP policy represents the overwhelming majority of configuration on routers and a substantial amount of the ongoing 'touches' to routers.  Thus, it makes sense to have a standardized, programmatic access to read and write such information on routers.

Finally, as an operator, I can certainly say that optimizing control over BGP *just Intra-AS* would be of a _substantial_ benefit.

Just my $0.02,

-shane