Re: [irs-discuss] Thoughts on draft-ward-irs-framework

[Alia Atlas <[e-mail]>]

Hi Russ,

Thanks for the good suggestions and comments.

I do agree that an internal representation for the IRS as it interacts
with the RIB and learning events is basically as "another routing
process" and those are the general semantics to describe.  One
difference, though, is the idea that different static routes installed
by IRS may want to have different preference values.

I also think that describing the IRS sub-interface for installing
static routes in such a fashion would provide the necessary process id
tag for origin in the RIB.  If more detail is needed, then that can
give a correct path to query.

I do think these aspects are more on the internal implementation side
than on the data-model or information-model side.  As much as they are
useful to describe the desired interactions, I think they are good to
capture.

On use-cases, I would be delighted to have your thoughts on examples
written down, even in email to the list.   What is in the framework
draft is explicitly not the motivating use-cases, but just some
instances of what is possible with the described IRS sub-interfaces.

If there is sufficient interest in IRS, I think that one of the first
focuses needs to be identifying a few (2-4) vertical use-cases with
feedback loops (topology, events, measurements up as well as installed
state down) that we can use to drive the data-model definitions and
desired functionality.

Thanks,
Alia

On Tue, Jul 31, 2012 at 8:41 PM, Russ White <[e-mail]> wrote:
>
> This framework is well put together, but I'd like to make a couple of
> suggestions/comments/put some ideas forward.
>
> 1. I think the draft struggles somewhat with describing something that's
> already in all routers today because it's attempting to describe an
> interface into the RIB that's somehow separate, or stands beside, the
> existing interfaces into the RIB. I would gently suggest that describing
> this entire idea as an "off board routing process," much like a BGP
> process on an existing implementation, might clarify things a bit, and
> make the model easier to understand.
>
> Consider --any given routing process already installs routes into the
> routing table, including the concept of preference. BGP routing
> processes, specifically, also have import and export capabilities into
> various VRFs. All routing processes also have redistribution capabilities.
>
> What if you modeled this entire thing as two types of "off board routing
> processes," one that only imports data from the RIB for northbound
> consumption (topology information), and one that interacts with the RIB
> like any other routing process would for southbound control as well as
> northbound consumption?
>
> It's going to be much easier to interact with the other routing
> protocols on the box without a lot of "special pleading" if IRS is a
> process that's peer to BGP, OSPF, IS-IS, et al. Take the instance of
> link down notifications --all the implementations I know of process link
> downs in the RIB, and the RIB then notifies the routing protocol... If
> you're hooking into the RIB locally, then, you need to hook into link
> down detection specifically and intentionally. If IRS is a routing
> process, the RIB will notify the northbound interface as a matter of
> course in processing link down notifications.
>
> I hope that makes sense, but I'm glad to sit and discuss if it doesn't.
>
> 2. There needs to be a way to mark routes inserted in the RIB with a
> process ID of some sort. This would come naturally if the entire IRS
> idea were to put an "off board routing process" on the box that
> interacts with existing on board processes (see #1 above), but as the
> draft stands, there's no way to insert a process id into the RIB. This
> is crucial for redistribution, and I suspect redistribution is going to
> be a huge problem to address in the long term, since the routes injected
> by IRS, however they're injected, will need to interact with the dynamic
> protocols running on the box.
>
> 3. There are a ton of other possible use cases, if more are
> needed/wanted to support the reasoning behind the draft. Choosing the
> optimal exit from any given edge (OER in cisco lingo), a superset of
> Flowspec to combat DDoS is another (mentioned tangentially, but not as a
> use case), live/live is another (packet replication and choosing the
> best of two identical streams) --and there are others... Some of these
> might actually be more interesting use cases than are currently
> described in the draft.
>
> More if I get the chance to reread it in a little more depth later.
>
> HTH
>
> Russ
>
> --
> <><
> [e-mail]
> [e-mail]
> _______________________________________________
> irs-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss