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

[Thomas Nadeau <[e-mail]>]

we should also include the corresponding topology use cases.

Tom 

On Nov 13, 2012, at 8:57 AM, "Shane Amante" <[e-mail]> wrote:

> 
> On Nov 13, 2012, at 6:07 AM, Adrian Farrel <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>