Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3
Thomas Nadeau <tnadeau@juniper.net> Thu, 02 August 2012 20:04 UTC
Return-Path: <tnadeau@juniper.net>
X-Original-To: irs-discuss@ietfa.amsl.com
Delivered-To: irs-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DE411E8186 for <irs-discuss@ietfa.amsl.com>; Thu, 2 Aug 2012 13:04:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.433
X-Spam-Level:
X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TNq6oeaFj5U for <irs-discuss@ietfa.amsl.com>; Thu, 2 Aug 2012 13:04:28 -0700 (PDT)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC3211E8118 for <irs-discuss@ietf.org>; Thu, 2 Aug 2012 13:04:27 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUBrdSuMnni0w+kpZZPR6v39g9mHNNDaf@postini.com; Thu, 02 Aug 2012 13:04:28 PDT
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Aug 2012 13:04:17 -0700
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Aug 2012 13:04:15 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 2 Aug 2012 16:03:55 -0400
From: Thomas Nadeau <tnadeau@juniper.net>
To: Ning So <ningso@yahoo.com>, "irs-discuss@ietf.org" <irs-discuss@ietf.org>
Date: Thu, 02 Aug 2012 16:03:49 -0400
Thread-Topic: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3
Thread-Index: Ac1w6fJXeQP/ldO2QNKpD5Mb4K++3g==
Message-ID: <CC401BBA.2CD6%tnadeau@juniper.net>
In-Reply-To: <CC4013B9.2CC8%tnadeau@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 20:04:31 -0000
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" <tnadeau@juniper.net> wrote: >They are at the bottom of the routing area meeting page: > >https://datatracker.ietf.org/meeting/84/agenda/rtgarea/ > >From: Ning So <ningso@yahoo.com<mailto:ningso@yahoo.com>> >Reply-To: Ning So <ningso@yahoo.com<mailto:ningso@yahoo.com>> >Date: Thursday, August 2, 2012 10:46 AM >To: "irs-discuss@ietf.org<mailto:irs-discuss@ietf.org>" ><irs-discuss@ietf.org<mailto:irs-discuss@ietf.org>> >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: "irs-discuss-request@ietf.org<mailto:irs-discuss-request@ietf.org>" ><irs-discuss-request@ietf.org<mailto:irs-discuss-request@ietf.org>> >To: irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >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 > irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> > >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 > irs-discuss-request@ietf.org<mailto:irs-discuss-request@ietf.org> > >You can reach the person managing the list at > irs-discuss-owner@ietf.org<mailto:irs-discuss-owner@ietf.org> > >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 ><susan.hares@huawei.com<mailto:susan.hares@huawei.com>> 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:akatlas@gmail.com<mailto:akatlas@gmail.com>] >> Sent: Wednesday, August 01, 2012 3:51 PM >> To: Susan Hares >> Cc: Joel M. Halpern; irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >> 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 >><susan.hares@huawei.com<mailto:susan.hares@huawei.com>> 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:akatlas@gmail.com<mailto:akatlas@gmail.com>] >>> Sent: Monday, July 30, 2012 6:33 PM >>> To: Susan Hares >>> Cc: Joel M. Halpern; irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>> 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 >>><susan.hares@huawei.com<mailto:susan.hares@huawei.com>> 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: >>>>irs-discuss-bounces@ietf.org<mailto:irs-discuss-bounces@ietf.org> >>>>[mailto:irs-discuss-bounces@ietf.org<mailto:irs-discuss-bounces@ietf.or >>>>g>] On Behalf Of Joel M. Halpern >>>> Sent: Monday, July 30, 2012 3:15 PM >>>> To: irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>>> 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, >>>>internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> 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 >>>> irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>> _______________________________________________ >>>> irs-discuss mailing list >>>> irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>>> 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 >><susan.hares@huawei.com<mailto:susan.hares@huawei.com>> 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:akatlas@gmail.com<mailto:akatlas@gmail.com>] >>> Sent: Monday, July 30, 2012 6:33 PM >>> To: Susan Hares >>> Cc: Joel M. Halpern; irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>> 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 >>><susan.hares@huawei.com<mailto:susan.hares@huawei.com>> 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: >>>>irs-discuss-bounces@ietf.org<mailto:irs-discuss-bounces@ietf.org> >>>>[mailto:irs-discuss-bounces@ietf.org<mailto:irs-discuss-bounces@ietf.or >>>>g>] On Behalf Of Joel M. Halpern >>>> Sent: Monday, July 30, 2012 3:15 PM >>>> To: irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>>> 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, >>>>internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> 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 >>>> irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>> _______________________________________________ >>>> irs-discuss mailing list >>>> irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>>> 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:akatlas@gmail.com<mailto:akatlas@gmail.com>] >Sent: Wednesday, August 01, 2012 3:41 PM >To: Susan Hares >Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; >irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >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 ><susan.hares@huawei.com<mailto:susan.hares@huawei.com>> 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:akatlas@gmail.com<mailto:akatlas@gmail.com>] >> Sent: Monday, July 30, 2012 6:40 PM >> To: Susan Hares >> Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; >>irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >> 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 >><susan.hares@huawei.com<mailto:susan.hares@huawei.com>> 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: >>>irs-discuss-bounces@ietf.org<mailto:irs-discuss-bounces@ietf.org> >>>[mailto:irs-discuss-bounces@ietf.org<mailto:irs-discuss-bounces@ietf.org >>>>] On Behalf Of Nitin Bahadur >>> Sent: Monday, July 30, 2012 3:33 PM >>> To: James Kempf; Thomas Nadeau; >>>irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>> 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" >>><james.kempf@ericsson.com<mailto:james.kempf@ericsson.com>> 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: >>>>irs-discuss-bounces@ietf.org<mailto:irs-discuss-bounces@ietf.org> >>>> >>>>[mailto:irs-discuss-bounces@ietf.org<mailto:irs-discuss-bounces@ietf.or >>>>g>] On Behalf Of Thomas Nadeau >>>> Sent: Monday, July 30, 2012 11:18 AM >>>> To: irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>>> 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 >>>> irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>> >>> _______________________________________________ >>> irs-discuss mailing list >>> irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>> https://www.ietf.org/mailman/listinfo/irs-discuss >>> >>> _______________________________________________ >>> irs-discuss mailing list >>> irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>> https://www.ietf.org/mailman/listinfo/irs-discuss >>> _______________________________________________ >>> irs-discuss mailing list >>> irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >>> 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 >irs-discuss@ietf.org<mailto:irs-discuss@ietf.org> >https://www.ietf.org/mailman/listinfo/irs-discuss > > >_______________________________________________ >irs-discuss mailing list >irs-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/irs-discuss
- Re: [irs-discuss] irs-discuss Digest, Vol 2, Issu… Ning So
- Re: [irs-discuss] irs-discuss Digest, Vol 2, Issu… Julien Meuric
- Re: [irs-discuss] irs-discuss Digest, Vol 2, Issu… Thomas Nadeau
- Re: [irs-discuss] irs-discuss Digest, Vol 2, Issu… Thomas Nadeau
- Re: [irs-discuss] irs-discuss Digest, Vol 2, Issu… Thomas Nadeau