Re: [irs-discuss] Now you're all awake!
Thomas Nadeau <email@example.com> Tue, 13 November 2012 16:24 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E34021F849A for <firstname.lastname@example.org>; Tue, 13 Nov 2012 08:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([18.104.22.168]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8Qlrvol+zQz for <email@example.com>; Tue, 13 Nov 2012 08:23:59 -0800 (PST)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [22.214.171.124]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA6021F8475 for <firstname.lastname@example.org>; Tue, 13 Nov 2012 08:23:55 -0800 (PST)
Received: from P-EMHUB03-HQ.jnpr.net ([126.96.36.199]) (using TLSv1) by exprod7ob109.postini.com ([188.8.131.52]) with SMTP ID DSNKUKJ0GVWSfx/SeAYq7fLolIZwALuEc58W@postini.com; Tue, 13 Nov 2012 08:23:55 PST
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 184.108.40.206; Tue, 13 Nov 2012 08:21:28 -0800
Received: from o365mail.juniper.net (220.127.116.11) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 13 Nov 2012 08:21:28 -0800
Received: from tx2outboundpool.messaging.microsoft.com (18.104.22.168) by o365mail.juniper.net (22.214.171.124) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 13 Nov 2012 08:23:48 -0800
Received: from mail65-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 126.96.36.199; Tue, 13 Nov 2012 16:21:26 +0000
Received: from mail65-tx2 (localhost [127.0.0.1]) by mail65-tx2-R.bigfish.com (Postfix) with ESMTP id 8B40E1A0122 for <email@example.com.FOPE.CONNECTOR.OVERRIDE>; Tue, 13 Nov 2012 16:21:26 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:188.8.131.52; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail65-tx2 (localhost.localdomain [127.0.0.1]) by mail65-tx2 (MessageSwitch) id 1352823684453087_24171; Tue, 13 Nov 2012 16:21:24 +0000 (UTC)
Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.240]) by mail65-tx2.bigfish.com (Postfix) with ESMTP id 67FE6A0063; Tue, 13 Nov 2012 16:21:24 +0000 (UTC)
Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (184.108.40.206) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 220.127.116.11; Tue, 13 Nov 2012 16:21:23 +0000
Received: from CH1PRD0511MB420.namprd05.prod.outlook.com ([169.254.9.137]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0233.004; Tue, 13 Nov 2012 16:21:22 +0000
From: Thomas Nadeau <firstname.lastname@example.org>
To: Shane Amante <email@example.com>
Thread-Topic: [irs-discuss] Now you're all awake!
Date: Tue, 13 Nov 2012 16:21:22 +0000
References: <firstname.lastname@example.org>, <43A3C76D-E3E8-4EF3-B511-A0DCF918B4DF@castlepoint.net>
Content-Type: text/plain; charset="us-ascii"
Cc: "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>
Subject: Re: [irs-discuss] Now you're all awake!
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Nov 2012 16:24:20 -0000
we should also include the corresponding topology use cases. Tom On Nov 13, 2012, at 8:57 AM, "Shane Amante" <email@example.com> wrote: > > On Nov 13, 2012, at 6:07 AM, Adrian Farrel <firstname.lastname@example.org> 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 > _______________________________________________ > irs-discuss mailing list > email@example.com > https://www.ietf.org/mailman/listinfo/irs-discuss >