Return-Path: 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 6F62A21F8907 for ; Tue, 31 Jul 2012 17:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 SmeDuo7ka6Vm for ; Tue, 31 Jul 2012 17:42:24 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 96A9C21F8900 for ; Tue, 31 Jul 2012 17:42:24 -0700 (PDT) Received: from dhcp-4151.meeting.ietf.org ([130.129.65.81]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SwN0z-0007aI-W2 for irs-discuss@ietf.org; Tue, 31 Jul 2012 17:42:18 -0700 Message-ID: <50187B55.407@riw.us> Date: Tue, 31 Jul 2012 20:41:57 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: irs-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: [irs-discuss] Thoughts on draft-ward-irs-framework X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 00:42:25 -0000 This framework is well put together, but I'd like to make a couple of suggestions/comments/put some ideas forward. 1. I think the draft struggles somewhat with describing something that's already in all routers today because it's attempting to describe an interface into the RIB that's somehow separate, or stands beside, the existing interfaces into the RIB. I would gently suggest that describing this entire idea as an "off board routing process," much like a BGP process on an existing implementation, might clarify things a bit, and make the model easier to understand. Consider --any given routing process already installs routes into the routing table, including the concept of preference. BGP routing processes, specifically, also have import and export capabilities into various VRFs. All routing processes also have redistribution capabilities. What if you modeled this entire thing as two types of "off board routing processes," one that only imports data from the RIB for northbound consumption (topology information), and one that interacts with the RIB like any other routing process would for southbound control as well as northbound consumption? It's going to be much easier to interact with the other routing protocols on the box without a lot of "special pleading" if IRS is a process that's peer to BGP, OSPF, IS-IS, et al. Take the instance of link down notifications --all the implementations I know of process link downs in the RIB, and the RIB then notifies the routing protocol... If you're hooking into the RIB locally, then, you need to hook into link down detection specifically and intentionally. If IRS is a routing process, the RIB will notify the northbound interface as a matter of course in processing link down notifications. I hope that makes sense, but I'm glad to sit and discuss if it doesn't. 2. There needs to be a way to mark routes inserted in the RIB with a process ID of some sort. This would come naturally if the entire IRS idea were to put an "off board routing process" on the box that interacts with existing on board processes (see #1 above), but as the draft stands, there's no way to insert a process id into the RIB. This is crucial for redistribution, and I suspect redistribution is going to be a huge problem to address in the long term, since the routes injected by IRS, however they're injected, will need to interact with the dynamic protocols running on the box. 3. There are a ton of other possible use cases, if more are needed/wanted to support the reasoning behind the draft. Choosing the optimal exit from any given edge (OER in cisco lingo), a superset of Flowspec to combat DDoS is another (mentioned tangentially, but not as a use case), live/live is another (packet replication and choosing the best of two identical streams) --and there are others... Some of these might actually be more interesting use cases than are currently described in the draft. More if I get the chance to reread it in a little more depth later. HTH Russ -- <>< riwhite@verisign.com russw@riw.us Return-Path: 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 388B321F853A for ; Tue, 31 Jul 2012 10:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 gHk+iqCrU2yp for ; Tue, 31 Jul 2012 10:08:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5F49121F8539 for ; Tue, 31 Jul 2012 10:08:50 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B524920BD9; Tue, 31 Jul 2012 19:08:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1gf4IDqtao9C; Tue, 31 Jul 2012 19:08:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C86020BD7; Tue, 31 Jul 2012 19:08:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 004BF20FD3FE; Tue, 31 Jul 2012 19:08:47 +0200 (CEST) Date: Tue, 31 Jul 2012 19:08:47 +0200 From: Juergen Schoenwaelder To: Alia Atlas Message-ID: <20120731170847.GE78653@elstar.local> References: <20120731144930.GA78451@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS problem statement and NETCONF/YANG X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:08:53 -0000 On Tue, Jul 31, 2012 at 12:56:04PM -0400, Alia Atlas wrote: > Hi Juergen, > > Thanks very much for your informative email. I certainly have more > reading to do on NetConf and would welcome help in correcting the > perspective in the appendix about NetConf. > > It sounds like NetConf could be a good candidate protocol when we get > there. As I've said, we've got to focus on clearly describing the > problem and vertical use-cases; then we should be able to think about > and evaluate protocol possibilities. > > Of course, it'd be useful to have a good accurate and up-to-date > understanding of the capabilities of each protocol before then. > > If you have time and interest, I'd be happy to chat off-line tomorrow > and have more NetConf/Yang clue installed. I agree that you should focus on "clearly describing the problem and vertical use-cases" first since that will help to understand the requirements. If you need NETCONF/YANG input, I am happy to help. I am around until Friday. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Return-Path: 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 2977121F86EF for ; Tue, 31 Jul 2012 09:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 O2zE-UDPq9zE for ; Tue, 31 Jul 2012 09:56:06 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEE521F86E8 for ; Tue, 31 Jul 2012 09:56:05 -0700 (PDT) Received: by yenq13 with SMTP id q13so6796266yen.31 for ; Tue, 31 Jul 2012 09:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c2o4pXNZPuoNyVa66iwRCvvAZdbHC9gckpuNK5/yAy8=; b=nDtT9e5iN0CDW7fsXT/f17tIYqTYTGrFmVPUjnHKvkf/mYLw8/EsKtpzuWX7xYNT7H 0cpqNvLFipt31DVsLUSZEMcU2NM0yLlGPVQ4muB+4HM94mt7zSm/3catguE6t/E9ArDC b03cs6MHiSygCCr2FIjsUnYCAp50FYRx5YQzMO9l93ZjgABsIR36jJNmdWMjY4AxgPBV 8piU/9GAKDrDxYoaPT5CpGVnR/pWEwltBVb+2a0PFxyRAnAcY0XU58v6ISwloiZ+Da2g ZkxZIUNShbbaavliQ3VcpiNhwQOAJZKamwXjhBNBsdq7aVM6G/12ydXF6qw0qJe0Di3I qvpw== MIME-Version: 1.0 Received: by 10.50.216.202 with SMTP id os10mr1304631igc.17.1343753764993; Tue, 31 Jul 2012 09:56:04 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Tue, 31 Jul 2012 09:56:04 -0700 (PDT) In-Reply-To: <20120731144930.GA78451@elstar.local> References: <20120731144930.GA78451@elstar.local> Date: Tue, 31 Jul 2012 12:56:04 -0400 Message-ID: From: Alia Atlas To: Juergen Schoenwaelder Content-Type: text/plain; charset=ISO-8859-1 Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS problem statement and NETCONF/YANG X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:56:07 -0000 Hi Juergen, Thanks very much for your informative email. I certainly have more reading to do on NetConf and would welcome help in correcting the perspective in the appendix about NetConf. It sounds like NetConf could be a good candidate protocol when we get there. As I've said, we've got to focus on clearly describing the problem and vertical use-cases; then we should be able to think about and evaluate protocol possibilities. Of course, it'd be useful to have a good accurate and up-to-date understanding of the capabilities of each protocol before then. If you have time and interest, I'd be happy to chat off-line tomorrow and have more NetConf/Yang clue installed. Alia On Tue, Jul 31, 2012 at 10:49 AM, Juergen Schoenwaelder wrote: > Hi, > > reading through the problem statement posted at > > http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt > > I noticed a number of statements concerning NETCONF and YANG that > probably need to be corrected. For more background where NETCONF and > YANG is, you may want to consult the tutorial slides posted at > > http://cnds.eecs.jacobs-university.de/slides/2012-ietf-84-netconf-yang.pdf > > and consult the documents referenced in the slides. Some more detailed > comments: > > : Finally, the IETF's Network Configuration (or NetConf) protocol has > : made many strides at overcoming most of the limitations around > : configuration that were just described. However, the lack of > : standard data models have hampered the adoption of NetConf. > > The NETMOD working group has been chartered to work on common core > data models and currently has core data models for the configuration > of network interfaces, ip interfaces and a core routing configuration > data model in WG last call: > > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-04 > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-05 > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-05 > > : While NetConf has solved many of the deficiencies present in SNMP in > : terms of configuration, it still does not satisfy a number of > : requirements needed to manage today's routing information. First, > : the lack of standard data models have hampered the adoption of > : NetConf; a significant amount of per-vendor customization is still > : needed. The transport mechanisms that are currently defined (e.g., > : SOAP/BEEP) for NetConf are not those commonly used by modern > : applications (e.g., ReST or JSON). > > The default to implement transport for NETCONF is SSH. There is > another transport over TLS. The BEEP and SOAP transports are on their > way to be declared historic. That said, there is work underway to > define a JSON / REST API to YANG modelled NETCONF data stores. > > http://tools.ietf.org/html/draft-bierman-netconf-yang-api-00 > http://tools.ietf.org/html/draft-lhotka-yang-json-00 > > : NetConf primarily facilitates configuration rather than reading of > : state or handling asynchronous events. > > Not sure what primarily facilitates means but NETCONF does support all > three functions. NETCONF allows read access to all existing SNMP > instrumentation of devices. > > : NetConf matches up to the key needed aspects as follows > : > : Multiple Simultaneous Asynchronous Operations: Not Possible > > The NETCONF protocol tags RPC invocations with a message-id that is > echoed back in RPC replies, allowing asynchronous operations. NETCONF > also provides global and partial locks to properly deal concurrent > operations received via multiple channels. > > : Configuration Not Re-Processed: Not Possible > > I simply do not understand the definition of this aspect. You document > says: > > : Configuration Not Re-Processed: When an IRS operation is processed, > : it does not require that any of the configuration be processed. > : I.e., the desired behavior is orthogonal to the static > : configuration. > > A clarficiation is needed what you mean with this. Anyway, NETCONF > distinguishes between different configuration data stores. If you want > to distinguish between changes that affect only the current behaviour > but not say the next startup behaviour (i.e. the changes do not > persist), then this is already supported by NETCONF. > > Perhaps your concern is that making a change requires to reprocess the > whole configuration? In that case, this is clearly not required > anywhere by the NETCONF protocol specification. In fact, the > edit-config operation allows to send detailed configuration change > sets to a NETCONF server. > > : Duplex: Not Possible - strict pull model. > > NETCONF does have support for event notifications that are pushed by > the device. The initiation of the session is client to server for the > existing transports - but this is mostly a property of the transports. > Some vendors use non-standard extensions for the SSH transport to > support device initiated sessions. > > : High-Throughput: Unlikely - Can depend on configuration size > > Well, this is ill defined in the first place. Your definition is: > > : High-Throughput: At a minimum, the IRS Agent and associated router > : should be able to handle hundreds of simple operations per second. > > So what is a "simple operation"? I am rather optimistic that it is > possible to do some "simple operation" in NETCONF at the requested > speed. To be useful, you really need to be more precise. > > : Responsive: Unlikely - Can depend on configuration size > > Again, this is under specified. Your definition is: > > : Responsive: It should be possible to complete simple operations > : within a sub-second time-scale. > > I am sure NETCONF servers easily respond within a sub-second > time-scale. We have several implementors here at the IETF, I > am sure they can provide more concrete information about the > efficiency aspects. > > : Multi-Channel: Not Possible > > NETCONF allows to use multiple SSH or TLS sessions (hence multiple TCP > sessions) and it provides the needed coordination primitives. In > addition, the SSH transport can be used to run multiple SSH channels > multiplexed over a single TCP session. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 8F3D321F86FD for ; Tue, 31 Jul 2012 09:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.852 X-Spam-Level: X-Spam-Status: No, score=-102.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 runbsDEWL4FW for ; Tue, 31 Jul 2012 09:49:12 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C88521F86D6 for ; Tue, 31 Jul 2012 09:49:12 -0700 (PDT) Received: by ggnc4 with SMTP id c4so6775548ggn.31 for ; Tue, 31 Jul 2012 09:49:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=VFTs5yVN4KxmzWu39WoX6K4TcC2JRGoD3EZugS6UfR4=; b=pYkGk3Ij9nmU7/9MlEXg+7mReIiKATlBO7tKJRJv61tgSPNSBOjV618NsXE4p1h+jr 32D98SRq5FetW8PQVFV2nbL426klHrXWG8JLVPWmICuF+edLW7JxTevZujpy6coKnXTL 2RnWAbcEOzQmNFidPGWEIvjqSAMqsFY4xS2i7Q2OxDRvnDwFLdBHpLMhIiaCGoef8LKN oI2GtjcPeC1M+0jQTHriCxSHQmIok7U5RfiewmshcRdAwwHt3UhsnCSl+CVh9Z5mglrH MWJGXclErfQ11XQvEPoaSxDDFAH4gJqpyPJbQsQI1/Ai1r66Y308kZk7VyxO9VI6jj0B W2ew== Received: by 10.60.28.101 with SMTP id a5mr24074204oeh.69.1343753351464; Tue, 31 Jul 2012 09:49:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.134.137 with HTTP; Tue, 31 Jul 2012 09:48:51 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Tue, 31 Jul 2012 12:48:51 -0400 Message-ID: To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnno6x0/2/3c2/4XFUhoRwU6d1glPYBaUhSeMZ1prra7Om8ZnoGexoS2am40B1RuXEChNjz Cc: Thomas Nadeau , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:49:12 -0000 On Tue, Jul 31, 2012 at 12:43 PM, Alia Atlas wrote: > Yes, I've heard the comments that ForCES may have good characteristics > for the protocol aspects of IRS. I think we need to focus on > discussing the problem and use-cases - before we start seriously > considering protocols. nod. cheers, jamal Return-Path: 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 895B121F86BD for ; Tue, 31 Jul 2012 09:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 V83iA5AxmdwV for ; Tue, 31 Jul 2012 09:43:33 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9817121F867E for ; Tue, 31 Jul 2012 09:43:33 -0700 (PDT) Received: by ggnc4 with SMTP id c4so6768320ggn.31 for ; Tue, 31 Jul 2012 09:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JiCfCjOulk4tKMlbTY1BX8pWjiSmOWepqMJRfH6Xg2Y=; b=HAfLJAEyNJm5gw1z1vWpjkqeJKxOFARaX3gKJsfxuCWK/fttIycVq/pyhG+f6FjvAR nFjbxVz6LedDzYvZlpNVmUjoj0hc9C9BMcCROXaUum4/P73//aVWMHGPkwToynWFl6OM yzbwqq/9ZXwolMoIhwRopxYc3nHVf6Fj5iOHL0zLoYB+pI0grGopjL2sGEuFQI7QXddg 25Sk/FiP581oNpe8d9DesVVjeI4uZef2ld9DopN8/jRPXMMXTti1NVmv7U/sqzrQkyA9 PK0Pt0seLXxTDRMWw+MfwGgeAP8zZwAInQkSQITBY6hcyRbbfxHDl/WIcWSgROy50iVD UHXg== MIME-Version: 1.0 Received: by 10.50.237.72 with SMTP id va8mr2594903igc.17.1343753012995; Tue, 31 Jul 2012 09:43:32 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Tue, 31 Jul 2012 09:43:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 Jul 2012 12:43:32 -0400 Message-ID: From: Alia Atlas To: Jamal Hadi Salim Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Nadeau , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:43:34 -0000 Yes, I've heard the comments that ForCES may have good characteristics for the protocol aspects of IRS. I think we need to focus on discussing the problem and use-cases - before we start seriously considering protocols. More information about them and their potential relevance is always welcome. Alia On Tue, Jul 31, 2012 at 12:40 PM, Jamal Hadi Salim wrote: > On Tue, Jul 31, 2012 at 12:30 PM, Alia Atlas wrote: > >> This is one of the key differences - ForCES is about programming the >> forwarding plane. IRS is about interfaces to the routing system - the >> lowest it goes is to the RIB layer. IMHO, this gives good control and >> abstraction - no need to model forwarding plane differences. That's >> what the router OS is for. > > Ok, guess i am going to have say something then;-> > While ForCES did start with intent to do control-datapath interfacing, > given that: we have a data model (and language); a protocol that is > agnostic of what the entity being configured is - over the last few > years it has been used for anything that can be modelled using > the ForCES language. Basically model it as an LFB and you are good > to go. > I am actually presenting on how we do parts of the FE management > plane via ForCES at a session today. In our implementation, this > is how we do remote debug settings, change syslog levels etc. > Nothing to do with a FIB table programming etc... > > cheers, > jamal Return-Path: 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 E5B4021F86AA for ; Tue, 31 Jul 2012 09:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.847 X-Spam-Level: X-Spam-Status: No, score=-102.847 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 OzVpSv1eYKwc for ; Tue, 31 Jul 2012 09:43:26 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECC221F867F for ; Tue, 31 Jul 2012 09:43:26 -0700 (PDT) Received: by qaea16 with SMTP id a16so1871674qae.10 for ; Tue, 31 Jul 2012 09:43:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=8cqYV1Qadl8leWeQ/tmR1x7ZWVAI8u48sBtrk5TNsSA=; b=FxVS8O6UK+jfoL9nORlKTyHSA0++Afx7DnrKAnRKu2MiVCRMiuw9EyyKf5pFxfWXBd 6MKvi9euZ60S5ISVOeMFHZhc5ynbU4OIBpI24qjFpHL3GqRvXUXzi1QugK6SVXvmHG56 Kk6Vv01jwKPhHHujZD6Zl+c93KudPha3bjBh8JZjTpZbjbwtSE5wv4OsNK/dXz5MDNLA iQkMMGRrJaGmnp+OfPrLkeS2Q8596OHc9i2GGILv0VlUm7ByfLYD1XhCV6wcL4ryag4h 5t0NOu7Gfu69UjA16yLMHAZwNH9L0Ia11OHhogdPTCM4iuoaEJZn6+zLmdUKmBVZeJiN t2NA== Received: by 10.60.2.131 with SMTP id 3mr24143433oeu.59.1343753005728; Tue, 31 Jul 2012 09:43:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.134.137 with HTTP; Tue, 31 Jul 2012 09:43:04 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Tue, 31 Jul 2012 12:43:04 -0400 Message-ID: To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkNyp0t8RTooMBrpNbUtTPAJAokaWs9dZ7OdJ6xfv5baMkDgaWTdF47pPnjcGOIf3Ly6drW Cc: Thomas Nadeau , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:43:27 -0000 On Tue, Jul 31, 2012 at 12:40 PM, Jamal Hadi Salim wrote: > Basically model it as an LFB and you are good > to go. Essentially from this perspective, theres a lot of parallels with protobufs or thrift. cheers, jamal Return-Path: 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 6ED1821F869E for ; Tue, 31 Jul 2012 09:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.841 X-Spam-Level: X-Spam-Status: No, score=-102.841 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 oYA0KGNn4DXs for ; Tue, 31 Jul 2012 09:41:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78D8D21F867F for ; Tue, 31 Jul 2012 09:41:06 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12382158obb.31 for ; Tue, 31 Jul 2012 09:41:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=RLITcF5MFXs3XhYce2IVH1NFG0sSDqnu7uv8Mw/PvuQ=; b=N6eGzAYe+m8FOI03/uVe8r1bGIPTeSa5jHlgksTtjj0WyPRG3te4fmG0280ZGfcrIF vQWErIz4jjlNtx5l7zkWePGTi93ejz3YpzkS2q1vvSVlJGYgt2CN7WnL1Lbv6SKeRSbV zp3/OrsohjNVeWtRSUDmQI1Gx1CpX9pQZhNbAVfYKf9VNTHGLXtrovE1v4SBluQURYja sl5JOP7yuTc35F0P1MyaGfg1jdFPqtOdkL6akxZxdtO2zUhyidR6JTGZ3oT6zIP28+gI vL6cefB64AUxmsVDHJfXOguN5l0jCqHt6ckimRc25mOUydbzy+WxGJjUWMJXtZ8hJUfW brRw== Received: by 10.182.117.71 with SMTP id kc7mr24159864obb.62.1343752866148; Tue, 31 Jul 2012 09:41:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.134.137 with HTTP; Tue, 31 Jul 2012 09:40:45 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Tue, 31 Jul 2012 12:40:45 -0400 Message-ID: To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQljFcmFhPYFnMjDZBxhNxafrCOK6ziv7kFHCaW22zDdiu9PzXMeiIROUp0+wVZJk7WUhQK0 Cc: Thomas Nadeau , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:41:07 -0000 On Tue, Jul 31, 2012 at 12:30 PM, Alia Atlas wrote: > This is one of the key differences - ForCES is about programming the > forwarding plane. IRS is about interfaces to the routing system - the > lowest it goes is to the RIB layer. IMHO, this gives good control and > abstraction - no need to model forwarding plane differences. That's > what the router OS is for. Ok, guess i am going to have say something then;-> While ForCES did start with intent to do control-datapath interfacing, given that: we have a data model (and language); a protocol that is agnostic of what the entity being configured is - over the last few years it has been used for anything that can be modelled using the ForCES language. Basically model it as an LFB and you are good to go. I am actually presenting on how we do parts of the FE management plane via ForCES at a session today. In our implementation, this is how we do remote debug settings, change syslog levels etc. Nothing to do with a FIB table programming etc... cheers, jamal Return-Path: 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 2767D21F8639 for ; Tue, 31 Jul 2012 09:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.835 X-Spam-Level: X-Spam-Status: No, score=-102.835 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 yUGZVFGufhVs for ; Tue, 31 Jul 2012 09:33:09 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9177D21F860B for ; Tue, 31 Jul 2012 09:33:09 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12372463obb.31 for ; Tue, 31 Jul 2012 09:33:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=wvbRZGy7aUUdj6ioIUx4gUklZQoihfQ8QEqG7ObxTtE=; b=AcGuXjVeEljqOiEvYFuLbwQdxQxbtqS+UZeH/i/Qz6AaFktT6XqPLBhlPoZajv1H85 QR9poyIAyBCMGXf/slgZJYFYIe3AXAJAgq4BH4a9YS2AehDqTeoGVepXjp/HTW+3d22D u/JUuvWM3tN7qdgR/KoVv6RA6MslNm2Qee+5s0FnrcNAPhQFrV8Y6itSSy8icXfGRyWD Xc6qtqxgZ0PiRjxxGnSCdVz4Z1AtO9IdXStJG6TwUkh6PqDa+tteMXjJeTfKT6NMkMZj nsgSQVibsJrVLrYG2Dn1jzILonAbvarj/fMr+3zo8LPT4L7Y0XuNzlGp29qaZYjkj15a UX8w== Received: by 10.182.164.40 with SMTP id yn8mr24207890obb.40.1343752389143; Tue, 31 Jul 2012 09:33:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.134.137 with HTTP; Tue, 31 Jul 2012 09:32:49 -0700 (PDT) In-Reply-To: <501805AA.5040303@raszuk.net> References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> <501805AA.5040303@raszuk.net> From: Jamal Hadi Salim Date: Tue, 31 Jul 2012 12:32:49 -0400 Message-ID: To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn1DiFSzuR50acLPldZSVW/QTpOtQna3pZpndqqyzIUARuB257XPtlAdYsvrBcKNJYBAs4H Cc: "irs-discuss@ietf.org" , Alia Atlas Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:33:10 -0000 On Tue, Jul 31, 2012 at 12:19 PM, Robert Raszuk wrote: > > I can do longest prefix match today using OF priority in each table. > > Sure maybe it is not optimal as compared with nice tree lookup alternatives > we see today with pure IP destination based lookup and of course there is > room for improvement. But let's work based on the correct assumptions. At the expense of steering this discussion into a further tangent (and not offend any work youve done in this space - it is a novel idea; i have done similar things with broadcom chips myself many seasons back): The problem with using ACL tables on the switches is their size. They range anywhere from 128 entries to a few K. Sure, you can perform acrobatics with re-populating them doing BGP or a medium size network but why not use the IP functional blocks which exists _on the same chip_ with much better organized tables for ip forwarding etc? cheers, jamal Return-Path: 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 762B721F8615 for ; Tue, 31 Jul 2012 09:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.405 X-Spam-Level: X-Spam-Status: No, score=-6.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 gdgC1x6NGPrv for ; Tue, 31 Jul 2012 09:32:18 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id CC2D821F860B for ; Tue, 31 Jul 2012 09:32:17 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUBgIkCpGrnOLiBBTC/m8GlEa0czMRUzK@postini.com; Tue, 31 Jul 2012 09:32:17 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 31 Jul 2012 09:26:06 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 31 Jul 2012 09:26:04 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 31 Jul 2012 12:25:46 -0400 From: Thomas Nadeau To: "robert@raszuk.net" , "irs-discuss@ietf.org" Date: Tue, 31 Jul 2012 12:25:46 -0400 Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1vOSOevvKerhxBRmWJOFJOwe0kug== Message-ID: In-Reply-To: <501804E4.7050705@raszuk.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 Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:32:18 -0000 On 7/31/12 9:16 AM, "Robert Raszuk" wrote: >Jim, > >> IMO the ability to manipulate routing state, context, etc... is what IRS > > brings to the table and this capability is needed.. >> >> Jim Uttaro > >Manipulating routing state from outside of routing protocols seems to me >like tampering with jet engines during the flight. Network operators modify the routing system while it is in flight all the time using other interfaces, so I fail to see why this is so alarming. >Alia, > >There is no point to keep arguing about IRS framework .. it can call to >address world hunger or propose to turn Sahara into rain forest. >I think we need to wait and see actual protocol(s) proposals which >write/stream into current routing systems as opposed to industry >alternatives which target to write to forwarding layer directly or use >already proposed IETF tools like NETCONF which already provide a very >good provisioning abstraction today. > >My observation is that IRS is yet one more attempt to wave the SDN >banner in the IETF without much substance behind it. We would appreciate keeping the discussion focused on whether or not this is a good problem to solve, and identifying that clearly. We are not interested in=20 pontifications about the IETF, its management or policies on this list. 8) Thanks, --Tom Return-Path: 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 64E2321F85F9 for ; Tue, 31 Jul 2012 09:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 icYMm9CVmZRu for ; Tue, 31 Jul 2012 09:30:56 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 484EC21F869A for ; Tue, 31 Jul 2012 09:30:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 9D87D2205B55; Tue, 31 Jul 2012 12:30:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO-PpMMaDgSw; Tue, 31 Jul 2012 12:30:55 -0400 (EDT) Received: from tnadeau-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id 950AC2205B52; Tue, 31 Jul 2012 12:30:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Thomas Nadeau In-Reply-To: Date: Tue, 31 Jul 2012 09:30:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: James Kempf X-Mailer: Apple Mail (2.1485) Cc: Thomas Nadeau , "irs-discuss@ietf.org" , Alia Atlas Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:30:57 -0000 James,=20 While an implicit goal to not invent anything that can be = recycled and still meet the requirements, we are at present not = proposing any solutions. We are trying to identify the problem space and = define a framework containing the components needed to solve the = problem(s). --Tom On Jul 31, 2012:9:26 AM, at 9:26 AM, James Kempf = wrote: > Hi Alia, >=20 > With respect to the interfaces defined in RFC 5810, it seems to me = that IRS is not proposing to replace existing routing protocols (OSPF, = IS-IS) so it seems it would be the Fp interface. But I have not studied = the Forces docs in detail recently so I may be in error. >=20 > jak=20 >=20 >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com]=20 >> Sent: Monday, July 30, 2012 5:53 PM >> To: James Kempf >> Cc: Thomas Nadeau; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS Problem Statement Posted >>=20 >> Hi James, >>=20 >> The routing system components are certainly part of a=20 >> router's control plane - but not all of it. The idea of IRS=20 >> involves sub-interfaces to the different layers in the routing = system. >>=20 >> Can you clarify what you are asking as it relates to ForCES and IRS? >> I don't feel that we're on the same page yet. >>=20 >> Alia >>=20 >>=20 >> On Mon, Jul 30, 2012 at 6:48 PM, James Kempf=20 >> wrote: >>> Hi Alia, >>>=20 >>> Perhaps you can explain to me the difference between the=20 >> state involved in "the routing system (FIB, IGPs, BGP,=20 >> RSVP-TE, etc.)" and the control plane? The last time I=20 >> looked, these protocols were all involved in routing control=20 >> and therefore could reasonably be characterized as components=20 >> of the control plane, IMHO. >>>=20 >>> jak >>>=20 >>>> -----Original Message----- >>>> From: Alia Atlas [mailto:akatlas@gmail.com] >>>> Sent: Monday, July 30, 2012 3:27 PM >>>> To: James Kempf >>>> Cc: Thomas Nadeau; irs-discuss@ietf.org >>>> Subject: Re: [irs-discuss] IRS Problem Statement Posted >>>>=20 >>>> Hi James, >>>>=20 >>>> Thanks for your thoughts. Streaming (as I've heard) is=20 >> not as good a >>>> description of the desired interface attributes as=20 >> described in Sec=20 >>>> 1.1, the functional overview. >>>>=20 >>>> IRS is NOT about having interfaces to the forwarding plane. That's >>>> what ForCES is focused on. This is about communication=20 >> to a router >>>> to install/retrieve routing state into the routing system=20 >> (FIB, IGPs, >>>> BGP, RSVP-TE, etc.) IRS is NOT splitting the control=20 >> plane from the >>>> router. >>>>=20 >>>> Are you suggesting that ForCES should drastically expand its scope? >>>>=20 >>>> Before we start debating what and whether to expand existing=20 >>>> protocols, I think we need a common understanding of the problem=20 >>>> we're trying to solve and the related framework. >>>>=20 >>>> Alia >>>>=20 >>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf=20 >>>> wrote: >>>>> I don't understand why streaming is specified in this >>>> draft. And I don't understand why this draft isn't put in=20 >> the Forces=20 >>>> framework. Forces is a framework explicitedly designed for=20 >> device to=20 >>>> controller communication. Its major drawback it that it is a=20 >>>> framework with a hole in the middle, in that there are no=20 >> specified=20 >>>> devices. This draft would fill that hole. >>>>>=20 >>>>> I don't think it is necessary to have a problem statement >>>> for router state update. Forces has already established that=20 >>>> splitting the control plane into a separate device is, in=20 >> some cases,=20 >>>> an attractive design option. So I think this should be=20 >> submitted to=20 >>>> the Forces working group, or, at least, recast in the Forces=20 >>>> framework. >>>>>=20 >>>>> jak >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: irs-discuss-bounces@ietf.org=20 >>>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >>>>>> Sent: Monday, July 30, 2012 11:18 AM >>>>>> To: irs-discuss@ietf.org >>>>>> Subject: [irs-discuss] IRS Problem Statement Posted >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Please review and discuss. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Tom, Alia, Ward >>>>>>=20 >>>>>>=20 >>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> irs-discuss mailing list >>>>>> irs-discuss@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>>>>=20 >>>>> _______________________________________________ >>>>> irs-discuss mailing list >>>>> irs-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>>=20 >>=20 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 Return-Path: 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 37A0D21F8605 for ; Tue, 31 Jul 2012 09:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 dYhJj6dFRwvH for ; Tue, 31 Jul 2012 09:30:35 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 582D021F85F9 for ; Tue, 31 Jul 2012 09:30:35 -0700 (PDT) Received: by qcac10 with SMTP id c10so4198552qca.31 for ; Tue, 31 Jul 2012 09:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Cp2eW4GCgkjpyx5V9vwTo5LDwLd4rKwXe9Hsth6p5XY=; b=QGFtfq6Xzs///W8omPYM16puu3tx2yxB6rpf2WenwCkRxvQfCFv4euPZV6UaQf/t6t UAV37O/0yl2gBP7Ra6ephZu5UzWbatvkq5HMXdWXxNSS6nwpOkKbLJrNu01EwHMD6klq vJAriSFfVg2TW2P37nRNF24kmzlIUB2njYmAckuFuZ1qxCC9VxmGCvXo1nfaNkhQjK5s 9f9LAby+PQPzlzCg/a4G8Skm3sxaHbrgJ9x0ENAkpxHGUt4Jz81Acy0SEIWFWKq6FFAu F1yWZrPwZc0zpA/yHQC5mXDlpIIW2eXzER1CiCCV2Gr53611sKCmeBrYQ6fI6fC0YO8C 5C4Q== MIME-Version: 1.0 Received: by 10.50.237.72 with SMTP id va8mr2558070igc.17.1343752234520; Tue, 31 Jul 2012 09:30:34 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Tue, 31 Jul 2012 09:30:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 Jul 2012 12:30:34 -0400 Message-ID: From: Alia Atlas To: James Kempf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Nadeau , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:30:36 -0000 Hi James, This is one of the key differences - ForCES is about programming the forwarding plane. IRS is about interfaces to the routing system - the lowest it goes is to the RIB layer. IMHO, this gives good control and abstraction - no need to model forwarding plane differences. That's what the router OS is for. I do discuss this briefly in the IRS problem-statement. I'd also be happy to chat between WGs. Alia On Tue, Jul 31, 2012 at 12:26 PM, James Kempf wr= ote: > Hi Alia, > > With respect to the interfaces defined in RFC 5810, it seems to me that I= RS is not proposing to replace existing routing protocols (OSPF, IS-IS) so = it seems it would be the Fp interface. But I have not studied the Forces do= cs in detail recently so I may be in error. > > jak > >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Monday, July 30, 2012 5:53 PM >> To: James Kempf >> Cc: Thomas Nadeau; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS Problem Statement Posted >> >> Hi James, >> >> The routing system components are certainly part of a >> router's control plane - but not all of it. The idea of IRS >> involves sub-interfaces to the different layers in the routing system. >> >> Can you clarify what you are asking as it relates to ForCES and IRS? >> I don't feel that we're on the same page yet. >> >> Alia >> >> >> On Mon, Jul 30, 2012 at 6:48 PM, James Kempf >> wrote: >> > Hi Alia, >> > >> > Perhaps you can explain to me the difference between the >> state involved in "the routing system (FIB, IGPs, BGP, >> RSVP-TE, etc.)" and the control plane? The last time I >> looked, these protocols were all involved in routing control >> and therefore could reasonably be characterized as components >> of the control plane, IMHO. >> > >> > jak >> > >> >> -----Original Message----- >> >> From: Alia Atlas [mailto:akatlas@gmail.com] >> >> Sent: Monday, July 30, 2012 3:27 PM >> >> To: James Kempf >> >> Cc: Thomas Nadeau; irs-discuss@ietf.org >> >> Subject: Re: [irs-discuss] IRS Problem Statement Posted >> >> >> >> Hi James, >> >> >> >> Thanks for your thoughts. Streaming (as I've heard) is >> not as good a >> >> description of the desired interface attributes as >> described in Sec >> >> 1.1, the functional overview. >> >> >> >> IRS is NOT about having interfaces to the forwarding plane. That's >> >> what ForCES is focused on. This is about communication >> to a router >> >> to install/retrieve routing state into the routing system >> (FIB, IGPs, >> >> BGP, RSVP-TE, etc.) IRS is NOT splitting the control >> plane from the >> >> router. >> >> >> >> Are you suggesting that ForCES should drastically expand its scope? >> >> >> >> Before we start debating what and whether to expand existing >> >> protocols, I think we need a common understanding of the problem >> >> we're trying to solve and the related framework. >> >> >> >> Alia >> >> >> >> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf >> >> 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] On Behalf Of Thomas Nadeau >> >> >> Sent: Monday, July 30, 2012 11:18 AM >> >> >> To: 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 >> >> >> https://www.ietf.org/mailman/listinfo/irs-discuss >> >> >> >> >> > _______________________________________________ >> >> > irs-discuss mailing list >> >> > irs-discuss@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/irs-discuss >> >> >> Return-Path: 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 4E96521F869F for ; Tue, 31 Jul 2012 09:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 zDrtIAW-VYp6 for ; Tue, 31 Jul 2012 09:26:59 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 66EFD21F84EF for ; Tue, 31 Jul 2012 09:26:59 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6VGQrjv022097; Tue, 31 Jul 2012 11:26:55 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 31 Jul 2012 12:26:48 -0400 From: James Kempf To: Alia Atlas Date: Tue, 31 Jul 2012 12:26:46 -0400 Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1utuNdwFa7paQGSZqcfD2Ky9h1zAAgdpfQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Nadeau , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:27:00 -0000 Hi Alia, With respect to the interfaces defined in RFC 5810, it seems to me that IRS= is not proposing to replace existing routing protocols (OSPF, IS-IS) so it= seems it would be the Fp interface. But I have not studied the Forces docs= in detail recently so I may be in error. jak=20 > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com]=20 > Sent: Monday, July 30, 2012 5:53 PM > To: James Kempf > Cc: Thomas Nadeau; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS Problem Statement Posted >=20 > Hi James, >=20 > The routing system components are certainly part of a=20 > router's control plane - but not all of it. The idea of IRS=20 > involves sub-interfaces to the different layers in the routing system. >=20 > Can you clarify what you are asking as it relates to ForCES and IRS? > I don't feel that we're on the same page yet. >=20 > Alia >=20 >=20 > On Mon, Jul 30, 2012 at 6:48 PM, James Kempf=20 > wrote: > > Hi Alia, > > > > Perhaps you can explain to me the difference between the=20 > state involved in "the routing system (FIB, IGPs, BGP,=20 > RSVP-TE, etc.)" and the control plane? The last time I=20 > looked, these protocols were all involved in routing control=20 > and therefore could reasonably be characterized as components=20 > of the control plane, IMHO. > > > > jak > > > >> -----Original Message----- > >> From: Alia Atlas [mailto:akatlas@gmail.com] > >> Sent: Monday, July 30, 2012 3:27 PM > >> To: James Kempf > >> Cc: Thomas Nadeau; irs-discuss@ietf.org > >> Subject: Re: [irs-discuss] IRS Problem Statement Posted > >> > >> Hi James, > >> > >> Thanks for your thoughts. Streaming (as I've heard) is=20 > not as good a > >> description of the desired interface attributes as=20 > described in Sec=20 > >> 1.1, the functional overview. > >> > >> IRS is NOT about having interfaces to the forwarding plane. That's > >> what ForCES is focused on. This is about communication=20 > to a router > >> to install/retrieve routing state into the routing system=20 > (FIB, IGPs, > >> BGP, RSVP-TE, etc.) IRS is NOT splitting the control=20 > plane from the > >> router. > >> > >> Are you suggesting that ForCES should drastically expand its scope? > >> > >> Before we start debating what and whether to expand existing=20 > >> protocols, I think we need a common understanding of the problem=20 > >> we're trying to solve and the related framework. > >> > >> Alia > >> > >> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf=20 > >> wrote: > >> > I don't understand why streaming is specified in this > >> draft. And I don't understand why this draft isn't put in=20 > the Forces=20 > >> framework. Forces is a framework explicitedly designed for=20 > device to=20 > >> controller communication. Its major drawback it that it is a=20 > >> framework with a hole in the middle, in that there are no=20 > specified=20 > >> 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=20 > >> splitting the control plane into a separate device is, in=20 > some cases,=20 > >> an attractive design option. So I think this should be=20 > submitted to=20 > >> the Forces working group, or, at least, recast in the Forces=20 > >> framework. > >> > > >> > jak > >> > > >> >> -----Original Message----- > >> >> From: irs-discuss-bounces@ietf.org=20 > >> >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau > >> >> Sent: Monday, July 30, 2012 11:18 AM > >> >> To: 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 > >> >> https://www.ietf.org/mailman/listinfo/irs-discuss > >> >> > >> > _______________________________________________ > >> > irs-discuss mailing list > >> > irs-discuss@ietf.org > >> > https://www.ietf.org/mailman/listinfo/irs-discuss > >> > = Return-Path: 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 8C76C21F844F for ; Tue, 31 Jul 2012 09:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599] 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 yyEiulJP3Jp7 for ; Tue, 31 Jul 2012 09:19:57 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 8E54821F86DB for ; Tue, 31 Jul 2012 09:19:57 -0700 (PDT) Received: (qmail 22253 invoked by uid 399); 31 Jul 2012 16:19:55 -0000 Received: from unknown (HELO ?130.129.17.42?) (pbs:robert@raszuk.net@130.129.17.42) by mail1310.opentransfer.com with ESMTPM; 31 Jul 2012 16:19:55 -0000 X-Originating-IP: 130.129.17.42 Message-ID: <501805AA.5040303@raszuk.net> Date: Tue, 31 Jul 2012 18:19:54 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Alia Atlas References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:19:58 -0000 Alia, > While I am not interested in discussing/refining/bashing OpenFlow on > IRS, except if necessary as to how to compares/contrasts to IRS in > terms of features, I do recall (sleep helps) that the L3 matching > capabilities are slightly beyond host routes since it does support > arbitrary wildcarding of bits for the flow lookup. > > That is still rather different than a longest-prefix match. I can do longest prefix match today using OF priority in each table. Sure maybe it is not optimal as compared with nice tree lookup alternatives we see today with pure IP destination based lookup and of course there is room for improvement. But let's work based on the correct assumptions. > It is > still dealing with the forwarding plane and not the RIBs, IGPs, BGP, > LDP, RSVP-TE, etc. And IMHO this is a feature not a bug. Best regards, R. Return-Path: 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 D996A21F86DC for ; Tue, 31 Jul 2012 09:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599] 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 MtHOzuhsqUEs for ; Tue, 31 Jul 2012 09:16:38 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE7E21F86DB for ; Tue, 31 Jul 2012 09:16:37 -0700 (PDT) Received: (qmail 15107 invoked by uid 399); 31 Jul 2012 16:16:37 -0000 Received: from unknown (HELO ?130.129.17.42?) (pbs:robert@raszuk.net@130.129.17.42) by mail1310.opentransfer.com with ESMTPM; 31 Jul 2012 16:16:37 -0000 X-Originating-IP: 130.129.17.42 Message-ID: <501804E4.7050705@raszuk.net> Date: Tue, 31 Jul 2012 18:16:36 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: irs-discuss@ietf.org References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:16:39 -0000 Jim, > IMO the ability to manipulate routing state, context, etc... is what IRS > brings to the table and this capability is needed.. > > Jim Uttaro Manipulating routing state from outside of routing protocols seems to me like tampering with jet engines during the flight. Alia, There is no point to keep arguing about IRS framework .. it can call to address world hunger or propose to turn Sahara into rain forest. I think we need to wait and see actual protocol(s) proposals which write/stream into current routing systems as opposed to industry alternatives which target to write to forwarding layer directly or use already proposed IETF tools like NETCONF which already provide a very good provisioning abstraction today. My observation is that IRS is yet one more attempt to wave the SDN banner in the IETF without much substance behind it. Best, R. Return-Path: 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 3E6E721F86DB for ; Tue, 31 Jul 2012 09:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 EOGyWGx535W7 for ; Tue, 31 Jul 2012 09:16:35 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D01321F86D1 for ; Tue, 31 Jul 2012 09:16:35 -0700 (PDT) Received: by ggnc4 with SMTP id c4so6734289ggn.31 for ; Tue, 31 Jul 2012 09:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=veP+sm8lbaFRHVqJIR84+xuAx+s0mYCdnSbx9p/xz+8=; b=irSgg8CPTFIa6oAYdntxbKhcOtVOGGV/X6+jbsTE/afkORBjLxhK1vmC84gDS/vO8R 1lpB7kVKJDPrm57B/vqHt+nsVelV5F7s1Ew9oZYCwUyMqWkdka+WG5o2HPO1cKf/dT/I 6cNDhlbW+4ltOw/HT7ZS6/I2h76j9VmWU2KCJiAkNjnx38DqlO0N8mfj8/74Zw2ZFAZo FUUdoQzX/589l8iHhcDzuNLmjukc+R62FG/MCdoJMwYhquNRc3aHMx7jhFsksBQmWpaY 2hEmn8jwrNjinWumVewqguYd4VEhqaNp1QQtPZG8cHOXDcwX1vqCBxqEdsHmrSkr718K cInw== MIME-Version: 1.0 Received: by 10.50.94.196 with SMTP id de4mr2510470igb.17.1343751393856; Tue, 31 Jul 2012 09:16:33 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Tue, 31 Jul 2012 09:16:33 -0700 (PDT) In-Reply-To: References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> <879186E3-D9D7-49B5-8E38-8CC4E4D34282@juniper.net> Date: Tue, 31 Jul 2012 12:16:33 -0400 Message-ID: From: Alia Atlas To: James Kempf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Nadeau , Nitin Bahadur , Susan Hares , Robert Raszuk , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:16:36 -0000 It is impressive what can be done with even the limited control and scalability that Openflow provides. IRS is to provide additional controls at the multiple layers in the routing system to facilitate application-level control/intelligence Alia On Tue, Jul 31, 2012 at 12:11 PM, James Kempf wr= ote: > >> [ off-topic ] >> >> Today in IDR, Microsoft folks presented on running data >> centers using BGP. So I guess we should put OSPF & ISIS to >> rest. We can use BGP for everything. >> > > Yeah, right. Then when it breaks due to being used for something it wasn'= t designed, we can spend the next 10 years in IETF working groups coming up= with fixes. And have to hire high priced BFG gurus to configure and keep i= t running in the meantime. :-) > >> [ / off-topic ] >> >> Openflow abstractions are at the forwarding level. IRS does >> not compete with that. >> >> [ rant ] >> Did I just hear that you've convinced your company to replace >> all of its networking gear with OF gear and a uber powerful >> controller. >> [ / rant ] > > Wollen Sie dann weiter die Unterhaltung auf Deutsch haben? >> > > Anyway, I've been working with OpenFlow on and off since 2006. You can do= stuff like: > > - make an access/aggregation network with a couple hundred switches look = like a gigantic router to the outside world by aggregating the interfaces (= and thereby make it easier to manage) > > - do application specific flow steering for chained processing in middleb= oxes (complaints about DPI please to /dev/null) > > - run a 3GPP/LTE mobile core with the control plane including routing com= pletely in a cloud instead of only the mobility mangement part > > - and finally, as Google has demonstrated, run your network at 90% capaci= ty as opposed to 30% (and, yes, I know that the network was rather special = and perhaps not characteristic of a provider network but it still shows wha= t you can do) > > > But it is not magic, there are lots of problems that need work, and it co= uld still go badly wrong. Right now, it is at the peak of the Gardner hype = curve, give it another year, and everybody will be trashing it, unless of c= ourse the hype curve moves up another notch. > > jak > >> Thanks >> Nitin >> >> On Jul 30, 2012, at 6:48 PM, "Robert Raszuk" >> wrote: >> >> > hi Nitin, >> > >> > >> >> So IRS needs to define interfaces for both the lower layer >> and the upper layer. >> > >> > That's precisely what openflow protocol does. Thx for >> confirming clearly the intentions ;). >> > >> > Best regards, >> > R. >> > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 BDD8721F867F for ; Tue, 31 Jul 2012 09:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.417, 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 cykyghuKSRiu for ; Tue, 31 Jul 2012 09:11:51 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id ED47121F869A for ; Tue, 31 Jul 2012 09:11:50 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q6VGBJhE022980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 11:11:47 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 31 Jul 2012 12:11:38 -0400 From: James Kempf To: Nitin Bahadur , Robert Raszuk Date: Tue, 31 Jul 2012 12:11:37 -0400 Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1uwSAnSG+rmSQ3S12saISb+HgJ8QAdG2zQ Message-ID: References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> <879186E3-D9D7-49B5-8E38-8CC4E4D34282@juniper.net> In-Reply-To: <879186E3-D9D7-49B5-8E38-8CC4E4D34282@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Nadeau , Susan Hares , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:11:58 -0000 =20 > [ off-topic ] >=20 > Today in IDR, Microsoft folks presented on running data=20 > centers using BGP. So I guess we should put OSPF & ISIS to=20 > rest. We can use BGP for everything. >=20 Yeah, right. Then when it breaks due to being used for something it wasn't = designed, we can spend the next 10 years in IETF working groups coming up w= ith fixes. And have to hire high priced BFG gurus to configure and keep it = running in the meantime. :-)=20 > [ / off-topic ] >=20 > Openflow abstractions are at the forwarding level. IRS does=20 > not compete with that. >=20 > [ rant ] > Did I just hear that you've convinced your company to replace=20 > all of its networking gear with OF gear and a uber powerful=20 > controller. > [ / rant ] Wollen Sie dann weiter die Unterhaltung auf Deutsch haben? >=20 Anyway, I've been working with OpenFlow on and off since 2006. You can do s= tuff like: - make an access/aggregation network with a couple hundred switches look li= ke a gigantic router to the outside world by aggregating the interfaces (an= d thereby make it easier to manage) - do application specific flow steering for chained processing in middlebox= es (complaints about DPI please to /dev/null) - run a 3GPP/LTE mobile core with the control plane including routing compl= etely in a cloud instead of only the mobility mangement part - and finally, as Google has demonstrated, run your network at 90% capacity= as opposed to 30% (and, yes, I know that the network was rather special an= d perhaps not characteristic of a provider network but it still shows what = you can do) But it is not magic, there are lots of problems that need work, and it coul= d still go badly wrong. Right now, it is at the peak of the Gardner hype cu= rve, give it another year, and everybody will be trashing it, unless of cou= rse the hype curve moves up another notch. jak > Thanks > Nitin >=20 > On Jul 30, 2012, at 6:48 PM, "Robert Raszuk"=20 > wrote: >=20 > > hi Nitin, > >=20 > >=20 > >> So IRS needs to define interfaces for both the lower layer=20 > and the upper layer. > >=20 > > That's precisely what openflow protocol does. Thx for=20 > confirming clearly the intentions ;). > >=20 > > Best regards, > > R. > = Return-Path: 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 DEF0B21F84EA for ; Tue, 31 Jul 2012 09:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.13 X-Spam-Level: X-Spam-Status: No, score=-6.13 tagged_above=-999 required=5 tests=[AWL=0.469, 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 pyMfDuN00JQ8 for ; Tue, 31 Jul 2012 09:00:04 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 455F621F855F for ; Tue, 31 Jul 2012 09:00:03 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6VFxuwR015295; Tue, 31 Jul 2012 10:59:59 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 31 Jul 2012 11:59:52 -0400 From: James Kempf To: Robert Raszuk , Alia Atlas Date: Tue, 31 Jul 2012 11:59:51 -0400 Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1uwYLM51fewlmcR7mZUNdRqj8CvQAc/dBQ Message-ID: References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Nadeau , Nitin Bahadur , Susan Hares , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:00:05 -0000 =20 =20 > Alia, >=20 >=20 > > Hi Rob, > >=20 > > On the lower layer, Openflow talks to control/specify the=20 > forwarding=20 > > plane - heading towards forwarding plane modeling; something that=20 > > ForCES did a while ago. It focuses on Layer-2 and does not=20 > interact=20 > > with the routing control plane - generally assuming that the routing > > control protocol does not/should not exist. =20 >=20 >=20 > Completely incorrect assumption sorry. OF does not assume L2=20 > as an example I have been working on routing applications=20 > over OF based data plane for over a year now. >=20 > OF separates control plane including ability to run routing=20 > protocols from forwarding entities. That's the most important point. >=20 > Hybrid work actually does not help too much .. Especially the=20 > integrated effort. Retrieving state is not a focus as the=20 > assumption is that such state is known in the controller.=20 > However state validation or verification is something that OF=20 > need to pay more attention to - no question. >=20 > Btw .. If IETF magically does something to equipment vendors=20 > so they will ship FORCEs enabled platforms I am all game.=20 > That would be productive. IRS as of now is more to mud the=20 > water then to come with an alternative to Forces or OF. >=20 Agree. jak > Best regards, > R. >=20 >=20 >=20 > > Yes, there is nascent > > work on hybrid OpenFlow switches - but that is very far=20 > from a model=20 > > based on USING the router's OS and routing capabilities and handling > > multiple applications installing state. Retrieving state=20 > is also not > > a focus in Openflow. > >=20 > > On the upper layer, ONF is starting to tentatively talk about=20 > > northbound APIs - which are from OpenFlow controllers up towards=20 > > orchestrators or applications. > >=20 > > I don't, personally, think that IRS should cover the latter upper=20 > > layer - though a translation layer and thinking through the=20 > network OS=20 > > abstractions is certainly interesting and part of the ecosystem. > >=20 > > Would you care to clearly clarify your concerns and=20 > assumptions about=20 > > intentions? > >=20 > > The two drafts work at defining what IRS should be; I think=20 > that there=20 > > is a clear difference in approach and intended functionality from=20 > > OpenFlow. > >=20 > > Surely you aren't suggesting that the IETF should not do=20 > anything in=20 > > this space because OpenFlow might get around to it someday? > >=20 > > Alia > >=20 > > On Mon, Jul 30, 2012 at 9:48 PM, Robert Raszuk=20 > wrote: > >> hi Nitin, > >>=20 > >>=20 > >>> So IRS needs to define interfaces for both the lower=20 > layer and the upper layer. > >>=20 > >> That's precisely what openflow protocol does. Thx for=20 > confirming clearly the intentions ;). > >>=20 > >> Best regards, > >> R. > >> _______________________________________________ > >> irs-discuss mailing list > >> 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 > = Return-Path: 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 604D021F8670 for ; Tue, 31 Jul 2012 07:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 EJO-7+wosCDx for ; Tue, 31 Jul 2012 07:49:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA7D21F8665 for ; Tue, 31 Jul 2012 07:49:38 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B3B820BD9; Tue, 31 Jul 2012 16:49:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tuHPHfT0qhQx; Tue, 31 Jul 2012 16:49:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69C7D20BCD; Tue, 31 Jul 2012 16:49:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CD3DD20FCCE7; Tue, 31 Jul 2012 16:49:30 +0200 (CEST) Date: Tue, 31 Jul 2012 16:49:30 +0200 From: Juergen Schoenwaelder To: irs-discuss@ietf.org Message-ID: <20120731144930.GA78451@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [irs-discuss] IRS problem statement and NETCONF/YANG X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 14:49:39 -0000 Hi, reading through the problem statement posted at http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt I noticed a number of statements concerning NETCONF and YANG that probably need to be corrected. For more background where NETCONF and YANG is, you may want to consult the tutorial slides posted at http://cnds.eecs.jacobs-university.de/slides/2012-ietf-84-netconf-yang.pdf and consult the documents referenced in the slides. Some more detailed comments: : Finally, the IETF's Network Configuration (or NetConf) protocol has : made many strides at overcoming most of the limitations around : configuration that were just described. However, the lack of : standard data models have hampered the adoption of NetConf. The NETMOD working group has been chartered to work on common core data models and currently has core data models for the configuration of network interfaces, ip interfaces and a core routing configuration data model in WG last call: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-04 http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-05 http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-05 : While NetConf has solved many of the deficiencies present in SNMP in : terms of configuration, it still does not satisfy a number of : requirements needed to manage today's routing information. First, : the lack of standard data models have hampered the adoption of : NetConf; a significant amount of per-vendor customization is still : needed. The transport mechanisms that are currently defined (e.g., : SOAP/BEEP) for NetConf are not those commonly used by modern : applications (e.g., ReST or JSON). The default to implement transport for NETCONF is SSH. There is another transport over TLS. The BEEP and SOAP transports are on their way to be declared historic. That said, there is work underway to define a JSON / REST API to YANG modelled NETCONF data stores. http://tools.ietf.org/html/draft-bierman-netconf-yang-api-00 http://tools.ietf.org/html/draft-lhotka-yang-json-00 : NetConf primarily facilitates configuration rather than reading of : state or handling asynchronous events. Not sure what primarily facilitates means but NETCONF does support all three functions. NETCONF allows read access to all existing SNMP instrumentation of devices. : NetConf matches up to the key needed aspects as follows : : Multiple Simultaneous Asynchronous Operations: Not Possible The NETCONF protocol tags RPC invocations with a message-id that is echoed back in RPC replies, allowing asynchronous operations. NETCONF also provides global and partial locks to properly deal concurrent operations received via multiple channels. : Configuration Not Re-Processed: Not Possible I simply do not understand the definition of this aspect. You document says: : Configuration Not Re-Processed: When an IRS operation is processed, : it does not require that any of the configuration be processed. : I.e., the desired behavior is orthogonal to the static : configuration. A clarficiation is needed what you mean with this. Anyway, NETCONF distinguishes between different configuration data stores. If you want to distinguish between changes that affect only the current behaviour but not say the next startup behaviour (i.e. the changes do not persist), then this is already supported by NETCONF. Perhaps your concern is that making a change requires to reprocess the whole configuration? In that case, this is clearly not required anywhere by the NETCONF protocol specification. In fact, the edit-config operation allows to send detailed configuration change sets to a NETCONF server. : Duplex: Not Possible - strict pull model. NETCONF does have support for event notifications that are pushed by the device. The initiation of the session is client to server for the existing transports - but this is mostly a property of the transports. Some vendors use non-standard extensions for the SSH transport to support device initiated sessions. : High-Throughput: Unlikely - Can depend on configuration size Well, this is ill defined in the first place. Your definition is: : High-Throughput: At a minimum, the IRS Agent and associated router : should be able to handle hundreds of simple operations per second. So what is a "simple operation"? I am rather optimistic that it is possible to do some "simple operation" in NETCONF at the requested speed. To be useful, you really need to be more precise. : Responsive: Unlikely - Can depend on configuration size Again, this is under specified. Your definition is: : Responsive: It should be possible to complete simple operations : within a sub-second time-scale. I am sure NETCONF servers easily respond within a sub-second time-scale. We have several implementors here at the IETF, I am sure they can provide more concrete information about the efficiency aspects. : Multi-Channel: Not Possible NETCONF allows to use multiple SSH or TLS sessions (hence multiple TCP sessions) and it provides the needed coordination primitives. In addition, the SSH transport can be used to run multiple SSH channels multiplexed over a single TCP session. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Return-Path: 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 7A4ED21F8668 for ; Tue, 31 Jul 2012 07:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.427 X-Spam-Level: X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 5iqYyWxh1vR5 for ; Tue, 31 Jul 2012 07:10:25 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id D464021F84F2 for ; Tue, 31 Jul 2012 07:10:24 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 057e7105.2aaafc853940.509630.00-594.1388767.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 31 Jul 2012 14:10:24 +0000 (UTC) X-MXL-Hash: 5017e75043cf6983-30baf9a5f742d60cc5740346a2b33b59c4000cc7 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id d47e7105.0.509611.00-399.1388697.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 31 Jul 2012 14:10:22 +0000 (UTC) X-MXL-Hash: 5017e74e1c335dd9-2944c89bd3f8a190331d0bf68bd642d1d43f62fb Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6VEALFo015706; Tue, 31 Jul 2012 10:10:21 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6VEAJnU015670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2012 10:10:20 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by sflint02.pst.cso.att.com (RSA Interceptor); Tue, 31 Jul 2012 10:10:07 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 10:10:07 -0400 From: "UTTARO, JAMES" To: "'Alia Atlas'" , Robert Raszuk Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1uf6vUr0RoAYPERve+GHr5XPQ6JgAIAMEAAADmuywABbPeIAAJLQWAAABQUQAAAFnagAAAYlmAAAB6owAAF9JzAAAHlYZA Date: Tue, 31 Jul 2012 14:10:06 +0000 Message-ID: References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=N8_Zyk_AHbsA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=2clOPd4P] X-AnalysisOut: [AAAA:8 a=CUwWThJu-Sx1_-2QhYEA:9 a=CjuIK1q_8ugA:10 a=lZB815] X-AnalysisOut: [dzVvQA:10 a=MSl-tDqOz04A:10 a=bDUki_mJ7DgA:10] Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 14:10:30 -0000 IMO the ability to manipulate routing state, context, etc... is what IRS br= ings to the table and this capability is needed.. Jim Uttaro -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Alia Atlas Sent: Tuesday, July 31, 2012 9:45 AM To: Robert Raszuk Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS Problem Statement Posted While I am not interested in discussing/refining/bashing OpenFlow on IRS, except if necessary as to how to compares/contrasts to IRS in terms of features, I do recall (sleep helps) that the L3 matching capabilities are slightly beyond host routes since it does support arbitrary wildcarding of bits for the flow lookup. That is still rather different than a longest-prefix match. It is still dealing with the forwarding plane and not the RIBs, IGPs, BGP, LDP, RSVP-TE, etc. Alia On Mon, Jul 30, 2012 at 10:22 PM, Alia Atlas wrote: > Rob, > > I have also been following Openflow - granted primarily on the hybrid > and futures areas. Yes, Openflow allows specification of flow-based > forwarding - which can apply to /32 IPv4 routes. > > This list is NOT to discuss OpenFlow nor to focus on what it does or > can be contorted to do. Are overlaps of interest? Yes - but you are > not usefully describing that. > > On Mon, Jul 30, 2012 at 10:09 PM, Robert Raszuk wrote= : >> Alia, >> >> >>> Hi Rob, >>> >>> On the lower layer, Openflow talks to control/specify the forwarding >>> plane - heading towards forwarding plane modeling; something that >>> ForCES did a while ago. It focuses on Layer-2 and does not interact >>> with the routing control plane - generally assuming that the routing >>> control protocol does not/should not exist. >> >> >> Completely incorrect assumption sorry. OF does not assume L2 as an examp= le I have been working on routing applications over OF based data plane for= over a year now. > > [Alia] OF requires LLDP to learn the topology! Yes, there is > flow-based policy-based forwarding - for host-routes. > >> OF separates control plane including ability to run routing protocols fr= om forwarding entities. That's the most important point. > > [Alia] And NOT what IRS is doing. > >> Hybrid work actually does not help too much .. Especially the integrated= effort. Retrieving state is not a focus as the assumption is that such sta= te is known in the controller. However state validation or verification is = something that OF need to pay more attention to - no question. > > [Alia] Right - Openflow assumes one controller for a switch. IRS does > not. I am NOT trying to suggest/guide OpenFlow here - that is what > the ONF is for. > >> Btw .. If IETF magically does something to equipment vendors so they wil= l ship FORCEs enabled platforms I am all game. That would be productive. IR= S as of now is more to mud the water then to come with an alternative to Fo= rces or OF. > > [Alia] IRS is providing control strings to different layers in the > routing system. It is not doing the same thing as ForCES or > Openflow. I am sorry that you feel that proposing something > different is muddying the water. > > Alia > >> Best regards, >> R. >> >> >> >>> Yes, there is nascent >>> work on hybrid OpenFlow switches - but that is very far from a model >>> based on USING the router's OS and routing capabilities and handling >>> multiple applications installing state. Retrieving state is also not >>> a focus in Openflow. >>> >>> On the upper layer, ONF is starting to tentatively talk about >>> northbound APIs - which are from OpenFlow controllers up towards >>> orchestrators or applications. >>> >>> I don't, personally, think that IRS should cover the latter upper >>> layer - though a translation layer and thinking through the network OS >>> abstractions is certainly interesting and part of the ecosystem. >>> >>> Would you care to clearly clarify your concerns and assumptions about >>> intentions? >>> >>> The two drafts work at defining what IRS should be; I think that there >>> is a clear difference in approach and intended functionality from >>> OpenFlow. >>> >>> Surely you aren't suggesting that the IETF should not do anything in >>> this space because OpenFlow might get around to it someday? >>> >>> Alia >>> >>> On Mon, Jul 30, 2012 at 9:48 PM, Robert Raszuk wrot= e: >>>> hi Nitin, >>>> >>>> >>>>> So IRS needs to define interfaces for both the lower layer and the up= per layer. >>>> >>>> That's precisely what openflow protocol does. Thx for confirming clear= ly the intentions ;). >>>> >>>> Best regards, >>>> R. >>>> _______________________________________________ >>>> irs-discuss mailing list >>>> 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 _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 752E121F8618 for ; Tue, 31 Jul 2012 06:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 jSkyq-25qjRL for ; Tue, 31 Jul 2012 06:45:00 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 222EF21F84EF for ; Tue, 31 Jul 2012 06:44:59 -0700 (PDT) Received: by ggnc4 with SMTP id c4so6538639ggn.31 for ; Tue, 31 Jul 2012 06:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XKIStzSVhCWnRBgejxOMBYuJCUeZzKSSHQCeg98bzN0=; b=MuKZuHxW9tXBpsUtAJmD4YB9FAja6ZQ9svWF6VwxOPop5iwJhw9kj3T2+tFRhfsuuq z1/0VAYqa5L7XL0pQS6pPFDgGVcmvchvt4JjDU03qZxtRD/TZz83IFLKW7grnzBQMCDz zLvv2y64jYINWcrRB7LEXy2TRlQje9SQcbsfK2/B9O1W8SgeHKpypz3gK7NPlGEF2tcF J5V1tcYws0aX7hXJPrhA3NO+27107jwBzl7G+Qvfl5lnhLIht84VOaESBQSHr5wbTSjS DBqyrZF2k7aqZObH/4fp6uH4DJh36TgYI5JPpPO7HUtqRLcueUFZxVSChzkQ2Do1LyIu pusw== MIME-Version: 1.0 Received: by 10.50.104.228 with SMTP id gh4mr639913igb.71.1343742298283; Tue, 31 Jul 2012 06:44:58 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Tue, 31 Jul 2012 06:44:58 -0700 (PDT) In-Reply-To: References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> Date: Tue, 31 Jul 2012 09:44:58 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 13:45:01 -0000 While I am not interested in discussing/refining/bashing OpenFlow on IRS, except if necessary as to how to compares/contrasts to IRS in terms of features, I do recall (sleep helps) that the L3 matching capabilities are slightly beyond host routes since it does support arbitrary wildcarding of bits for the flow lookup. That is still rather different than a longest-prefix match. It is still dealing with the forwarding plane and not the RIBs, IGPs, BGP, LDP, RSVP-TE, etc. Alia On Mon, Jul 30, 2012 at 10:22 PM, Alia Atlas wrote: > Rob, > > I have also been following Openflow - granted primarily on the hybrid > and futures areas. Yes, Openflow allows specification of flow-based > forwarding - which can apply to /32 IPv4 routes. > > This list is NOT to discuss OpenFlow nor to focus on what it does or > can be contorted to do. Are overlaps of interest? Yes - but you are > not usefully describing that. > > On Mon, Jul 30, 2012 at 10:09 PM, Robert Raszuk wrote= : >> Alia, >> >> >>> Hi Rob, >>> >>> On the lower layer, Openflow talks to control/specify the forwarding >>> plane - heading towards forwarding plane modeling; something that >>> ForCES did a while ago. It focuses on Layer-2 and does not interact >>> with the routing control plane - generally assuming that the routing >>> control protocol does not/should not exist. >> >> >> Completely incorrect assumption sorry. OF does not assume L2 as an examp= le I have been working on routing applications over OF based data plane for= over a year now. > > [Alia] OF requires LLDP to learn the topology! Yes, there is > flow-based policy-based forwarding - for host-routes. > >> OF separates control plane including ability to run routing protocols fr= om forwarding entities. That's the most important point. > > [Alia] And NOT what IRS is doing. > >> Hybrid work actually does not help too much .. Especially the integrated= effort. Retrieving state is not a focus as the assumption is that such sta= te is known in the controller. However state validation or verification is = something that OF need to pay more attention to - no question. > > [Alia] Right - Openflow assumes one controller for a switch. IRS does > not. I am NOT trying to suggest/guide OpenFlow here - that is what > the ONF is for. > >> Btw .. If IETF magically does something to equipment vendors so they wil= l ship FORCEs enabled platforms I am all game. That would be productive. IR= S as of now is more to mud the water then to come with an alternative to Fo= rces or OF. > > [Alia] IRS is providing control strings to different layers in the > routing system. It is not doing the same thing as ForCES or > Openflow. I am sorry that you feel that proposing something > different is muddying the water. > > Alia > >> Best regards, >> R. >> >> >> >>> Yes, there is nascent >>> work on hybrid OpenFlow switches - but that is very far from a model >>> based on USING the router's OS and routing capabilities and handling >>> multiple applications installing state. Retrieving state is also not >>> a focus in Openflow. >>> >>> On the upper layer, ONF is starting to tentatively talk about >>> northbound APIs - which are from OpenFlow controllers up towards >>> orchestrators or applications. >>> >>> I don't, personally, think that IRS should cover the latter upper >>> layer - though a translation layer and thinking through the network OS >>> abstractions is certainly interesting and part of the ecosystem. >>> >>> Would you care to clearly clarify your concerns and assumptions about >>> intentions? >>> >>> The two drafts work at defining what IRS should be; I think that there >>> is a clear difference in approach and intended functionality from >>> OpenFlow. >>> >>> Surely you aren't suggesting that the IETF should not do anything in >>> this space because OpenFlow might get around to it someday? >>> >>> Alia >>> >>> On Mon, Jul 30, 2012 at 9:48 PM, Robert Raszuk wrot= e: >>>> hi Nitin, >>>> >>>> >>>>> So IRS needs to define interfaces for both the lower layer and the up= per layer. >>>> >>>> That's precisely what openflow protocol does. Thx for confirming clear= ly the intentions ;). >>>> >>>> Best regards, >>>> R. >>>> _______________________________________________ >>>> irs-discuss mailing list >>>> 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 Return-Path: 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 8FD3011E80CC for ; Mon, 30 Jul 2012 19:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 wdpIHWeDmy3J for ; Mon, 30 Jul 2012 19:22:56 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1051E11E809A for ; Mon, 30 Jul 2012 19:22:54 -0700 (PDT) Received: by yenq13 with SMTP id q13so6018184yen.31 for ; Mon, 30 Jul 2012 19:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GleVUhe6Xqmc3tPtYA++iJO/Jf4DnMYkMCk/0vlED74=; b=XPb0IULm01FJE++pEFpoOWcJbmTSfgSZ01qCrQTeVPWk7lEctk5uBtDlcsI4Or9obx 98YBBegELeilkCB5nmZPLHTzwa0HCRSsBnItPTN8WUQMzqWL+hWH7N9NdIqdiPgE1F7V PqidmYv0HF2T6KA8cf4TrZtRUBiXh1YHzz59KMoNmZ33uw55q9DXS8I3F3CZtTIvegY0 qgGYYTouo2sjwBu8GIg8TAzmkBhK/AWrlAIlZuyN6r/71lYc6nhUXZSPVeeRVAD/SZxh KmGxm37m3362d5kVwTGeEWF7LnsZpYc2951tndL7P6zDERN8YFAFLMN8qIK2w/JO+M3F 8MWw== MIME-Version: 1.0 Received: by 10.50.213.1 with SMTP id no1mr544021igc.71.1343701372831; Mon, 30 Jul 2012 19:22:52 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 19:22:52 -0700 (PDT) In-Reply-To: References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> Date: Mon, 30 Jul 2012 22:22:52 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Nadeau , Nitin Bahadur , Susan Hares , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:22:57 -0000 Rob, I have also been following Openflow - granted primarily on the hybrid and futures areas. Yes, Openflow allows specification of flow-based forwarding - which can apply to /32 IPv4 routes. This list is NOT to discuss OpenFlow nor to focus on what it does or can be contorted to do. Are overlaps of interest? Yes - but you are not usefully describing that. On Mon, Jul 30, 2012 at 10:09 PM, Robert Raszuk wrote: > Alia, > > >> Hi Rob, >> >> On the lower layer, Openflow talks to control/specify the forwarding >> plane - heading towards forwarding plane modeling; something that >> ForCES did a while ago. It focuses on Layer-2 and does not interact >> with the routing control plane - generally assuming that the routing >> control protocol does not/should not exist. > > > Completely incorrect assumption sorry. OF does not assume L2 as an exampl= e I have been working on routing applications over OF based data plane for = over a year now. [Alia] OF requires LLDP to learn the topology! Yes, there is flow-based policy-based forwarding - for host-routes. > OF separates control plane including ability to run routing protocols fro= m forwarding entities. That's the most important point. [Alia] And NOT what IRS is doing. > Hybrid work actually does not help too much .. Especially the integrated = effort. Retrieving state is not a focus as the assumption is that such stat= e is known in the controller. However state validation or verification is s= omething that OF need to pay more attention to - no question. [Alia] Right - Openflow assumes one controller for a switch. IRS does not. I am NOT trying to suggest/guide OpenFlow here - that is what the ONF is for. > Btw .. If IETF magically does something to equipment vendors so they will= ship FORCEs enabled platforms I am all game. That would be productive. IRS= as of now is more to mud the water then to come with an alternative to For= ces or OF. [Alia] IRS is providing control strings to different layers in the routing system. It is not doing the same thing as ForCES or Openflow. I am sorry that you feel that proposing something different is muddying the water. Alia > Best regards, > R. > > > >> Yes, there is nascent >> work on hybrid OpenFlow switches - but that is very far from a model >> based on USING the router's OS and routing capabilities and handling >> multiple applications installing state. Retrieving state is also not >> a focus in Openflow. >> >> On the upper layer, ONF is starting to tentatively talk about >> northbound APIs - which are from OpenFlow controllers up towards >> orchestrators or applications. >> >> I don't, personally, think that IRS should cover the latter upper >> layer - though a translation layer and thinking through the network OS >> abstractions is certainly interesting and part of the ecosystem. >> >> Would you care to clearly clarify your concerns and assumptions about >> intentions? >> >> The two drafts work at defining what IRS should be; I think that there >> is a clear difference in approach and intended functionality from >> OpenFlow. >> >> Surely you aren't suggesting that the IETF should not do anything in >> this space because OpenFlow might get around to it someday? >> >> Alia >> >> On Mon, Jul 30, 2012 at 9:48 PM, Robert Raszuk wrote= : >>> hi Nitin, >>> >>> >>>> So IRS needs to define interfaces for both the lower layer and the upp= er layer. >>> >>> That's precisely what openflow protocol does. Thx for confirming clearl= y the intentions ;). >>> >>> Best regards, >>> R. >>> _______________________________________________ >>> irs-discuss mailing list >>> 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 Return-Path: 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 C965111E80F5 for ; Mon, 30 Jul 2012 19:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 duZxHWS+dgYB for ; Mon, 30 Jul 2012 19:12:09 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4781C21F855D for ; Mon, 30 Jul 2012 19:12:08 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUBc+8/2KG2CVhx9ANRT9K8fZp6f7wbxu@postini.com; Mon, 30 Jul 2012 19:12:08 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jul 2012 19:08:36 -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; Mon, 30 Jul 2012 22:08:34 -0400 From: Thomas Nadeau To: Gert Grammel , "akatlas@gmail.com" Date: Mon, 30 Jul 2012 22:08:32 -0400 Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac1uwWN64ObMuHlhQ1O6WGxpRCFoGQ== Message-ID: In-Reply-To: <812700A304640D4292205D5E83FC59E1061C211F@p-embx01-eq.jnpr.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 Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS comments X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:12:11 -0000 That is correct; it is not our intent to reinvent SNMP or anything else. --Tom On 7/30/12 7:05 PM, "Gert Grammel" wrote: >Alia, > >My point was not about the abbreviation. It was about positioning IRS. >In the end IRS is not yet another MIB nor just another IGP extension. > >Gert=20 > > > > >----- Original Message ----- >From: Alia Atlas >To: Gert Grammel >Cc: irs-discuss@ietf.org >Sent: Tue Jul 31 02:44:35 2012 >Subject: Re: [irs-discuss] IRS comments > >We can consider other namings, whether NPP or RSI or other suggestions. > >I think we still have a bit of time and discussion for the >requirements before we have to finalize that. > >Alia > >On Mon, Jul 30, 2012 at 9:40 PM, Gert Grammel >wrote: >> Tom, >> >> It is confusing to understand whether IRS belongs to a new network >>management plane or if it's more of a control plane extension. The draft >>wisely avoids this classification. >> To me IRS appears to be a completely different beast which should best >>be characterized as 'Network Programming Plane' NPP. >> It neither aims to do full provisioning (as a management plane would >>do) nor aims to replace routing (as a control plane would do). >> Hence we better name the baby NPP -- thereby avoiding any linkage to >>taxation. >> >> >> Gert >> >> >> >> >> ----- Original Message ----- >> From: irs-discuss-bounces@ietf.org >> To: Lenny Giuliano; Alia Atlas >> Cc: irs-discuss@ietf.org >> Sent: Tue Jul 31 01:50:40 2012 >> Subject: Re: [irs-discuss] IRS comments >> >> >> [Re-adding IRS] >> >> Thank you for reviewing and the comments. We will incorporate >>the edits >> in the next rev. >> >> --Tom >> >> >> On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: >> >>> >>>Minor points: >>> >>>-section 4, para 2, 3rd sentence, "Howeve,r" >>> >>>-4.1.3 "There is no bidirectional programmatic interface to add, modify, >>> remove or read state from the multicast RIB." >>> -How is this unique to mcast? Couldn't you say the same thing >>> about unicast? >>> >>>-4.1.3 "The multicast state added need not match to well-known protocol >>> installed state. For instance, traffic received on an specified >>>set, >>> or all, interfaces that is destined to a particular prefix from all >>> sources or a particular prefix could be subject to the specified >>> replication." >>> -Not clear to me at all what this para is saying. >>> >>>-"IRS"- you may want to select a different acronym that isn't related to >>>something as unpopular as taxation (something we learned with AMT). >>>Maybe >>>RSI instead... >>> >>>Overall, I found the doc to be clearly written and straightforward. >>>Sounds like Openflow for routers. Not sure if it's intentional that you >>>didn't mention Openflow, but it did seem like an elephant in the room as >>>I >>>was reading thru. Also, I did wonder what was new and novel here, as >>>this >>>sounded like our SDK which has been around for years. >>> >>> >>>-Lenny >> >> _______________________________________________ >> irs-discuss mailing list >> 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 >_______________________________________________ >irs-discuss mailing list >irs-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 B290D11E8124 for ; Mon, 30 Jul 2012 19:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 QdDjUcED8xSb for ; Mon, 30 Jul 2012 19:12:08 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4789321F8569 for ; Mon, 30 Jul 2012 19:12:08 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5963052ghb.31 for ; Mon, 30 Jul 2012 19:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Efd0IJU17vlY6qJCvAXczRdeF2/oB3J7cZQBUPDPVYk=; b=m7HBuV3xNcaD86C8xm2hWMVgJ6Whp+2J3mmU0oHioKQo5g0MtL1pTC9IrJB/YKfKSU 30OEteQB/pHMHlrNeZ+tfk6u4zNxlVsV2Kc6saQFauQTO4cmu1aIgq1Ripv/TDwARFVR hWHm2bbeIwO7ZRDHm+p5wKLbD4SlpLy9eI8KBgNJjhF0+jmLsV0eMcpel4/JD/nO8bBU HNEt5ypHBpcyEIXlfWj/xyK3RBn259vyYLf4yiY02BXCDZEJdXhwQjFEihNfMThezlqL shStS+NTHFEj36mAp2xHbVQuvFFBaocpexrBKgMH4NgcEK4oGXKpEehvJ0cJhqpauX9I sbww== MIME-Version: 1.0 Received: by 10.50.236.4 with SMTP id uq4mr676117igc.18.1343700719983; Mon, 30 Jul 2012 19:11:59 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 19:11:59 -0700 (PDT) In-Reply-To: <812700A304640D4292205D5E83FC59E1061C211F@p-embx01-eq.jnpr.net> References: <812700A304640D4292205D5E83FC59E1061C211F@p-embx01-eq.jnpr.net> Date: Mon, 30 Jul 2012 22:11:59 -0400 Message-ID: From: Alia Atlas To: Gert Grammel Content-Type: text/plain; charset=ISO-8859-1 Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:12:10 -0000 I do agree - and trying to describe IRS can be hard because of confusion as to whether it is a configuration protocol or ... It's really to support programmable networks - I rather like the idea of describing it as Network Programming Plane... Alia On Mon, Jul 30, 2012 at 10:05 PM, Gert Grammel wrote: > Alia, > > My point was not about the abbreviation. It was about positioning IRS. > In the end IRS is not yet another MIB nor just another IGP extension. > > Gert > > > > > ----- Original Message ----- > From: Alia Atlas > To: Gert Grammel > Cc: irs-discuss@ietf.org > Sent: Tue Jul 31 02:44:35 2012 > Subject: Re: [irs-discuss] IRS comments > > We can consider other namings, whether NPP or RSI or other suggestions. > > I think we still have a bit of time and discussion for the > requirements before we have to finalize that. > > Alia > > On Mon, Jul 30, 2012 at 9:40 PM, Gert Grammel wrote: >> Tom, >> >> It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification. >> To me IRS appears to be a completely different beast which should best be characterized as 'Network Programming Plane' NPP. >> It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do). >> Hence we better name the baby NPP -- thereby avoiding any linkage to taxation. >> >> >> Gert >> >> >> >> >> ----- Original Message ----- >> From: irs-discuss-bounces@ietf.org >> To: Lenny Giuliano; Alia Atlas >> Cc: irs-discuss@ietf.org >> Sent: Tue Jul 31 01:50:40 2012 >> Subject: Re: [irs-discuss] IRS comments >> >> >> [Re-adding IRS] >> >> Thank you for reviewing and the comments. We will incorporate the edits >> in the next rev. >> >> --Tom >> >> >> On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: >> >>> >>>Minor points: >>> >>>-section 4, para 2, 3rd sentence, "Howeve,r" >>> >>>-4.1.3 "There is no bidirectional programmatic interface to add, modify, >>> remove or read state from the multicast RIB." >>> -How is this unique to mcast? Couldn't you say the same thing >>> about unicast? >>> >>>-4.1.3 "The multicast state added need not match to well-known protocol >>> installed state. For instance, traffic received on an specified set, >>> or all, interfaces that is destined to a particular prefix from all >>> sources or a particular prefix could be subject to the specified >>> replication." >>> -Not clear to me at all what this para is saying. >>> >>>-"IRS"- you may want to select a different acronym that isn't related to >>>something as unpopular as taxation (something we learned with AMT). >>>Maybe >>>RSI instead... >>> >>>Overall, I found the doc to be clearly written and straightforward. >>>Sounds like Openflow for routers. Not sure if it's intentional that you >>>didn't mention Openflow, but it did seem like an elephant in the room as >>>I >>>was reading thru. Also, I did wonder what was new and novel here, as >>>this >>>sounded like our SDK which has been around for years. >>> >>> >>>-Lenny >> >> _______________________________________________ >> irs-discuss mailing list >> 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 Return-Path: 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 6D70111E811A for ; Mon, 30 Jul 2012 19:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 rdnpxmfybTOo for ; Mon, 30 Jul 2012 19:10:51 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 4E28511E80F5 for ; Mon, 30 Jul 2012 19:10:51 -0700 (PDT) Received: (qmail 19588 invoked by uid 399); 31 Jul 2012 02:10:50 -0000 Received: from unknown (HELO ?130.129.19.9?) (robert@raszuk.net@130.129.19.9) by mail1310.opentransfer.com with ESMTPAM; 31 Jul 2012 02:10:50 -0000 X-Originating-IP: 130.129.19.9 References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> <879186E3-D9D7-49B5-8E38-8CC4E4D34282@juniper.net> In-Reply-To: <879186E3-D9D7-49B5-8E38-8CC4E4D34282@juniper.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <2E42195C-1292-49E7-85B6-6FA9BC326442@raszuk.net> X-Mailer: iPad Mail (9B206) From: Robert Raszuk Date: Mon, 30 Jul 2012 19:10:49 -0700 To: Nitin Bahadur Cc: Thomas Nadeau , James Kempf , Susan Hares , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:10:52 -0000 > [ off-topic ] >=20 > Today in IDR, Microsoft folks presented on running data centers using BGP.= So I guess we should put OSPF & ISIS to rest. We can use BGP for everything= . >=20 No > [ / off-topic ] >=20 > Openflow abstractions are at the forwarding level. IRS does not compete wi= th that. >=20 > [ rant ] > Did I just hear that you've convinced your company to replace all of its n= etworking gear with OF gear and a uber powerful controller. > [ / rant ] No Thx, R. >=20 > Thanks > Nitin >=20 > On Jul 30, 2012, at 6:48 PM, "Robert Raszuk" wrote: >=20 >> hi Nitin, >>=20 >>=20 >>> So IRS needs to define interfaces for both the lower layer and the upper= layer. >>=20 >> That's precisely what openflow protocol does. Thx for confirming clearly t= he intentions ;). >>=20 >> Best regards, >> R. Return-Path: 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 F25BB11E80F5 for ; Mon, 30 Jul 2012 19:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 JNxc0HC7IFLw for ; Mon, 30 Jul 2012 19:09:18 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 378A411E80EE for ; Mon, 30 Jul 2012 19:09:18 -0700 (PDT) Received: (qmail 18485 invoked by uid 399); 31 Jul 2012 02:09:17 -0000 Received: from unknown (HELO ?130.129.19.9?) (robert@raszuk.net@130.129.19.9) by mail1310.opentransfer.com with ESMTPAM; 31 Jul 2012 02:09:17 -0000 X-Originating-IP: 130.129.19.9 References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Robert Raszuk Date: Mon, 30 Jul 2012 19:09:09 -0700 To: Alia Atlas Cc: Thomas Nadeau , Nitin Bahadur , Susan Hares , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:09:19 -0000 Alia, > Hi Rob, >=20 > On the lower layer, Openflow talks to control/specify the forwarding > plane - heading towards forwarding plane modeling; something that > ForCES did a while ago. It focuses on Layer-2 and does not interact > with the routing control plane - generally assuming that the routing > control protocol does not/should not exist. =20 Completely incorrect assumption sorry. OF does not assume L2 as an example I= have been working on routing applications over OF based data plane for over= a year now. OF separates control plane including ability to run routing protocols from f= orwarding entities. That's the most important point. Hybrid work actually does not help too much .. Especially the integrated eff= ort. Retrieving state is not a focus as the assumption is that such state is= known in the controller. However state validation or verification is someth= ing that OF need to pay more attention to - no question. Btw .. If IETF magically does something to equipment vendors so they will sh= ip FORCEs enabled platforms I am all game. That would be productive. IRS as o= f now is more to mud the water then to come with an alternative to Forces or= OF. Best regards, R. > Yes, there is nascent > work on hybrid OpenFlow switches - but that is very far from a model > based on USING the router's OS and routing capabilities and handling > multiple applications installing state. Retrieving state is also not > a focus in Openflow. >=20 > On the upper layer, ONF is starting to tentatively talk about > northbound APIs - which are from OpenFlow controllers up towards > orchestrators or applications. >=20 > I don't, personally, think that IRS should cover the latter upper > layer - though a translation layer and thinking through the network OS > abstractions is certainly interesting and part of the ecosystem. >=20 > Would you care to clearly clarify your concerns and assumptions about > intentions? >=20 > The two drafts work at defining what IRS should be; I think that there > is a clear difference in approach and intended functionality from > OpenFlow. >=20 > Surely you aren't suggesting that the IETF should not do anything in > this space because OpenFlow might get around to it someday? >=20 > Alia >=20 > On Mon, Jul 30, 2012 at 9:48 PM, Robert Raszuk wrote: >> hi Nitin, >>=20 >>=20 >>> So IRS needs to define interfaces for both the lower layer and the upper= layer. >>=20 >> That's precisely what openflow protocol does. Thx for confirming clearly t= he intentions ;). >>=20 >> Best regards, >> R. >> _______________________________________________ >> irs-discuss mailing list >> 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 Return-Path: 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 5EB0D11E810F for ; Mon, 30 Jul 2012 19:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.365, 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 HpIqrIitsFwT for ; Mon, 30 Jul 2012 19:07:20 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 54FDB11E8105 for ; Mon, 30 Jul 2012 19:07:20 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUBc91zFVWzlLEm5mSwh8OhkLhWuUe1fX@postini.com; Mon, 30 Jul 2012 19:07:20 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.3.213.0; Mon, 30 Jul 2012 19:05:20 -0700 Received: from p-embx01-eq.jnpr.net ([172.26.192.150]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jul 2012 03:05:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Jul 2012 03:05:18 +0100 Message-ID: <812700A304640D4292205D5E83FC59E1061C211F@p-embx01-eq.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [irs-discuss] IRS comments Thread-Index: Ac1uvgwqE+kfC8oUSSyi22wTl6lt6wAAuLOA From: Gert Grammel To: X-OriginalArrivalTime: 31 Jul 2012 02:05:18.0930 (UTC) FILETIME=[EF302B20:01CD6EC0] Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:07:21 -0000 Alia, My point was not about the abbreviation. It was about positioning IRS.=20 In the end IRS is not yet another MIB nor just another IGP extension. Gert=20 ----- Original Message ----- From: Alia Atlas To: Gert Grammel Cc: irs-discuss@ietf.org Sent: Tue Jul 31 02:44:35 2012 Subject: Re: [irs-discuss] IRS comments We can consider other namings, whether NPP or RSI or other suggestions. I think we still have a bit of time and discussion for the requirements before we have to finalize that. Alia On Mon, Jul 30, 2012 at 9:40 PM, Gert Grammel = wrote: > Tom, > > It is confusing to understand whether IRS belongs to a new network = management plane or if it's more of a control plane extension. The draft = wisely avoids this classification. > To me IRS appears to be a completely different beast which should best = be characterized as 'Network Programming Plane' NPP. > It neither aims to do full provisioning (as a management plane would = do) nor aims to replace routing (as a control plane would do). > Hence we better name the baby NPP -- thereby avoiding any linkage to = taxation. > > > Gert > > > > > ----- Original Message ----- > From: irs-discuss-bounces@ietf.org > To: Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Sent: Tue Jul 31 01:50:40 2012 > Subject: Re: [irs-discuss] IRS comments > > > [Re-adding IRS] > > Thank you for reviewing and the comments. We will incorporate = the edits > in the next rev. > > --Tom > > > On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: > >> >>Minor points: >> >>-section 4, para 2, 3rd sentence, "Howeve,r" >> >>-4.1.3 "There is no bidirectional programmatic interface to add, = modify, >> remove or read state from the multicast RIB." >> -How is this unique to mcast? Couldn't you say the same thing >> about unicast? >> >>-4.1.3 "The multicast state added need not match to well-known = protocol >> installed state. For instance, traffic received on an specified = set, >> or all, interfaces that is destined to a particular prefix from = all >> sources or a particular prefix could be subject to the specified >> replication." >> -Not clear to me at all what this para is saying. >> >>-"IRS"- you may want to select a different acronym that isn't related = to >>something as unpopular as taxation (something we learned with AMT). >>Maybe >>RSI instead... >> >>Overall, I found the doc to be clearly written and straightforward. >>Sounds like Openflow for routers. Not sure if it's intentional that = you >>didn't mention Openflow, but it did seem like an elephant in the room = as >>I >>was reading thru. Also, I did wonder what was new and novel here, as >>this >>sounded like our SDK which has been around for years. >> >> >>-Lenny > > _______________________________________________ > irs-discuss mailing list > 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 Return-Path: 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 1B18D11E80EE for ; Mon, 30 Jul 2012 19:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 phNr+FI4lr+8 for ; Mon, 30 Jul 2012 19:07:02 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD1C11E80D2 for ; Mon, 30 Jul 2012 19:07:02 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUBc9vS6xQSkH1+R8iKXTAdTUSIqF5ApP@postini.com; Mon, 30 Jul 2012 19:07:02 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 30 Jul 2012 19:06:41 -0700 From: Nitin Bahadur To: Robert Raszuk Date: Mon, 30 Jul 2012 19:06:42 -0700 Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1uwSAnSG+rmSQ3S12saISb+HgJ8Q== Message-ID: <879186E3-D9D7-49B5-8E38-8CC4E4D34282@juniper.net> References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Nadeau , James Kempf , Susan Hares , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:07:03 -0000 [ off-topic ] Today in IDR, Microsoft folks presented on running data centers using BGP. = So I guess we should put OSPF & ISIS to rest. We can use BGP for everything= . [ / off-topic ] Openflow abstractions are at the forwarding level. IRS does not compete wit= h that. [ rant ] Did I just hear that you've convinced your company to replace all of its ne= tworking gear with OF gear and a uber powerful controller. [ / rant ] Thanks Nitin On Jul 30, 2012, at 6:48 PM, "Robert Raszuk" wrote: > hi Nitin, >=20 >=20 >> So IRS needs to define interfaces for both the lower layer and the upper= layer. >=20 > That's precisely what openflow protocol does. Thx for confirming clearly = the intentions ;). >=20 > Best regards, > R. Return-Path: 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 C3EA011E8091 for ; Mon, 30 Jul 2012 18:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7r3VzmBpXywc for ; Mon, 30 Jul 2012 18:58:10 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE8F511E808A for ; Mon, 30 Jul 2012 18:58:10 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5989099ggn.31 for ; Mon, 30 Jul 2012 18:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dJgnJJozKcINBAOFvUb3e6CmY2JZWalGtrqw6Xjf7B0=; b=evKKJOMuvTb8uuLEU0aflNrgnxwRWfZuPWetKfbLKUfRDBNcwMwVF85HHNucFsZFu0 RzFb0/RVAkv3D3FAkbUMjmkYCH1bN2VOChUKj7eumd0TpOTrif6Wq5iQsHRleB/AxtG1 fALOTRzwX4cDI/Ri1SmvmHSVxpBmMWPFzPq8V8VGryJzzIdgjLgvYGTlkzrlELlN1EAR kIK18AvGD+MTbaxVtnEx+Fpo5jUxf7NqBb2zX6e9JRHooWmkJSPUWejB4twfm/Pf7abY 3d+lciWs5e8zLlVhAk1iJZGtvrl9pf5XXvtZtH2DYJPHqhZ/ymb//ldgtfUPTTrHSpXi gOgw== MIME-Version: 1.0 Received: by 10.50.216.202 with SMTP id os10mr561089igc.17.1343699889897; Mon, 30 Jul 2012 18:58:09 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 18:58:09 -0700 (PDT) In-Reply-To: References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> Date: Mon, 30 Jul 2012 21:58:09 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Nadeau , Nitin Bahadur , Susan Hares , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:58:11 -0000 Hi Rob, On the lower layer, Openflow talks to control/specify the forwarding plane - heading towards forwarding plane modeling; something that ForCES did a while ago. It focuses on Layer-2 and does not interact with the routing control plane - generally assuming that the routing control protocol does not/should not exist. Yes, there is nascent work on hybrid OpenFlow switches - but that is very far from a model based on USING the router's OS and routing capabilities and handling multiple applications installing state. Retrieving state is also not a focus in Openflow. On the upper layer, ONF is starting to tentatively talk about northbound APIs - which are from OpenFlow controllers up towards orchestrators or applications. I don't, personally, think that IRS should cover the latter upper layer - though a translation layer and thinking through the network OS abstractions is certainly interesting and part of the ecosystem. Would you care to clearly clarify your concerns and assumptions about intentions? The two drafts work at defining what IRS should be; I think that there is a clear difference in approach and intended functionality from OpenFlow. Surely you aren't suggesting that the IETF should not do anything in this space because OpenFlow might get around to it someday? Alia On Mon, Jul 30, 2012 at 9:48 PM, Robert Raszuk wrote: > hi Nitin, > > >> So IRS needs to define interfaces for both the lower layer and the upper layer. > > That's precisely what openflow protocol does. Thx for confirming clearly the intentions ;). > > Best regards, > R. > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 F037121F850C for ; Mon, 30 Jul 2012 18:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 ti-4K6xAxe5r for ; Mon, 30 Jul 2012 18:48:16 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id D43B021F8512 for ; Mon, 30 Jul 2012 18:48:15 -0700 (PDT) Received: (qmail 27402 invoked by uid 399); 31 Jul 2012 01:48:14 -0000 Received: from unknown (HELO ?130.129.19.9?) (robert@raszuk.net@130.129.19.9) by mail1310.opentransfer.com with ESMTPAM; 31 Jul 2012 01:48:14 -0000 X-Originating-IP: 130.129.19.9 References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Robert Raszuk Date: Mon, 30 Jul 2012 18:48:06 -0700 To: Nitin Bahadur Cc: Thomas Nadeau , James Kempf , Susan Hares , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:48:17 -0000 hi Nitin, > So IRS needs to define interfaces for both the lower layer and the upper l= ayer. That's precisely what openflow protocol does. Thx for confirming clearly the= intentions ;). Best regards, R.= Return-Path: 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 16DC821F8508 for ; Mon, 30 Jul 2012 18:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 mProl7Xz6JQa for ; Mon, 30 Jul 2012 18:44:36 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 65C3621F8505 for ; Mon, 30 Jul 2012 18:44:36 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5980563ggn.31 for ; Mon, 30 Jul 2012 18:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1/gqsD9pVPqBFQyUqTAu+e0TsGIqwGRREfqhYOh48Xw=; b=gfUXvJlv76yuBOo1P+Z5QRUo8lW3Un2u4h9DDUxbT/rtuRZkoHB68ZlqTlburhJwwd jMqLvVfTMi+1fzYmMzQKXa6KkvsUiD1sz4MlF0GnWNYcr9yHtunl3YBjqcWN3z07Bkv3 437Dht/vJ4SRN8liFdsX0fTi32x7Du0CclveU2NFm7yqs5TQU0gGDwx16Jz0psdY5zIT AMKXjrApMzDDdtS2i6gNfFK2j4yhewjheUd5m38xkqucfetkscoOWq2wX/e7R+zaIg5W CEJFrAKQKY6yomNcWD/2idOvK74kIguggfK+PtXp0UqpS/6gjVfpIrF34iZnDvTfQBEr EkyQ== MIME-Version: 1.0 Received: by 10.50.158.226 with SMTP id wx2mr478308igb.18.1343699075155; Mon, 30 Jul 2012 18:44:35 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 18:44:35 -0700 (PDT) In-Reply-To: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> References: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> Date: Mon, 30 Jul 2012 21:44:35 -0400 Message-ID: From: Alia Atlas To: Gert Grammel Content-Type: text/plain; charset=ISO-8859-1 Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:44:37 -0000 We can consider other namings, whether NPP or RSI or other suggestions. I think we still have a bit of time and discussion for the requirements before we have to finalize that. Alia On Mon, Jul 30, 2012 at 9:40 PM, Gert Grammel wrote: > Tom, > > It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification. > To me IRS appears to be a completely different beast which should best be characterized as 'Network Programming Plane' NPP. > It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do). > Hence we better name the baby NPP -- thereby avoiding any linkage to taxation. > > > Gert > > > > > ----- Original Message ----- > From: irs-discuss-bounces@ietf.org > To: Lenny Giuliano; Alia Atlas > Cc: irs-discuss@ietf.org > Sent: Tue Jul 31 01:50:40 2012 > Subject: Re: [irs-discuss] IRS comments > > > [Re-adding IRS] > > Thank you for reviewing and the comments. We will incorporate the edits > in the next rev. > > --Tom > > > On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: > >> >>Minor points: >> >>-section 4, para 2, 3rd sentence, "Howeve,r" >> >>-4.1.3 "There is no bidirectional programmatic interface to add, modify, >> remove or read state from the multicast RIB." >> -How is this unique to mcast? Couldn't you say the same thing >> about unicast? >> >>-4.1.3 "The multicast state added need not match to well-known protocol >> installed state. For instance, traffic received on an specified set, >> or all, interfaces that is destined to a particular prefix from all >> sources or a particular prefix could be subject to the specified >> replication." >> -Not clear to me at all what this para is saying. >> >>-"IRS"- you may want to select a different acronym that isn't related to >>something as unpopular as taxation (something we learned with AMT). >>Maybe >>RSI instead... >> >>Overall, I found the doc to be clearly written and straightforward. >>Sounds like Openflow for routers. Not sure if it's intentional that you >>didn't mention Openflow, but it did seem like an elephant in the room as >>I >>was reading thru. Also, I did wonder what was new and novel here, as >>this >>sounded like our SDK which has been around for years. >> >> >>-Lenny > > _______________________________________________ > irs-discuss mailing list > 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 Return-Path: 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 0D60111E80F2 for ; Mon, 30 Jul 2012 18:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.052 X-Spam-Level: X-Spam-Status: No, score=-6.052 tagged_above=-999 required=5 tests=[AWL=0.547, 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 OH5K2LjX3CIF for ; Mon, 30 Jul 2012 18:42:19 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 4257411E80D5 for ; Mon, 30 Jul 2012 18:42:19 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUBc3+WL3GvP39CLpSuOmEYlR6asfTjfF@postini.com; Mon, 30 Jul 2012 18:42:19 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.3.213.0; Mon, 30 Jul 2012 18:40:59 -0700 Received: from p-embx01-eq.jnpr.net ([172.26.192.150]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jul 2012 02:40:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Jul 2012 02:40:56 +0100 Message-ID: <812700A304640D4292205D5E83FC59E1061C211D@p-embx01-eq.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IRS comments Thread-Index: Ac1utoJXMLn1Fv5cTmO9ZkEBmEbA7gABwUJe From: Gert Grammel To: Thomas Nadeau , Lenny Giuliano , Alia Atlas X-OriginalArrivalTime: 31 Jul 2012 01:40:56.0715 (UTC) FILETIME=[87A3DDB0:01CD6EBD] Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] IRS comments X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:42:20 -0000 Tom, It is confusing to understand whether IRS belongs to a new network = management plane or if it's more of a control plane extension. The draft = wisely avoids this classification. To me IRS appears to be a completely different beast which should best = be characterized as 'Network Programming Plane' NPP.=20 It neither aims to do full provisioning (as a management plane would do) = nor aims to replace routing (as a control plane would do). Hence we better name the baby NPP -- thereby avoiding any linkage to = taxation. Gert ----- Original Message ----- From: irs-discuss-bounces@ietf.org To: Lenny Giuliano; Alia Atlas Cc: irs-discuss@ietf.org Sent: Tue Jul 31 01:50:40 2012 Subject: Re: [irs-discuss] IRS comments [Re-adding IRS] Thank you for reviewing and the comments. We will incorporate the edits in the next rev. --Tom On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: > >Minor points: > >-section 4, para 2, 3rd sentence, "Howeve,r" > >-4.1.3 "There is no bidirectional programmatic interface to add, = modify, > remove or read state from the multicast RIB." > -How is this unique to mcast? Couldn't you say the same thing > about unicast? > >-4.1.3 "The multicast state added need not match to well-known protocol > installed state. For instance, traffic received on an specified = set, > or all, interfaces that is destined to a particular prefix from all > sources or a particular prefix could be subject to the specified > replication." > -Not clear to me at all what this para is saying. > >-"IRS"- you may want to select a different acronym that isn't related = to >something as unpopular as taxation (something we learned with AMT). >Maybe=20 >RSI instead... > >Overall, I found the doc to be clearly written and straightforward. >Sounds like Openflow for routers. Not sure if it's intentional that = you >didn't mention Openflow, but it did seem like an elephant in the room = as >I=20 >was reading thru. Also, I did wonder what was new and novel here, as >this=20 >sounded like our SDK which has been around for years. > > >-Lenny _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 A8B2211E8088 for ; Mon, 30 Jul 2012 18:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 n-Q1EB5gPpbN for ; Mon, 30 Jul 2012 18:39:36 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D822D21F843E for ; Mon, 30 Jul 2012 18:39:35 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5942429ghb.31 for ; Mon, 30 Jul 2012 18:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nLuSMkuo2yRNYg7+GqAGdS+6ifapS3hrey53d8wI36g=; b=X+cg2MD8gnikfM860uEWXws8Mh06BRaCfKYFm5Teeg7f+OW5u4vqqxNaEsMzYQFiK5 hvdatA49KMYVRbMQD/J5sntIokiL093Sh02/ndAhhPGUDnzmDh6jJTdjTqoLM9mOiZOs tb8gaNB9+R1qIdFXEmnJGVbK403Wy2WeMbcxEsunkVjxGzleUPrUl7zxhQbgpcBWiBJF zfj92hwz4n3MA3VpE7Ck0mxP02SePGypT+a1bUGnXBqgu3XmY1PRUbmUtm0ytMAj01at 1mL6fAgvLNkOn/2liQGZd8rHWIxxdzb5Tw6Ye6h2d5tSDQOnqfihCO2IjkSCHZJsFOwJ riww== MIME-Version: 1.0 Received: by 10.50.213.1 with SMTP id no1mr469081igc.71.1343698775070; Mon, 30 Jul 2012 18:39:35 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 18:39:35 -0700 (PDT) In-Reply-To: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> Date: Mon, 30 Jul 2012 21:39:35 -0400 Message-ID: From: Alia Atlas To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Nadeau , Nitin Bahadur , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:39:36 -0000 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 wrote= : > Nitin: > > Exposing some network intelligence can either be done in detail or in som= e amount of summarization. > If you are doing detail, you have bandwidth issues. If you are doing summ= arization 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 det= ails - just the fact they can get from point A to Point B (or for multi-cas= t 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 o= f exposing information. > > Sue Hares > > -----Original Message----- > From: 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 > Subject: Re: [irs-discuss] IRS Problem Statement Posted > > Hi James, > > This is not about splitting control plane and forwarding plane. It is abo= ut exposing network intelligence in the network elements to an external con= troller. > And it is about allowing an external controller to use that information f= or 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 req= uest/response gated mechanism. > > Hope that helps. > > Thanks > Nitin > > On 7/30/12 3:11 PM, "James Kempf" 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 fr= amework explicitedly designed for device to controller communication. Its m= ajor 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 stat= e update. Forces has already established that splitting the control plane i= nto 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, r= ecast in the Forces framework. > > jak > >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Monday, July 30, 2012 11:18 AM >> To: 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 >> https://www.ietf.org/mailman/listinfo/irs-discuss >> > _______________________________________________ > irs-discuss mailing list > 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 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 7A5F021F84C8 for ; Mon, 30 Jul 2012 18:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 fVt2+yX1fMff for ; Mon, 30 Jul 2012 18:39:28 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5534D21F84B9 for ; Mon, 30 Jul 2012 18:39:26 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUBc3R3K7M1C5cI8fDUTPOqpJgPWIaMBh@postini.com; Mon, 30 Jul 2012 18:39:26 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 30 Jul 2012 18:39:06 -0700 From: Nitin Bahadur To: Susan Hares Date: Mon, 30 Jul 2012 18:39:07 -0700 Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1uvUYitDcUATnOQoe+4Z7tDqzUdg== Message-ID: References: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> In-Reply-To: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Nadeau , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:39:29 -0000 Hi Susan, You've expressed my thoughts very succinctly. I fully agree with all yo= u said. IRS is nothing but a middleware IMO.=20 An orchestrator has 3 layers: The top layer exposes the northbound Apis to apps - I want a path from A to= B with a constrain on low latency. That's all the app should need to say. The bottom layer fetches topology, stats and other data from network elemen= ts and programs the network elements. And the middle layer is the business layer that takes user input from north= bound Apis, takes input from bottom layer; munches on the data and converts= it into rules for the bottom layer to program. So IRS needs to define interfaces for both the lower layer and the upper la= yer. Thanks Nitin On Jul 30, 2012, at 6:27 PM, "Susan Hares" wrote: > Nitin:=20 >=20 > Exposing some network intelligence can either be done in detail or in som= e amount of summarization.=20 > If you are doing detail, you have bandwidth issues. If you are doing summ= arization or opacity, you are talking about layers of information.=20 >=20 > Apps need to find out what they need to get. They do not need all the det= ails - just the fact they can get from point A to Point B (or for multi-cas= t 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. =20 >=20 > The network orchestration then serves to be the paths to the place to eat= . This can either be distributed or centralized. =20 >=20 > If we have an Interface to routing, it need to have a two-layer concept o= f exposing information. =20 >=20 > Sue Hares=20 >=20 > -----Original Message----- > From: 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 > Subject: Re: [irs-discuss] IRS Problem Statement Posted >=20 > Hi James, >=20 > This is not about splitting control plane and forwarding plane. It is abo= ut exposing network intelligence in the network elements to an external con= troller. > And it is about allowing an external controller to use that information f= or enabling network-aware apps. And it is about allowing apps to influence = the > network element's RIB (not the FIB directly). >=20 > Streaming is essential to allow for operations at scale...and avoid a req= uest/response gated mechanism. >=20 > Hope that helps. >=20 > Thanks > Nitin >=20 > On 7/30/12 3:11 PM, "James Kempf" wrote: >=20 > 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 fr= amework explicitedly designed for device to controller communication. Its m= ajor 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. >=20 > I don't think it is necessary to have a problem statement for router stat= e update. Forces has already established that splitting the control plane i= nto 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, r= ecast in the Forces framework. >=20 > jak >=20 >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Monday, July 30, 2012 11:18 AM >> To: irs-discuss@ietf.org >> Subject: [irs-discuss] IRS Problem Statement Posted >>=20 >>=20 >>=20 >> Please review and discuss. >>=20 >> Thanks, >>=20 >> Tom, Alia, Ward >>=20 >>=20 >> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>=20 >>=20 >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss >>=20 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 9051711E810F for ; Mon, 30 Jul 2012 18:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 9keKtYX1wHGU for ; Mon, 30 Jul 2012 18:33:11 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3AB21F8441 for ; Mon, 30 Jul 2012 18:33:11 -0700 (PDT) Received: by yhq56 with SMTP id 56so5974409yhq.31 for ; Mon, 30 Jul 2012 18:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=iAmLhcRx6MACkBQlBCE5DBms6+fW6lmPl79JHjiCxyY=; b=bG8/KlquVdyR4Z4t4sCjs9UP+LV8m2ntPd453wcCX+cgjBsz5FKHlBqeiqQ3paV26E kDqcQ0GLRUNbYRdQ2e1khD00ktOG4EglUSv1huryRsRYL//9ZrSnPgUhrgUGEV9EcAtN 3V/Kl9enCICkbTpgUJa/j/ZyjutEj9XoYJntZuqdtvAfxLJmpHBTy+OLWlQOAdgfXgG8 S0SbN166P9DYhJRHtwQrNRMBpWuJbcpRg2NZY9bwB8Jq6BU6l4ZlcmImnBIc5/96bv/Z Jrdk1DhJRjEtGnFmDbML2kt/7TIDxMz0Gmg0luW7PjfpNbwnn2Ua8IQ+qMAePYiBIvLF zlpg== MIME-Version: 1.0 Received: by 10.50.158.226 with SMTP id wx2mr457367igb.18.1343698390695; Mon, 30 Jul 2012 18:33:10 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 18:33:10 -0700 (PDT) In-Reply-To: <728F9B956B2C48439CA9294B1723B14623754A03@dfweml509-mbs.china.huawei.com> References: <20120730180849.1235.96769.idtracker@ietfa.amsl.com> <50170758.3030908@joelhalpern.com> <728F9B956B2C48439CA9294B1723B14623754A03@dfweml509-mbs.china.huawei.com> Date: Mon, 30 Jul 2012 21:33:10 -0400 Message-ID: From: Alia Atlas To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:33:12 -0000 Hi Sue, On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares 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 p= rioritization and sequencing is key to multi-interfaces operation on the mo= nitoring, 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. [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. > 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. Alia > Sue > > > > -----Original Message----- > From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] = On Behalf Of Joel M. Halpern > Sent: Monday, July 30, 2012 3:15 PM > To: 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 wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> >> >> 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 th= e >> 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 > https://www.ietf.org/mailman/listinfo/irs-discuss > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 B03B421F8442 for ; Mon, 30 Jul 2012 18:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=3.061, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, 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 ahp-0UFgh5Si for ; Mon, 30 Jul 2012 18:32:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id ADA7521F8441 for ; Mon, 30 Jul 2012 18:32:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIF35399; Mon, 30 Jul 2012 21:32:55 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jul 2012 18:31:01 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Mon, 30 Jul 2012 18:30:56 -0700 From: Susan Hares To: Thomas Nadeau , "Joel M. Halpern" Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1uf6vUr0RoAYPERve+GHr5XPQ6JgAIAMEAAA9c7IAAAHDOAAAAf0EAAAleJJA= Date: Tue, 31 Jul 2012 01:30:55 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623754A35@dfweml509-mbs.china.huawei.com> References: <50170D34.503@joelhalpern.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Nadeau , James Kempf , Alia Atlas , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:32:56 -0000 Joel: +1. IRS requires many different things. We can use netconf, netmod+yang, = ForCES. As my draft states, ForCES is likely to be equivalent or better than ONF. (= OFS: [0.9][1.0][1.1][1.2]). See my detailed review, and the 2nd drafts reca= sting of ONF as ForCES LFB. We need to look at the requirements of the routing system and your proposed= multiple interfaces.=20 Sue=20 -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Thomas Nadeau Sent: Monday, July 30, 2012 3:54 PM To: Joel M. Halpern Cc: Thomas Nadeau; James Kempf; irs-discuss@ietf.org; Alia Atlas Subject: Re: [irs-discuss] IRS Problem Statement Posted On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" wrote: > Alia, I do have to disagree with one aspect of your characterization fo F= orCES. While the initial design goal was forwarding behavior, the protocol= design is such that it is usable over a broad range of abstraction levels. >=20 > Similarly, depending upon exactly what we need, netconf + Netmad/YANG may= be suitable / useable. We are not ruling out any existing solutions, either in whole or in part (= modified). The goal right now is to define the problem space and a framewor= k of components that can be used to solve that problem. > On the other hand, I think that working out the problems and entities tha= t need to be modeled first (which probably does need a dedicated working gr= oup), and then worrying about which protocol meets the requirements when we= know what exactly we need. At that point, the protocol work can be done w= herever appropriate. Yes, that is precisely what the goals are right now. --Tom >=20 > yours, > Jitl >=20 > On 7/30/2012 6:27 PM, Alia Atlas wrote: >> Hi James, >>=20 >> Thanks for your thoughts. Streaming (as I've heard) is not as good a >> description of the desired interface attributes as described in Sec >> 1.1, the functional overview. >>=20 >> IRS is NOT about having interfaces to the forwarding plane. That's >> what ForCES is focused on. This is about communication to a router >> to install/retrieve routing state into the routing system (FIB, IGPs, >> BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from the >> router. >>=20 >> Are you suggesting that ForCES should drastically expand its scope? >>=20 >> Before we start debating what and whether to expand existing >> protocols, I think we need a common understanding of the problem we're >> trying to solve and the related framework. >>=20 >> Alia >>=20 >> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf = 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 tha= t there are no specified devices. This draft would fill that hole. >>>=20 >>> I don't think it is necessary to have a problem statement for router st= ate 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. >>>=20 >>> jak >>>=20 >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >>>> Sent: Monday, July 30, 2012 11:18 AM >>>> To: irs-discuss@ietf.org >>>> Subject: [irs-discuss] IRS Problem Statement Posted >>>>=20 >>>>=20 >>>>=20 >>>> Please review and discuss. >>>>=20 >>>> Thanks, >>>>=20 >>>> Tom, Alia, Ward >>>>=20 >>>>=20 >>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> irs-discuss mailing list >>>> irs-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>>=20 >>> _______________________________________________ >>> irs-discuss mailing list >>> 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 >>=20 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 E03DE11E8113 for ; Mon, 30 Jul 2012 18:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.865 X-Spam-Level: X-Spam-Status: No, score=-2.865 tagged_above=-999 required=5 tests=[AWL=3.735, 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 SG5sc9woBT+M for ; Mon, 30 Jul 2012 18:27:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BAA9B11E80DB for ; Mon, 30 Jul 2012 18:27:23 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIF35174; Mon, 30 Jul 2012 21:27:23 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jul 2012 18:24:37 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Mon, 30 Jul 2012 18:24:39 -0700 From: Susan Hares To: Nitin Bahadur , James Kempf , Thomas Nadeau , "irs-discuss@ietf.org" Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1uf6vUr0RoAYPERve+GHr5XPQ6JgAIAMEAAADmuywABbPeIA== Date: Tue, 31 Jul 2012 01:24:39 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623754A18@dfweml509-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:27:27 -0000 Nitin:=20 Exposing some network intelligence can either be done in detail or in some = amount of summarization.=20 If you are doing detail, you have bandwidth issues. If you are doing summar= ization or opacity, you are talking about layers of information.=20 Apps need to find out what they need to get. They do not need all the detai= ls - 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 ne= ed a match-maker for the application who determine where the applications s= hall flow. Now, if they are smart - like people going out to eat - they pi= ck several ways go to eat traffic. =20 The network orchestration then serves to be the paths to the place to eat. = This can either be distributed or centralized. =20 If we have an Interface to routing, it need to have a two-layer concept of = exposing information. =20 Sue Hares=20 -----Original Message----- From: 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 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 contr= oller. 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 th= e network element's RIB (not the FIB directly). Streaming is essential to allow for operations at scale...and avoid a reque= st/response gated mechanism. Hope that helps. Thanks Nitin On 7/30/12 3:11 PM, "James Kempf" wrote: I don't understand why streaming is specified in this draft. And I don't un= derstand why this draft isn't put in the Forces framework. Forces is a fram= ework explicitedly designed for device to controller communication. Its maj= or drawback it that it is a framework with a hole in the middle, in that th= ere 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 int= o a separate device is, in some cases, an attractive design option. So I th= ink this should be submitted to the Forces working group, or, at least, rec= ast in the Forces framework. jak > -----Original Message----- > From: irs-discuss-bounces@ietf.org > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Monday, July 30, 2012 11:18 AM > To: 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 > https://www.ietf.org/mailman/listinfo/irs-discuss > _______________________________________________ irs-discuss mailing list 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 Return-Path: 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 79EE811E80E4 for ; Mon, 30 Jul 2012 18:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qOrBNs3ugovW for ; Mon, 30 Jul 2012 18:23:01 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD3711E80DE for ; Mon, 30 Jul 2012 18:23:01 -0700 (PDT) Received: by yhq56 with SMTP id 56so5967725yhq.31 for ; Mon, 30 Jul 2012 18:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UfXOC3YbdFM8twFPlF2tQydlOe4oqz+9+0JBqWM3FBg=; b=1F/OFIUK6d/vjOirvMbrQzIz3vty8QM3QZWD06Xvv5/L8dyaZxxWEAlF+ESRplzIqg kNgcxXu9Tm9bZau9AgZMg/8qAFvUliGwSE0Bd5SRBX3SduzMFpV/c4j01E5uXL6Enki9 zz0+LJZJCika8CPaBhHvwX07tVtcAB+Y3ehRZankalRHVnc7hvekvEM777Vx67vBl66Y xD1KnIfBCt+yHsVwjXFOALKr7Ay8+vWA+j/JQOrqFoSz8MUu0wgoPkxodDdRmDCTySMI fmNU48XFzVE+eelHkp/1LYXCzVt8k2DHW/9Ii8SAhToOu3PzAwa2eNkHFuri3oD/luZ8 9GPQ== MIME-Version: 1.0 Received: by 10.50.104.228 with SMTP id gh4mr431554igb.71.1343697780583; Mon, 30 Jul 2012 18:23:00 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 18:23:00 -0700 (PDT) In-Reply-To: <82E1F44F-5EB2-4B06-8682-724555B51896@raszuk.net> References: <50170D34.503@joelhalpern.com> <1FB014C5-8B5A-4D34-82AD-D8E64A0098FF@raszuk.net> <82E1F44F-5EB2-4B06-8682-724555B51896@raszuk.net> Date: Mon, 30 Jul 2012 21:23:00 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:23:03 -0000 Rob, On Mon, Jul 30, 2012 at 9:11 PM, Robert Raszuk wrote: > What is not clear for me is ability from arbitrary entities to be able to= write to BGP or ISIS at sort of ad-hoc streaming. I do not see anything go= od can be seen as result of this. [Alia] Arbitrary AUTHORIZED entities - and we will probably need policy around what type of state and policy can be added so that basic routing assumptions aren't broken. > Exporting information is fine - no objection at all. [Alia] Kind of you - a feedback loop is important. > However for programming state into dynamic system the entity which writes= in should be the master and not the slave which unfortunately as of now it= looks like it is the latter. [Alia] Are you suggesting the application should be the master of the information? Or the router? The application could add information and own (based upon its authorization and role hierarchy) that data as far as not having it removed. I'm a bit puzzled by where you are obtaining this assumption from? > Perhaps you have in mind just adding bunch of ACLs on the edges, perhaps = just add static routes, perhaps insert network statements into BGP configur= ation. But till details are defined and till we understand how is this any = better from already standards based tools to do the same I think it is well= premature to judge any benefit from the IRS framework. [Alia] Do you mean because we haven't ironed out absolutely all of the details, requirements and data-models, there is no point in discussing what would be useful and working on doing so? [Alia] I've asked for your concerns, thoughts on the problem-statement, and possible use-cases. Instead of engaging, I feel like you've thrown up your hands and said "it's too uncertain" when we are clearly in the early stages of defining those things. Alia > Best Rgs, > R. > > > > Sent from my iPad > > On Jul 30, 2012, at 5:55 PM, Alia Atlas wrote: > >> Rob, >> >> We've been trying. I've written semi-copious words so far. >> I'd be happy to discuss with you in person as well and get your >> thoughts on reasonable use-cases. >> >> Describing an elephant for the first time is always tricky. >> >> Perhaps you could describe your perspective on the problem and what >> you think is unclear. >> >> Regards, >> Alia >> >> >> On Mon, Jul 30, 2012 at 7:31 PM, Robert Raszuk wrote= : >>> Tom, >>> >>> Yes indeed .. Clearly defining what problem are you trying to solve wou= ld be greatly helpful. >>> >>> Best, >>> R. >>> >>> >>> Sent from my iPad >>> >>> On Jul 30, 2012, at 3:54 PM, Thomas Nadeau wr= ote: >>> >>>> >>>> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" wrote: >>>> >>>>> Alia, I do have to disagree with one aspect of your characterization = fo ForCES. While the initial design goal was forwarding behavior, the prot= ocol design is such that it is usable over a broad range of abstraction lev= els. >>>>> >>>>> Similarly, depending upon exactly what we need, netconf + Netmad/YANG= may be suitable / useable. >>>> >>>> We are not ruling out any existing solutions, either in whole or in = part (modified). The goal right now is to define the problem space and a fr= amework of components that can be used to solve that problem. >>>> >>>>> On the other hand, I think that working out the problems and entities= that need to be modeled first (which probably does need a dedicated workin= g group), and then worrying about which protocol meets the requirements whe= n we know what exactly we need. At that point, the protocol work can be do= ne wherever appropriate. >>>> >>>> Yes, that is precisely what the goals are right now. >>>> >>>> --Tom >>>> >>>> >>>>> >>>>> yours, >>>>> Jitl >>>>> >>>>> On 7/30/2012 6:27 PM, Alia Atlas wrote: >>>>>> Hi James, >>>>>> >>>>>> Thanks for your thoughts. Streaming (as I've heard) is not as good= a >>>>>> description of the desired interface attributes as described in Sec >>>>>> 1.1, the functional overview. >>>>>> >>>>>> IRS is NOT about having interfaces to the forwarding plane. That's >>>>>> what ForCES is focused on. This is about communication to a router >>>>>> to install/retrieve routing state into the routing system (FIB, IGPs= , >>>>>> BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from th= e >>>>>> router. >>>>>> >>>>>> Are you suggesting that ForCES should drastically expand its scope? >>>>>> >>>>>> Before we start debating what and whether to expand existing >>>>>> protocols, I think we need a common understanding of the problem we'= re >>>>>> trying to solve and the related framework. >>>>>> >>>>>> Alia >>>>>> >>>>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf 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 i= s 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 route= r state update. Forces has already established that splitting the control p= lane 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 le= ast, recast in the Forces framework. >>>>>>> >>>>>>> jak >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: irs-discuss-bounces@ietf.org >>>>>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >>>>>>>> Sent: Monday, July 30, 2012 11:18 AM >>>>>>>> To: 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 >>>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> irs-discuss mailing list >>>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> irs-discuss mailing list >>>>> 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 Return-Path: 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 DC47711E80DE for ; Mon, 30 Jul 2012 18:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=4.201, 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 hez-WyZwVKBw for ; Mon, 30 Jul 2012 18:18:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADFC11E80DB for ; Mon, 30 Jul 2012 18:18:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIM23359; Mon, 30 Jul 2012 21:18:25 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jul 2012 18:16:18 -0700 Received: from dfweml509-mbs.china.huawei.com ([169.254.12.123]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Mon, 30 Jul 2012 18:16:15 -0700 From: Susan Hares To: "Joel M. Halpern" , "irs-discuss@ietf.org" Thread-Topic: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt Thread-Index: AQHNbqDE0RghEMqjhk+pxE1DLzQQ1JdClGzA Date: Tue, 31 Jul 2012 01:16:14 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14623754A03@dfweml509-mbs.china.huawei.com> References: <20120730180849.1235.96769.idtracker@ietfa.amsl.com> <50170758.3030908@joelhalpern.com> In-Reply-To: <50170758.3030908@joelhalpern.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:18:26 -0000 Joel and irs-folks:=20 +1 on Joel. Beyond your comments, the requirement prioritization of the interworking o= f these interfaces is not clearly delineated in this work. This type of pri= oritization and sequencing is key to multi-interfaces operation on the moni= toring, configuration or insertion of information into the depth. In addition, if you are going to do configuration with roll-forward/roll-ba= ck - you need a transaction based processing. =20 Therefore, you've skipped even requiring the hard problems.=20 Is this just the -00.draft?=20 Sue=20 -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Joel M. Halpern Sent: Monday, July 30, 2012 3:15 PM To: 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=20 information that can not be manipulated with existing systems, and then=20 proceeds to give a list of use cases all of which can be manipulated=20 with existing systems at a suitable degree of abstraction. As a lesser confusion, the document says that "streaming" is important,=20 but then describes "streaming" as "fast, interactive access." That is=20 not streaming. And depending upon what one means by interactive, plenty=20 of systems provide "fest, interactive access." I realize the document=20 later goes on tot talk about speed and frequency of state updates. But=20 that section simply reasserts the earlier terms withotu better=20 description or justification. Yours, Joel On 7/30/2012 2:08 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > > 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 https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 F0D4111E80D5 for ; Mon, 30 Jul 2012 18:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 mDCzWHYStzZl for ; Mon, 30 Jul 2012 18:11:21 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A4ECD11E80E4 for ; Mon, 30 Jul 2012 18:11:20 -0700 (PDT) Received: (qmail 16403 invoked by uid 399); 31 Jul 2012 01:11:19 -0000 Received: from unknown (HELO ?130.129.19.9?) (robert@raszuk.net@130.129.19.9) by mail1310.opentransfer.com with ESMTPAM; 31 Jul 2012 01:11:19 -0000 X-Originating-IP: 130.129.19.9 References: <50170D34.503@joelhalpern.com> <1FB014C5-8B5A-4D34-82AD-D8E64A0098FF@raszuk.net> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <82E1F44F-5EB2-4B06-8682-724555B51896@raszuk.net> X-Mailer: iPad Mail (9B206) From: Robert Raszuk Date: Mon, 30 Jul 2012 18:11:16 -0700 To: Alia Atlas Cc: Thomas Nadeau , James Kempf , "Joel M. Halpern" , "irs-discuss@ietf.org" , Thomas Nadeau Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:11:22 -0000 What is not clear for me is ability from arbitrary entities to be able to wr= ite to BGP or ISIS at sort of ad-hoc streaming. I do not see anything good c= an be seen as result of this.=20 Exporting information is fine - no objection at all. However for programming state into dynamic system the entity which writes in= should be the master and not the slave which unfortunately as of now it loo= ks like it is the latter. Perhaps you have in mind just adding bunch of ACLs on the edges, perhaps jus= t add static routes, perhaps insert network statements into BGP configuratio= n. But till details are defined and till we understand how is this any bette= r from already standards based tools to do the same I think it is well prema= ture to judge any benefit from the IRS framework. Best Rgs, R. Sent from my iPad On Jul 30, 2012, at 5:55 PM, Alia Atlas wrote: > Rob, >=20 > We've been trying. I've written semi-copious words so far. > I'd be happy to discuss with you in person as well and get your > thoughts on reasonable use-cases. >=20 > Describing an elephant for the first time is always tricky. >=20 > Perhaps you could describe your perspective on the problem and what > you think is unclear. >=20 > Regards, > Alia >=20 >=20 > On Mon, Jul 30, 2012 at 7:31 PM, Robert Raszuk wrote: >> Tom, >>=20 >> Yes indeed .. Clearly defining what problem are you trying to solve would= be greatly helpful. >>=20 >> Best, >> R. >>=20 >>=20 >> Sent from my iPad >>=20 >> On Jul 30, 2012, at 3:54 PM, Thomas Nadeau wrot= e: >>=20 >>>=20 >>> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" wrote: >>>=20 >>>> Alia, I do have to disagree with one aspect of your characterization fo= ForCES. While the initial design goal was forwarding behavior, the protoco= l design is such that it is usable over a broad range of abstraction levels.= >>>>=20 >>>> Similarly, depending upon exactly what we need, netconf + Netmad/YANG m= ay be suitable / useable. >>>=20 >>> We are not ruling out any existing solutions, either in whole or in pa= rt (modified). The goal right now is to define the problem space and a frame= work of components that can be used to solve that problem. >>>=20 >>>> On the other hand, I think that working out the problems and entities t= hat need to be modeled first (which probably does need a dedicated working g= roup), and then worrying about which protocol meets the requirements when we= know what exactly we need. At that point, the protocol work can be done wh= erever appropriate. >>>=20 >>> Yes, that is precisely what the goals are right now. >>>=20 >>> --Tom >>>=20 >>>=20 >>>>=20 >>>> yours, >>>> Jitl >>>>=20 >>>> On 7/30/2012 6:27 PM, Alia Atlas wrote: >>>>> Hi James, >>>>>=20 >>>>> Thanks for your thoughts. Streaming (as I've heard) is not as good a= >>>>> description of the desired interface attributes as described in Sec >>>>> 1.1, the functional overview. >>>>>=20 >>>>> IRS is NOT about having interfaces to the forwarding plane. That's >>>>> what ForCES is focused on. This is about communication to a router >>>>> to install/retrieve routing state into the routing system (FIB, IGPs, >>>>> BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from the >>>>> router. >>>>>=20 >>>>> Are you suggesting that ForCES should drastically expand its scope? >>>>>=20 >>>>> Before we start debating what and whether to expand existing >>>>> protocols, I think we need a common understanding of the problem we're= >>>>> trying to solve and the related framework. >>>>>=20 >>>>> Alia >>>>>=20 >>>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf wrote: >>>>>> I don't understand why streaming is specified in this draft. And I do= n'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. >>>>>>=20 >>>>>> I don't think it is necessary to have a problem statement for router s= tate 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, r= ecast in the Forces framework. >>>>>>=20 >>>>>> jak >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: irs-discuss-bounces@ietf.org >>>>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >>>>>>> Sent: Monday, July 30, 2012 11:18 AM >>>>>>> To: irs-discuss@ietf.org >>>>>>> Subject: [irs-discuss] IRS Problem Statement Posted >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Please review and discuss. >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> Tom, Alia, Ward >>>>>>>=20 >>>>>>>=20 >>>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> irs-discuss mailing list >>>>>>> irs-discuss@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> irs-discuss mailing list >>>>>> 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 >>>>>=20 >>>> _______________________________________________ >>>> irs-discuss mailing list >>>> irs-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>>=20 >>>=20 >>> _______________________________________________ >>> irs-discuss mailing list >>> irs-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 EEEED21F8615 for ; Mon, 30 Jul 2012 17:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gT2ygwL6sI37 for ; Mon, 30 Jul 2012 17:55:32 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0155B21F8600 for ; Mon, 30 Jul 2012 17:55:31 -0700 (PDT) Received: by yhq56 with SMTP id 56so5950365yhq.31 for ; Mon, 30 Jul 2012 17:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ErzL5dAt+ZmhkDgp2mGhmOXjdlsYzRQDtl8VEjXmlZI=; b=PRqPBPpO27YvwVArosMXau6+dZUmqsB3Htn1KNYwyTAinu+d1bK9/x1afZ3yVLUMIX DRbWBmuxqAqFRHlP5tPZ69XusS0i4UUCNN4Q6KpBHOZOHBhzLNNKqUQAnVtlQmBj5DNM uJ0Sa0blcid+LGotqIo37aIw7lZujAtD739/3P9Md2mmCwEJXirrlf5NaF6pKyrD3t+F MnkCjSgAlf5JEqWy3tBZFBj6Kj0vSiGY8bVY34vPRasXpDnEWN4ndb1LI/Kv/gH4OmnU 9nkDk9TWHqV2+OcUFms6xdShINiHBCZg0mt9ubiSGI0ZJmgFrXegrAomuOwsZsHpRkSX XBOA== MIME-Version: 1.0 Received: by 10.50.216.202 with SMTP id os10mr447025igc.17.1343696130739; Mon, 30 Jul 2012 17:55:30 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 17:55:30 -0700 (PDT) In-Reply-To: <1FB014C5-8B5A-4D34-82AD-D8E64A0098FF@raszuk.net> References: <50170D34.503@joelhalpern.com> <1FB014C5-8B5A-4D34-82AD-D8E64A0098FF@raszuk.net> Date: Mon, 30 Jul 2012 20:55:30 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Nadeau , James Kempf , "Joel M. Halpern" , "irs-discuss@ietf.org" , Thomas Nadeau Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:55:33 -0000 Rob, We've been trying. I've written semi-copious words so far. I'd be happy to discuss with you in person as well and get your thoughts on reasonable use-cases. Describing an elephant for the first time is always tricky. Perhaps you could describe your perspective on the problem and what you think is unclear. Regards, Alia On Mon, Jul 30, 2012 at 7:31 PM, Robert Raszuk wrote: > Tom, > > Yes indeed .. Clearly defining what problem are you trying to solve would= be greatly helpful. > > Best, > R. > > > Sent from my iPad > > On Jul 30, 2012, at 3:54 PM, Thomas Nadeau wrot= e: > >> >> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" wrote: >> >>> Alia, I do have to disagree with one aspect of your characterization fo= ForCES. While the initial design goal was forwarding behavior, the protoc= ol design is such that it is usable over a broad range of abstraction level= s. >>> >>> Similarly, depending upon exactly what we need, netconf + Netmad/YANG m= ay be suitable / useable. >> >> We are not ruling out any existing solutions, either in whole or in p= art (modified). The goal right now is to define the problem space and a fra= mework of components that can be used to solve that problem. >> >>> On the other hand, I think that working out the problems and entities t= hat need to be modeled first (which probably does need a dedicated working = group), and then worrying about which protocol meets the requirements when = we know what exactly we need. At that point, the protocol work can be done= wherever appropriate. >> >> Yes, that is precisely what the goals are right now. >> >> --Tom >> >> >>> >>> yours, >>> Jitl >>> >>> On 7/30/2012 6:27 PM, Alia Atlas wrote: >>>> Hi James, >>>> >>>> Thanks for your thoughts. Streaming (as I've heard) is not as good a >>>> description of the desired interface attributes as described in Sec >>>> 1.1, the functional overview. >>>> >>>> IRS is NOT about having interfaces to the forwarding plane. That's >>>> what ForCES is focused on. This is about communication to a router >>>> to install/retrieve routing state into the routing system (FIB, IGPs, >>>> BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from the >>>> router. >>>> >>>> Are you suggesting that ForCES should drastically expand its scope? >>>> >>>> Before we start debating what and whether to expand existing >>>> protocols, I think we need a common understanding of the problem we're >>>> trying to solve and the related framework. >>>> >>>> Alia >>>> >>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf wrote: >>>>> I don't understand why streaming is specified in this draft. And I do= n't understand why this draft isn't put in the Forces framework. Forces is = a framework explicitedly designed for device to controller communication. I= ts major drawback it that it is a framework with a hole in the middle, in t= hat 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 pla= ne into a separate device is, in some cases, an attractive design option. S= o I think this should be submitted to the Forces working group, or, at leas= t, recast in the Forces framework. >>>>> >>>>> jak >>>>> >>>>>> -----Original Message----- >>>>>> From: irs-discuss-bounces@ietf.org >>>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >>>>>> Sent: Monday, July 30, 2012 11:18 AM >>>>>> To: 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 >>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>>>> >>>>> _______________________________________________ >>>>> irs-discuss mailing list >>>>> 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 >>>> >>> _______________________________________________ >>> irs-discuss mailing list >>> 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 Return-Path: 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 1CB0C21F85BB for ; Mon, 30 Jul 2012 17:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 FYI1KIHrxbkr for ; Mon, 30 Jul 2012 17:53:23 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C143921F858E for ; Mon, 30 Jul 2012 17:53:21 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5913024ghb.31 for ; Mon, 30 Jul 2012 17:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wDDyZYlcEJ6N7m7J/giNB7kkxd2PbXVshcJHbgaOeKQ=; b=CV473qcGb+IRhradYMwmxmKLBKv2T3jhYW3Z+N4kPawSpHqVcqaCYj752ZapPkNtWB Jrojk9H0bUhV4lZVxRQDJ4uihk0RMv0DRRZYPVArZEC/0lRUXf2XA/XNsnztobU/Zxl+ 7FGv87T9dQeGKrH7tdBAEw/GWF4HLBxn92coR2dJSGAz/SY4is8RGro9T42mloo6a+55 qySoWESFgQX7lAwC95XDjkz0SRCFOIn4PJ0CdsQEy4QWAlF7JOrTM5W95H2UEluOXlHD hkscWTTxzw6N2xpF9EkOgZ7AUkRF+WkPFseobsOw7RVjSslhQXRlpH/UZyJIG6SI9ZZs wciQ== MIME-Version: 1.0 Received: by 10.50.216.202 with SMTP id os10mr443235igc.17.1343696001112; Mon, 30 Jul 2012 17:53:21 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 17:53:21 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Jul 2012 20:53:21 -0400 Message-ID: From: Alia Atlas To: James Kempf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Nadeau , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:53:27 -0000 Hi James, The routing system components are certainly part of a router's control plane - but not all of it. The idea of IRS involves sub-interfaces to the different layers in the routing system. Can you clarify what you are asking as it relates to ForCES and IRS? I don't feel that we're on the same page yet. Alia On Mon, Jul 30, 2012 at 6:48 PM, James Kempf wro= te: > Hi Alia, > > Perhaps you can explain to me the difference between the state involved i= n "the routing system (FIB, IGPs, BGP, RSVP-TE, etc.)" and the control plan= e? The last time I looked, these protocols were all involved in routing con= trol and therefore could reasonably be characterized as components of the c= ontrol plane, IMHO. > > jak > >> -----Original Message----- >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Monday, July 30, 2012 3:27 PM >> To: James Kempf >> Cc: Thomas Nadeau; irs-discuss@ietf.org >> Subject: Re: [irs-discuss] IRS Problem Statement Posted >> >> Hi James, >> >> Thanks for your thoughts. Streaming (as I've heard) is not as good a >> description of the desired interface attributes as described >> in Sec 1.1, the functional overview. >> >> IRS is NOT about having interfaces to the forwarding plane. That's >> what ForCES is focused on. This is about communication to a router >> to install/retrieve routing state into the routing system (FIB, IGPs, >> BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from the >> router. >> >> Are you suggesting that ForCES should drastically expand its scope? >> >> Before we start debating what and whether to expand existing >> protocols, I think we need a common understanding of the >> problem we're trying to solve and the related framework. >> >> Alia >> >> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf >> 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] On Behalf Of Thomas Nadeau >> >> Sent: Monday, July 30, 2012 11:18 AM >> >> To: 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 >> >> https://www.ietf.org/mailman/listinfo/irs-discuss >> >> >> > _______________________________________________ >> > irs-discuss mailing list >> > irs-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/irs-discuss >> Return-Path: 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 17A2121F8539 for ; Mon, 30 Jul 2012 17:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 HXbTNQJqftBN for ; Mon, 30 Jul 2012 17:53:03 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id EE1C721F8530 for ; Mon, 30 Jul 2012 17:53:01 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUBcsbVVGogjZrFSwkmr9HqMAh9KsiTks@postini.com; Mon, 30 Jul 2012 17:53:01 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jul 2012 17:50:43 -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; Mon, 30 Jul 2012 20:50:42 -0400 From: Thomas Nadeau To: Lenny Giuliano , Alia Atlas Date: Mon, 30 Jul 2012 20:50:40 -0400 Thread-Topic: IRS comments Thread-Index: Ac1utoJXMLn1Fv5cTmO9ZkEBmEbA7g== Message-ID: In-Reply-To: <20120730164422.U88614@eng-mail01.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 Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS comments X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:53:04 -0000 [Re-adding IRS] Thank you for reviewing and the comments. We will incorporate the edits in the next rev. --Tom On 7/30/12 5:04 PM, "Lenny Giuliano" wrote: > >Minor points: > >-section 4, para 2, 3rd sentence, "Howeve,r" > >-4.1.3 "There is no bidirectional programmatic interface to add, modify, > remove or read state from the multicast RIB." > -How is this unique to mcast? Couldn't you say the same thing > about unicast? > >-4.1.3 "The multicast state added need not match to well-known protocol > installed state. For instance, traffic received on an specified set, > or all, interfaces that is destined to a particular prefix from all > sources or a particular prefix could be subject to the specified > replication." > -Not clear to me at all what this para is saying. > >-"IRS"- you may want to select a different acronym that isn't related to >something as unpopular as taxation (something we learned with AMT). >Maybe=20 >RSI instead... > >Overall, I found the doc to be clearly written and straightforward. >Sounds like Openflow for routers. Not sure if it's intentional that you >didn't mention Openflow, but it did seem like an elephant in the room as >I=20 >was reading thru. Also, I did wonder what was new and novel here, as >this=20 >sounded like our SDK which has been around for years. > > >-Lenny Return-Path: 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 693B011E80BA for ; Mon, 30 Jul 2012 17:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 k9XDZi2Q2rng for ; Mon, 30 Jul 2012 17:48:21 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB8111E80BF for ; Mon, 30 Jul 2012 17:48:15 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUBcrTWGx7vCtXYPOo9I5ipPdUXsTV+PF@postini.com; Mon, 30 Jul 2012 17:48:21 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jul 2012 17:48:13 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 30 Jul 2012 20:48:12 -0400 From: Thomas Nadeau To: "Manuel.Paul@telekom.de" , "irs-discuss@ietf.org" Date: Mon, 30 Jul 2012 20:48:06 -0400 Thread-Topic: IRS Problem Statement Posted Thread-Index: Ac1utij8zW11RAG2R+WHrJNSw+vmcA== Message-ID: In-Reply-To: <9435EDACD941174099E143BCA2BCD615FAC450C3D3@HE101452.emea1.cds.t-internal.com> 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 Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:48:22 -0000 The problem statement/framework are pretty clear that the intent is to talk directly to the routing system. What happens below that is not part of the problem we are trying to solve at the moment. --Tom On 7/30/12 4:31 PM, "Manuel.Paul@telekom.de" wrote: >Hi, > >How much of this is intended (or not) to actually represent a use case >for Software-Defined Networking, i.e. become part of the application >space for a North-Bound Interface? > > >Thanks, >Manuel > > >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] >> On Behalf Of Thomas Nadeau >> Sent: Monday, July 30, 2012 11:18 AM >> To: 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 >> https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 08B6011E80DE for ; Mon, 30 Jul 2012 17:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 FigcKuWzS6qF for ; Mon, 30 Jul 2012 17:48:15 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1215811E80BA for ; Mon, 30 Jul 2012 17:48:14 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5909760ghb.31 for ; Mon, 30 Jul 2012 17:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=17JPAEchThe0i+i3Sn4BIjdJp4tZjOawkR9WJvXeelo=; b=ALdbYxa3O1VRq2l+W8/CUq2zaoYQyvBCp+zpi1/Wgax5o/Oe4UgrEjOYEJtFnUYwOa uCcgFjsRTuMcYIAkB08WLIBK/Dp7xyjJY8Gx+T1ZV4WdjKthUAtw3W2AALE6gpSkMbrt aDUn7SozOe8dd62nkyjIywr+VoPtjQxerfpUib6Fi4fROhDgDSvb44HzlwZTrBB3OhAG /NXjAfscHDS4dBygGpX2oQ3IqrNe8l8gvMnriNi8R2UeJaN5lIIb7UFtANf7rlvfhkjT SuO4Z5W0m5E1qm7Iaj1R6u121ax3CPCyyE7VAzb/zk7Kf04vcJOig+RqqFYrYaaOz81q CWgg== MIME-Version: 1.0 Received: by 10.50.0.137 with SMTP id 9mr446591ige.18.1343695693581; Mon, 30 Jul 2012 17:48:13 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 17:48:13 -0700 (PDT) In-Reply-To: <50170D34.503@joelhalpern.com> References: <50170D34.503@joelhalpern.com> Date: Mon, 30 Jul 2012 20:48:13 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Nadeau , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:48:16 -0000 Joel, As we define the requirements and use-cases, it's possible that NetConf or ForCES or other options may appear as good options. We might even want the ability to use different ones as the transfer protocol; I'm not yet convinced. The other strong requirement is around security, authorization, authentication, roles, etc. I think that will play a role in helping define what protocols may be suitable to use or extend. Alia On Mon, Jul 30, 2012 at 6:39 PM, Joel M. Halpern wrote: > Alia, I do have to disagree with one aspect of your characterization fo > ForCES. While the initial design goal was forwarding behavior, the protocol > design is such that it is usable over a broad range of abstraction levels. > > Similarly, depending upon exactly what we need, netconf + Netmad/YANG may be > suitable / useable. > > On the other hand, I think that working out the problems and entities that > need to be modeled first (which probably does need a dedicated working > group), and then worrying about which protocol meets the requirements when > we know what exactly we need. At that point, the protocol work can be done > wherever appropriate. > > yours, > Jitl > > > On 7/30/2012 6:27 PM, Alia Atlas wrote: >> >> Hi James, >> >> Thanks for your thoughts. Streaming (as I've heard) is not as good a >> description of the desired interface attributes as described in Sec >> 1.1, the functional overview. >> >> IRS is NOT about having interfaces to the forwarding plane. That's >> what ForCES is focused on. This is about communication to a router >> to install/retrieve routing state into the routing system (FIB, IGPs, >> BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from the >> router. >> >> Are you suggesting that ForCES should drastically expand its scope? >> >> Before we start debating what and whether to expand existing >> protocols, I think we need a common understanding of the problem we're >> trying to solve and the related framework. >> >> Alia >> >> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf >> 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] On Behalf Of Thomas Nadeau >>>> Sent: Monday, July 30, 2012 11:18 AM >>>> To: 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 >>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>> >>> _______________________________________________ >>> irs-discuss mailing list >>> 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 >> > Return-Path: 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 23D9311E80BA for ; Mon, 30 Jul 2012 17:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 XPq5qCYJ80dq for ; Mon, 30 Jul 2012 17:43:13 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F19E11E80A2 for ; Mon, 30 Jul 2012 17:43:13 -0700 (PDT) Received: by yhq56 with SMTP id 56so5943089yhq.31 for ; Mon, 30 Jul 2012 17:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K5YddXqtVyJs/Bne77RqUZ6z+32/xl3+IowmZJORZGA=; b=l8LxZ66lTMjR0X68e/l+EZ5EW7DMwgx/Bqt3yWV1if6Je0+qcP+rkG133N6ld4/bGb CYFWhcVGbJB5v4SUMgYVlC7C7T60aRI2IcCt/8pN/gFOHZ7h6kHkwUrhE0vMx+URohIi pSpgvP554zx5xsQn1+9zzvwqKpvw3axvq/HrYN62k4mvqBQBeX8aEyB8/R39fD2fPaHL km9Kbto2Q6j8sxc/t5U32/4TCPUy/k3OIc0KILU3AnoxG7q+pPVgJ16e5HrmPDq2kd/I zqgAJ3p4tnBZdumW3bmfhr67CniunmtRs/Rugcgo2yjQ/9i4OWLegsdCBz+rz0TefsoT hYRw== MIME-Version: 1.0 Received: by 10.50.237.72 with SMTP id va8mr501340igc.17.1343695392306; Mon, 30 Jul 2012 17:43:12 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 17:43:12 -0700 (PDT) In-Reply-To: References: <89A782BC-4907-4EC7-BFB4-CC0F5545EE03@lucidvision.com> Date: Mon, 30 Jul 2012 20:43:12 -0400 Message-ID: From: Alia Atlas To: Vytautas Valancius Content-Type: text/plain; charset=ISO-8859-1 Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] irs problem statement X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:43:14 -0000 Thanks for the pointers - I saw them on the agenda for NetConf as well. As I said to Joel, we need to agree and focus on agreeing on the problem-statement and use-cases before trying to pin down particular protocol(s). Hearing more feedback though about how well NetConf does or could meet the needs and suggested requirements is quite interesting. Alia On Mon, Jul 30, 2012 at 7:30 PM, Vytautas Valancius wrote: >> URL: http://www.ietf.org/internet-drafts/draft-atlas-irs-problem-statement-00.txt >> Status: http://datatracker.ietf.org/doc/draft-atlas-irs-problem-statement >> Htmlized: http://tools.ietf.org/html/draft-atlas-irs-problem-statement-00 > > Nitpick: > > "The transport mechanisms that are currently defined (e.g., SOAP/BEEP) > for NetConf are not those commonly used by modern applications (e.g., > ReST or JSON)." > > Technically correct, but, FYI, there is active work going on to make > NetConf and YANG REST and JSON friendly: > http://tools.ietf.org/html/draft-bierman-netconf-yang-api-00 > http://tools.ietf.org/html/draft-lhotka-yang-json-00 > > Regards, > Valas > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 412BB11E80BA for ; Mon, 30 Jul 2012 16:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 vLQZJ54Dbfiu for ; Mon, 30 Jul 2012 16:31:49 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 747BC11E809A for ; Mon, 30 Jul 2012 16:31:48 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 31 Jul 2012 01:31:47 +0200 Received: from HE101452.emea1.cds.t-internal.com ([10.125.92.148]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Tue, 31 Jul 2012 01:31:47 +0200 From: To: , Date: Tue, 31 Jul 2012 01:31:44 +0200 Thread-Topic: IRS Problem Statement Posted Thread-Index: Ac1uf6vUr0RoAYPERve+GHr5XPQ6JgAK504g Message-ID: <9435EDACD941174099E143BCA2BCD615FAC450C3D3@HE101452.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:31:50 -0000 SGksDQoNCkhvdyBtdWNoIG9mIHRoaXMgaXMgaW50ZW5kZWQgKG9yIG5vdCkgdG8gYWN0dWFsbHkg cmVwcmVzZW50IGEgdXNlIGNhc2UgZm9yIFNvZnR3YXJlLURlZmluZWQgTmV0d29ya2luZywgaS5l LiBiZWNvbWUgcGFydCBvZiB0aGUgYXBwbGljYXRpb24gc3BhY2UgZm9yIGEgTm9ydGgtQm91bmQg SW50ZXJmYWNlPw0KDQoNClRoYW5rcywNCk1hbnVlbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogaXJzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmly cy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddDQo+IE9uIEJlaGFsZiBPZiBUaG9tYXMgTmFkZWF1 DQo+IFNlbnQ6IE1vbmRheSwgSnVseSAzMCwgMjAxMiAxMToxOCBBTQ0KPiBUbzogaXJzLWRpc2N1 c3NAaWV0Zi5vcmcNCj4gU3ViamVjdDogW2lycy1kaXNjdXNzXSBJUlMgUHJvYmxlbSBTdGF0ZW1l bnQgUG9zdGVkDQo+DQo+DQo+DQo+IFBsZWFzZSByZXZpZXcgYW5kIGRpc2N1c3MuDQo+DQo+IFRo YW5rcywNCj4NCj4gVG9tLCBBbGlhLCBXYXJkDQo+DQo+DQo+IGh0dHA6Ly9sdWNpZHZpc2lvbi5j b20vZHJhZnQtYXRsYXMtaXJzLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4dA0KPg0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBpcnMtZGlzY3Vz cyBtYWlsaW5nIGxpc3QNCj4gaXJzLWRpc2N1c3NAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcnMtZGlzY3Vzcw0K Return-Path: 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 23A4911E80BA for ; Mon, 30 Jul 2012 16:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 8vjzKEkYkd2s for ; Mon, 30 Jul 2012 16:31:30 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 1454911E809A for ; Mon, 30 Jul 2012 16:31:29 -0700 (PDT) Received: (qmail 522 invoked by uid 399); 30 Jul 2012 23:31:29 -0000 Received: from unknown (HELO ?130.129.19.9?) (robert@raszuk.net@130.129.19.9) by mail1310.opentransfer.com with ESMTPAM; 30 Jul 2012 23:31:29 -0000 X-Originating-IP: 130.129.19.9 References: <50170D34.503@joelhalpern.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <1FB014C5-8B5A-4D34-82AD-D8E64A0098FF@raszuk.net> X-Mailer: iPad Mail (9B206) From: Robert Raszuk Date: Mon, 30 Jul 2012 16:31:28 -0700 To: Thomas Nadeau Cc: Alia Atlas , Thomas Nadeau , James Kempf , "Joel M. Halpern" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:31:31 -0000 Tom, Yes indeed .. Clearly defining what problem are you trying to solve would be= greatly helpful. Best, R. Sent from my iPad On Jul 30, 2012, at 3:54 PM, Thomas Nadeau wrote: >=20 > On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" wrote: >=20 >> Alia, I do have to disagree with one aspect of your characterization fo Fo= rCES. While the initial design goal was forwarding behavior, the protocol d= esign is such that it is usable over a broad range of abstraction levels. >>=20 >> Similarly, depending upon exactly what we need, netconf + Netmad/YANG may= be suitable / useable. >=20 > We are not ruling out any existing solutions, either in whole or in par= t (modified). The goal right now is to define the problem space and a framew= ork of components that can be used to solve that problem. >=20 >> On the other hand, I think that working out the problems and entities tha= t need to be modeled first (which probably does need a dedicated working gro= up), and then worrying about which protocol meets the requirements when we k= now what exactly we need. At that point, the protocol work can be done wher= ever appropriate. >=20 > Yes, that is precisely what the goals are right now. >=20 > --Tom >=20 >=20 >>=20 >> yours, >> Jitl >>=20 >> On 7/30/2012 6:27 PM, Alia Atlas wrote: >>> Hi James, >>>=20 >>> Thanks for your thoughts. Streaming (as I've heard) is not as good a >>> description of the desired interface attributes as described in Sec >>> 1.1, the functional overview. >>>=20 >>> IRS is NOT about having interfaces to the forwarding plane. That's >>> what ForCES is focused on. This is about communication to a router >>> to install/retrieve routing state into the routing system (FIB, IGPs, >>> BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from the >>> router. >>>=20 >>> Are you suggesting that ForCES should drastically expand its scope? >>>=20 >>> Before we start debating what and whether to expand existing >>> protocols, I think we need a common understanding of the problem we're >>> trying to solve and the related framework. >>>=20 >>> Alia >>>=20 >>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf w= rote: >>>> 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 f= ramework explicitedly designed for device to controller communication. Its m= ajor drawback it that it is a framework with a hole in the middle, in that t= here are no specified devices. This draft would fill that hole. >>>>=20 >>>> I don't think it is necessary to have a problem statement for router st= ate update. Forces has already established that splitting the control plane i= nto a separate device is, in some cases, an attractive design option. So I t= hink this should be submitted to the Forces working group, or, at least, rec= ast in the Forces framework. >>>>=20 >>>> jak >>>>=20 >>>>> -----Original Message----- >>>>> From: irs-discuss-bounces@ietf.org >>>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >>>>> Sent: Monday, July 30, 2012 11:18 AM >>>>> To: irs-discuss@ietf.org >>>>> Subject: [irs-discuss] IRS Problem Statement Posted >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Please review and discuss. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Tom, Alia, Ward >>>>>=20 >>>>>=20 >>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> irs-discuss mailing list >>>>> irs-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>>>=20 >>>> _______________________________________________ >>>> irs-discuss mailing list >>>> 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 >>>=20 >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss >>=20 >=20 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 A163B11E8109 for ; Mon, 30 Jul 2012 16:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 dSzzrsu6IoUn for ; Mon, 30 Jul 2012 16:30:54 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0171411E80BA for ; Mon, 30 Jul 2012 16:30:53 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so10544545pbc.31 for ; Mon, 30 Jul 2012 16:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record; bh=ybhHIlDmxKUAdxWvxFuTRlOOAnk1bIohtcOM97ZETg8=; b=CPgemaMQd1knK17wYXXp+lbbZP/mcfA8ppWLemRe8ZRKglhRCWfXNL4U3mhpsMC/z2 bbi7zfCBm7Z6mAP+oQRUPJ5APmHoZsup/O7YjzBJgt8jfREZTi1ExppUNfXRVTctXhFw Sn3WrNOhm2OOSb/BZBK4DIasEh8cHZVSeyAsgc4RPNxinwfhmJBMKNCKVCotTtxOn3M5 slSwYvpP4QG/lidSQn7ny8rGOoxGtWQjPcKDBXBsv9F+vrw0rUlr2ctalpUi14RoaSwq nO9HRmC5aaGh3RtIJwVTSrIRJ9iYgEyqegsXkkSQ/7ynZs/bmqukJIoZz3nvop6LTzA+ sXkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record:x-gm-message-state; bh=ybhHIlDmxKUAdxWvxFuTRlOOAnk1bIohtcOM97ZETg8=; b=d2ziFnVxrC5LHtK96sJ3S/wddOrKqRl9QyOCnbm08bQ9TtJqa4xM5novUPvRmmGo5r Uuy3oAeiDUHQ6suNa0EOxeFYAvgHf+Ar0xuUl4uSd67/NJFmiPJ0FRA57eRxa6dT+5sV lOzqvfSy74XCHIfTDCStc4osZE7LgSCymHTUmw38ijdIwRSAxmJlFCFqlXFOBSmk08Eb zk3Ela2+6kJbXhtMQU9OvFBO1l7Lonpue0ri2ks9yiKHScnsUX/9v2pYsEOebnytjcPf I26ICb3PabJVezJJ7tt3hhRXKI6/UbdYBLRQdPb35EEYbpAch/VKoP/hgqs3w1FQm9PS GrDw== Received: by 10.68.221.38 with SMTP id qb6mr38514959pbc.144.1343691053734; Mon, 30 Jul 2012 16:30:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.221.38 with SMTP id qb6mr38514933pbc.144.1343691053483; Mon, 30 Jul 2012 16:30:53 -0700 (PDT) Received: by 10.68.189.33 with HTTP; Mon, 30 Jul 2012 16:30:53 -0700 (PDT) In-Reply-To: <89A782BC-4907-4EC7-BFB4-CC0F5545EE03@lucidvision.com> References: <89A782BC-4907-4EC7-BFB4-CC0F5545EE03@lucidvision.com> Date: Mon, 30 Jul 2012 16:30:53 -0700 Message-ID: From: Vytautas Valancius To: "irs-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl86tYBNQb6mjPXdsiDQ6prb4Q0a1srP8LHKIEiCFy1v3XVr+1LbV1W/LUfJuRSczGcDLjVsLHCW2C70Mb3AaOYD/s40dFVl0KuUpoR4WB9LNwhGxZ0R/O+2ad8FfEojXZ9gtrpn4VfMOBhRCdMEvatvBF2e87ctC+lugrl931tF8vnZREzVBkBojehRLEknFvCUv+K Subject: Re: [irs-discuss] irs problem statement X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:30:54 -0000 > URL: http://www.ietf.org/internet-drafts/draft-atlas-irs-problem-statement-00.txt > Status: http://datatracker.ietf.org/doc/draft-atlas-irs-problem-statement > Htmlized: http://tools.ietf.org/html/draft-atlas-irs-problem-statement-00 Nitpick: "The transport mechanisms that are currently defined (e.g., SOAP/BEEP) for NetConf are not those commonly used by modern applications (e.g., ReST or JSON)." Technically correct, but, FYI, there is active work going on to make NetConf and YANG REST and JSON friendly: http://tools.ietf.org/html/draft-bierman-netconf-yang-api-00 http://tools.ietf.org/html/draft-lhotka-yang-json-00 Regards, Valas Return-Path: 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 4390C11E809A for ; Mon, 30 Jul 2012 15:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 j3BoQ7LD2g0p for ; Mon, 30 Jul 2012 15:54:05 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1F68F21F860D for ; Mon, 30 Jul 2012 15:54:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 9D3592203AF6; Mon, 30 Jul 2012 18:54:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeEQz76OgDRi; Mon, 30 Jul 2012 18:54:04 -0400 (EDT) Received: from tnadeau-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id A80E82203AF3; Mon, 30 Jul 2012 18:54:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Thomas Nadeau In-Reply-To: <50170D34.503@joelhalpern.com> Date: Mon, 30 Jul 2012 15:54:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50170D34.503@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1485) Cc: Thomas Nadeau , James Kempf , "irs-discuss@ietf.org" , Alia Atlas Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:54:06 -0000 On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" = wrote: > Alia, I do have to disagree with one aspect of your characterization = fo ForCES. While the initial design goal was forwarding behavior, the = protocol design is such that it is usable over a broad range of = abstraction levels. >=20 > Similarly, depending upon exactly what we need, netconf + Netmad/YANG = may be suitable / useable. We are not ruling out any existing solutions, either in whole or = in part (modified). The goal right now is to define the problem space = and a framework of components that can be used to solve that problem. > On the other hand, I think that working out the problems and entities = that need to be modeled first (which probably does need a dedicated = working group), and then worrying about which protocol meets the = requirements when we know what exactly we need. At that point, the = protocol work can be done wherever appropriate. Yes, that is precisely what the goals are right now. --Tom >=20 > yours, > Jitl >=20 > On 7/30/2012 6:27 PM, Alia Atlas wrote: >> Hi James, >>=20 >> Thanks for your thoughts. Streaming (as I've heard) is not as good = a >> description of the desired interface attributes as described in Sec >> 1.1, the functional overview. >>=20 >> IRS is NOT about having interfaces to the forwarding plane. That's >> what ForCES is focused on. This is about communication to a router >> to install/retrieve routing state into the routing system (FIB, IGPs, >> BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from the >> router. >>=20 >> Are you suggesting that ForCES should drastically expand its scope? >>=20 >> Before we start debating what and whether to expand existing >> protocols, I think we need a common understanding of the problem = we're >> trying to solve and the related framework. >>=20 >> Alia >>=20 >> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf = 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. >>>=20 >>> 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. >>>=20 >>> jak >>>=20 >>>> -----Original Message----- >>>> From: irs-discuss-bounces@ietf.org >>>> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >>>> Sent: Monday, July 30, 2012 11:18 AM >>>> To: irs-discuss@ietf.org >>>> Subject: [irs-discuss] IRS Problem Statement Posted >>>>=20 >>>>=20 >>>>=20 >>>> Please review and discuss. >>>>=20 >>>> Thanks, >>>>=20 >>>> Tom, Alia, Ward >>>>=20 >>>>=20 >>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> irs-discuss mailing list >>>> irs-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/irs-discuss >>>>=20 >>> _______________________________________________ >>> irs-discuss mailing list >>> 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 >>=20 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 Return-Path: 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 AFB6C21F85F9 for ; Mon, 30 Jul 2012 15:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=0.536, 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 kwgks7jKtxgd for ; Mon, 30 Jul 2012 15:48:48 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id DFD6B21F85D8 for ; Mon, 30 Jul 2012 15:48:47 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6UMmeTT025828; Mon, 30 Jul 2012 17:48:47 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 30 Jul 2012 18:48:41 -0400 From: James Kempf To: Alia Atlas Date: Mon, 30 Jul 2012 18:48:39 -0400 Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1uon0lOLisX2QeT7OIn7le4MDYSgAAsIww Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Nadeau , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:48:48 -0000 Hi Alia, Perhaps you can explain to me the difference between the state involved in = "the routing system (FIB, IGPs, BGP, RSVP-TE, etc.)" and the control plane?= The last time I looked, these protocols were all involved in routing contr= ol and therefore could reasonably be characterized as components of the con= trol plane, IMHO. jak=20 > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com]=20 > Sent: Monday, July 30, 2012 3:27 PM > To: James Kempf > Cc: Thomas Nadeau; irs-discuss@ietf.org > Subject: Re: [irs-discuss] IRS Problem Statement Posted >=20 > Hi James, >=20 > Thanks for your thoughts. Streaming (as I've heard) is not as good a > description of the desired interface attributes as described=20 > in Sec 1.1, the functional overview. >=20 > IRS is NOT about having interfaces to the forwarding plane. That's > what ForCES is focused on. This is about communication to a router > to install/retrieve routing state into the routing system (FIB, IGPs, > BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from the > router. >=20 > Are you suggesting that ForCES should drastically expand its scope? >=20 > Before we start debating what and whether to expand existing=20 > protocols, I think we need a common understanding of the=20 > problem we're trying to solve and the related framework. >=20 > Alia >=20 > On Mon, Jul 30, 2012 at 6:11 PM, James Kempf=20 > wrote: > > I don't understand why streaming is specified in this=20 > draft. And I don't understand why this draft isn't put in the=20 > Forces framework. Forces is a framework explicitedly designed=20 > for device to controller communication. Its major drawback it=20 > that it is a framework with a hole in the middle, in that=20 > there are no specified devices. This draft would fill that hole. > > > > I don't think it is necessary to have a problem statement=20 > for router state update. Forces has already established that=20 > splitting the control plane into a separate device is, in=20 > some cases, an attractive design option. So I think this=20 > should be submitted to the Forces working group, or, at=20 > least, recast in the Forces framework. > > > > jak > > > >> -----Original Message----- > >> From: irs-discuss-bounces@ietf.org > >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau > >> Sent: Monday, July 30, 2012 11:18 AM > >> To: 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 > >> https://www.ietf.org/mailman/listinfo/irs-discuss > >> > > _______________________________________________ > > irs-discuss mailing list > > irs-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/irs-discuss > = Return-Path: 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 6D5DB11E8097 for ; Mon, 30 Jul 2012 15:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 R6ZY921uwxfG for ; Mon, 30 Jul 2012 15:39:50 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id CA83521F8517 for ; Mon, 30 Jul 2012 15:39:50 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id B0DD4557F08 for ; Mon, 30 Jul 2012 15:39:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5EE221BDA3F0; Mon, 30 Jul 2012 15:39:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [130.129.32.82] (dhcp-2052.meeting.ietf.org [130.129.32.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 0D5261BDA3EC; Mon, 30 Jul 2012 15:39:50 -0700 (PDT) Message-ID: <50170D34.503@joelhalpern.com> Date: Mon, 30 Jul 2012 18:39:48 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Alia Atlas References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Nadeau , James Kempf , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:39:51 -0000 Alia, I do have to disagree with one aspect of your characterization fo ForCES. While the initial design goal was forwarding behavior, the protocol design is such that it is usable over a broad range of abstraction levels. Similarly, depending upon exactly what we need, netconf + Netmad/YANG may be suitable / useable. On the other hand, I think that working out the problems and entities that need to be modeled first (which probably does need a dedicated working group), and then worrying about which protocol meets the requirements when we know what exactly we need. At that point, the protocol work can be done wherever appropriate. yours, Jitl On 7/30/2012 6:27 PM, Alia Atlas wrote: > Hi James, > > Thanks for your thoughts. Streaming (as I've heard) is not as good a > description of the desired interface attributes as described in Sec > 1.1, the functional overview. > > IRS is NOT about having interfaces to the forwarding plane. That's > what ForCES is focused on. This is about communication to a router > to install/retrieve routing state into the routing system (FIB, IGPs, > BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from the > router. > > Are you suggesting that ForCES should drastically expand its scope? > > Before we start debating what and whether to expand existing > protocols, I think we need a common understanding of the problem we're > trying to solve and the related framework. > > Alia > > On Mon, Jul 30, 2012 at 6:11 PM, James Kempf 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] On Behalf Of Thomas Nadeau >>> Sent: Monday, July 30, 2012 11:18 AM >>> To: 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 >>> https://www.ietf.org/mailman/listinfo/irs-discuss >>> >> _______________________________________________ >> irs-discuss mailing list >> 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 > Return-Path: 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 C596311E80E5 for ; Mon, 30 Jul 2012 15:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 WmtS1PrffxT1 for ; Mon, 30 Jul 2012 15:33:57 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 449AD11E80DC for ; Mon, 30 Jul 2012 15:33:57 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 37F35558376 for ; Mon, 30 Jul 2012 15:33:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D1AF1200B70; Mon, 30 Jul 2012 15:33:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [130.129.32.82] (dhcp-2052.meeting.ietf.org [130.129.32.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 96135200B6A; Mon, 30 Jul 2012 15:33:56 -0700 (PDT) Message-ID: <50170BD3.3030801@joelhalpern.com> Date: Mon, 30 Jul 2012 18:33:55 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Alia Atlas References: <17897894-CD09-482F-9F1A-F01CF44DC906@lucidvision.com> <50156873.2030407@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] draft-ward-irs-framework X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:33:58 -0000 Sounds good. Thank you. Joel On 7/30/2012 6:19 PM, Alia Atlas wrote: > Joel, > > Thanks for the feedback. I think the problem-statement draft (now at > http://tools.ietf.org/html/draft-atlas-irs-problem-statement-00) > focuses a bit more on the problem and less on the protocol aspects. > > The framework does try to describe the need for data models that have > semantic meaning included - and gives some ideas on what information > might want to be in some of those data-models. To get the details > correct, I think we'll want to drive from agreed upon specific > vertical use-cases. > > I do think that, assuming there is interest, we want to move forward > to use-cases and nail down a small set of data-models to focus on, at > least with their requirements. There could be multiple transfer > protocols, if we needed them, but it's quite premature to focus on the > protocol specifics now. > > As for the protocol, I tried to focus on the key aspects and/or goals > that we think the interface needs to have. I do apologize for the > extensive use of "streaming" in the doc - I added the key aspects part > and obviously didn't prune out the streaming adjective everywhere. > The intent was to to imply the asynchronous, duplex nature - not, say, > TCP like streaming. > > Alia > > On Sun, Jul 29, 2012 at 12:44 PM, Joel M. Halpern wrote: >> As far as I can tell, the document could use signifiantly more clarity on >> the problem to be solved, and the information modeling gaps that appear to >> exist, and much less (maybe none) discussion of why a new protocol is >> needed. It seems to me that the descriptions of existing protocols tend to >> be based on assumptions that are not borne out by the rest of the document. >> >> As an example, the assumption that the solution must be some form of >> streaming (whatever that means) is not grounded in the document. >> >> Yours, >> Joel M. Halpern >> >> >> On 7/29/2012 12:39 PM, Thomas Nadeau wrote: >>> >>> >>> We wanted to kick off the discussion here about the framework >>> draft. What do you think? How can this be improved? Are we on the right >>> track? >>> >>> The (proposed) Framework can be found here: >>> >>> http://lucidvision.com/draft-ward-irs-framework-00.txt >>> >>> We will be sending out a problem statement draft later today as >>> well. >>> >>> --Tom, Alia, Ward >>> >>> >>> _______________________________________________ >>> irs-discuss mailing list >>> 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 > Return-Path: 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 677F311E8097 for ; Mon, 30 Jul 2012 15:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 MNgLyCE33f-s for ; Mon, 30 Jul 2012 15:33:33 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id B28D011E8087 for ; Mon, 30 Jul 2012 15:33:32 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUBcLt7tE4KgyUmXGgjpGGjqk0Dp08knA@postini.com; Mon, 30 Jul 2012 15:33:32 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 30 Jul 2012 15:33:07 -0700 From: Nitin Bahadur To: James Kempf , Thomas Nadeau , "irs-discuss@ietf.org" Date: Mon, 30 Jul 2012 15:33:06 -0700 Thread-Topic: [irs-discuss] IRS Problem Statement Posted Thread-Index: Ac1uf6vUr0RoAYPERve+GHr5XPQ6JgAIAMEAAADmuyw= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:33:34 -0000 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 contr= oller. 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 th= e network element's RIB (not the FIB directly). Streaming is essential to allow for operations at scale...and avoid a reque= st/response gated mechanism. Hope that helps. Thanks Nitin On 7/30/12 3:11 PM, "James Kempf" wrote: I don't understand why streaming is specified in this draft. And I don't un= derstand why this draft isn't put in the Forces framework. Forces is a fram= ework explicitedly designed for device to controller communication. Its maj= or drawback it that it is a framework with a hole in the middle, in that th= ere 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 int= o a separate device is, in some cases, an attractive design option. So I th= ink this should be submitted to the Forces working group, or, at least, rec= ast in the Forces framework. jak > -----Original Message----- > From: irs-discuss-bounces@ietf.org > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Monday, July 30, 2012 11:18 AM > To: 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 > https://www.ietf.org/mailman/listinfo/irs-discuss > _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 C797A11E80E1 for ; Mon, 30 Jul 2012 15:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 CdO-o2uzEmsl for ; Mon, 30 Jul 2012 15:27:12 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA10E11E80B8 for ; Mon, 30 Jul 2012 15:27:11 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5840696ggn.31 for ; Mon, 30 Jul 2012 15:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/xgtIiztz2gWuKchVeCZRqBs2MiLte2ts63nTIAD88E=; b=iKC7oj6iLXmQp21vKMco3k9ECjI0JWMjHRB87cGwwEMwCtbDdtthOy7r8S+ek9eLIr PlY760tWtDn2AUpT7NJmmo5RcS6kCIs8XbCh4+upG2R1waZuq5cCAb3JS5JHo326odwl OoMGXXrBpM4vWuW14mxRsPFZjLIh9Yb1EX/AP9+65gX9enSY12EER4arZowIDQcpYY5R 9DjmODvKqFCr+nWGhYu1DZyRL0KTObZHqM2D8BxPYLhPc15HBp+c/Nes1h/qsWZSaW39 ryvBQU3i0S+JH5sVjGk3L0klLwMB0+SBGoqP+JwjAwi9GMdEDD1aOJdnWlbouHU1UWfl /uqw== MIME-Version: 1.0 Received: by 10.50.0.137 with SMTP id 9mr180882ige.18.1343687231078; Mon, 30 Jul 2012 15:27:11 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 15:27:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Jul 2012 18:27:11 -0400 Message-ID: From: Alia Atlas To: James Kempf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Nadeau , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:27:13 -0000 Hi James, Thanks for your thoughts. Streaming (as I've heard) is not as good a description of the desired interface attributes as described in Sec 1.1, the functional overview. IRS is NOT about having interfaces to the forwarding plane. That's what ForCES is focused on. This is about communication to a router to install/retrieve routing state into the routing system (FIB, IGPs, BGP, RSVP-TE, etc.) IRS is NOT splitting the control plane from the router. Are you suggesting that ForCES should drastically expand its scope? Before we start debating what and whether to expand existing protocols, I think we need a common understanding of the problem we're trying to solve and the related framework. Alia On Mon, Jul 30, 2012 at 6:11 PM, James Kempf wro= te: > 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 fr= amework explicitedly designed for device to controller communication. Its m= ajor 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 stat= e update. Forces has already established that splitting the control plane i= nto 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, r= ecast in the Forces framework. > > jak > >> -----Original Message----- >> From: irs-discuss-bounces@ietf.org >> [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: Monday, July 30, 2012 11:18 AM >> To: 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 >> https://www.ietf.org/mailman/listinfo/irs-discuss >> > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: 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 F2CDF11E820B for ; Mon, 30 Jul 2012 15:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 D11E-69SU4bY for ; Mon, 30 Jul 2012 15:19:46 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2917511E81EB for ; Mon, 30 Jul 2012 15:19:46 -0700 (PDT) Received: by yenq13 with SMTP id q13so5848914yen.31 for ; Mon, 30 Jul 2012 15:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1tUVZu6uIVZl1kkrz+dnNt8j8Nm0BK55csm6OFrdFqU=; b=GWDitlhj3vHMbYOcD5WDCecLzoLgZT9Br6tot+/Iwc6wxLrlPuZ7PUOTmJ7Up8FH3N CwO5OiMPz7gWBqYoDiPf61PepgvMp8/BajAHmndYG6aXWqXmpWbMygRCoXtBkTH3BpQv T2rKYa469Qmw3TrJNvOF9tJ+3eN2IlYVzNm4mdMTYV04chtk+s5AvSqiYpX1CNqFRudK g0Ao/uuQ3dDUbf8tuoFEiu16zAE5ZHcQ5TNcSSY+AivYY7Lyq2M69aH8sTXtP9zbUjpu 3aXR3Fx5y9ihSbi3rrDtBZGaMXRoxSJWIKMM/oP25rOsNmKh1JG/7C/VvAoCqiF2Gadb Ztsg== MIME-Version: 1.0 Received: by 10.50.158.226 with SMTP id wx2mr85358igb.18.1343686785390; Mon, 30 Jul 2012 15:19:45 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 15:19:45 -0700 (PDT) In-Reply-To: <50156873.2030407@joelhalpern.com> References: <17897894-CD09-482F-9F1A-F01CF44DC906@lucidvision.com> <50156873.2030407@joelhalpern.com> Date: Mon, 30 Jul 2012 18:19:45 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] draft-ward-irs-framework X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:19:47 -0000 Joel, Thanks for the feedback. I think the problem-statement draft (now at http://tools.ietf.org/html/draft-atlas-irs-problem-statement-00) focuses a bit more on the problem and less on the protocol aspects. The framework does try to describe the need for data models that have semantic meaning included - and gives some ideas on what information might want to be in some of those data-models. To get the details correct, I think we'll want to drive from agreed upon specific vertical use-cases. I do think that, assuming there is interest, we want to move forward to use-cases and nail down a small set of data-models to focus on, at least with their requirements. There could be multiple transfer protocols, if we needed them, but it's quite premature to focus on the protocol specifics now. As for the protocol, I tried to focus on the key aspects and/or goals that we think the interface needs to have. I do apologize for the extensive use of "streaming" in the doc - I added the key aspects part and obviously didn't prune out the streaming adjective everywhere. The intent was to to imply the asynchronous, duplex nature - not, say, TCP like streaming. Alia On Sun, Jul 29, 2012 at 12:44 PM, Joel M. Halpern wrote: > As far as I can tell, the document could use signifiantly more clarity on > the problem to be solved, and the information modeling gaps that appear to > exist, and much less (maybe none) discussion of why a new protocol is > needed. It seems to me that the descriptions of existing protocols tend to > be based on assumptions that are not borne out by the rest of the document. > > As an example, the assumption that the solution must be some form of > streaming (whatever that means) is not grounded in the document. > > Yours, > Joel M. Halpern > > > On 7/29/2012 12:39 PM, Thomas Nadeau wrote: >> >> >> We wanted to kick off the discussion here about the framework >> draft. What do you think? How can this be improved? Are we on the right >> track? >> >> The (proposed) Framework can be found here: >> >> http://lucidvision.com/draft-ward-irs-framework-00.txt >> >> We will be sending out a problem statement draft later today as >> well. >> >> --Tom, Alia, Ward >> >> >> _______________________________________________ >> irs-discuss mailing list >> 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 Return-Path: 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 CCD4C11E81FB for ; Mon, 30 Jul 2012 15:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 UndGn1jAXpA4 for ; Mon, 30 Jul 2012 15:14:52 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 73ABC11E81F7 for ; Mon, 30 Jul 2012 15:14:52 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 615AD55836A for ; Mon, 30 Jul 2012 15:14:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id AF5F92009CE for ; Mon, 30 Jul 2012 15:14:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [130.129.32.82] (dhcp-2052.meeting.ietf.org [130.129.32.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8AA412009CB for ; Mon, 30 Jul 2012 15:14:49 -0700 (PDT) Message-ID: <50170758.3030908@joelhalpern.com> Date: Mon, 30 Jul 2012 18:14:48 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: irs-discuss@ietf.org References: <20120730180849.1235.96769.idtracker@ietfa.amsl.com> In-Reply-To: <20120730180849.1235.96769.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:14:52 -0000 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 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. > Return-Path: 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 6F62B11E81EC for ; Mon, 30 Jul 2012 15:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.973 X-Spam-Level: X-Spam-Status: No, score=-5.973 tagged_above=-999 required=5 tests=[AWL=0.626, 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 y-yLOCIiqx3i for ; Mon, 30 Jul 2012 15:11:21 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id AF86D11E81EB for ; Mon, 30 Jul 2012 15:11:21 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q6UMB7a7005055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jul 2012 17:11:20 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 30 Jul 2012 18:11:17 -0400 From: James Kempf To: Thomas Nadeau , "irs-discuss@ietf.org" Date: Mon, 30 Jul 2012 18:11:16 -0400 Thread-Topic: IRS Problem Statement Posted Thread-Index: Ac1uf6vUr0RoAYPERve+GHr5XPQ6JgAIAMEA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:11:22 -0000 I don't understand why streaming is specified in this draft. And I don't un= derstand why this draft isn't put in the Forces framework. Forces is a fram= ework explicitedly designed for device to controller communication. Its maj= or drawback it that it is a framework with a hole in the middle, in that th= ere 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 int= o a separate device is, in some cases, an attractive design option. So I th= ink this should be submitted to the Forces working group, or, at least, rec= ast in the Forces framework. jak > -----Original Message----- > From: irs-discuss-bounces@ietf.org=20 > [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Monday, July 30, 2012 11:18 AM > To: irs-discuss@ietf.org > Subject: [irs-discuss] IRS Problem Statement Posted >=20 >=20 >=20 > Please review and discuss. >=20 > Thanks, >=20 > Tom, Alia, Ward >=20 >=20 > http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt >=20 >=20 > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss > = Return-Path: 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 933B611E81EB for ; Mon, 30 Jul 2012 15:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 7L7pzDuCwhBw for ; Mon, 30 Jul 2012 15:06:52 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id E2C8311E81EA for ; Mon, 30 Jul 2012 15:06:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id E2BCC22038B8 for ; Mon, 30 Jul 2012 18:06:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgx1fTUlvvMF for ; Mon, 30 Jul 2012 18:06:50 -0400 (EDT) Received: from tnadeau-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id 5C60022038B3 for ; Mon, 30 Jul 2012 18:06:50 -0400 (EDT) From: Thomas Nadeau Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <89A782BC-4907-4EC7-BFB4-CC0F5545EE03@lucidvision.com> Date: Mon, 30 Jul 2012 15:06:48 -0700 To: "irs-discuss@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) X-Mailer: Apple Mail (2.1485) Subject: [irs-discuss] irs problem statement X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:06:52 -0000 FYI... A new version of I-D, draft-atlas-irs-problem-statement-00.txt has been successfully submitted by Thomas Nadeau and posted to the IETF repository. Filename: draft-atlas-irs-problem-statement Revision: 00 Title: Interface to the Routing System Problem Statement Creation date: 2012-07-30 WG ID: Individual Submission Number of pages: 12 URL: = http://www.ietf.org/internet-drafts/draft-atlas-irs-problem-statement-00.t= xt Status: = http://datatracker.ietf.org/doc/draft-atlas-irs-problem-statement Htmlized: = http://tools.ietf.org/html/draft-atlas-irs-problem-statement-00 Abstract: As modern networks grow in scale and complexity, the need for rapid and dynamic control increases. With scale, the need to automate even the simplest operations is important, but even more critical is the ability to quickly interact with more complex operations such as policy-based controls. In order to enable applications to have access to and control over information in the Internet's routing system, we need a publically documented interface specification. The interface needs to support real-time, transaction-based interactions using efficient data models and encodings. Furthermore, the interface must support a variety of use cases including those where verified control feed-back loops are needed. This document expands upon these statements of requirements to provide a problem statement for an interface to the Internet routing system. The IETF Secretariat Return-Path: 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 5A7FB21F85CE for ; Mon, 30 Jul 2012 11:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.331 X-Spam-Level: X-Spam-Status: No, score=-6.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 zsmUeU29vxUo for ; Mon, 30 Jul 2012 11:19:12 -0700 (PDT) Received: from exprod7ob112.obsmtp.com (exprod7ob112.obsmtp.com [64.18.2.176]) by ietfa.amsl.com (Postfix) with ESMTP id A9DC421F85AC for ; Mon, 30 Jul 2012 11:19:12 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUBbQH/W8s6vdgeMsv6n3623FHaKe8Hs2@postini.com; Mon, 30 Jul 2012 11:19:12 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; Mon, 30 Jul 2012 11:18:13 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 30 Jul 2012 11:18:13 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 30 Jul 2012 14:18:09 -0400 From: Thomas Nadeau To: "irs-discuss@ietf.org" Date: Mon, 30 Jul 2012 14:18:07 -0400 Thread-Topic: IRS Problem Statement Posted Thread-Index: Ac1uf6vUr0RoAYPERve+GHr5XPQ6Jg== Message-ID: 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: [irs-discuss] IRS Problem Statement Posted X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 18:19:13 -0000 Please review and discuss. Thanks, Tom, Alia, Ward http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt Return-Path: 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 24E4721F8726 for ; Sun, 29 Jul 2012 09:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 QwJlS7kaS8Vo for ; Sun, 29 Jul 2012 09:44:41 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9028A21F8722 for ; Sun, 29 Jul 2012 09:44:41 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 259BD558316 for ; Sun, 29 Jul 2012 09:44:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id BE7451BD8013 for ; Sun, 29 Jul 2012 09:44:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [130.129.32.82] (dhcp-2052.meeting.ietf.org [130.129.32.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 96D011BD8012 for ; Sun, 29 Jul 2012 09:44:39 -0700 (PDT) Message-ID: <50156873.2030407@joelhalpern.com> Date: Sun, 29 Jul 2012 12:44:35 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: irs-discuss@ietf.org References: <17897894-CD09-482F-9F1A-F01CF44DC906@lucidvision.com> In-Reply-To: <17897894-CD09-482F-9F1A-F01CF44DC906@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [irs-discuss] draft-ward-irs-framework X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 16:44:42 -0000 As far as I can tell, the document could use signifiantly more clarity on the problem to be solved, and the information modeling gaps that appear to exist, and much less (maybe none) discussion of why a new protocol is needed. It seems to me that the descriptions of existing protocols tend to be based on assumptions that are not borne out by the rest of the document. As an example, the assumption that the solution must be some form of streaming (whatever that means) is not grounded in the document. Yours, Joel M. Halpern On 7/29/2012 12:39 PM, Thomas Nadeau wrote: > > We wanted to kick off the discussion here about the framework draft. What do you think? How can this be improved? Are we on the right track? > > The (proposed) Framework can be found here: > > http://lucidvision.com/draft-ward-irs-framework-00.txt > > We will be sending out a problem statement draft later today as well. > > --Tom, Alia, Ward > > > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss > Return-Path: 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 E68E021F85C2 for ; Sun, 29 Jul 2012 09:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 vnJTbrJZHg5a for ; Sun, 29 Jul 2012 09:40:00 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA3E21F8504 for ; Sun, 29 Jul 2012 09:40:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id C41632200A5B for ; Sun, 29 Jul 2012 12:39:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLsR6vnFnaQk for ; Sun, 29 Jul 2012 12:39:59 -0400 (EDT) Received: from [172.30.1.206] (c-98-247-226-85.hsd1.wa.comcast.net [98.247.226.85]) by lucidvision.com (Postfix) with ESMTP id 5E2892200A58 for ; Sun, 29 Jul 2012 12:39:59 -0400 (EDT) From: Thomas Nadeau Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <17897894-CD09-482F-9F1A-F01CF44DC906@lucidvision.com> Date: Sun, 29 Jul 2012 09:39:57 -0700 To: irs-discuss@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) X-Mailer: Apple Mail (2.1485) Subject: [irs-discuss] draft-ward-irs-framework X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 16:40:07 -0000 We wanted to kick off the discussion here about the framework = draft. What do you think? How can this be improved? Are we on the right = track? The (proposed) Framework can be found here: http://lucidvision.com/draft-ward-irs-framework-00.txt We will be sending out a problem statement draft later today as = well. --Tom, Alia, Ward =09= Return-Path: 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 4165221F853F for ; Thu, 26 Jul 2012 19:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Izqjddb8jDPl for ; Thu, 26 Jul 2012 19:27:47 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6891121F8518 for ; Thu, 26 Jul 2012 19:27:38 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUBH8mZiZti6xYGfddZKC/IhkJJQDHfwJ@postini.com; Thu, 26 Jul 2012 19:27:47 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 26 Jul 2012 19:25:20 -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, 26 Jul 2012 22:25:19 -0400 From: Alia Atlas To: "irs-discuss@ietf.org" Date: Thu, 26 Jul 2012 22:25:18 -0400 Thread-Topic: IRS framework draft Thread-Index: Ac1rnxCSrG11LY65TEahCj141EJSvQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 26 Jul 2012 19:28:24 -0700 Subject: [irs-discuss] IRS framework draft X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 02:27:49 -0000 I'm excited to see so much interested in IRS and hope we can get started on= some good discussion. For those who didn't see Tom's email to related mai= ling lists, the relevant draft to read is at: http://www.lucidvision.com/draft-ward-irs-framework-00.txt We will be discussing IRS during the Routing Area Open Meeting on Thurs mor= ning. Regards, Alia Return-Path: 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 5A4F411E80C1; Thu, 26 Jul 2012 17:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 cAaMCyQk-Dv8; Thu, 26 Jul 2012 17:45:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E116C11E8086; Thu, 26 Jul 2012 17:45:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120727004529.5739.53836.idtracker@ietfa.amsl.com> Date: Thu, 26 Jul 2012 17:45:29 -0700 Cc: tnadeau@juniper.net, wardd@cisco.com, akatlas@juniper.net, irs-discuss@ietf.org Subject: [irs-discuss] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS) X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 00:45:30 -0000 A new IETF non-working group email list has been created. List address: irs-discuss@ietf.org Archive: http://www.ietf.org/mail-archive/web/irs-discuss/ To subscribe: https://www.ietf.org/mailman/listinfo/irs-discuss Purpose: This list is for the discussion of an interface to the routing = system (IRS) that allows applications to rapidly and dynamically install = routing state into routers, and to learn sufficient information from = routers to make timely, data-based decisions about what routing state to = specify. Such an interface would facilitate control and diagnosis of the = routing infrastructure, as well as enabling sophisticated applications = to be built on top of today's routed networks. The IRS is conceived as a = programmatic, streaming interface for transferring state into and out of = the Internet's routing system, recognizing that the routing system and a = router's OS provide useful mechanisms that applications could harness to = accomplish application-level goals. A fundamental component of the IRS = is a clear data model that defines the semantics of the information that = can be written and read. = For additional information, please contact the list administrators.