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

[Susan Hares <[e-mail]>]

Russ: 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Russ White
Sent: Tuesday, July 31, 2012 5:42 PM
To: [e-mail]
Subject: [irs-discuss] Thoughts on draft-ward-irs-framework


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?

----> [Russ]: +1 - This Offboard controller processing aligns with the ONF view of SDN.  And it has been done in practice for 10+ years. However as you know, the timing between the calculation and download to HW is important. 

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.

[Sue] See our work on Route servers (1990-1995) and current work - for an example.
This is what I mentioned above. 

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.

Sue: Use cases are key.  The clarity of the use cases will guide us.  Please send USE cases.

Russ

-- 
<><
[e-mail]
[e-mail]
_______________________________________________
irs-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/irs-discuss