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

[Russ White <[e-mail]>]

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

==