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

[Thomas Nadeau <[e-mail]>]

	
	Russ,

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

	--Tom

	
On Aug 1, 2012:10:20 PM, at 10:20 PM, Russ White <[e-mail]> wrote:

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