Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3

[Thomas Nadeau <[e-mail]>]

They are at the bottom of the routing area meeting page:

https://datatracker.ietf.org/meeting/84/agenda/rtgarea/

From: Ning So <[e-mail]<mailto:[e-mail]>>
Reply-To: Ning So <[e-mail]<mailto:[e-mail]>>
Date: Thursday, August 2, 2012 10:46 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3

All,

Is Alia's presentation loaded anywhere?  It's not on the meeting agenda page.

Ning

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
To: [e-mail]<mailto:[e-mail]>
Sent: Thursday, August 2, 2012 1:20 AM
Subject: irs-discuss Digest, Vol 2, Issue 3

----- Forwarded Message -----

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/irs-discuss

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send irs-discuss mailing list submissions to
    [e-mail]<mailto:[e-mail]>

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/listinfo/irs-discuss
or, via email, send a message with subject or body 'help' to
    [e-mail]<mailto:[e-mail]>

You can reach the person managing the list at
    [e-mail]<mailto:[e-mail]>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of irs-discuss digest..."

Today's Topics:

  1. Re: I-D Action: draft-ward-irs-framework-00.txt (Alia Atlas)
  2. Re: I-D Action: draft-ward-irs-framework-00.txt (Joel M. Halpern)
  3. Re: IRS Problem Statement Posted (Susan Hares)
  4. Re: Thoughts on draft-ward-irs-framework (Russ White)
Thanks!

On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
> Alia:
>
> I'll try to create a bibliography of things people should read.  It will be mid-next week since I'm away from my home library on the SDN topic.
>
> Sue
>
> -----Original Message-----
> From: Alia Atlas [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Wednesday, August 01, 2012 3:51 PM
> To: Susan Hares
> Cc: Joel M. Halpern; [e-mail]<mailto:[e-mail]>
> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>
> Sue,
>
> I look forward to talking with you more off-line on the policy and
> local-pref research and issues.  If you have suggestions on good
> background research to read, by all means send it to the list so
> others can get up to speed as well.
>
> On the atomic transaction semantics question, let's get a bit further
> into the use-cases and framework - and then have a focused discussion.
>  I'm not opposed to it forever or if it is necessary - just would like
> to thoroughly analyze if it is a real requirement.
>
> Do others have opinions and perspective on this?
>
> Alia
>
> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
>> Alia:
>>
>> The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me".
>>
>> It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer.  You need to look at the MIF WG (+/-) for some of the struggles of mobility.
>>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[e-mail]<mailto:[e-mail]>]
>> Sent: Monday, July 30, 2012 6:33 PM
>> To: Susan Hares
>> Cc: Joel M. Halpern; [e-mail]<mailto:[e-mail]>
>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>
>> Hi Sue,
>>
>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
>>> Joel and irs-folks:
>>>
>>> +1 on Joel.
>>>
>>>  Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth.
>>
>> [Alia] Can you further clarify, maybe with an example, which aspect
>> you are thinking of?  Do you mean the ability of an application to
>> access multiple sub-interfaces?  The interaction of operations
>> requested by differerent applications?
>>
>>> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.
>>
>> [Alia] I'm pretty sure that I avoided the word "transaction" in both
>> drafts.  That was deliberate.  Of course, we can have a discussion
>> about whether or not some form of transactions might be desirable.  I
>> am concerned about their potentially heavy-weight nature.
>>
>>> Therefore, you've skipped even requiring the hard problems.
>>
>> [Alia] Can I optimistically pretend that means that the requirements
>> we do have don't seem too hard?  For the responsiveness and throughput
>> goals, I've put a stake in the ground to avoid transaction-based
>> semantics.  Naturally, the hordes can run over that stake, if
>> necessary.
>>
>> [Sue]: The requirements are necessary even if they are hard.
>>
>> [Alia] For the interaction between different layers of sub-interfaces,
>> I've been assuming that we'll define the interactions between the
>> layers based on how they are generally done.  For instance, perhaps we
>> standardize the idea of preference value - and then the RIB can pick
>> the best route based upon those preferences.  For interaction between
>> different applications, I think there's a mixture of
>> authorization/authentication to get right plus a good set of events
>> that an application could register for.
>>
>> [Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement.  However, it breaks down to prioritization that is pre-set by preferences.
>>
>> The policy issues behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am.
>>
>>> Is this just the -00.draft?
>>
>> [Alia] Certainly, I expect that we'll uncover more requirements as we
>> go along.  As I said, some of this is initially setting parts  out of
>> scope.
>>
>> ---> Scope == good.  Setting scope allows us to pick a piece of this work and standardize it for interoperability.
>>
>> Alia
>>
>>> Sue
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Joel M. Halpern
>>> Sent: Monday, July 30, 2012 3:15 PM
>>> To: [e-mail]<mailto:[e-mail]>
>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>
>>> I am finding this document quite confusing.
>>>
>>> The primary confusion is that the document first says that it is about
>>> information that can not be manipulated with existing systems, and then
>>> proceeds to give a list of use cases all of which can be manipulated
>>> with existing systems at a suitable degree of abstraction.
>>>
>>> As a lesser confusion, the document says that "streaming" is important,
>>> but then describes "streaming" as "fast, interactive access."  That is
>>> not streaming.  And depending upon what one means by interactive, plenty
>>> of systems provide "fest, interactive access."  I realize the document
>>> later goes on tot talk about speed and frequency of state updates.  But
>>> that section simply reasserts the earlier terms withotu better
>>> description or justification.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/30/2012 2:08 PM, [e-mail]<mailto:[e-mail]> wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>
>>>>
>>>>      Title          : Interface to the Routing System Framework
>>>>      Author(s)      : Alia Atlas
>>>>                            Thomas Nadeau
>>>>                            Dave Ward
>>>>      Filename        : draft-ward-irs-framework-00.txt
>>>>      Pages          : 21
>>>>      Date            : 2012-07-30
>>>>
>>>> Abstract:
>>>>    This document describes a framework for a standard, programmatic
>>>>    interface for full-duplex, streaming state transfer in and out of the
>>>>    Internet's routing system.  It lists the information that might be
>>>>    exchanged over the interface, and describes the uses of an interface
>>>>    to the Internet routing system.
>>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss

With regard to transaction issues, we discussed this extensively when
doing ForCES.  We concluded that the answer we needed was "yes and no".
  That is, the protocol has mechanisms which can be used for
transactional integrity, including integrity across interactions with
multiple FEs.  However, the protocol does not require the CE to use
those mechanisms.  In fact, if it does not even want explicit acks (the
messages go over TCP), it can defer that until it gets to a good "please
confirm" point.
And in the efforts to use this later, having this range of options has
been useful.

Yours,
Joel

On 8/1/2012 6:51 PM, Alia Atlas wrote:
> Sue,
>
> I look forward to talking with you more off-line on the policy and
> local-pref research and issues.  If you have suggestions on good
> background research to read, by all means send it to the list so
> others can get up to speed as well.
>
> On the atomic transaction semantics question, let's get a bit further
> into the use-cases and framework - and then have a focused discussion.
>  I'm not opposed to it forever or if it is necessary - just would like
> to thoroughly analyze if it is a real requirement.
>
> Do others have opinions and perspective on this?
>
> Alia
>
> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
>> Alia:
>>
>> The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me".
>>
>> It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer.  You need to look at the MIF WG (+/-) for some of the struggles of mobility.
>>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[e-mail]<mailto:[e-mail]>]
>> Sent: Monday, July 30, 2012 6:33 PM
>> To: Susan Hares
>> Cc: Joel M. Halpern; [e-mail]<mailto:[e-mail]>
>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>
>> Hi Sue,
>>
>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
>>> Joel and irs-folks:
>>>
>>> +1 on Joel.
>>>
>>>  Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth.
>>
>> [Alia] Can you further clarify, maybe with an example, which aspect
>> you are thinking of?  Do you mean the ability of an application to
>> access multiple sub-interfaces?  The interaction of operations
>> requested by differerent applications?
>>
>>> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.
>>
>> [Alia] I'm pretty sure that I avoided the word "transaction" in both
>> drafts.  That was deliberate.  Of course, we can have a discussion
>> about whether or not some form of transactions might be desirable.  I
>> am concerned about their potentially heavy-weight nature.
>>
>>> Therefore, you've skipped even requiring the hard problems.
>>
>> [Alia] Can I optimistically pretend that means that the requirements
>> we do have don't seem too hard?  For the responsiveness and throughput
>> goals, I've put a stake in the ground to avoid transaction-based
>> semantics.  Naturally, the hordes can run over that stake, if
>> necessary.
>>
>> [Sue]: The requirements are necessary even if they are hard.
>>
>> [Alia] For the interaction between different layers of sub-interfaces,
>> I've been assuming that we'll define the interactions between the
>> layers based on how they are generally done.  For instance, perhaps we
>> standardize the idea of preference value - and then the RIB can pick
>> the best route based upon those preferences.  For interaction between
>> different applications, I think there's a mixture of
>> authorization/authentication to get right plus a good set of events
>> that an application could register for.
>>
>> [Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement.  However, it breaks down to prioritization that is pre-set by preferences.
>>
>> The policy issues behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am.
>>
>>> Is this just the -00.draft?
>>
>> [Alia] Certainly, I expect that we'll uncover more requirements as we
>> go along.  As I said, some of this is initially setting parts  out of
>> scope.
>>
>> ---> Scope == good.  Setting scope allows us to pick a piece of this work and standardize it for interoperability.
>>
>> Alia
>>
>>> Sue
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Joel M. Halpern
>>> Sent: Monday, July 30, 2012 3:15 PM
>>> To: [e-mail]<mailto:[e-mail]>
>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>
>>> I am finding this document quite confusing.
>>>
>>> The primary confusion is that the document first says that it is about
>>> information that can not be manipulated with existing systems, and then
>>> proceeds to give a list of use cases all of which can be manipulated
>>> with existing systems at a suitable degree of abstraction.
>>>
>>> As a lesser confusion, the document says that "streaming" is important,
>>> but then describes "streaming" as "fast, interactive access."  That is
>>> not streaming.  And depending upon what one means by interactive, plenty
>>> of systems provide "fest, interactive access."  I realize the document
>>> later goes on tot talk about speed and frequency of state updates.  But
>>> that section simply reasserts the earlier terms withotu better
>>> description or justification.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/30/2012 2:08 PM, [e-mail]<mailto:[e-mail]> wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>
>>>>
>>>>        Title          : Interface to the Routing System Framework
>>>>        Author(s)      : Alia Atlas
>>>>                            Thomas Nadeau
>>>>                            Dave Ward
>>>>        Filename        : draft-ward-irs-framework-00.txt
>>>>        Pages          : 21
>>>>        Date            : 2012-07-30
>>>>
>>>> Abstract:
>>>>      This document describes a framework for a standard, programmatic
>>>>      interface for full-duplex, streaming state transfer in and out of the
>>>>      Internet's routing system.  It lists the information that might be
>>>>      exchanged over the interface, and describes the uses of an interface
>>>>      to the Internet routing system.
>>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>

Alia:

I'm going to check with a colleague who has been doing lots of model work to see if he's got a better.  More later.

Sue

-----Original Message-----
From: Alia Atlas [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, August 01, 2012 3:41 PM
To: Susan Hares
Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [e-mail]<mailto:[e-mail]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Sue,

In this case, I was thinking of "translating" from a "higher
abstraction layer" to a "lower abstraction layer".

Do you have a better/different term to suggest?  I agree that clarity
of terminology is important.

Alia

On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
> Alia:
>
> +1 on abstraction + filters (abstract/detail) IRS fits at the routing control.
>
> The real question about translation is what the translation is doing.  Is it translating one thing to another at the same layer of abstraction (e.g., Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail change.
>
> I define translation as the same layer of abstraction.  Some people suggest translation = abstract/detailing.  We first need a common way to talk about the difference.
>
> Sue
>
> By the way --- I'm thrilled about the pace of the discussion.
>
>
> -----Original Message-----
> From: Alia Atlas [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Monday, July 30, 2012 6:40 PM
> To: Susan Hares
> Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [e-mail]<mailto:[e-mail]>
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>
> Sue,
>
> I certainly agree that we want IRS to have the ability to express
> information at different abstraction layers and filtered on request.
>
> There may still be a gap between the "network OS abstractions" and IRS
> sub-interfaces; I'd be surprised if there weren't.  IRS is to provide
> the bottom-up control strings.
>
> IMHO, it's reasonable to have an entity that manages the translation.
> For instance, one doesn't need a PCE-equiv in every application - nor
> in every router; that might be an entity in between.
>
> The quantity of information is part of why explicit filtering and
> hopefully abstraction layers should be built into the data-models.
>
> Alia
>
> On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
>> Nitin:
>>
>> Exposing some network intelligence can either be done in detail or in some amount of summarization.
>> If you are doing detail, you have bandwidth issues. If you are doing summarization or opacity, you are talking about layers of information.
>>
>> Apps need to find out what they need to get. They do not need all the details - just the fact they can get from point A to Point B (or for multi-cast B/C/D). They need to where they can go to date other applications.  They need a match-maker for the application who determine where the applications shall flow.  Now, if they are smart - like people going out to eat - they pick several ways go to eat traffic.
>>
>> The network orchestration then serves to be the paths to the place to eat.  This can either be distributed or centralized.
>>
>> If we have an Interface to routing, it need to have a two-layer concept of exposing information.
>>
>> Sue Hares
>>
>> -----Original Message-----
>> From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Nitin Bahadur
>> Sent: Monday, July 30, 2012 3:33 PM
>> To: James Kempf; Thomas Nadeau; [e-mail]<mailto:[e-mail]>
>> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>
>> Hi James,
>>
>> This is not about splitting control plane and forwarding plane. It is about exposing network intelligence in the network elements to an external controller.
>> And it is about allowing an external controller to use that information for enabling network-aware apps. And it is about allowing apps to influence the
>> network element's RIB (not the FIB directly).
>>
>> Streaming is essential to allow for operations at scale...and avoid a request/response gated mechanism.
>>
>> Hope that helps.
>>
>> Thanks
>> Nitin
>>
>> On 7/30/12 3:11 PM, "James Kempf" <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> I don't understand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole.
>>
>> I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework.
>>
>>                jak
>>
>>> -----Original Message-----
>>> From: [e-mail]<mailto:[e-mail]>
>>> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Thomas Nadeau
>>> Sent: Monday, July 30, 2012 11:18 AM
>>> To: [e-mail]<mailto:[e-mail]>
>>> Subject: [irs-discuss] IRS Problem Statement Posted
>>>
>>>
>>>
>>> Please review and discuss.
>>>
>>> Thanks,
>>>
>>> Tom, Alia, Ward
>>>
>>>
>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>
>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>> _______________________________________________
>> irs-discuss mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/irs-discuss


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