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

[Julien Meuric <[e-mail]>]

http://www.ietf.org/proceedings/84/slides/slides-84-rtgarea-3.pptx (from 
https://datatracker.ietf.org/meeting/84/materials.html)

Julien


Le 02/08/2012 19:46, Ning So a écrit :
> All,
> Is Alia's presentation loaded anywhere?  It's not on the meeting 
> agenda page.
> Ning
>
> *From:* "[e-mail]" <[e-mail]>
> *To:* [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
>
>
>
>
> _______________________________________________
> irs-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss