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

From: Alia Atlas <[email-masked]>
Date: Wed, 1 Aug 2012 09:52:21 -0400

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 <[email-masked]> 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
>
> --
> <><
> [email-masked]
> [email-masked]
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

---

From: Susan Hares <[email-masked]>
Date: Wed, 1 Aug 2012 19:38:00 +0000

Russ: 

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

----> [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. 

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

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

Russ

---

From: Russ White <[email-masked]>
Date: Thu, 02 Aug 2012 01:20:34 -0400

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

Here are three I just threw together. We can talk about refining these
tomorrow, if you like... My fingers got tired before my brain did. :-)

Russ

==
Optimized Exit Use Case

Assume you have a network where there are two possible exit points
towards any set of destinations. The cost of using these links varies by
time, and the quality of the links is highly variable, but not
necessarily related to the actual load the local network is putting on
them (in other words, these are oversubscribed links shared with other
parallel networks or customers with unpredictable traffic patterns).
What you'd like to do is to use the lowest cost link until the quality
of the link reaches a specific level, and then switch to the higher cost
link. The point at which this link switch might occur may vary based on
time of day, because the RTO on specific traffic levels varies by the
time of day as well.

So you have a problem with multiple variables: link quality (apparently
random from your perspective), link cost (varies by time of day), return
on investment (varies by time of day). Combined with this you have
multiple exit points, and you must draw traffic from an inside network
as efficiently as possible to the best exit point, as determined by
these various factors.

The only well defined way to resolve this problem is to feed the
variables to an off router controller, calculate the best exit point on
some periodic basis, and then feed this information back into the
routing table. All solutions that can solve this problem today use route
injection into BGP, static route injection, or some other means to
direct traffic --difficult and error prone mechanisms. All of these
solutions also draw traffic only along links between the edge routers
themselves to put traffic on the best possible outbound link.

With IRS, the best path could be calculated using any number of custom
written mechanisms, and the routes injected into the right places in the
network to effect the most efficient drawing of traffic to the best exit
point. Changes in the network environment could quickly cause traffic to
be shifted to alternate exit points when circumstances dictate.

==
Denial of Service

FlowSpec is designed to allow an AS to push a filter upstream, with the
ultimate goal being to block the source of DDoS and other attacks as
close to the origin of those attacks as possible. There are some
situations, however, where you would prefer to block an attack at all
edges, or throughout an entire local network. For instance, you might
want to block the forwarding of traffic within your network while you
are pushing FlowSpec updates upstream to block the traffic closer to the
source, or you might be dealing with an attack originating from multiple
points within your own network.

While these responses are possible with standard routing, there is a
strong case to be made that routing information should not be mixed with
security response information within the routing domain (within an AS).
Mixing these two types of information can make network management more
difficult, and slow down the repair of a network during large scale
failures. It would be simpler to have a single controller in a network
tied to the various attack detection mechanisms that could directly
install the correct routing information to pull all attack traffic to a
central location, or to simply route the traffic to a null interface.

An related use is that of pulling unknown traffic through specific
devices for analysis. A network operator may not want to drive all
traffic through traffic analysis devices simply because of cost and
quality of service degredation. A network operator could use IRS to
directly modify the routing tables on devices in the path of unknown or
possibly dangerous flows so this traffic is pulled through the correct
monitoring and analysis devices.

==
Remote Service Routing

In hub and spoke overlay networks, there is always an issue with
balancing between the information held in the spoke routing table,
optimal routing through the network underlying the overlay, and
mobility. Most solutions in this space use some form of centralized
route server that acts as a directory of all reachable destinations and
next hops, a protocol by which spoke devices and this route server
communicate, and caches at the remote sites.

An IRS solution would use the same elements, but with a different
control plane. Remote sites would register (or advertise through some
standard routing protocol, such as BGP), the reachable destinations at
each site, along with the address of the router (or other device) used
to reach that destination. These would, as always, be stored in a route
server (or several redundant route servers) at a central location.

When a remote site sends a set of packets to the central location that
are eventually destined to some other remote site, the central location
can forward this traffic, but at the same time simply directly insert
the correct routing information into the remote site's routing table. If
the location of the destination changes, the route server can directly
modify the routing information at the remote site as needed.
An interesting aspect of this solution is that no new and specialized
protocols are needed between the remote sites and the centralized route
server(s). Normal routing protocols can be used to notify the
centralized route server(s) of modifications in reachability
information, and the route server(s) can respond as needed, based on
local algorithms optimized for a particular application or network. For
instance, short lived flows might be allowed to simply pass through the
hub site with no reaction, while longer lived flows might warrant a
specific route to be installed in the remote router. Algorithms can also
be developed that would optimize traffic flow through the overlay, and
also to remove routing entries from remote devices when they are no
longer needed based on far greater intelligence than simple non-use for
some period of time.

==

---

From: Russ White <[email-masked]>
Date: Thu, 02 Aug 2012 01:26:06 -0400

> ----> [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…

If we just insert the information into "yet another process" parallel
with the already existing routing processes on the hardware, I think we
shunt aside the problems with insertion speed, etc. Routes installed in
this "off board interface routing process" would be handled just like
routes learned through other sources. Any improvements in the speed of
route insertion from, say, OSPF running on the box would be reflected in
speed improvements for IRS. IMHO, this is a huge win overall.

> One

All the implementations I've worked with have the ability to install
routes from a single process with different preferences. If no
preference is specifically stated, the process' preference is used.
Specific per route preferences override these, though --see, for
instance, the EIGRP distance command in IOS. I suspect all
implementations have the ability to handle this sort of thing in the API
between each routing process and the RIB, but it's just not used a lot.

:-)

Russ

---

From: Alia Atlas <[email-masked]>
Date: Thu, 2 Aug 2012 01:30:54 -0400

K - so the idea of the IRS sub-interface to the RIB being semantically
similar to another routing process sounds like an initially useful way
of describing it - but we're going to want to qualify out what that
means in terms of interactions and into the appropriate description &
models.

Alia

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 2 Aug 2012 09:24:43 -0700

Russ,

	These are very cool. Thanks for posting them.  It would be great to get these into draft form and online. 8)

	--Tom

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 02 Aug 2012 19:45:48 +0200

Q1:

I have seen a framework slide showing IRS Agent withing the router.

I would like to clarify if you are going to have such IRS Agent in each 
router participating in given (maybe new) service in the AS ? How many 
IRS clients your envision ?

Is the model of 1000s of IRS agents talking to 10s of IRS clients as 
example ?

Q2:

Is data currently distributed by routing protocols explicitly prohibited 
to be also distributed by IRS overlay and send to the routers by TBD IRS 
channel ?

Thx a lot !
R.

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 2 Aug 2012 14:22:23 -0400

>Is the model of 1000s of IRS agents talking to 10s of IRS clients as

	That¹s been a bit of confusion.  The "agent" is the IRS interface on the
router. You could certainly have more htan one, but your implementation
would have to coordinate internally to make sure they can work together.
In the slides, its a logical representation.  Similarly, the "client"
component, is in the simple case, just the lib you import into the
application that understands the protocol; its not necessarily a
stand-alone thing.

>to be also distributed by IRS overlay and send to the routers by TBD IRS

	I think that is a reasonable question to ask.  I personally see it as
being valid to do both.

	--Tom