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

[Thomas Nadeau <[e-mail]>]

        Apologies for the typo:

http://www.lucidvision.com/draft-ward-irs-framework-00e.pptx



On 8/2/12 1:03 PM, "Thomas Nadeau" <[e-mail]> wrote:

>
>        Apologies, they appear to not be there.  In the meantime, you can
>find
>them here:
>
>http://www.lucidvision.com/draft-ward-irs-framework-00d.ppt
>
>
>On 8/2/12 11:23 AM, "Thomas Nadeau" <[e-mail]> wrote:
>
>>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:irs-discuss-bounces@ietf.o
>>>>>r
>>>>>g>] 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:irs-discuss-bounces@ietf.o
>>>>>r
>>>>>g>] 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]
>>>>g
>>>>>] 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:irs-discuss-bounces@ietf.o
>>>>>r
>>>>>g>] 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
>
>_______________________________________________
>irs-discuss mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/irs-discuss