From ietfc@btconnect.com Fri Mar 1 02:43:34 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C26921F8830 for ; Fri, 1 Mar 2013 02:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVkf+hhC3aCh for ; Fri, 1 Mar 2013 02:43:33 -0800 (PST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id 33FB721F886A for ; Fri, 1 Mar 2013 02:43:32 -0800 (PST) Received: from mail101-db8-R.bigfish.com (10.174.8.225) by DB8EHSOBE033.bigfish.com (10.174.4.96) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Mar 2013 10:43:32 +0000 Received: from mail101-db8 (localhost [127.0.0.1]) by mail101-db8-R.bigfish.com (Postfix) with ESMTP id F2EDA960094; Fri, 1 Mar 2013 10:43:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -14 X-BigFish: PS-14(z426fnz9371Ic89bh1b0bI542I1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dh8275bhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h304l1155h) Received: from mail101-db8 (localhost.localdomain [127.0.0.1]) by mail101-db8 (MessageSwitch) id 1362134609573043_14835; Fri, 1 Mar 2013 10:43:29 +0000 (UTC) Received: from DB8EHSMHS016.bigfish.com (unknown [10.174.8.237]) by mail101-db8.bigfish.com (Postfix) with ESMTP id 89A1122006B; Fri, 1 Mar 2013 10:43:29 +0000 (UTC) Received: from DBXPRD0710HT005.eurprd07.prod.outlook.com (157.56.253.197) by DB8EHSMHS016.bigfish.com (10.174.4.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Mar 2013 10:43:24 +0000 Received: from DBXPRD0611HT004.eurprd06.prod.outlook.com (157.56.254.85) by pod51017.outlook.com (10.255.79.168) with Microsoft SMTP Server (TLS) id 14.16.275.6; Fri, 1 Mar 2013 10:43:24 +0000 Message-ID: <01bd01ce1669$1a291440$4001a8c0@gateway.2wire.net> From: t.petch To: Russ White References: <512BECC0.3020306@riw.us> <512CFF4E.6060400@riw.us> Date: Fri, 1 Mar 2013 10:39:42 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.254.85] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: i2rs@ietf.org Subject: Re: [i2rs] Router Models X-BeenThere: i2rs@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, 01 Mar 2013 10:43:34 -0000 Russ FYI I understand that you sent an e-mail to the list with an attached diagram but, if so, it was way over the limit that trips my spam filters so I never got it. The archive strips attachments so there is nothing there. I accessed the URI you gave and downloaded 500kbyte which displays as 28x30 pixels of not very much. I note that it starts with =FF=D8=FF=E0 ... .Adobe... Exif whereas a jpeg usually starts with =FF=D8=FF=E0 ... JFIF There is a Lot to be Said for ASCII Art. Tom Petch ----- Original Message ----- From: "Russ White" To: "Rob (William) Rice" Cc: Sent: Tuesday, February 26, 2013 6:30 PM > > 1. Within your Routing Process boxes, I think what you mean by "A" > > is the injection of the same type of raw data the routing process > > receives from normal protocol neighbor (e.g., LSAs for OSPF, > > paths/NLRI for BGP). By "B," I think you mean injecting items that > > are the product of the routing protocol's processing of this raw > > data (i.e., protocol-specific routes). Am I understanding you > > correctly on this? "B" is not a modification to the routing protocol > > logic itself, is it? Would it be clearer to have another box below > > the Policy cloud to represent the set of routes the protocol > > computes, with the Policy cloud representing the internal protocol > > logic that transforms the input data into routes? > > I'm using A to represent information put into the routing process like a > peer running the same routing protocol would put information into that > routing process, and B to represent modifications to the policy the > routing process uses to choose which route to present to the RIB. > > B is not a modification to the actual algorithm the process uses to > select the best paths --that would be really, really bad. :-) > > I would argue that putting information directly into the OSPF LSA > database -- for instance, modifying a type 1 LSA to include a link that > wasn't advertised by the originator of that type 1 LSA -- would also be > "bad juju." Once you start messing with the internal data structures of > algorithms and protocols which count on the consistency and accuracy of > those data structures to make accurate and timely decisions, you're > someplace you really don't want to be. > > > 2. Does the RIB in your diagram include all routes from all sources > > or just best routes (those to be used for forwarding)? > > All the routes from all sources. The RIB would select which routes to > present to the FIB based on it's internal policy (such as admin > distance). Perhaps the "policy cloud" should really be below the RIB, > between the RIB and the FIB. > > > 3. Is the policy cloud hovering above the RIB box applying whatever > > rules the implementation uses (e.g., admin distance) to select best > > routes? Maybe also rules for filtering routes accepted from various > > sources? I'm trying to understand the difference between "C" and > > "D." > > Yes... > > > 4. Can you clarify why you think injecting at "D" is "bad juju"? > > Presumably, "D" says "x is the best route to destination N, > > regardless of anything anyone else says"? > > This is bad, IMHO, because it's mixing local policy with remote policy > in a way that's not obvious to an engineering examining the local > forwarding table, and because it bypasses the normal checks that prevent > the formation of routing loops, unreachable next hops, overwriting > connected routes, and other things of that sort. > > If you want a route to be installed "no matter what other process > think," then the preference on the route (the "administrative > distance"), should be set to cause this particular route to be installed > instead of any route presented by another process, within the rule set > allowed by the local RIB process. > > In general, I think overriding the internal algorithms and policies > implemented by protocols and processes is a "bad thing." We should > strive to work with and through those internal algorithms and policies, > not around them. > > :-) > > Russ > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From cdl@asgaard.org Wed Feb 27 11:41:59 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A620621F8B98 for ; Wed, 27 Feb 2013 11:41:59 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjBT3+ZXI1F0 for ; Wed, 27 Feb 2013 11:41:59 -0800 (PST) Received: from smtp1.emailarray.com (smtp1.emailarray.com [65.39.216.14]) by ietfa.amsl.com (Postfix) with ESMTP id 08CAE21F8BA4 for ; Wed, 27 Feb 2013 11:41:55 -0800 (PST) Received: (qmail 25986 invoked by uid 89); 27 Feb 2013 19:41:55 -0000 Received: from unknown (HELO ?204.29.150.161?) (Y2RsQGFzZ2FhcmQub3JnQDUwLjc2LjM0LjE4NQ==) (POLARISLOCAL) by smtp1.emailarray.com with (AES128-SHA encrypted) SMTP; 27 Feb 2013 19:41:54 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Christopher LILJENSTOLPE X-Mailer: Apple Mail (2.1499) In-Reply-To: <23F95046-D50F-4835-ABAF-3C8CD3F47A9F@castlepoint.net> Date: Wed, 27 Feb 2013 11:41:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7B9D8EA3-C3DC-4EAB-9E10-A50A9296B775@asgaard.org> References: <512BECC0.3020306@riw.us> <512CFF4E.6060400@riw.us> <512D24C3.2000306@riw.us> <23F95046-D50F-4835-ABAF-3C8CD3F47A9F@castlepoint.net> To: Shane Amante X-PolarisMail-Flags: x X-Mailman-Approved-At: Fri, 01 Mar 2013 08:04:59 -0800 Cc: Russ White , "i2rs@ietf.org" , "Rob \(William\) Rice" Subject: Re: [i2rs] Router Models X-BeenThere: i2rs@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, 27 Feb 2013 19:41:59 -0000 Greetings all, On 26Feb2013, at 18.48, Shane Amante wrote: >>>=20 > Taking a look at (b) and looking at your diagram, it seems as though = (b) should be within the boxes you have labelled "Routing Process". = More specifically, I think you need more "clouds" ;-) sitting directly = above the "Local Database" (Loc-RIB?) that, at a minimum, represent = protocol adjacencies (e.g.: BGP neighbor adjacencies) where I2RS = _should_ be allowed to apply (BGP) policy to those routing protocol = sessions, in order to permit filtering of _and_ manipulation of = attributes in those routes inbound to or outbound from the routing = protocol process, (just like we do in today's networks). I would think = that this additional cloud would represent something like the = Adj-RIB-In/Adj-RIB-Out, at least wrt a BGP Routing Process. >=20 > With respect to (a) above, namely placement of = aggregate/summarization/etc. routes, I believe that would most likely = belong inside of and/or injected into the "policy" cloud (inside the = "Routing Process" box) through "B" in your diagram. IOW, I place a = summarization route in the routing process, which then flows two = directions: i) up into the routing processes database and outward = through the routing protocol, using normal routing update protocol = mechanisms; and, ii) down to the RIB process for consideration as to = whether it should be installed in the FIB after passing through "D" and = "E", of course. >=20 I think Shane brings up some salient points. However, I do wonder if = the same could be accomplished by injecting the routes "below" the = individual routing protocols policy engine/cloud and allow for the = redistribution "up (in the diagram)" based on that policy engine (under = the control of a system that uses I2RS, but that policy may actually be = driven by another protocol (interesting point, do we want I2RS to drive = policy configuration, or use something else, ala NETCONF). =20 As Shane says, that policy engine is different from different vendors, = so I'm not sure if it would be any easier to implement policy config via = a common model in I2RS v.v. NETCONF. =20 Another option would be for I2RS to bypass the policy engine on the = protocol all together and enforce policy on the I2RS "controller". In = that approach, you could either bypass the policy engine in reality, or = virtually, by defining a policy in the protocol engine that allowed I2RS = to bypass local policy (think global "accept"). >=20 >> :-) >>=20 >> Russ >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf Check my calendar availability: https://tungle.me/cdl From russw@riw.us Fri Mar 1 10:11:44 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A16521E80C1 for ; Fri, 1 Mar 2013 10:11:44 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0up3jChH0pn for ; Fri, 1 Mar 2013 10:11:43 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD3421E80CA for ; Fri, 1 Mar 2013 10:11:43 -0800 (PST) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=[192.168.100.69]) by da31.namelessnet.net with esmtpa (Exim 4.80) (envelope-from ) id 1UBUQm-0000CR-Qd; Fri, 01 Mar 2013 10:11:40 -0800 Message-ID: <5130EF65.8070207@riw.us> Date: Fri, 01 Mar 2013 13:11:49 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Scott Whyte References: <512BECC0.3020306@riw.us> <512CC60D.6000202@joelhalpern.com> <512D07EE.3000000@riw.us> <512D0BF8.4030902@riw.us> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, "Joel M. Halpern" Subject: Re: [i2rs] Router Models X-BeenThere: i2rs@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, 01 Mar 2013 18:11:44 -0000 > I'd find it helpful if we could agree to use Alia's terminology from > draft-atlas-i2rs-problem-statement-01, specifically "Policy Database" > and "RIB Manager", or clarify what's wrong with that terminology. IMHO, this terminology isn't specific enough to drive the discussion... The policy manager, as shown in problem-statement, controls what kind of policy for which elements which is inserted where? What's the difference between the connection to the "routing and signaling protocols," box, and the "RIB Manager?" Further, the drawing in problem-statement appears to assume a local process called the "I2RS agent," which intercedes between the policy and database injection points and the I2RS client/applications. I don't think we're going to build a solid data model if we're building a model around a local process, with it's own internal database, processes, and policy, rather than targeting the ultimate end users of the information (the policy and database in each of the independent processes). :-) Russ From russw@riw.us Fri Mar 1 10:20:26 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6172921F8EDB for ; Fri, 1 Mar 2013 10:20:26 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqjNe7MleHp5 for ; Fri, 1 Mar 2013 10:20:25 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id B568021F8C32 for ; Fri, 1 Mar 2013 10:19:59 -0800 (PST) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=[192.168.100.69]) by da31.namelessnet.net with esmtpa (Exim 4.80) (envelope-from ) id 1UBUYo-0000lx-Mm; Fri, 01 Mar 2013 10:19:58 -0800 Message-ID: <5130F157.2070301@riw.us> Date: Fri, 01 Mar 2013 13:20:07 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Shane Amante References: <512BECC0.3020306@riw.us> <512CFF4E.6060400@riw.us> <512D24C3.2000306@riw.us> <23F95046-D50F-4835-ABAF-3C8CD3F47A9F@castlepoint.net> In-Reply-To: <23F95046-D50F-4835-ABAF-3C8CD3F47A9F@castlepoint.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "i2rs@ietf.org" , "Rob \(William\) Rice" Subject: Re: [i2rs] Router Models X-BeenThere: i2rs@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, 01 Mar 2013 18:20:26 -0000 > I would hope more folks in the WG want that too. :-) > > On a more general note ... first, thanks for putting this diagram > together. At least now we have a decent picture to start a > discussion. > > I think you've mostly (?) been focused on routes being received by > and processed by a router that, ultimately, are distilled into a > FIB. That's certainly important, but I think that we also need to > look in the other direction, namely: routes that get /exported/ from > one, or more, routers into an IGP or BGP. > a) > placement of aggregate/tie-down/summarization/flow-spec routes, (at > certain routers at certain places in the topology); I would think of this as inserting information through the normal peering process, or through a "static route," (which is just another routing process) + the policy needed to import/redistribute that route into BGP. So, assuming B in the diagram is bidirectional, setting up the policy for what the routing process receives from the RIB as well as what the routing process presents to the RIB. > b) "route > filters" applied to, for example, eBGP neighbor sessions inbound & > outbound This is where I think the diagram needs another "policy cloud," showing a policy insertion point between "Peering" and the "local database." > Taking a look at (b) and looking at your diagram, it seems as though > (b) should be within the boxes you have labelled "Routing Process". > More specifically, I think you need more "clouds" ;-) sitting > directly above the "Local Database" (Loc-RIB?) that, at a minimum, > represent protocol adjacencies (e.g.: BGP neighbor adjacencies) > where I2RS _should_ be allowed to apply (BGP) policy to those > routing protocol sessions, in order to permit filtering of _and_ > manipulation of attributes in those routes inbound to or outbound > from the routing protocol process, (just like we do in today's > networks). I would think that this additional cloud would represent > something like the Adj-RIB-In/Adj-RIB-Out, at least wrt a BGP Routing > Process. Yep. > In summary, although I think you chose your words carefully when > describing "A" by proposing that I2RS avoid (forbid?) "direct > injection of information [in]to a routing process", I think there's > an important point we should not miss here. Namely, I2RS can do > that, but only _when_ I2RS informs the routing process, which then Or rather when I2RS uses the "normal, front door," APIs provided by the routing process to interact with those local databases. What we don't want is the ability to inject a route into the BGP table that just overwrites other routes, no matter what other policy might be implemented within the BGP process itself. I expect there will always be some way to say, "this route must win," such as weight in IOS, or admin distance, but we don't want to bypass these sorts of things, we want to work with them. > [2] While we're here, I'm not sure where (if it all) you intended > for routing protocol redistribution to be illustrated in your > diagram. Given that different vendors have vastly different > models/ideas of how this is accomplished in their code, I'm not sure > such a thing is even practical or possible. :-( See above, about the bidirectional nature of B in the diagram... I think that would cover the redistribution case. You might have to include D, as shown, in the process of redistribution as well (for instance, redistribution in a particular implementation might be a push from the RIB process to each impacted routing process --so we need to account for both push and pull models here). :-) Russ From russw@riw.us Fri Mar 1 10:22:40 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EB921F93B8 for ; Fri, 1 Mar 2013 10:22:40 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl9CLFxQR22t for ; Fri, 1 Mar 2013 10:22:39 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id BD8F921F93B6 for ; Fri, 1 Mar 2013 10:22:39 -0800 (PST) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=[192.168.100.69]) by da31.namelessnet.net with esmtpa (Exim 4.80) (envelope-from ) id 1UBUbP-0000wG-90 for i2rs@ietf.org; Fri, 01 Mar 2013 10:22:39 -0800 Message-ID: <5130F1F8.8090105@riw.us> Date: Fri, 01 Mar 2013 13:22:48 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: i2rs@ietf.org References: <512BECC0.3020306@riw.us> <512CFF4E.6060400@riw.us> In-Reply-To: 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: Re: [i2rs] Router Models X-BeenThere: i2rs@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, 01 Mar 2013 18:22:40 -0000 > It might be useful to have an upfront agreement on the definitions of terms like RIB, FIB, routing table and forwarding table. Previously, we had an interesting discussion about them in the NETMOD mailing list, see this thread: I suspect there are so many definitions that we're going to need to come up with I2RS specific definitions and enforce them in our particular set of drafts to make this work... We're not going to get to a consensus across the entire IETF --at least I don't think we will... :-) Russ From russw@riw.us Fri Mar 1 10:25:24 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D64421F8E94 for ; Fri, 1 Mar 2013 10:25:24 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrCQ8Z0SrswV for ; Fri, 1 Mar 2013 10:25:18 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id ACDB821F8D2D for ; Fri, 1 Mar 2013 10:25:10 -0800 (PST) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=[192.168.100.69]) by da31.namelessnet.net with esmtpa (Exim 4.80) (envelope-from ) id 1UBUdp-00017n-HV; Fri, 01 Mar 2013 10:25:09 -0800 Message-ID: <5130F28E.4040204@riw.us> Date: Fri, 01 Mar 2013 13:25:18 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Bruno Rijsman References: <512BECC0.3020306@riw.us> <512CC60D.6000202@joelhalpern.com> <512D07EE.3000000@riw.us> <3E909C8EAA9AEF4EB627ADC0DA8526B1AB740B@BY2PRD0511MB404.namprd05.prod.outlook.com> In-Reply-To: <3E909C8EAA9AEF4EB627ADC0DA8526B1AB740B@BY2PRD0511MB404.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] Router Models X-BeenThere: i2rs@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, 01 Mar 2013 18:25:24 -0000 > It took me a while to figure out that different types of information are being manipulated at each arrow. The diagram would be easier to understand if each arrow was labeled with the type of object which is being inserted or retrieved at each interface: > > A: Local routing process state > B: Routing process to RIB process export policy rules > C: Routes in the RIB > D: RIB process import policy rules > E: RIB process to FIB best route selection rules Yes --thanks... I think it is probably important to make certain we not only define the type of operation at each point, but also the data being injected/received, at least broadly... The point in building the data model would then be to define these data transfers more specifically, and then the protocol work to figure out how to carry the data specifically called for in an intelligible way, I think... But I'm thinking way ahead of the ball at this point, and just throwing out some possible lines of approach. Nothing definite here! :-) Russ From abdussalambaryun@gmail.com Sat Mar 2 11:42:33 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9821D21F85A4 for ; Sat, 2 Mar 2013 11:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pM4NZrcT22MK for ; Sat, 2 Mar 2013 11:42:32 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E16C21F85A2 for ; Sat, 2 Mar 2013 11:42:25 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so1911877dae.31 for ; Sat, 02 Mar 2013 11:42:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/zmqYy40CMKFUfkFQGFrtWYR7Kn1BtYdMre10UsHmbY=; b=RknlRt1KnAE9Tj7RduL94x40AP3GZlV8JcdLjL54I4dG5B3EnJOsMkIsGylrCvbV+N miMazMBmP2y64ZHCZFS5coh12vuWFx2exXiqjfzyN/Yo6f9UqMfGQEU2ORVDDSz1JDSK EXvhQwTLZxNLZsYY6+wKNvNOSBZadguwgybS2pI0PxlbMIgYoRuvVJaJaB4R+Wikf6Ck f7EqkeS7GfhI/hVpW1mSODiL+ldtRkuFrtKBCWWiF0eCdFgk627crlDRcRk/JLAGEg+l Y2WSwDbsbH9cjLJRrM66DHEkpM4aj6aUVnl16Sv85Z4cjQWhSL7WO+vSQlvA2GkiD1zk +Jtg== MIME-Version: 1.0 X-Received: by 10.66.27.199 with SMTP id v7mr24372833pag.215.1362253344903; Sat, 02 Mar 2013 11:42:24 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sat, 2 Mar 2013 11:42:24 -0800 (PST) In-Reply-To: <512BECC0.3020306@riw.us> References: <512BECC0.3020306@riw.us> Date: Sat, 2 Mar 2013 20:42:24 +0100 Message-ID: From: Abdussalam Baryun To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: i2rs@ietf.org Subject: Re: [i2rs] Router Models X-BeenThere: i2rs@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: Sat, 02 Mar 2013 19:42:33 -0000 I agree that we MAY start from defined router model with defined I2RS use-cases, so both not each separate. I argued before that we SHOULD define both parts of communication that includes the router but my ideas may be ignored, AB On 2/25/13, Russ White wrote: > Y'all: > > Because of a long and protracted exchange off list with a number of > folks, I've come to the conclusion that we can't (really) start with a > data model --even working from the use cases to a data model seems to be > difficult. I think we need to come to agreement on what a router looks > like first. > > No, not blue, grey, green, or... :-) > > Look at the attached (hopefully the attachment works --if not, I've > stashed a copy here, as well: http://www.riw.us/temp/router%20model.jpg). > > Let's ignore the question of whether or not there is some sort of I2RS > local process --more on this in a sec. > > Note I'm not claiming: > > - This is the only possible model for a router's operation > - This is a model that is widely used and deployed > - This is a model that contains every piece of a possible router > > What I am claiming is this is a useful model that will help us > understand what we want to do, and what we don't want to do --and, I > hope, it will lead to a better understanding of the difference between > policy, forwarding information, and configuration. > > IMHO: > > - If a process wants to inject information at A, then it can simply > participate in the routing protocol in question --so I2RS doesn't really > need to do anything there. In fact, I would argue that injecting > information at A without participating in the protocol could be very > dangerous, and we don't want to go there. > > - I2RS should be in the business of injecting information at B. We can > discuss whether that should be through configuration or not (IMHO, it > should be). > > - I2RS should be in the business of injecting information at C (because > the current use cases demand it). In fact, C should be a bidirectional > interface that looks, to the RIB, just like an on-box routing process > (like either of the other two routing processes shown in the diagram). > > - I2RS should not mess with D. This is bad juju. > > - I2RS should not mess with E, this is FORCES. > > - I2RS should not mess with F, this is OpenFlow. > > Now, to return to the idea of a "local process." There are several > issues to assuming a "local I2RS process." The first is that it > restricts implementation in a way that might be unacceptable in all > situations. Smaller devices with only partial I2RS interfaces might find > it painful to build a separate process, with all that entails, just to > support some simple commands from an I2RS controller. The second is that > assuming a local process really doesn't help us in any material way to > define anything. When we're in the process of building a data model for > interacting with BGP policy, for instance, how does saying, "well, the > local I2RS process has a data model that looks like x, which it > translates into data model y to talk through some local interface to the > BGP process," really help? The only thing I can see assuming a "local > process," does is add complexity. > > So, thoughts... > > - Is this a reasonable model of a controlled device? > - What would you add? > - What would you subtract? > - What specific operation can you think of that doesn't quite fit into > the model as it's shown? > > Hopefully, this will kick off some discussion here, and bring us to a > place where we can go back to the two use cases the WG originally agreed > to restrict itself to, and make some progress in understanding how to > build the right pieces to support those use cases. > > :-) > > Russ > From akatlas@gmail.com Mon Mar 4 06:51:19 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B881F21F8922 for ; Mon, 4 Mar 2013 06:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 y9CnkxuLVfC4 for ; Mon, 4 Mar 2013 06:51:19 -0800 (PST) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4A721F88E2 for ; Mon, 4 Mar 2013 06:51:19 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id u20so4752108iag.5 for ; Mon, 04 Mar 2013 06:51:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8QAzSmmTJSJdzl0A+EvKiYRtJOoOFMUcbEuctE6K4A8=; b=AEs3YGsDc3/l6JhfnI3EjzFfDcuj+S+9DzK1FiptRghGHyjdAEA9xPLMJPuALmRs2j VO13BVQzjuHGwiLOLoKvw/C7InrUrw+kTsLeHhueDmAvYIz2VOXu1jYeDeyKy2Y3wyoQ DV2Rk6vBvHkzu6Nk8K8xDgFg94X3OpEKtzydFOV5mkYsY8RwqH2eoDx1txxML3hXRtPL AxS5tr4P6hNAz1bkC5/t0YOcRGS52eUB0VZOmO3nyMdrJwwWC47l5XoYLsVd0K3QC2Mv 4VtcZJJPLAdh6gJqqdrEB0qcH4IZcVRLp1CxR20QvLBFImGNZXXcvgHz+vfFeLKSxV/n qhYA== MIME-Version: 1.0 X-Received: by 10.50.181.167 with SMTP id dx7mr2605882igc.12.1362408675835; Mon, 04 Mar 2013 06:51:15 -0800 (PST) Received: by 10.64.44.169 with HTTP; Mon, 4 Mar 2013 06:51:15 -0800 (PST) In-Reply-To: <5130EF65.8070207@riw.us> References: <512BECC0.3020306@riw.us> <512CC60D.6000202@joelhalpern.com> <512D07EE.3000000@riw.us> <512D0BF8.4030902@riw.us> <5130EF65.8070207@riw.us> Date: Mon, 4 Mar 2013 09:51:15 -0500 Message-ID: From: Alia Atlas To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: i2rs@ietf.org, "Joel M. Halpern" , Scott Whyte Subject: Re: [i2rs] Router Models X-BeenThere: i2rs@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, 04 Mar 2013 14:51:19 -0000 The diagram is a high-level conceptual picture mostly showing connections from i2rs to other aspects of the box. The RIB Manager is, I think, the exception. Alia On Fri, Mar 1, 2013 at 1:11 PM, Russ White wrote: > >> I'd find it helpful if we could agree to use Alia's terminology from >> draft-atlas-i2rs-problem-statement-01, specifically "Policy Database" >> and "RIB Manager", or clarify what's wrong with that terminology. > > IMHO, this terminology isn't specific enough to drive the discussion... > The policy manager, as shown in problem-statement, controls what kind of > policy for which elements which is inserted where? What's the difference > between the connection to the "routing and signaling protocols," box, > and the "RIB Manager?" > > Further, the drawing in problem-statement appears to assume a local > process called the "I2RS agent," which intercedes between the policy and > database injection points and the I2RS client/applications. I don't > think we're going to build a solid data model if we're building a model > around a local process, with it's own internal database, processes, and > policy, rather than targeting the ultimate end users of the information > (the policy and database in each of the independent processes). > > :-) > > Russ > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From russw@riw.us Mon Mar 4 14:42:48 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CC421F882F for ; Mon, 4 Mar 2013 14:42:48 -0800 (PST) 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 QziLExwsxc-8 for ; Mon, 4 Mar 2013 14:42:48 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2979E21F8826 for ; Mon, 4 Mar 2013 14:42:48 -0800 (PST) Received: from ip-64-134-182-243.public.wayport.net ([64.134.182.243] helo=[192.168.10.214]) by da31.namelessnet.net with esmtpa (Exim 4.80) (envelope-from ) id 1UCe5l-000560-Nr; Mon, 04 Mar 2013 14:42:45 -0800 Message-ID: <5135236D.6030601@riw.us> Date: Mon, 04 Mar 2013 17:42:53 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Alia Atlas References: <512BECC0.3020306@riw.us> <512CC60D.6000202@joelhalpern.com> <512D07EE.3000000@riw.us> <512D0BF8.4030902@riw.us> <5130EF65.8070207@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, "Joel M. Halpern" , Scott Whyte Subject: Re: [i2rs] Router Models X-BeenThere: i2rs@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, 04 Mar 2013 22:42:48 -0000 > The diagram is a high-level conceptual picture mostly showing > connections from i2rs > to other aspects of the box. The RIB Manager is, I think, the exception. Of course --my point was that to drive the data model, and better understand the interaction between I2RS and the devices we want to interact with, we need something that's more specific. Different purposes, but both are needed, IMHO. :-) Russ From akatlas@gmail.com Mon Mar 4 14:47:37 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D79321F88E2 for ; Mon, 4 Mar 2013 14:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 7OFeDDpmZHNq for ; Mon, 4 Mar 2013 14:47:36 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2AD21F88B6 for ; Mon, 4 Mar 2013 14:47:36 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k11so6839948iea.24 for ; Mon, 04 Mar 2013 14:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MejPkIYNgKRtAiFXuhnDBsU1B8UsEsF4xo+gsl4fGx4=; b=lI3mcB0Q7rYI7VcJ9NgrpIuF2G/Fe+WRaufV+HoCQZ7Fmm9axevOHeT/3YZ/qM8rvm 1Kdq+tLoT/mGE83RmDzlqJS+lYvQZSGa8h/TBcY6TmDK4gpS9Lt89vimtu3R1Li0Zttu L8cOuUAGEdwzw5gRfwwAxWq7DPm+aKJJiBZGRyyepSU/bF3hX3QCYSfQ7yWCr8PTjHnp ZzOagNXSGhDWBJDFXtIwuORly8Bvkm5GMjfWT3BzkqZVW/YO0UvzHgx7YptYBWJAtSWr zoq/ZKGso/KU7T+/m3he0a15W3Gt1jhIh1MDZ8xZyd0KZjyzyNMzMdcfmgQ+0Oz4Ods+ Hs8g== MIME-Version: 1.0 X-Received: by 10.50.47.168 with SMTP id e8mr4176229ign.50.1362437255452; Mon, 04 Mar 2013 14:47:35 -0800 (PST) Received: by 10.64.44.169 with HTTP; Mon, 4 Mar 2013 14:47:35 -0800 (PST) In-Reply-To: <5135236D.6030601@riw.us> References: <512BECC0.3020306@riw.us> <512CC60D.6000202@joelhalpern.com> <512D07EE.3000000@riw.us> <512D0BF8.4030902@riw.us> <5130EF65.8070207@riw.us> <5135236D.6030601@riw.us> Date: Mon, 4 Mar 2013 17:47:35 -0500 Message-ID: From: Alia Atlas To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: i2rs@ietf.org, "Joel M. Halpern" , Scott Whyte Subject: Re: [i2rs] Router Models X-BeenThere: i2rs@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, 04 Mar 2013 22:47:38 -0000 Yes, I think that your diagram is a good start. I hope your ASCII art fu is better than mine :-) For the "functional analysis" of I2RS discussion, I think that a diagram or two would be a good idea as well - to make it clear what aspects are interesting, in-scope, and generally likely to be safe. Do you have time to draw something a bit more detailed up? Of course, it's not going to fully describe all the aspects - but things like mucking with data learned via routing (as opposed to policy in processing that data or in specifying data "owned" by the network element) is pretty clearly hazardous. Thanks, Alia On Mon, Mar 4, 2013 at 5:42 PM, Russ White wrote: > >> The diagram is a high-level conceptual picture mostly showing >> connections from i2rs >> to other aspects of the box. The RIB Manager is, I think, the exception. > > Of course --my point was that to drive the data model, and better > understand the interaction between I2RS and the devices we want to > interact with, we need something that's more specific. > > Different purposes, but both are needed, IMHO. > > :-) > > Russ > > From edc@google.com Tue Mar 5 15:22:56 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201B111E8123 for ; Tue, 5 Mar 2013 15:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 4v3WXhiUuVWk for ; Tue, 5 Mar 2013 15:22:55 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3F53A11E8122 for ; Tue, 5 Mar 2013 15:22:55 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id k14so6944131wer.39 for ; Tue, 05 Mar 2013 15:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=xetAH1eW9W2E41vtTA6CdxvgdQIth0VVF7urAUpxlGo=; b=kuoA/qg875rmv8sRa6WtJ/djMfAXBKq8lAfGZJUuiMOsoQoaai8XUB8V1VlHBrnEn5 pPqAtrO+1ys2DaPdvZXhTWuwybqO+Ge6kM3thn5l2lGQH5VoKOSQ63feEPTgR8ZLvF6/ gpsJJ2z2vSCmwNW31RIO4WLv7aBQavzgiNtLmyUz82ltSkppvgySBkFN78XaJjR4LDwW kFPrpsWW5naKDcqsKHH/8xJ/plGZNyH/CjRdYvwmYpJGw1Wd1+1eRUs4fCfURlfsl4Gp a88nk+gC3UmiLyZUpSECqpX7eEupCUf0CNBT/AlObQeUrJlbXCjM7Aa1Hswsjwf+NZ+A A8Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=xetAH1eW9W2E41vtTA6CdxvgdQIth0VVF7urAUpxlGo=; b=Hq2m9L3GCdwYis0ZfKE9EgiirXnpnIVa3ZE1kopAwxVywthTVv8FMyUXkOBlmYUXSh xM12fcPk7WzfpMbKUQLH9OVvYhsrdqZeOzAUWhWwwtGrZHT8rIoV9klZdcKqgRXefEIJ DdXJywzCat9O/9Sa7KTLb1uH+0vOHlK8zmdM0FobtH5H0u7tKrsLLfWHP2gJTxnleNoI Q9N3mJJaAji5V5wYB42rg7of7E23vo+T64B1AxI5SHsiAUF2VFXNb42wHb+R1azGiSbU 5BQsmW0iUq3u51IYqNc9yz0YIv/vEHjTZG1u8lL5nbsK3wOzwHBrgAKbFEhVKnP61vk3 eelA== X-Received: by 10.180.75.110 with SMTP id b14mr22397695wiw.21.1362525774363; Tue, 05 Mar 2013 15:22:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.28.201 with HTTP; Tue, 5 Mar 2013 15:22:14 -0800 (PST) In-Reply-To: References: From: Edward Crabbe Date: Tue, 5 Mar 2013 15:22:14 -0800 Message-ID: To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=f46d043be228c7573e04d735c06e X-Gm-Message-State: ALoCoQmxlNOTzGlwUINzceqBahDGQvoHYovpuLCMnEqsaH6/pusI/TYB6MUOno9SU8zHTPaxpi2T96Qukk8EvxlZa3bqT726xbSQ9iEh8TN3oUb40LUedivxPQ4VJnihOoije3th2DjDuuhvdl5bDBne3UD+PiKKT6213J3SvuEDNpQZ6myfANh7eahpTNdr+EBbPUNxz5VA Subject: Re: [i2rs] IETF 86 I2RS Agenda X-BeenThere: i2rs@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, 05 Mar 2013 23:22:56 -0000 --f46d043be228c7573e04d735c06e Content-Type: text/plain; charset=ISO-8859-1 Hello all; An updated version of the agenda has been posted at: https://datatracker.ietf.org/meeting/86/agenda/i2rs/ best, -ed On Fri, Feb 22, 2013 at 4:49 PM, Edward Crabbe wrote: > Hello all; > > The first portion of the agenda for the our upcoming working group meeting > in Florida has been posted at: > > https://datatracker.ietf.org/meeting/86/agenda/i2rs/ > > As this is the first official meeting of the working group, we will be > spending some time on charter, goals and introductory material. We've > reserved an hour for draft presentations. > > Please let Alia and I know by Feb 25th if you would like to have a time > slot at the WG meeting. > > best, > Ed and Alia > --f46d043be228c7573e04d735c06e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all;

An updated version of = the agenda has been posted at:



<= /div>
best,
=A0 -= ed

On Fri, Feb 22, 2013 at 4:49 PM, Edwar= d Crabbe <edc@google.com> wrote:
Hello all;

The first po= rtion of the agenda for the our upcoming working group meeting in Florida h= as been posted at:


As this is the first official meeting of the working group, we w= ill be spending some time on charter, goals and introductory material. =A0W= e've reserved an hour for draft presentations. =A0

Ple= ase let Alia and I know by Feb 25th if you would like to have a time= slot=A0at the=A0WG meeting.

best,
Ed and A= lia

--f46d043be228c7573e04d735c06e-- From akatlas@juniper.net Wed Mar 6 06:57:28 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8D621F8A3E for ; Wed, 6 Mar 2013 06:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 ntzCu-ixRof4 for ; Wed, 6 Mar 2013 06:57:24 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id BD73121F897F for ; Wed, 6 Mar 2013 06:57:23 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUTdZU7thtdv61cUPRE60zMTMR66UrTnA@postini.com; Wed, 06 Mar 2013 06:57:23 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Mar 2013 06:52:12 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 6 Mar 2013 06:52:11 -0800 Received: from TX2EHSOBE001.bigfish.com (65.55.88.14) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 6 Mar 2013 07:01:24 -0800 Received: from mail212-tx2-R.bigfish.com (10.9.14.227) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Mar 2013 14:51:56 +0000 Received: from mail212-tx2 (localhost [127.0.0.1]) by mail212-tx2-R.bigfish.com (Postfix) with ESMTP id B300990025A for ; Wed, 6 Mar 2013 14:51:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zzc85fhd799hzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dh18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail212-tx2 (localhost.localdomain [127.0.0.1]) by mail212-tx2 (MessageSwitch) id 1362581468159630_1758; Wed, 6 Mar 2013 14:51:08 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.236]) by mail212-tx2.bigfish.com (Postfix) with ESMTP id D7ECCB00085 for ; Wed, 6 Mar 2013 14:50:53 +0000 (UTC) Received: from BY2PRD0510HT001.namprd05.prod.outlook.com (157.56.236.101) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 6 Mar 2013 14:50:51 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.83]) by BY2PRD0510HT001.namprd05.prod.outlook.com ([10.255.84.36]) with mapi id 14.16.0275.006; Wed, 6 Mar 2013 14:50:51 +0000 From: Alia Atlas To: "i2rs@ietf.org" Thread-Topic: Functional Analysis of I2RS Thread-Index: AQHOGnn+k429oeElm0eCnjtVNnFO1A== Date: Wed, 6 Mar 2013 14:50:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_D1CF735B7C7B744582438550F826E01B2D3A2F0DBY2PRD0510MB389_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [i2rs] Functional Analysis of I2RS X-BeenThere: i2rs@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, 06 Mar 2013 14:57:28 -0000 --_000_D1CF735B7C7B744582438550F826E01B2D3A2F0DBY2PRD0510MB389_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As you may have seen from the planned I2RS agenda, Ed and I are planning on= having two significant discussions during the WG. These are to help deve= lop ideas and consensus around what types of use-cases we have (or need) an= d around what types of functionality (new or new combinations) that is need= ed to support those use-cases. We have a deadline of THIS JULY to publish a high-level architecture. I ex= pect that the discussion of the functional analysis of i2rs will drive what= belongs in that architecture. Please come to the meeting with your though= ts, ideas, and concerns well thought through so we can have a very producti= ve meeting. Towards that end, I am including in this email a list of the features whose= combination I believe are driving the various new use-cases. These featur= es come from the following drafts and I would strongly encourage everyone w= ho is participating in the discussion to READ them beforehand, since the fe= ature description given is, of necessity, merely a short-hand that lacks th= e details in the drafts. Note that the drafts may, of course, have differ= ences between them. The drafts are: http://tools.ietf.org/id/draft-ward-i2rs-framework-00.txt http://tools.ietf.org/id/draft-atlas-i2rs-policy-framework-00.txt http://tools.ietf.org/html/draft-rfernando-irs-framework-requirement The list of features I am sending is a first pass. I might have missed som= e that are in the drafts. I may not have included one that you think is ne= eded (whether in the drafts or not). Please bring those up. At the end of= discussions, we hope to have a list of agreed upon new functionality - AND= pointers to the use-cases that explain why and how they are needed. The = use-cases should be specific cases of those in the charter (though for futu= re-thinking arguments sake, key new features could also be discussed). So - here's what I see as new features or combinations. 1. Support multi-headed control. This drives (at least) three sub-fe= atures. a. I2RS agent-based arbitration: I2RS uses policy associated with cl= ients/roles to determine which state to install. Policy need not just be l= ast-to-arrive (as with CLI/NetConf). This gives a way to handle/resolve co= nflicts when multiple clients touch the same configuration. b. Client Ownership: Written state is tracked by client who installed= it (or owns it). This determines which client can delete it and, for some= cases, indicates which client can modify it (for example, a sub-tree with = multiple attributes) versus simply delete/replace it. c. Notifications when written state changes: An application can lear= n when its written state is overwritten by another client. d. Optionally garbage collect ephemeral state when that client goes aw= ay. e. RELATED USE-CASES: i. CLI = writes something and an i2rs client wants to write the same data or vice ve= rsa. ii. 2 cli= ents want to use ACLs to direct the same traffic-flow (one client policy-ro= utes large flows and the second client identifies suspicious flows and dire= cts them to a DoS mitigation box) - described in draft-atlas-i2rs-policy-fr= amework-00.txt 2. Filtered thresholded subscriptions for notifications: Network App= lications use notifications to learn about the network in a push model that= can be more responsive and scale better than a pull model. Such events m= ight be everything from a link over a particular threshold to a next-hop ch= anging on a route of interest to a route being successfully installed into = the forwarding plane. 3. Different Operation Models: a. Persistence: permanent survives reboots & ephemeral doesn't b. Start-time modes - immediate/temporal/triggered c. State Expiration - unbounded or temporal 4. Standard data-models for read/write: some may already be in progre= ss in netmod (if YANG ends up being the selected data-modeling language) a. RIB interactions: static routes, redistribution to other protocol= s, varying admin-distance, etc. b. BGP policy c. IGP local policy: local link metrics, attached prefixes, etc. d. PIM local policy: local listeners, etc e. topology f. Etc - based on use-cases: framework suggests a number of differen= t areas 5. Client limited authorization: Network applications have limited a= uthorization to both read and write based upon role. In particular, for to= pology, a client should be able to learn a subset of topology and not need = very high trust/testing to learn. (e.g. IGPs may provide active topology, = but peers must be trusted & tested not to add in or modify data owned by ot= her network elements). 6. Expose topology at different abstraction layers a. Service topologies (i.e. points of presence and connections) b. VPN topologies c. Potential/previously active links? 7. Multiple transport sessions: Allows multiple senders and receivers= on the network element and on the client side. Allows different levels of= encryption, replay, etc. as appropriate for the data exchange. a. USE-CASE: Sending lots of notifications (statistics, analytics) f= rom line-cards directly. 8. Client has ability to prioritize its own operations: This supports= ASAP vs. in-flight on a single transport channel as well as providing an a= id for sending operations on multiple channels. 9. Role-based Client Identity not tied to a transport : A single net= work application can be distributed across multiple devices and for recover= y, it's important for an application to identify as a particular client, ev= en with a different IP address, different TCP session, etc. 10. Speed of programmatic interface - ability to react to operations in s= ub-second times. Fast is hard to tie down to a particular feature, but it= clearly plays a role in what kinds of use-cases are possible. Any suggest= ions on how to better describe this would be useful. Other functionality that isn't "new" but we do need to decide upon are gene= rally things like: i. Atomic operations: All the data sent to be read or w= ritten in a single operation is done only if all parts can be done (i.e. wr= itten). This may have size limitations to be discussed. It's not quite a = full transaction model, where a client can send multiple operations and an = explicit done. Exact details of what this means need to be specified. ii. Read Locks/Claiming Ownership: For data that can be = written, a client may need to take ownership to prevent that data from bein= g changed (by a lower precedence client). An example would be where a clie= nt makes a decision to write X based on a piece of data being Y (classic re= ad and increment by multiple writers). iii. Rollback or expiring an operation: Is rollback done = by the client (my assumption)? When an operation expires, does the state g= o back to either the default or the next highest client's stored operation = (which might be CLI)? Please think and then jump in and start talking! Regards, Alia --_000_D1CF735B7C7B744582438550F826E01B2D3A2F0DBY2PRD0510MB389_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As you may have seen from the planned I2RS agenda, E= d and I are planning on having two significant discussions during the WG.&n= bsp;  These are to help develop ideas and consensus around what types = of use-cases we have (or need) and around what types of functionality (new or new combinations) that is needed to support= those use-cases.

 

We have a deadline of THIS JULY to publish a high-le= vel architecture.  I expect that the discussion of the functional anal= ysis of i2rs will drive what belongs in that architecture.  Please com= e to the meeting with your thoughts, ideas, and concerns well thought through so we can have a very productive meeting= .

 

Towards that end, I am including in this email a lis= t of the features whose combination I believe are driving the various new u= se-cases.  These features come from the following drafts and I would s= trongly encourage everyone who is participating in the discussion to READ them beforehand, since the feature description g= iven is, of necessity, merely a short-hand that lacks the details in the dr= afts.   Note that the drafts may, of course, have differences bet= ween them.  The drafts are:

 

http://tools.ietf.org/id/draft= -ward-i2rs-framework-00.txt

http://tools.ietf.org/= id/draft-atlas-i2rs-policy-framework-00.txt

http://tools.ietf.o= rg/html/draft-rfernando-irs-framework-requirement

 

The list of features I am sending is a first pass.&n= bsp; I might have missed some that are in the drafts.  I may not have = included one that you think is needed (whether in the drafts or not). = Please bring those up.  At the end of discussions, we hope to have a list of agreed upon new functionality – AND pointe= rs to the use-cases that explain why and how they are needed.   T= he use-cases should be specific cases of those in the charter (though for f= uture-thinking arguments sake, key new features could also be discussed).

 

So – here’s what I see as new features o= r combinations.

 

1.     &= nbsp; Support multi-headed control.  This drives (at= least) three sub-features.

a.       I2RS agent-based arbitration:  I2RS uses polic= y associated with clients/roles to determine which state to install.  = Policy need not just be last-to-arrive (as with CLI/NetConf).  This gi= ves a way to handle/resolve conflicts when multiple clients touch the same configuration.

b.      Client Ownership:  Written state is tracked by= client who installed it (or owns it).  This determines which client c= an delete it and, for some cases, indicates which client can modify it (for= example, a sub-tree with multiple attributes) versus simply delete/replace it.

c.       Notifications when written state changes:  An = application can learn when its written state is overwritten by another clie= nt.

d.      Optionally garbage collect ephemeral state when tha= t client goes away.

e.        RELATED USE-CASES:  

       =             &nb= sp;            =             &nb= sp;            =       i.  = ;    CLI writes something and an i2r= s client wants to write the same data or vice versa.

       =             &nb= sp;            =             &nb= sp;            =     ii. &nbs= p;    2 clients want to use ACLs to = direct the same traffic-flow (one client policy-routes large flows and the = second client identifies suspicious flows and directs them to a DoS mitigat= ion box) – described in draft-atlas-i2rs-policy-framework-00.txt

2.     &= nbsp; Filtered thresholded subscriptions for notification= s:  Network Applications use notifications to learn about the network = in a push model that can be more responsive and scale better than a pull mo= del.   Such events might be everything from a link over a particular threshold to a next-hop changing on a route = of interest to a route being successfully installed into the forwarding pla= ne.

3.     &= nbsp; Different Operation Models:

a.       Persistence:  permanent survives reboots = & ephemeral doesn’t

b.      Start-time modes – immediate/temporal/trigger= ed

c.       State Expiration – unbounded or temporal=

4.     &= nbsp; Standard data-models for read/write: some may alrea= dy be in progress in netmod (if YANG ends up being the selected data-modeli= ng language)

a.       RIB interactions:  static routes, redistributi= on to other protocols, varying admin-distance, etc.

b.      BGP policy

c.       IGP local policy:  local link metrics, attache= d prefixes, etc.

d.      PIM local policy: local listeners, etc

e.      topology 

f.      &nbs= p; Etc – based on use-cases: framework suggests = a number of different areas

5.     &= nbsp; Client limited authorization:  Network applica= tions have limited authorization to both read and write based upon role.&nb= sp; In particular, for topology, a client should be able to learn a subset = of topology and not need very high trust/testing to learn.  (e.g. IGPs may provide active topology, but peers must be = trusted & tested not to add in or modify data owned by other network el= ements).

6.     &= nbsp; Expose topology at different abstraction layers

a.       Service topologies (i.e. points of presence and con= nections)

b.      VPN topologies

c.       Potential/previously active links?

7.     &= nbsp; Multiple transport sessions: Allows multiple sender= s and receivers on the network element and on the client side.  Allows= different levels of encryption, replay, etc. as appropriate for the data e= xchange.

a.       USE-CASE:  Sending lots of notifications (stat= istics, analytics) from line-cards directly.

8.     &= nbsp; Client has ability to prioritize its own operations= : This supports ASAP vs. in-flight on a single transport channel as well as= providing an aid for sending operations on multiple channels.

9.     &= nbsp; Role-based Client Identity not tied to a transport = :  A single network application can be distributed across multiple dev= ices and for recovery, it’s important for an application to identify = as a particular client, even with a different IP address, different TCP session, etc.

10.   Speed of programmatic interface – ability to = react to operations in sub-second times. = ;  Fast is hard to tie down to a particular feature, but it clear= ly plays a role in what kinds of use-cases are possible.  Any suggesti= ons on how to better describe this would be useful.

 

Other functionality that isn’t “new̶= 1; but we do need to decide upon are generally things like:

       =   i.  = ;          Atomic operations: All the data sent to be read or written in a single= operation is done only if all parts can be done (i.e. written).  This= may have size limitations to be discussed.  It’s not quite a full transaction model, where a= client can send multiple operations and an explicit done.   Exac= t details of what this means need to be specified.

       ii. &nbs= p;          Read Locks/Claiming Ownership:  For data that can be written, a = client may need to take ownership to prevent that data from being changed (= by a lower precedence client).  An example would be where a client makes a decision to write X based on a = piece of data being Y (classic read and increment by multiple writers).

      iii. &nb= sp;          Rollback or expiring an operation:  Is rollback done by the cli= ent (my assumption)?  When an operation expires, does the state go bac= k to either the default or the next highest client’s stored operation (which might be CLI)?

 

Please think and then jump in and start talking!

 

Regards,

Alia

--_000_D1CF735B7C7B744582438550F826E01B2D3A2F0DBY2PRD0510MB389_-- From swhyte@google.com Wed Mar 6 17:22:09 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FA921F84CD for ; Wed, 6 Mar 2013 17:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.978 X-Spam-Level: X-Spam-Status: No, score=-99.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_43=1, J_BACKHAIR_47=1, NO_RELAYS=-0.001, 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 3+xDlo1X-4jt for ; Wed, 6 Mar 2013 17:22:00 -0800 (PST) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBC921F84A9 for ; Wed, 6 Mar 2013 17:21:56 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id u20so7877817iag.19 for ; Wed, 06 Mar 2013 17:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=g4Q4lWmVA3q+foxG9NdPrFP2OpG2jnHjTvr1woInZm8=; b=iuSJ9mrLdSJKVKfqfdBBL7l1FI+asMz6PI9jOLSLE2qaAFRiiHtrazo+DMb4N9b8rl 5siTq5ryYHbPK4TMlC0oqQrDqtuFEmiRyh0AD6RlvGHc2vWhasGooxdw/KUQrgOC6nZJ /itV4gEiXKkpbVrXxDYDfzkdw2bRBSZbUAi3yeG85HJI7jSnigDZumCXt4wAezqBJeVl a69IDm4oBr58f2D9sEcHpYHQBB/vCU0NmON7/tlqBmOB27aZtTt9Gi8dVayMhuQ9CgMN zqwpe7ziYZlg4miEyVURuXyxSR6NlLKVCYNhf4k0MoyXRlGrAykazTn39c5bfBEBAuxu GW3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=g4Q4lWmVA3q+foxG9NdPrFP2OpG2jnHjTvr1woInZm8=; b=ojfP3JmaxFwgtBQg1e5y/KAbekyCAxUYA6CpHYgBO26y9wrsYCY+qXoRkbU2GAs0Ky KIqWUnMIBX6d1YHmHjg6ZtUA9hopUKkA/FJHOwFjrbzq6LAjVgs/35q4Eqr9RkSOHaPM PhZ03GJwGxewYj7g27l6OWX1XHiBxm0U/X+7as8FF/ADO/gUnQ3M5THGdSNcuN7RCt23 kERrXidHoa+ZQAF99Qzip8mae8auWBNxx/tGexGtRUh7pDLWyOxgpzXFj76mwkFiPyC5 sR3U2KBPsGYWcXwiWlQ7J5/WfFyNhSSMZIkBHJMqeE1U+1NwgZu367rWxORCk1MbK6c0 CuMg== MIME-Version: 1.0 X-Received: by 10.50.184.132 with SMTP id eu4mr12856796igc.19.1362619315670; Wed, 06 Mar 2013 17:21:55 -0800 (PST) Received: by 10.43.46.129 with HTTP; Wed, 6 Mar 2013 17:21:55 -0800 (PST) In-Reply-To: <5130F157.2070301@riw.us> References: <512BECC0.3020306@riw.us> <512CFF4E.6060400@riw.us> <512D24C3.2000306@riw.us> <23F95046-D50F-4835-ABAF-3C8CD3F47A9F@castlepoint.net> <5130F157.2070301@riw.us> Date: Wed, 6 Mar 2013 17:21:55 -0800 Message-ID: From: Scott Whyte To: Russ White Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQn72RaT+f4NIFX3l02w0rjBmUzRwPF/5jSyvNuMzfxo1tbE2G32NC4A6hJ45a9A0gEZi7D84RnBAGlvYaBpjw+XlQl/n6ck+1oXU/D53ijJ4NN8eak0mFe1PEZqePo7vcwIvmwNmFkW6dw4U0JdqI/IpQyneEo5VINsz+dFBmS5JLfeTZ+EIAiwSPfURGQ+FMbqgqWa Cc: Shane Amante , "Rob \(William\) Rice" , "i2rs@ietf.org" Subject: Re: [i2rs] Router Models X-BeenThere: i2rs@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: Thu, 07 Mar 2013 01:22:09 -0000 On Fri, Mar 1, 2013 at 10:20 AM, Russ White wrote: > >> I would hope more folks in the WG want that too. :-) >> >> On a more general note ... first, thanks for putting this diagram >> together. At least now we have a decent picture to start a >> discussion. >> >> I think you've mostly (?) been focused on routes being received by >> and processed by a router that, ultimately, are distilled into a >> FIB. That's certainly important, but I think that we also need to >> look in the other direction, namely: routes that get /exported/ from >> one, or more, routers into an IGP or BGP. > >> a) >> placement of aggregate/tie-down/summarization/flow-spec routes, (at >> certain routers at certain places in the topology); > > I would think of this as inserting information through the normal > peering process, or through a "static route," (which is just another > routing process) + the policy needed to import/redistribute that route > into BGP. So, assuming B in the diagram is bidirectional, setting up the > policy for what the routing process receives from the RIB as well as > what the routing process presents to the RIB. > >> b) "route >> filters" applied to, for example, eBGP neighbor sessions inbound & >> outbound > > This is where I think the diagram needs another "policy cloud," showing > a policy insertion point between "Peering" and the "local database." > >> Taking a look at (b) and looking at your diagram, it seems as though >> (b) should be within the boxes you have labelled "Routing Process". >> More specifically, I think you need more "clouds" ;-) sitting >> directly above the "Local Database" (Loc-RIB?) that, at a minimum, >> represent protocol adjacencies (e.g.: BGP neighbor adjacencies) >> where I2RS _should_ be allowed to apply (BGP) policy to those >> routing protocol sessions, in order to permit filtering of _and_ >> manipulation of attributes in those routes inbound to or outbound >> from the routing protocol process, (just like we do in today's >> networks). I would think that this additional cloud would represent >> something like the Adj-RIB-In/Adj-RIB-Out, at least wrt a BGP Routing >> Process. > > Yep. > >> In summary, although I think you chose your words carefully when >> describing "A" by proposing that I2RS avoid (forbid?) "direct >> injection of information [in]to a routing process", I think there's >> an important point we should not miss here. Namely, I2RS can do >> that, but only _when_ I2RS informs the routing process, which then > > Or rather when I2RS uses the "normal, front door," APIs provided by the > routing process to interact with those local databases. What we don't > want is the ability to inject a route into the BGP table that just > overwrites other routes, no matter what other policy might be > implemented within the BGP process itself. I guess I'm having a hard time following all this. If you move the routing process policy cloud and "B" (bidirectional now) up between the peering and local database, similar to what you said above, you'd get this clean front-door requirement for I2RS<->routing protocol interactions, and I2RS<->RIB interactions would remain at "C". What am I missing? -Scott > > I expect there will always be some way to say, "this route must win," > such as weight in IOS, or admin distance, but we don't want to bypass > these sorts of things, we want to work with them. > >> [2] While we're here, I'm not sure where (if it all) you intended >> for routing protocol redistribution to be illustrated in your >> diagram. Given that different vendors have vastly different >> models/ideas of how this is accomplished in their code, I'm not sure >> such a thing is even practical or possible. :-( > > See above, about the bidirectional nature of B in the diagram... I think > that would cover the redistribution case. You might have to include D, > as shown, in the process of redistribution as well (for instance, > redistribution in a particular implementation might be a push from the > RIB process to each impacted routing process --so we need to account for > both push and pull models here). > > :-) > > Russ > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- panem et circenses - a winning strategy for over 2000 years! From akatlas@gmail.com Sun Mar 10 13:01:13 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD9521F8949 for ; Sun, 10 Mar 2013 13:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 RkB1m+tRGzAO for ; Sun, 10 Mar 2013 13:01:12 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD8D21F8945 for ; Sun, 10 Mar 2013 13:01:05 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id c13so3889247ieb.37 for ; Sun, 10 Mar 2013 13:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Q0O3EWmDlQfNb0I2aOmFAzbPBmDPqSSYpVEeIMd9SDM=; b=s8jPRv9c4Ionw+IgDJgy095ZLYIuv8mH//k/4RJ7alLZXIm1lVUp1b4ffConqcCmH+ gH4muHT39nRUODHrUYIohVpAqUuSbA7mCwprsf2pc26dRl1OqHS9kkfv8Mdz/tH5/WL7 iQUuT+mXMPJuLAfyA3nL1sOfuoVGnzUzVGVTE4McRIRT8gLvVKaB+Z/6zeOMeHGrpof3 OM8imSydODMmAlSQr6867Vni598C15WOyMiIOwC5saPj689Vv/OI6piqt3Nl+gOYw9br 8pw9H9RRlk8qXnwmjPt1HR9y1SUiEL4iIgA6Q13+t9hipBGAP5Dly2eH4THc/rVLTIDF jQXg== MIME-Version: 1.0 X-Received: by 10.50.191.133 with SMTP id gy5mr5455189igc.50.1362945665005; Sun, 10 Mar 2013 13:01:05 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Sun, 10 Mar 2013 13:01:04 -0700 (PDT) Date: Sun, 10 Mar 2013 16:01:04 -0400 Message-ID: From: Alia Atlas To: i2rs@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [i2rs] remote participation and meetecho X-BeenThere: i2rs@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, 10 Mar 2013 20:01:13 -0000 We have a meetecho session set-up for our meeting; the tutorial about how to use meetecho is at: http://ietf86.conf.meetecho.com/index.php/Tutorials Sue Hares has volunteered to take minutes via Etherpad. A jabber scribe and another minute-taker would be quite useful. I'm hoping for good conversations... Alia From shane@castlepoint.net Mon Mar 11 04:58:19 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8658621F89D3 for ; Mon, 11 Mar 2013 04:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 AolJB9aginiB for ; Mon, 11 Mar 2013 04:58:19 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 03FB121F89C0 for ; Mon, 11 Mar 2013 04:58:18 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 892F9300077 for ; Mon, 11 Mar 2013 11:58:18 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 4A08F300074 for ; Mon, 11 Mar 2013 05:58:18 -0600 (MDT) From: Shane Amante Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Mar 2013 05:58:17 -0600 References: <20130311115446.23224.52847.idtracker@ietfa.amsl.com> To: "i2rs@ietf.org" Message-Id: <1D366F7E-7D44-4B88-8484-8A1B267836B1@castlepoint.net> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Mar 11 05:58:18 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 513dc6da42073697110682 X-DSPAM-Factors: 27, typically+#+#+#+of, 0.40000, Reply+#+internet, 0.40000, Drafts+#+#+available, 0.40000, on+#+#+#+directories, 0.40000, name+#+#+#+message, 0.40000, Filename+#+#+i2rs, 0.40000, Shane+#+Filename, 0.40000, operation+#+#+BGP, 0.40000, solution+draft, 0.40000, control+#+#+diagnose, 0.40000, Programmatic+#+as, 0.40000, Interface+#+or, 0.40000, NETCONF+These, 0.40000, to+#+the, 0.40000, to+#+the, 0.40000, Url*org/shadow, 0.40000, https+Internet, 0.40000, for+#+#+is, 0.40000, describes+#+of, 0.40000, the+#+#+#+shane, 0.40000, configuration+#+#+parameters, 0.40000, network+routing, 0.40000, shane+#+#+message, 0.40000, I+#+#+#+framework, 0.40000, as+defined, 0.40000, protocol+I2RS, 0.40000, i+#+announce, 0.40000 Subject: [i2rs] Fwd: I-D Action: draft-keyupate-i2rs-bgp-usecases-00.txt X-BeenThere: i2rs@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, 11 Mar 2013 11:58:19 -0000 FYI. We've updated this draft to reflect the I2RS WG name. -shane Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-keyupate-i2rs-bgp-usecases-00.txt > Date: March 11, 2013 5:54:46 AM MDT > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Use Cases for an Interface to BGP Protocol > Author(s) : Keyur Patel > Rex Fernando > Hannes Gredler > Shane Amante > Filename : draft-keyupate-i2rs-bgp-usecases-00.txt > Pages : 15 > Date : 2013-03-11 >=20 > Abstract: > A network routing protocol like BGP is typically configured and > results of its operation are analyzed through some form of Command > Line Interface (CLI) or NETCONF. These interactions to control BGP > and diagnose its operation encompass: configuration of protocol > parameters, display of protocol data, setting of certain protocol > state and debugging of the protocol. >=20 > Interface to the Routing System's (I2RS) Programmatic interfaces, as > defined in [I-D.ward-i2rs-framework], provides an alternate way to > control the configuration and diagnose the operation of the BGP > protocol. I2RS may be used for the configuration, manipulation, > polling or analyzing protocol data. This document describes set of > use cases for which I2RS can be used for BGP protocol. It is > intended to provide a base for the solution draft describing a set = of > interfaces to the BGP protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From edc@google.com Tue Mar 12 13:38:24 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9227C11E810F for ; Tue, 12 Mar 2013 13:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.535 X-Spam-Level: X-Spam-Status: No, score=-101.535 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 qcguzo0JQadl for ; Tue, 12 Mar 2013 13:38:24 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id F161E11E8100 for ; Tue, 12 Mar 2013 13:38:23 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t11so299518wey.0 for ; Tue, 12 Mar 2013 13:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=HxByyTUPKwE2OKEuusPx2HnkSLMD9HhkzIxy5b12cQ0=; b=ihaxdg/BT52UraiiNYDxa8gvKry4/tFcFKqN7n7Z4kvnA67/MHlrizFQafZjYBT+q/ NkocKGBtLSr1jcEjGFo0TFuXE01jmozTm9AuNAeckSU5D4JCxKe4OxAERu1SziemlaPY arU7F3R0q6i0MXZtMZB7UZWiLjq6a0C52xjNqE2hfGuVupgnvpU7A4ZuoYaajDV+m5gw hJ5Y+Vdjm4lRS6tjUFytiRFeJy79k6aanZpSRqzqNJzjXTxogsNWaocNMJVi54FVt36i 00ZnanPVjneTWI1UjV1bJ/syV+p8hUZK3ROIhasHuntxZWmr9hmBXMlLg7bkTny5y+d1 C/og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=HxByyTUPKwE2OKEuusPx2HnkSLMD9HhkzIxy5b12cQ0=; b=JKvSPAacCs9KKEZQIf8K3bC19iSTjRLvwWwncSppOY8daaLSRq9EZOP88Htb7Erzk8 f1sLWIAglX+JRcmtTkB/iHwzucW4I5EhHW40+AWQ/1Oora25Q2ltJX+IrUUBHhmsH7yx jpO/Aa6GATIk2/M8ldcyCdybtgdkMKpbw9vXWtOHBR+mlAM0e2OVozxDp3OtwCA50HUE a2O0E+gDdoYgnvti1NtaKPmpJ176Q0I8BL7OkbrKVxEsJzYtXkwx1dJZm4XMZiMHu4AU ZjBuUnmdEbYD+mpeiyMM4Wo+M/ZNxO/vdO9r/CMlD6KTkhibSC6kZnzmnUI51mabKy9z xf2g== X-Received: by 10.181.12.5 with SMTP id em5mr22530048wid.24.1363120703174; Tue, 12 Mar 2013 13:38:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.83.195 with HTTP; Tue, 12 Mar 2013 13:37:43 -0700 (PDT) From: Edward Crabbe Date: Tue, 12 Mar 2013 13:37:43 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7c584c95a304d7c04559 X-Gm-Message-State: ALoCoQnyfwfkvzGkv7YiHCzYw0xirBrFnURzP5tLyT8J+tkKc76LGTLEoUSs5y4zlZBfC3Jfr7Y8Do7Oma5YbmkJjpjHDpmQ+Wz/R3P6IbarCaNYT58dYv8Po5idRRlvgNorF5NINGd/iDc7dNKiKdI6nIKG/V+QKlAtP9pfKPVu03U7FgHbXDdLDCmOE+krzQkQmg8trxPe Subject: [i2rs] presentation slides X-BeenThere: i2rs@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, 12 Mar 2013 20:38:24 -0000 --f46d043c7c584c95a304d7c04559 Content-Type: text/plain; charset=ISO-8859-1 Hey all; If you haven't gotten me your slide decks for Thursday's working group meeting, could you please do so ASAP. Thanks very much, -ed --f46d043c7c584c95a304d7c04559 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey all;

If you haven't gotte= n me your slide decks for Thursday's working group meeting, could you p= lease do so ASAP. =A0

Thanks very much= ,

=A0 =A0-ed=A0
--f46d043c7c584c95a304d7c04559-- From ietf@meetecho.com Wed Mar 13 16:31:50 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C3C11E8168 for ; Wed, 13 Mar 2013 16:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 sRmVs89NXeYO for ; Wed, 13 Mar 2013 16:31:50 -0700 (PDT) Received: from smtpdg7.aruba.it (smtpdg3.aruba.it [62.149.158.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0792E11E810D for ; Wed, 13 Mar 2013 16:31:49 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd03.ad.aruba.it with bizsmtp id BBXm1l00J2w8SR601BXotP; Thu, 14 Mar 2013 00:31:48 +0100 Date: Wed, 13 Mar 2013 19:31:44 -0400 (EDT) From: Meetecho Team To: i2rs@ietf.org Message-ID: <2707298.17.1363217504256.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_16_13579577.1363217504254" X-Mailman-Approved-At: Wed, 13 Mar 2013 20:31:44 -0700 Subject: [i2rs] Meetecho support for I2RS session X-BeenThere: i2rs@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, 13 Mar 2013 23:31:50 -0000 ------=_Part_16_13579577.1363217504254 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, a virtual room has been reserved on the Meetecho system for the I2RS WG meeting session. Access to the on-line session (including audio and video streams) will be made available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/i2rs The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_16_13579577.1363217504254-- From rraszuk@gmail.com Thu Mar 14 07:13:38 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8686521F8CC5 for ; Thu, 14 Mar 2013 07:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 aHlIGRGfbHmw for ; Thu, 14 Mar 2013 07:13:37 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9114211E817F for ; Thu, 14 Mar 2013 07:13:28 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id y26so706425iab.23 for ; Thu, 14 Mar 2013 07:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=Lgq/qnhvqiVKGdTIfDxaXq1vUmUcVQJdMTIN8lN0WU4=; b=aLq82ZgRQfIAtVTMPqh41/EILbIOrcK5ly8aAjGML5Zr2jrWoQ5VoMnokeJfIWxI6A ztCXG9jAaNoKyyV5PjvEEEjCyY7k94qkWpLV+3YO2nsnMgRqFgIUgzVIB26Mm5Sgvlz7 ShuYpn7/BDog+vvdRiHXpPXmalM9/PEBjmr9htLnryXic5u7Nqs0KXTwvwAR9+GOpmJB zBqTk9tZDn8JBcSktFFML8gXXvlIUTXS8J5hIOtwkChlYm59l4Y2ph/c64EA7vL1IZ8Z 5dLr71PCxT+sOS6x7/v61vvHaf1iLlAplog+V+l1bc0dw+U5aqDIp3uu2LmMhXzAisYw APgw== MIME-Version: 1.0 X-Received: by 10.50.178.36 with SMTP id cv4mr2314362igc.98.1363270408173; Thu, 14 Mar 2013 07:13:28 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 07:13:27 -0700 (PDT) Date: Thu, 14 Mar 2013 15:13:27 +0100 X-Google-Sender-Auth: jvfHsDt-t9YmlErD4R89VjCz44c Message-ID: From: Robert Raszuk To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:13:38 -0000 Hi, As we have seen today I2RS is scoped to interface with RIB. Great. But what is the precise definition of RIB here ? Are we talking about currently known RIBs or is the RIB definition yet to be defined. I think it should be something defined now as pretty much all other work will depend on it. I bet everyone in the room has different opinion on it ;) Example: Assume I have invented a routing protocol which routes based on tuple of dst IP address + port number. (Latency sensitive applications go on different links that non time sensitive ones). Is I2RS effort going to help me to push such routing data to the box's RIB or not ? Note that I am not talking about pushing bunch of ACLs to 100s of my boxes doing PBR. Thx, R. From rraszuk@gmail.com Thu Mar 14 07:13:38 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861C521F8CC2 for ; Thu, 14 Mar 2013 07:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 NFKCrviCm1pQ for ; Thu, 14 Mar 2013 07:13:37 -0700 (PDT) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 243BA11E8181 for ; Thu, 14 Mar 2013 07:13:34 -0700 (PDT) Received: by mail-ia0-f181.google.com with SMTP id u8so709897iag.26 for ; Thu, 14 Mar 2013 07:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=0BZtbkJELQ8lJtiGCWyXpsUt6wsuXkpkJtpqZc1xT4Q=; b=oqfEfCF+bJsHH+Nke05mG494QUh2ZyFsGQtL5eJGrzB2qqKzqqc24wuUU9KM3aIccl hibABKUSlxUFguMi8Sn6AG+7bW4yk1KehB3oW8qtxlicMqjpSxbK96OMQEUWrV8Tss+Y 1aJMxtsOwZKIZxBmgQxWLYCCJ8OGiFbqvt0xX11OFKJegUtRBQeW8U1T4KZl2hVh+Xf3 9KcDMyft06tbjf2G5FCQBKk15fMjNe+/7mbBBVweLudl4PyND179sATT+y+81L8goazP hWXwrLYaAAp8y6UGGMEzfgDQON3CzsiENclMme3bHeFRbdrQhYB2W0CUAw3BUsPGo7H1 obgQ== MIME-Version: 1.0 X-Received: by 10.50.190.233 with SMTP id gt9mr2274599igc.80.1363270413589; Thu, 14 Mar 2013 07:13:33 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 07:13:33 -0700 (PDT) Date: Thu, 14 Mar 2013 15:13:33 +0100 X-Google-Sender-Auth: WwgDlZOxKsKVJUAI_FiOHHziTZE Message-ID: From: Robert Raszuk To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [i2rs] Centralized vs distributed I2RS use model X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:13:38 -0000 Hi, I think I am hearing quite clearly from most of the presentations that there is sort of opinion that I2RS talks to RIBs from some form of centralized controllers/route servers/topology collectors etc ... Does this mean that I can't use I2RS in completely distributed manner without any central controller ? Note that more and more modern routers and switches gives customers x86 local compute facilities on the box. So I can easily imagine that I write a distributed application which communicates box to box at the application level and installs locally via I2RS interface it's "routes" to RIB. Is this model of operation out of scope of this WG ? Best regards, R. From lhotka@nic.cz Thu Mar 14 07:22:18 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8CC11E8133 for ; Thu, 14 Mar 2013 07:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] 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 KY8yXlCE-g-9 for ; Thu, 14 Mar 2013 07:22:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1412611E815A for ; Thu, 14 Mar 2013 07:22:06 -0700 (PDT) Received: from [IPv6:2001:df8::16:85c6:1503:5f38:692b] (unknown [IPv6:2001:df8:0:16:85c6:1503:5f38:692b]) by mail.nic.cz (Postfix) with ESMTPSA id 061A313F628; Thu, 14 Mar 2013 15:22:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1363270925; bh=hAyRHehG8mdtmPgTqCr0/+HGr4Luf2Qt0cxIPyPZkTo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=YjtDVQ4A2zaqHwH1Sv2cXSq+Lt27qBnKZNNqsQR+OGR8w2gNVeEjiWR55QAABszxU bCduEUK3uVRQN7H6ciynldxx7eFExqGcRhlYvlCHsPacKLP4VH25kNGbmf8urDJpG6 3xaB/5y5hCeRn/FsUjOsKio3HTrBbDJk2f7BmRYk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 14 Mar 2013 10:22:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Robert Raszuk X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:22:18 -0000 On Mar 14, 2013, at 10:13 AM, Robert Raszuk wrote: > Hi, >=20 > As we have seen today I2RS is scoped to interface with RIB. Great. But > what is the precise definition of RIB here ? Are we talking about I already raised pretty much the same question before: http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html I think one of the initial documents (architecture?) should include a = detailed terminology section. Lada > currently known RIBs or is the RIB definition yet to be defined. I > think it should be something defined now as pretty much all other work > will depend on it. I bet everyone in the room has different opinion on > it ;) >=20 > Example: >=20 > Assume I have invented a routing protocol which routes based on tuple > of dst IP address + port number. (Latency sensitive applications go on > different links that non time sensitive ones). >=20 > Is I2RS effort going to help me to push such routing data to the box's > RIB or not ? Note that I am not talking about pushing bunch of ACLs to > 100s of my boxes doing PBR. >=20 > Thx, > R. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From rraszuk@gmail.com Thu Mar 14 07:30:48 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B790C11E815A for ; Thu, 14 Mar 2013 07:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] 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 Yf+3HLUJEW8u for ; Thu, 14 Mar 2013 07:30:36 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 135B011E8129 for ; Thu, 14 Mar 2013 07:30:29 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 13so3132392iea.0 for ; Thu, 14 Mar 2013 07:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=a19sCH2guBl6NS2WzrkEL5JFFLg+k63XLMNbzP7jEVg=; b=gELA2NhQAgDe7CYL0HHGrO4cVuYNpX1xWB/FB+N3aMWOPXtgoBwyICwi902DUAYD8+ NxGtqbCEvcCTS5p2NiyHqCjmuowkPZXHg1INWLdmsbpnlWLlBZ4Jaqr9nToGjId6utkm keJcifHKM658QQb4XC2eLCsVuWJ2HkYLqNCs1eAhwwaXrvnWAH3NNBXOneQxfufmRG1z OLqXXnQj3ZhzvAkhIiVkitJiLQhbaaBtkM08wg1PdaZxNOpT17rsG6Ban2mlOdzxKb0x U3SPyHOAMfJymogx2lHhTxIK+XcL8SkzVy4ceUxgE7eu1y8tWJGGoZzvI90Uxd952hE0 snTQ== MIME-Version: 1.0 X-Received: by 10.43.103.195 with SMTP id dj3mr2212070icc.3.1363271428340; Thu, 14 Mar 2013 07:30:28 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 07:30:28 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Mar 2013 15:30:28 +0100 X-Google-Sender-Auth: Tfu3trAa2xL0qj7qCAXg_hfSbIE Message-ID: From: Robert Raszuk To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:30:48 -0000 Hi Ladislav, Yes I think this is a crux of this WG. I saw your mail in the past but no precise answer from anyone ;) Moreover even if one provides a RIB definition on one box today how do we make it extensible so new network applications can be deployed on it tomorrow. Worse how do we accomplish consistent RIBs being supported across multiple vendors ? Otherwise I can't see how read/write of any data can be abstracted for network wide services provisioning using I2RS. Regards, R. On Thu, Mar 14, 2013 at 3:22 PM, Ladislav Lhotka wrote: > > On Mar 14, 2013, at 10:13 AM, Robert Raszuk wrote: > >> Hi, >> >> As we have seen today I2RS is scoped to interface with RIB. Great. But >> what is the precise definition of RIB here ? Are we talking about > > I already raised pretty much the same question before: > > http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html > > I think one of the initial documents (architecture?) should include a detailed terminology section. > > Lada > >> currently known RIBs or is the RIB definition yet to be defined. I >> think it should be something defined now as pretty much all other work >> will depend on it. I bet everyone in the room has different opinion on >> it ;) >> >> Example: >> >> Assume I have invented a routing protocol which routes based on tuple >> of dst IP address + port number. (Latency sensitive applications go on >> different links that non time sensitive ones). >> >> Is I2RS effort going to help me to push such routing data to the box's >> RIB or not ? Note that I am not talking about pushing bunch of ACLs to >> 100s of my boxes doing PBR. >> >> Thx, >> R. >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From swhyte@google.com Thu Mar 14 07:32:22 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D9611E8196 for ; Thu, 14 Mar 2013 07:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 0lm92h4CbUc7 for ; Thu, 14 Mar 2013 07:32:20 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id F3AC511E80FE for ; Thu, 14 Mar 2013 07:32:15 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id uo15so2300001pbc.33 for ; Thu, 14 Mar 2013 07:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Orec3HYV1drbIfU9vfQrgf5bz2tZWQTmbAZ7uZU5ruM=; b=MMtlZXhs+OHSo/oehsNl2HX7rCTl68PE2zG/GdHh0TPDGnweuDiOtTNVRsoa7mv79w lr2HtjgKdoujKsRR5E80b1HF+3KT+FXnhbXdlIZL+ZIg/8UMD9QnJUEz77YYeRN3sbnR Ni3CtNjWEYonm9O+l/HXm/pdUcrXqie6OmKpZ5pKTcEFdTENPn2v4nbwZiMo1SIS+NF9 c8PeV/S4Kvd4ycxaTXLrXLN/3rizZPhYf92g6KlP8T16tW4eXPS+QEfcQxNzSDs02usO iora78dtYqYhENWceDwE+4n4yMtOt6uE0LoLKKg1rBLUOWmJp+MHbeVtYRBis923WUVY VLog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=Orec3HYV1drbIfU9vfQrgf5bz2tZWQTmbAZ7uZU5ruM=; b=Km3WdkQF4B9PgAMzwva3AmjH7dq83eHf6/f2jRqbtQCpsd57AUViscbo+AOCtiRohh zJZkZXlvgh9FJXYX/aZUjQdYh5VvsjDk2Lw6egWEjgMU6UUJzwL/yOqgLhJg74GqkcQo WgJIRK43mgwhsSJM5YQT0sVbwmyXSwMlOV74r03wKHRuVqWgIeAZ6as1XcAGIqo8R7/L lDHtLlcKhJI+17x+ZNZ+iLopMYBYCQjoDnVo/rnS7ZJVyRECJh9BZ7J/ukZ6thO7Em8T VwE2b6XPThX64j2zasY7Pn3rybJE8UDs+bUyyT1h3eKpO7zD5eNkQ9wiV1qrxg+1q2lO 1isw== X-Received: by 10.68.59.199 with SMTP id b7mr6360474pbr.167.1363271529053; Thu, 14 Mar 2013 07:32:09 -0700 (PDT) Received: from ?IPv6:2001:df8:0:80:8868:3fef:f5c1:8cf1? ([2001:df8:0:80:8868:3fef:f5c1:8cf1]) by mx.google.com with ESMTPS id is1sm3544073pbc.15.2013.03.14.07.32.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 07:32:08 -0700 (PDT) Message-ID: <5141DF65.6000508@google.com> Date: Thu, 14 Mar 2013 07:32:05 -0700 From: Scott Whyte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Robert Raszuk References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk3BYYUvgyf0mR6hSafMglYbB3Ge5l/YYvWHsdE0oEcU/z6rv35tXhj0ooMSqZMSnmoZ1eZIHZ74Xl5t7/eU9YNN+K4JKtbAzcPJU8fbjHFHk/YvuPIZGDmuPTse5x4dSLWfIASiMtrjEA/hzjjkueZKBzy1hmQ0RrOdD+E+ocoa77TrbBLVb1XPphTBsw2ExKFH0X9 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:32:22 -0000 On 03/14/2013 07:13 AM, Robert Raszuk wrote: > Hi, > > As we have seen today I2RS is scoped to interface with RIB. Great. But > what is the precise definition of RIB here ? Are we talking about > currently known RIBs or is the RIB definition yet to be defined. I > think it should be something defined now as pretty much all other work > will depend on it. I bet everyone in the room has different opinion on > it ;) > > Example: > > Assume I have invented a routing protocol which routes based on tuple > of dst IP address + port number. (Latency sensitive applications go on > different links that non time sensitive ones). > > Is I2RS effort going to help me to push such routing data to the box's > RIB or not ? Note that I am not talking about pushing bunch of ACLs to > 100s of my boxes doing PBR. Why do we need to go beyond defining an interface to the RIB to make your use case work? -Scott > > Thx, > R. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- People who are essentially without the power to implement their ideas in the real world must leverage the power of their reputations. From rraszuk@gmail.com Thu Mar 14 07:34:41 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722CE11E811F for ; Thu, 14 Mar 2013 07:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 uUTsyvVmEboq for ; Thu, 14 Mar 2013 07:34:41 -0700 (PDT) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E76E411E8112 for ; Thu, 14 Mar 2013 07:34:40 -0700 (PDT) Received: by mail-ia0-f175.google.com with SMTP id o25so2064450iad.34 for ; Thu, 14 Mar 2013 07:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DR8eIDQYwUWZt8RQTK3+ft+SzcUw8xRedv/t5O3Diyg=; b=Zk7OFXhyhOdylx52c3LNiEfLaVcrs/hNZmdpl0TV4ANbpHubVrZFxmzCY1rs4uKjeW I3vrXpA7Q3FS2++xlstzNp7Sge/nZ5EebogO/l1NSTiPYEdjrU7qArm/EuzborQjCM68 t/cSkzgn4/s2cpgokNVL577CWChQgvvIaG15VqiGYXbLAGwsW01UhAhL0B+Kzy933C0J jC5ohsa7rXg4Amc/hY+bi6IM+cCUSUMFe4KJ+B+wy5rm5sTfJXJ3LHxOEeiXRvJVhbDo 8cTv7Tu8GKG1StFGwans5dt1kHye89d/EV0v4EkVbizD2cgmxe2dBDP7Kqrn1ra2lyIk CVLg== MIME-Version: 1.0 X-Received: by 10.50.178.36 with SMTP id cv4mr2382788igc.98.1363271680582; Thu, 14 Mar 2013 07:34:40 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 07:34:40 -0700 (PDT) In-Reply-To: <5141DF65.6000508@google.com> References: <5141DF65.6000508@google.com> Date: Thu, 14 Mar 2013 15:34:40 +0100 X-Google-Sender-Auth: U_JUBo459Pq2d4fINIO5-82251U Message-ID: From: Robert Raszuk To: Scott Whyte Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:34:41 -0000 Hi Scott, > Why do we need to go beyond defining an interface to the RIB to make your > use case work? I am talking precise about that definition of RIB interface. Not how the RIB works in given vendor of network element. That is implementation detail. Basically a list of values one can write or read to/from RIB. Have you seen any document with such list yet ? Cheers, R. From swhyte@google.com Thu Mar 14 07:34:55 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6703411E8155 for ; Thu, 14 Mar 2013 07:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 FIVPZN7+l+2I for ; Thu, 14 Mar 2013 07:34:54 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 583EA11E8141 for ; Thu, 14 Mar 2013 07:34:43 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id uo15so2292970pbc.5 for ; Thu, 14 Mar 2013 07:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BuDJEZlBm4PoNJlkbKwF4vM14QInlf8ojYSoXmYmn/A=; b=gxFiGflbIwE7lnEHdQgC/ENJhjALHh7DbznLbyQm6VrgonPKFr1iTgI2LYb+IhW/BH oSTbZghzmDn/WNRF73uhYNdXrIpzqi6RBtwcuNe2b+iR8+apcxrlOy/+6qPXZJLFU8Po 2YGSzbTripZi/vvAAyElKJEh2U85yMsQX1mk+car4eVg4cYY3+LlPoe+W7CRAExPcC80 eEXiVyFdEJHTBrH2N99g/QxDVmv4lGiy9J7GA2uFAEzcux4VsKe6/63wn81ocDuYa3Tk Sie3764Gtu1lqyDrPeKHvgoKvCFeUvczeDmxqnMInQv1In9bLc82eVSzYXLQXvousCHj 9kfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=BuDJEZlBm4PoNJlkbKwF4vM14QInlf8ojYSoXmYmn/A=; b=dCFPbJZv89g+MI+KCjrqkC4CNMouO4VFW+FdJlCmtxygncYHuSfbE22YtV1IpM0BKh XujKwR25+LxuVk12BG+QQlRxQ9JZFl02W62Vp0q4cOgATa8kVdebmW96dhPwTVntEzwA /beso8D9UMBB3RrpA3b6eBd23BlQtdKw8LcZmJy6XvDNBSb57m/sdu9YTb3NW6T+lO0M YO5UmWsPAl70Ye6rdF26rNknjCSAP8wWHzzq3s9K9Xq24sYmPqnMDutd4jHcsfmIOsR0 0NVoeGWqCZN49e2THG6HjxlsCvawczVafu9qpklqXRauiHhdb6opTWkQT9Jcpho61j4V PTDw== X-Received: by 10.68.196.35 with SMTP id ij3mr6328009pbc.56.1363271683064; Thu, 14 Mar 2013 07:34:43 -0700 (PDT) Received: from ?IPv6:2001:df8:0:80:8868:3fef:f5c1:8cf1? ([2001:df8:0:80:8868:3fef:f5c1:8cf1]) by mx.google.com with ESMTPS id iv3sm3535008pbc.40.2013.03.14.07.34.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 07:34:41 -0700 (PDT) Message-ID: <5141DFFE.1000803@google.com> Date: Thu, 14 Mar 2013 07:34:38 -0700 From: Scott Whyte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Robert Raszuk References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk++K2Fj3AQGSkbfa9lFx4ON/MbvkdjsMIbyfEb4MkjFSRrxE0XocVOmSSt/jdNB2EbM/jWgtjFLgpt9qbZ4R+Qda39v/2/qoTlFbWRi41qvtIa+ccbefCswhGX5M0AmDP59kRY8Z+DF2X44Mh04PYzms8Q07pecglsz/v7oWmGGWD0a//bDlXyjCnhd1U0m/kEV0zg Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Centralized vs distributed I2RS use model X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:34:56 -0000 On 03/14/2013 07:13 AM, Robert Raszuk wrote: > Hi, > > I think I am hearing quite clearly from most of the presentations that > there is sort of opinion that I2RS talks to RIBs from some form of > centralized controllers/route servers/topology collectors etc ... > > Does this mean that I can't use I2RS in completely distributed manner > without any central controller ? > > Note that more and more modern routers and switches gives customers > x86 local compute facilities on the box. So I can easily imagine that > I write a distributed application which communicates box to box at the > application level and installs locally via I2RS interface it's > "routes" to RIB. > > Is this model of operation out of scope of this WG ? I think there's enough rope for you to do that and have plenty left over. -Scott > > Best regards, > R. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- People who are essentially without the power to implement their ideas in the real world must leverage the power of their reputations. From bensons@queuefull.net Thu Mar 14 07:39:12 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D533611E8196 for ; Thu, 14 Mar 2013 07:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 99uW8fugMB08 for ; Thu, 14 Mar 2013 07:38:53 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 47D7B11E8185 for ; Thu, 14 Mar 2013 07:38:51 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id p43so2212429wea.24 for ; Thu, 14 Mar 2013 07:38:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=bHYP9bQMyFaMFpiI2YEGPz8u80WPwv+Y/nWhZyYCLm4=; b=oOD0EPXjmV2QS4BEHO7auw/aL2MyS6MD3UvNRWuR8LKHTkRNv/Y5DsoqXDwA596n6k m5S2UUkWpNc49aYX4AEbi2ZqNNc5lZ5hjdBMbNGVXNf6b/r9L0o4+1ZAlcOz9Mptc0k2 OqW9jLIUSQJtyug3IeULXdQue++GF1pwxWNJzD+n9iwBmOT5Gt1zXJ8MV7GwflJG2wPe yQlnl3PggS284KbLOZuae1/qnki3E+jOLakJsQ4kfx2va2e+ix9YfKuq47XudvK+wDuj fEGUHugpqqlPkhkDSMy3SaQfPvWNtKvZuRlBzH9N/Q4XcG9Re3/QP0rOULagtaXQ2vFp Fi1g== X-Received: by 10.194.57.137 with SMTP id i9mr4667208wjq.18.1363271927100; Thu, 14 Mar 2013 07:38:47 -0700 (PDT) References: From: Benson Schliesser Mime-Version: 1.0 (1.0) In-Reply-To: Date: Thu, 14 Mar 2013 10:38:44 -0400 Message-ID: <-5935599738098279524@unknownmsgid> To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnrvi2icARQ3q6er55OkEGKDJsbDNB6OydY87TPV05rg6aEckqzbBrMr5yed3HtrLJRKB5/ Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Centralized vs distributed I2RS use model X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:39:12 -0000 I assume the chairs will speak authoritatively on scope, but my current understanding is that this topic is still up for discussion. On that topic, I'd like to point out that we have been vague about the definition of a "broker". I think we assume there is a centralized broker for each network element - because that lets us push the coordination problems (multi-personality arbitration etc) to somebody else. But we haven't explicitly talked about network-wide broker centralization, keeping the operational state in sync across multiple devices (to avoid loops and black holes), etc. Nor have we talked about whether the broker is really a single entity, or if it is distributed itself - and if that means we've really solved the problem of coordination (and sanity), or just avoided dealing with it here. I'd be interested in hearing thoughts, flames, etc about these questions. Cheers, -Benson On Mar 14, 2013, at 10:14, Robert Raszuk wrote: > Hi, > > I think I am hearing quite clearly from most of the presentations that > there is sort of opinion that I2RS talks to RIBs from some form of > centralized controllers/route servers/topology collectors etc ... > > Does this mean that I can't use I2RS in completely distributed manner > without any central controller ? > > Note that more and more modern routers and switches gives customers > x86 local compute facilities on the box. So I can easily imagine that > I write a distributed application which communicates box to box at the > application level and installs locally via I2RS interface it's > "routes" to RIB. > > Is this model of operation out of scope of this WG ? > > Best regards, > R. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From edc@google.com Thu Mar 14 07:40:10 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812A121F9058 for ; Thu, 14 Mar 2013 07:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.311 X-Spam-Level: X-Spam-Status: No, score=-100.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, 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 TvTQ4upAHtLv for ; Thu, 14 Mar 2013 07:40:05 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2732811E8199 for ; Thu, 14 Mar 2013 07:39:52 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi8so1861208wib.13 for ; Thu, 14 Mar 2013 07:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=h7Q8JsBL4DXqixhOP3XuckUCTF1TGjGjs/5zXVa3fNw=; b=Gf6kqNVIl/pEEA68nR3HQ+guJJqT53CSms8Wsa//rTATiVqdX/Ml5w25GXgVtdQu72 3DbHdUvQXWnBTH7081OrkbFMvjstN2IjM1MsH8vjQwHpmSi1c3iaWCGkAthmGswcz/Xy SmjWPTZW58PxHdt5YCpM55noebzbXRwzqd0WrADK2YmFIUqjpFZBL25qFDla1v7hGHyo Y4J6psgvSWsPVn2YzyGpoKuBVJPJxg3dPIWDK9ZVOKGr6+QzxY9B0+o8PEQNca8dUf7I obE/06Wi6Uk0Zek8/OOItnWPnqDt3Bmkp186r5jlOhuZeXUYta65Sr3gCdOtnphBydD8 H8Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=h7Q8JsBL4DXqixhOP3XuckUCTF1TGjGjs/5zXVa3fNw=; b=mzDjcjIL5SqpcSqrXeFuOMyw078eQFp9YXHgEsxD9LdBqu2GOv4OE+UJ9ZTR7uIwWE otJODGI9ZePvnSK95+Wue2jiurp7M0t2UkWQC8Qe5Tcqf9m+09Bu8tFUf7z7KZDXIB2a K7Hq7YXf+W8bzXsb+gnn6Hmwa3jSVTNi/3aj2pjMtKAgntrno5L8Vi/CbDtn4TsPJJSv jpoNublxZttu7nMdo7baWXS7N45dRrYWSgXrM4V1aAOYfUh2FzhAu/1uYDZtEtY+DE+5 j40pCz3dvpZHe7kRjMIv4tH15KrKP8yooFXuFBf4I4XcDcydQZOZtx981K8XjafTPp4k ffug== X-Received: by 10.194.158.161 with SMTP id wv1mr4615226wjb.38.1363271988296; Thu, 14 Mar 2013 07:39:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.83.195 with HTTP; Thu, 14 Mar 2013 07:39:08 -0700 (PDT) In-Reply-To: <5141DFFE.1000803@google.com> References: <5141DFFE.1000803@google.com> From: Edward Crabbe Date: Thu, 14 Mar 2013 10:39:08 -0400 Message-ID: To: Scott Whyte Content-Type: multipart/alternative; boundary=089e013c6ab09856a704d7e37e08 X-Gm-Message-State: ALoCoQkbwHKMJNfHuv9N13DOtxe1b6oxXL4qNdkc6Ak1681jTr23Zr7VRKO/jp4zbVZhIZ5rAqzGr30fKEttikHe+P0LHA1b7x5+a8uT9qqw26mRcJj9B5mxqcoEvHoaGNyrJdUGXlAGpKCmHRuPBbJQ/Mef5w30wYoZmlZyS0aB0XPq6UDBJ8zz94jkeyaAn5DUjTk547no Cc: "i2rs@ietf.org" , Robert Raszuk Subject: Re: [i2rs] Centralized vs distributed I2RS use model X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:40:17 -0000 --089e013c6ab09856a704d7e37e08 Content-Type: text/plain; charset=ISO-8859-1 +1 We have plenty of rope. ^_^ On Thu, Mar 14, 2013 at 10:34 AM, Scott Whyte wrote: > On 03/14/2013 07:13 AM, Robert Raszuk wrote: > >> Hi, >> >> I think I am hearing quite clearly from most of the presentations that >> there is sort of opinion that I2RS talks to RIBs from some form of >> centralized controllers/route servers/topology collectors etc ... >> >> Does this mean that I can't use I2RS in completely distributed manner >> without any central controller ? >> >> Note that more and more modern routers and switches gives customers >> x86 local compute facilities on the box. So I can easily imagine that >> I write a distributed application which communicates box to box at the >> application level and installs locally via I2RS interface it's >> "routes" to RIB. >> >> Is this model of operation out of scope of this WG ? >> > > I think there's enough rope for you to do that and have plenty left over. > > -Scott > > > >> Best regards, >> R. >> ______________________________**_________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/**listinfo/i2rs >> >> > > -- > People who are essentially without the power to implement their ideas in > the real world must leverage the power of their reputations. > > ______________________________**_________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/**listinfo/i2rs > --089e013c6ab09856a704d7e37e08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 =A0We have plenty of rope. ^_^ =A0


On Thu, Mar 14, 2013 at 10:3= 4 AM, Scott Whyte <swhyte@google.com> wrote:
On 03/14/2013 07:13 AM, Ro= bert Raszuk wrote:
Hi,

I think I am hearing quite clearly from most of the presentations that
there is sort of opinion that I2RS talks to RIBs from some form of
centralized controllers/route servers/topology collectors etc ...

Does this mean that I can't use I2RS in completely distributed manner without any central controller ?

Note that more and more modern routers and switches gives customers
x86 local compute facilities on the box. So I can easily imagine that
I write a distributed application which communicates box to box at the
application level and installs locally via I2RS interface it's
"routes" to RIB.

Is this model of operation out of scope of this WG ?

I think there's enough rope for you to do that and have plenty left ove= r.

-Scott



Best regards,
R.
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs



--
People who are essentially without the power to implement their ideas in th= e real world must leverage the power of their reputations.

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--089e013c6ab09856a704d7e37e08-- From swhyte@google.com Thu Mar 14 07:41:22 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D3111E819B for ; Thu, 14 Mar 2013 07:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 y5kDCvwDHBuz for ; Thu, 14 Mar 2013 07:41:21 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id CFDA011E8192 for ; Thu, 14 Mar 2013 07:41:18 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id rr4so2312912pbb.13 for ; Thu, 14 Mar 2013 07:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tjf2zp5wW6R1gf5ZdotITr7akZzyRUpgWz4J4mc5M/k=; b=ZB7hyuY8QXqBQm0kKmbK2WUITD+KvvpA7MBXHm41tKZOD7Km11c3HAi60W9x1tm++d HxdwaEZW3TjxjtPi4viyE8LIrMgZ9LLLZ9RUoTm2HPKl9DfCOLzUAfLeECnc5RQHCr5N D8og1VPf/gOWcJ2CCgF4UCFcS4t3m5IC2qpJ7dCzJ+Z53LmQ/FmkpoMz/SGTfoIY904H wpjsEJq8OEK/Z2b/vOanoB5c53E3c2Rx420iaDNqK6/kfPJwIHryFb1OqstYJWMNHDHj aka9NRLBlRvbLG3ojEjxTl23CsVaiVasVYZTfEKzSOshS16kYDgHJ2VuN1bCaFlPNKZf 4w3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=tjf2zp5wW6R1gf5ZdotITr7akZzyRUpgWz4J4mc5M/k=; b=VBrOuCbqBarLXN4BSlVfUjeHflpf5wbghWtEImu5fVOCUml8VhZ/QJkRQvmxEWhZQj ewRaM+985cy6fDk43S6xj6zHG/hvaY8cmC1hdrP5foixY6UA2yOlWLu4bQf2ifqzReHB W/v+/Aluszu/BJuZfVslcVWnLi+0c8WuYwp1EkB5qZ1wT96BIkZhF+7O4WBrna93PG+7 M4/L/1lhrE9CLAEuTjettdVg5RjNT6z9JYIW7P42ddb1y9t0sg3g21XY11WO4onjbPMZ 9DS2ELK8/rovMrwrvX2QPdyRKlAa3wT1KjhYpby+F1pRi5oqIV+sq2HgMCFnW0qcZpC5 GmJA== X-Received: by 10.68.134.133 with SMTP id pk5mr6123405pbb.209.1363272078529; Thu, 14 Mar 2013 07:41:18 -0700 (PDT) Received: from ?IPv6:2001:df8:0:80:8868:3fef:f5c1:8cf1? ([2001:df8:0:80:8868:3fef:f5c1:8cf1]) by mx.google.com with ESMTPS id f4sm1964048pbc.6.2013.03.14.07.41.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 07:41:17 -0700 (PDT) Message-ID: <5141E18A.5010909@google.com> Date: Thu, 14 Mar 2013 07:41:14 -0700 From: Scott Whyte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Robert Raszuk References: <5141DF65.6000508@google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlnCZX+ZFfRuLwiNuHcRQ7McP6UU2+FcwzEaac69P6g7MKVYH5KJXOZLPtY9/JBZgHz/H2LQ2VZRYMgZyAZ0VqJ6eu83xgA8HAzGsVzZNIQMcqePJBApVAHDjaya1kVi1BIrplqCKWZhUoorDMgiAjsoQfde1cAbdb5wtPsrx7vK5U/Te0ViIz48wasFEjGgxURnIbF Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:41:22 -0000 On 03/14/2013 07:34 AM, Robert Raszuk wrote: > Hi Scott, > >> Why do we need to go beyond defining an interface to the RIB to make your >> use case work? > > I am talking precise about that definition of RIB interface. Not how > the RIB works in given vendor of network element. That is > implementation detail. > > Basically a list of values one can write or read to/from RIB. Have you > seen any document with such list yet ? So we agree that what a RIB looks like is out of scope, and we need to insure extensibility beyond proposed use cases for the actual RIB interface? If so I think the group is well on track to get there, as we grind through use cases and existing data models. -Scott > > Cheers, > R. > -- People who are essentially without the power to implement their ideas in the real world must leverage the power of their reputations. From russw@riw.us Thu Mar 14 07:45:04 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5C811E8153 for ; Thu, 14 Mar 2013 07:45:04 -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, 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 xSKCVKqT+oNo for ; Thu, 14 Mar 2013 07:45:04 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 411D411E8115 for ; Thu, 14 Mar 2013 07:45:04 -0700 (PDT) Received: from dhcp-13ef.meeting.ietf.org ([130.129.19.239]) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UG9Ow-00039x-Kw; Thu, 14 Mar 2013 07:45:02 -0700 References: <5141DF65.6000508@google.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <558AB9CA-4867-461C-8FF8-0733AADB50BC@riw.us> X-Mailer: iPad Mail (10B146) From: Russ White Date: Thu, 14 Mar 2013 10:44:55 -0400 To: Robert Raszuk X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:45:04 -0000 No, but I did try to address at least a partial list in one of the use cases= draft. I think this would really entail building a data model for "the enti= ty officially known as the rib." Is the current YANG model a good solution t= o the question? It seems like we should answer that question before writing a= nother one. I suspect we'll need either need to extend an existing ones to get where we w= ant?=20 I think the right place to start might be to explicitly include the objects t= hat need to be manipulated in each use case. Maybe we need a "standard set" of things that need to be included in each us= e case?=20 Thoughts? :-) Russ <>< russw@riw.us riwhite@verisign.com On Mar 14, 2013, at 10:34 AM, Robert Raszuk wrote: > Hi Scott, >=20 >> Why do we need to go beyond defining an interface to the RIB to make your= >> use case work? >=20 > I am talking precise about that definition of RIB interface. Not how > the RIB works in given vendor of network element. That is > implementation detail. >=20 > Basically a list of values one can write or read to/from RIB. Have you > seen any document with such list yet ? >=20 > Cheers, > R. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From rraszuk@gmail.com Thu Mar 14 07:46:11 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41BD11E81BE for ; Thu, 14 Mar 2013 07:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 ri2kaY9fxNX7 for ; Thu, 14 Mar 2013 07:46:11 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7159911E8153 for ; Thu, 14 Mar 2013 07:46:11 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id k10so3110414iea.33 for ; Thu, 14 Mar 2013 07:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jXDfMpwF0HMgDQrKBQTcdSmArGPx/cU6u2jPNPZq9+I=; b=zS3263BDTcf6URfnSZrJuB+PmNPcJHt2OkXR+s7TMmpZFjpswCLK2CsbneJb3leMeQ bey8XhakkaDQpgy4lBZ6596ujlDaRfe2sxgkMWmYap2HWX0DO8djGFxi8qlW091quQoT FZu5c0HuYLjbJBG7Tfrn4PQQaDPVD9PjaF7YB4CkPf+xW2zubJjtFZGew9Cu3UDG0h/R dxuffgDPYQDCc4PYcYGDXbpU7PGOwgbbZxh7QcC7E9hw7TB/xziA/6VVLxg5OvOyvP8m JI3dd6zQPtEkgdyBxFdh0qYPkAyvuYk6QEeyYiYaNmhKIp5N9FyDLYVM+wNBz6b0CQrz jhmQ== MIME-Version: 1.0 X-Received: by 10.43.103.195 with SMTP id dj3mr2257824icc.3.1363272371133; Thu, 14 Mar 2013 07:46:11 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 07:46:11 -0700 (PDT) In-Reply-To: <5141E18A.5010909@google.com> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> Date: Thu, 14 Mar 2013 15:46:11 +0100 X-Google-Sender-Auth: j7vXCrk2Z-foXOAgMqEvPPeP2_M Message-ID: From: Robert Raszuk To: Scott Whyte Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:46:12 -0000 I think we agree that RIB elements for read and write must be clearly defined. And should be extensible. But is RIB abstraction sufficient for I2RS ? For example as we know each VRF contains it's own RIB (different table id). So protocol must be able to also encode which RIB we are talking to. Further who will instantiate the VRF in this case ? Will I2RS be able to create a RIB instance on the fly ? How will we attach such RIB instance to interfaces ? There is dozens of details here without which I am afraid we can't go productively forward. Best, R. On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte wrote: > On 03/14/2013 07:34 AM, Robert Raszuk wrote: >> >> Hi Scott, >> >>> Why do we need to go beyond defining an interface to the RIB to make your >>> use case work? >> >> >> I am talking precise about that definition of RIB interface. Not how >> the RIB works in given vendor of network element. That is >> implementation detail. >> >> Basically a list of values one can write or read to/from RIB. Have you >> seen any document with such list yet ? > > > So we agree that what a RIB looks like is out of scope, and we need to > insure extensibility beyond proposed use cases for the actual RIB interface? > If so I think the group is well on track to get there, as we grind through > use cases and existing data models. > > -Scott > >> >> Cheers, >> R. >> > > > -- > People who are essentially without the power to implement their ideas in the > real world must leverage the power of their reputations. From russw@riw.us Thu Mar 14 07:47:30 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DAC11E81D9 for ; Thu, 14 Mar 2013 07:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-0.349, 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 JIYayhu+KmfT for ; Thu, 14 Mar 2013 07:47:26 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9235C11E81D5 for ; Thu, 14 Mar 2013 07:47:26 -0700 (PDT) Received: from dhcp-13ef.meeting.ietf.org ([130.129.19.239]) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UG9RG-0003N1-10; Thu, 14 Mar 2013 07:47:26 -0700 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9001D75E-039A-4C9C-9854-F62C0A21EA5E@riw.us> X-Mailer: iPad Mail (10B146) From: Russ White Date: Thu, 14 Mar 2013 10:47:24 -0400 To: Robert Raszuk X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Centralized vs distributed I2RS use model X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:47:30 -0000 IMHO, the answer should be "we're not defining a model that works only centr= alized or distributed, but a just a model --use it any way you like." :-) Russ <>< russw@riw.us riwhite@verisign.com On Mar 14, 2013, at 10:13 AM, Robert Raszuk wrote: > Hi, >=20 > I think I am hearing quite clearly from most of the presentations that > there is sort of opinion that I2RS talks to RIBs from some form of > centralized controllers/route servers/topology collectors etc ... >=20 > Does this mean that I can't use I2RS in completely distributed manner > without any central controller ? >=20 > Note that more and more modern routers and switches gives customers > x86 local compute facilities on the box. So I can easily imagine that > I write a distributed application which communicates box to box at the > application level and installs locally via I2RS interface it's > "routes" to RIB. >=20 > Is this model of operation out of scope of this WG ? >=20 > Best regards, > R. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From rraszuk@gmail.com Thu Mar 14 07:53:32 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B129411E81EA for ; Thu, 14 Mar 2013 07:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 uGs-MqI2Lhsn for ; Thu, 14 Mar 2013 07:53:28 -0700 (PDT) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id D02A211E8197 for ; Thu, 14 Mar 2013 07:53:13 -0700 (PDT) Received: by mail-ia0-f180.google.com with SMTP id f27so2119235iae.25 for ; Thu, 14 Mar 2013 07:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ohUSHTDL/JFraxZvnzvDXimjug5AOOAgV/+H92NCt8M=; b=MWqilUvk6MSMmdZdIkO/sW53HfQe226BU3aoWZ4GZ2SJuNPQOoX4723Vi3LoJ8bwvW Eeqreum5eVWsTJ18g0S8U9/oYEDDkVIbBsZX4u3qFSz8SOdcuGJoNLGyZ3nnAoeGBhId Awm8+Ra4R3vfWe0exe8FM4Rf8mZU9GKXILipPFCmiFTZ1ShRir1RdWt5fxEZSgt/+55i 069porASQIL9JWuKH4kDl/P+FJqIB5duSvsEQJLEEq03VOZKSwjhIWQ+poxAPLRiR66Z mDw3a26TWRwKoMzNVLKO4HPAUtSaav1tvfILNBu32mJVsF/aRcMS3l8ULj5V0iis/Q7p q55A== MIME-Version: 1.0 X-Received: by 10.50.47.200 with SMTP id f8mr20731341ign.98.1363272792875; Thu, 14 Mar 2013 07:53:12 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 07:53:12 -0700 (PDT) In-Reply-To: <9001D75E-039A-4C9C-9854-F62C0A21EA5E@riw.us> References: <9001D75E-039A-4C9C-9854-F62C0A21EA5E@riw.us> Date: Thu, 14 Mar 2013 15:53:12 +0100 X-Google-Sender-Auth: BuT2v7az4tvzUGMvF3ongs-E2c4 Message-ID: From: Robert Raszuk To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Centralized vs distributed I2RS use model X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:53:32 -0000 Ok then I think we all agree on this. Thread closed. (That was incredibly quick :). Cheers, R. On Thu, Mar 14, 2013 at 3:47 PM, Russ White wrote: > > IMHO, the answer should be "we're not defining a model that works only centralized or distributed, but a just a model --use it any way you like." > > :-) > > Russ > > <>< > russw@riw.us > riwhite@verisign.com > > On Mar 14, 2013, at 10:13 AM, Robert Raszuk wrote: > >> Hi, >> >> I think I am hearing quite clearly from most of the presentations that >> there is sort of opinion that I2RS talks to RIBs from some form of >> centralized controllers/route servers/topology collectors etc ... >> >> Does this mean that I can't use I2RS in completely distributed manner >> without any central controller ? >> >> Note that more and more modern routers and switches gives customers >> x86 local compute facilities on the box. So I can easily imagine that >> I write a distributed application which communicates box to box at the >> application level and installs locally via I2RS interface it's >> "routes" to RIB. >> >> Is this model of operation out of scope of this WG ? >> >> Best regards, >> R. >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs From lhotka@nic.cz Thu Mar 14 07:53:36 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87781F0D09 for ; Thu, 14 Mar 2013 07:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] 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 h-5X3Rd0efWt for ; Thu, 14 Mar 2013 07:53:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BE0A111E81E2 for ; Thu, 14 Mar 2013 07:53:21 -0700 (PDT) Received: from [IPv6:2001:df8::16:85c6:1503:5f38:692b] (unknown [IPv6:2001:df8:0:16:85c6:1503:5f38:692b]) by mail.nic.cz (Postfix) with ESMTPSA id E62F313F83A; Thu, 14 Mar 2013 15:53:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1363272800; bh=b4HjIIZNmJwvGv0Xv6EuMowKNSCLE07xEJdFLa4L3UI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mdhYvt18aEchPWiNHq+bXbvAGf8Q04cPyFxLl8HEXvEDNmj0HU0lC9Edgu0LaZq90 IMPSXc3Sa0gAwIfliDgKMwNRgw8B+KnqAHqLNRIefVU1eSRFyZL4zbD4ov1flSokSy QHe3texkrVRoUfD6dcMf9lsxQ04+RdQGtvlljlrg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 14 Mar 2013 10:53:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <11A9C40F-3C47-448C-8248-F5A7484CE91F@nic.cz> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> To: Robert Raszuk X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:53:37 -0000 On Mar 14, 2013, at 10:46 AM, Robert Raszuk wrote: > I think we agree that RIB elements for read and write must be clearly > defined. And should be extensible. >=20 > But is RIB abstraction sufficient for I2RS ? >=20 > For example as we know each VRF contains it's own RIB (different table > id). So protocol must be able to also encode which RIB we are talking > to. Well, according to RFC 4271, RIB (i.e., Adj-RIBs, Loc_RIB and = Adj-RIBs-Out) are data structures internal to a BGP speaker. I suspect = that what I2RS aims at interacting with is what 4271 calls "Routing = Table". Lada >=20 > Further who will instantiate the VRF in this case ? Will I2RS be able > to create a RIB instance on the fly ? How will we attach such RIB > instance to interfaces ? There is dozens of details here without which > I am afraid we can't go productively forward. >=20 > Best, > R. >=20 >=20 > On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte = wrote: >> On 03/14/2013 07:34 AM, Robert Raszuk wrote: >>>=20 >>> Hi Scott, >>>=20 >>>> Why do we need to go beyond defining an interface to the RIB to = make your >>>> use case work? >>>=20 >>>=20 >>> I am talking precise about that definition of RIB interface. Not how >>> the RIB works in given vendor of network element. That is >>> implementation detail. >>>=20 >>> Basically a list of values one can write or read to/from RIB. Have = you >>> seen any document with such list yet ? >>=20 >>=20 >> So we agree that what a RIB looks like is out of scope, and we need = to >> insure extensibility beyond proposed use cases for the actual RIB = interface? >> If so I think the group is well on track to get there, as we grind = through >> use cases and existing data models. >>=20 >> -Scott >>=20 >>>=20 >>> Cheers, >>> R. >>>=20 >>=20 >>=20 >> -- >> People who are essentially without the power to implement their ideas = in the >> real world must leverage the power of their reputations. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From swhyte@google.com Thu Mar 14 07:58:50 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FE511E820E for ; Thu, 14 Mar 2013 07:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 gmmG6sr2N8-O for ; Thu, 14 Mar 2013 07:58:45 -0700 (PDT) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id 78A7111E80E1 for ; Thu, 14 Mar 2013 07:58:44 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id un15so2331890pbc.38 for ; Thu, 14 Mar 2013 07:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LbuzCaOtnV3mY44M4QuB5kM5RfY4otVc8jKgaOWm3Po=; b=dtMFtYy+yUhY2LAqGvY6aL9R6FkcdpFN61hzzQsoSSItmj0TbiXHZDqhcKulTzrp+l OM5nmbTUFsTvRvq+cu7sg8UnKVptliYG2ioKSf45WPNfyRwk/DxlYuMkwuljCYyvks0a 0aBaUKF+d/gahFeDo0Rh8ocVYQnNCyhh9Z93/bvyfJEocUYvw7Mr/4Mmk3rTCKt2Xlbj RD0oH6SbS3iqc039UZsP58RMu4Z1P8C/bVz4d5k32Krmq8Xh3HqmKz0pCzG6xMNiWbvN 5hNH8IMkHoF22rQ/5GDd5qctV5n8dAmUI0vKO+kBJSCaEHIDqRHESepyetfDWATvfhNA ZpWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=LbuzCaOtnV3mY44M4QuB5kM5RfY4otVc8jKgaOWm3Po=; b=RWuwQK2CvqRhylkPr7K3Uo3hHNqFZ9NygPTSyghyUysAj+LraLHXamGZoyRbINbWxJ Gx6ks7dE98l14xtpB+krUYIkS8SRt3NS/kiBTzF/4StrE1pft7vRQZpXAaB5FilUpJ0N U0k1+kFatJNqNQiw4VbD06CVXN3jIxx2f/JEYW0H9pUCqf44TihcZRJIfx1ilgab2nZW xMYYomz1sEoOpEb2YiULwbo/AYqmKokj4dUIbZ1uhuhk8egdHWl7y4OSmcBOtB2FC7vq H0vRbP06dN862It3vLN3g9DlmRq//YMdRABrL/BXpVYmx+DqHruyPDNxxWjXBUqw7oq3 rr5A== X-Received: by 10.68.216.226 with SMTP id ot2mr6442913pbc.99.1363273123851; Thu, 14 Mar 2013 07:58:43 -0700 (PDT) Received: from ?IPv6:2001:df8:0:80:8868:3fef:f5c1:8cf1? ([2001:df8:0:80:8868:3fef:f5c1:8cf1]) by mx.google.com with ESMTPS id vq9sm3636324pbc.36.2013.03.14.07.58.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 07:58:42 -0700 (PDT) Message-ID: <5141E5A0.7000001@google.com> Date: Thu, 14 Mar 2013 07:58:40 -0700 From: Scott Whyte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Robert Raszuk References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmKDhVq3Q3+YpTr4us+/1f2mLKUAqP9daUv5+wgk3yU2UO8yxTkJZ4BZLi4dgOhCVPVHZcONG1ux4Jbpr5JrGKrWZIV6GU6pcS0VqbudQGmMUVDSJ3YydfF4NKdb3FXMJTxjWShpBTy1GoZRm1OLLc4zpI1DJC9BSw0e8kDlMBAojzf4M3vxTksX9/dS2vIrrjDap1j Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:58:51 -0000 On 03/14/2013 07:46 AM, Robert Raszuk wrote: > I think we agree that RIB elements for read and write must be clearly > defined. And should be extensible. > > But is RIB abstraction sufficient for I2RS ? > > For example as we know each VRF contains it's own RIB (different table > id). So protocol must be able to also encode which RIB we are talking > to. > > Further who will instantiate the VRF in this case ? Will I2RS be able > to create a RIB instance on the fly ? How will we attach such RIB > instance to interfaces ? There is dozens of details here without which > I am afraid we can't go productively forward. I guess I'm confused now on what you consider propietary implementation detail of a RIB, but I'll assume you are still talking strictly about a RIB abstraction and increasing its scope to multiple RIBs communicating with a single I2RS agent. Not sure about dozens of details, but your four good questions above all seem to revolve around a single issue, handling of multiple RIBs, which I think is important to have as a use case. -Scott > > Best, > R. > > > On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte wrote: >> On 03/14/2013 07:34 AM, Robert Raszuk wrote: >>> >>> Hi Scott, >>> >>>> Why do we need to go beyond defining an interface to the RIB to make your >>>> use case work? >>> >>> >>> I am talking precise about that definition of RIB interface. Not how >>> the RIB works in given vendor of network element. That is >>> implementation detail. >>> >>> Basically a list of values one can write or read to/from RIB. Have you >>> seen any document with such list yet ? >> >> >> So we agree that what a RIB looks like is out of scope, and we need to >> insure extensibility beyond proposed use cases for the actual RIB interface? >> If so I think the group is well on track to get there, as we grind through >> use cases and existing data models. >> >> -Scott >> >>> >>> Cheers, >>> R. >>> >> >> >> -- >> People who are essentially without the power to implement their ideas in the >> real world must leverage the power of their reputations. -- People who are essentially without the power to implement their ideas in the real world must leverage the power of their reputations. From rraszuk@gmail.com Thu Mar 14 07:59:01 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02FC11E80E1 for ; Thu, 14 Mar 2013 07:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] 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 sCO8SzR8jixb for ; Thu, 14 Mar 2013 07:59:00 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D711E8142 for ; Thu, 14 Mar 2013 07:58:51 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id k38so2168203iah.33 for ; Thu, 14 Mar 2013 07:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gyJnaHnA+8KPfVHu+oPL3z7kQvLLTKHM8bUKGNoJcvs=; b=Dhys2swvdBnu0rD1Y2efnPOfawv7PFv7RS4eIwDXsurJm6sQ0xJV2+Dge4CSW5h6kc TByPtnqxyy0IayXVgyzEe3PHYyCvT68Bk288YoeeT9FsLGpANX5hISuOv4dgrBRDqY1x vMkm9cH1eOP++ORPai6iMjJx2rErMWD7/uMAONATWVqtnot8IpH5pxmGTRl1nH7F3ns9 5MtqNsEmPqmnFkpWtAX0FKFzIhdMO3D8yQZpqv3XDZCLo5BUCeygCIHZUL4t83+IMgh4 yW/GVyNg7CX3XkeFyiln4QwWnau/9PAjNq6HbOXd/JAmV1+PAJPmbIjBBSdvzNciXWBF JqZw== MIME-Version: 1.0 X-Received: by 10.50.190.233 with SMTP id gt9mr2418444igc.80.1363273130902; Thu, 14 Mar 2013 07:58:50 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 07:58:50 -0700 (PDT) In-Reply-To: <11A9C40F-3C47-448C-8248-F5A7484CE91F@nic.cz> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <11A9C40F-3C47-448C-8248-F5A7484CE91F@nic.cz> Date: Thu, 14 Mar 2013 15:58:50 +0100 X-Google-Sender-Auth: 9mwWOxx7n8D11ybW6wi5QwTttj4 Message-ID: From: Robert Raszuk To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 14:59:01 -0000 Yes from what I understand I2RS aims to interact with "global RIB" aka inet.X tables and ACLs. Not to protocol local RIBs. Hence my question what actual data can be read and written to such RIBs by I2RS. Rgs, R. > On Thu, Mar 14, 2013 at 3:53 PM, Ladislav Lhotka wrote: > > On Mar 14, 2013, at 10:46 AM, Robert Raszuk wrote: > >> I think we agree that RIB elements for read and write must be clearly >> defined. And should be extensible. >> >> But is RIB abstraction sufficient for I2RS ? >> >> For example as we know each VRF contains it's own RIB (different table >> id). So protocol must be able to also encode which RIB we are talking >> to. > > Well, according to RFC 4271, RIB (i.e., Adj-RIBs, Loc_RIB and Adj-RIBs-Out) are data structures internal to a BGP speaker. I suspect that what I2RS aims at interacting with is what 4271 calls "Routing Table". > > Lada > >> >> Further who will instantiate the VRF in this case ? Will I2RS be able >> to create a RIB instance on the fly ? How will we attach such RIB >> instance to interfaces ? There is dozens of details here without which >> I am afraid we can't go productively forward. >> >> Best, >> R. >> >> >> On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte wrote: >>> On 03/14/2013 07:34 AM, Robert Raszuk wrote: >>>> >>>> Hi Scott, >>>> >>>>> Why do we need to go beyond defining an interface to the RIB to make your >>>>> use case work? >>>> >>>> >>>> I am talking precise about that definition of RIB interface. Not how >>>> the RIB works in given vendor of network element. That is >>>> implementation detail. >>>> >>>> Basically a list of values one can write or read to/from RIB. Have you >>>> seen any document with such list yet ? >>> >>> >>> So we agree that what a RIB looks like is out of scope, and we need to >>> insure extensibility beyond proposed use cases for the actual RIB interface? >>> If so I think the group is well on track to get there, as we grind through >>> use cases and existing data models. >>> >>> -Scott >>> >>>> >>>> Cheers, >>>> R. >>>> >>> >>> >>> -- >>> People who are essentially without the power to implement their ideas in the >>> real world must leverage the power of their reputations. >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From rraszuk@gmail.com Thu Mar 14 08:02:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4277F11E820F for ; Thu, 14 Mar 2013 08:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] 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 NdHLa+6HbXGG for ; Thu, 14 Mar 2013 08:02:04 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC7611E819F for ; Thu, 14 Mar 2013 08:02:00 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id k14so3101247iea.41 for ; Thu, 14 Mar 2013 08:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=a2dx1pZHru7Mq+yPawVo0g2k9XKhAnkgUNkEaRtJSGA=; b=AbcqOD6/Icn+SkF573sX5GmiKoBM4m5C7iZlxAhgxUhAPuQqvNVGZjegQONeaSxqMX ih+FE5EsLIZSLon+qa8PC3SpUyfTBNi6Ve/QBUlTwUW9rawBEuUSnuwpvia7McQb/8u6 iVcJfwWOKQsW11eTayZ0nE6FycKbfyUp6VW5AQdAd90BAxI0PfgfgiD9IFnJf/PDEbaL bxssvAZktxCUvDkCB3mcYd4mZWpQrCdA8pZzzRDFp0dc/mrDqkwAEt1Rw+BHbwN5axG1 uuj9yaS8Rz7zvASUrjRR1WpwuejeK7yMOGRJp2CjbUR6aYjC1zxOUvKkIy8muiirT/6u U+Zg== MIME-Version: 1.0 X-Received: by 10.43.103.195 with SMTP id dj3mr2304010icc.3.1363273320230; Thu, 14 Mar 2013 08:02:00 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 08:02:00 -0700 (PDT) In-Reply-To: <5141E5A0.7000001@google.com> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> Date: Thu, 14 Mar 2013 16:02:00 +0100 X-Google-Sender-Auth: wb-aUE7HzRewlfM4mM_l8W2j6j4 Message-ID: From: Robert Raszuk To: Scott Whyte Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 15:02:05 -0000 My main question is what L2-L4 fields for the packet lookup I can program to the 'RIB" by I2RS. Very precise and simple. The use case for multiple RIBs is just being shown in the room. L3VPN PE auto-provisioning ;) Best, R,. On Thu, Mar 14, 2013 at 3:58 PM, Scott Whyte wrote: > On 03/14/2013 07:46 AM, Robert Raszuk wrote: >> >> I think we agree that RIB elements for read and write must be clearly >> defined. And should be extensible. >> >> But is RIB abstraction sufficient for I2RS ? >> >> For example as we know each VRF contains it's own RIB (different table >> id). So protocol must be able to also encode which RIB we are talking >> to. >> >> Further who will instantiate the VRF in this case ? Will I2RS be able >> to create a RIB instance on the fly ? How will we attach such RIB >> instance to interfaces ? There is dozens of details here without which >> I am afraid we can't go productively forward. > > > I guess I'm confused now on what you consider propietary implementation > detail of a RIB, but I'll assume you are still talking strictly about a RIB > abstraction and increasing its scope to multiple RIBs communicating with a > single I2RS agent. > > Not sure about dozens of details, but your four good questions above all > seem to revolve around a single issue, handling of multiple RIBs, which I > think is important to have as a use case. > > -Scott > > > >> >> Best, >> R. >> >> >> On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte wrote: >>> >>> On 03/14/2013 07:34 AM, Robert Raszuk wrote: >>>> >>>> >>>> Hi Scott, >>>> >>>>> Why do we need to go beyond defining an interface to the RIB to make >>>>> your >>>>> use case work? >>>> >>>> >>>> >>>> I am talking precise about that definition of RIB interface. Not how >>>> the RIB works in given vendor of network element. That is >>>> implementation detail. >>>> >>>> Basically a list of values one can write or read to/from RIB. Have you >>>> seen any document with such list yet ? >>> >>> >>> >>> So we agree that what a RIB looks like is out of scope, and we need to >>> insure extensibility beyond proposed use cases for the actual RIB >>> interface? >>> If so I think the group is well on track to get there, as we grind >>> through >>> use cases and existing data models. >>> >>> -Scott >>> >>>> >>>> Cheers, >>>> R. >>>> >>> >>> >>> -- >>> People who are essentially without the power to implement their ideas in >>> the >>> real world must leverage the power of their reputations. > > > > -- > People who are essentially without the power to implement their ideas in the > real world must leverage the power of their reputations. From michael.scharf@alcatel-lucent.com Thu Mar 14 08:06:37 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D0C11E825D for ; Thu, 14 Mar 2013 08:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 p+Ncy677jjU7 for ; Thu, 14 Mar 2013 08:06:33 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFA811E8267 for ; Thu, 14 Mar 2013 08:05:48 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2EF5kgb008560 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 14 Mar 2013 16:05:46 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 14 Mar 2013 16:05:46 +0100 From: "Scharf, Michael (Michael)" To: "i2rs@ietf.org" Date: Thu, 14 Mar 2013 16:05:42 +0100 Thread-Topic: Existing northbound topology API: ALTO Thread-Index: Ac4gxWWFdZmqSpKjSJSy6ePOqx8WSQ== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6C83@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [i2rs] Existing northbound topology API: ALTO X-BeenThere: i2rs@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: Thu, 14 Mar 2013 15:06:37 -0000 As mentioned on the mic: Here is an analysis how ALTO can expose service/VP= N topologies: http://tools.ietf.org/html/draft-scharf-alto-vpn-service-00 Comments on the ALTO mailing list would be very welcome. Thanks Michael From yiya@cisco.com Thu Mar 14 08:09:31 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9300D11E8268 for ; Thu, 14 Mar 2013 08:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_HI=-8] 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 pZ4qzjsAnh4l for ; Thu, 14 Mar 2013 08:09:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A03A411E8270 for ; Thu, 14 Mar 2013 08:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2062; q=dns/txt; s=iport; t=1363273763; x=1364483363; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=g+y2lBH/GhprN/WAFvKuUuvouNrrlilTdIh7Khz0ktk=; b=P56fOJft78AtxtyQJgEGO+2UfLS32Ej7y5sPqY7+dPfGIKoDmhsQ6jJe +cU4YSQDG5pLWKyfczhWctCBIL1CkRjMHYXm0ijUxSw7o1TX4SUfC6N4t RaQhi+EE2J4nxQoBRR2Lpb4tCJoRmvTeTnJEJrkFQqz8f/rdNI7r5LDVh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMvmQVGtJV2Z/2dsb2JhbABDxHiBYhZ0gioBAQEEAQEBNzQLEgEIGAoUNwslAgQBDQUIE4d5DMErjl8xB4JfYQOXd49jgwqCKA X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208";a="187259316" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 14 Mar 2013 15:09:20 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2EF9KB7031732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 15:09:20 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.252]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 10:09:20 -0500 From: "Yi Yang (yiya)" To: Russ White , Robert Raszuk Thread-Topic: [i2rs] RIB definition ... Thread-Index: AQHOIL5Vo4U4V6GD7kKbdmbKIkEkc5ilk7uAgAAAuACAAALegP//w8EA Date: Thu, 14 Mar 2013 15:09:18 +0000 Message-ID: In-Reply-To: <558AB9CA-4867-461C-8FF8-0733AADB50BC@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.82.237.31] Content-Type: text/plain; charset="us-ascii" Content-ID: <2A98222D82FAC647841578BE0805DC2D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 15:09:31 -0000 On 3/14/13 10:44 AM, "Russ White" wrote: > >No, but I did try to address at least a partial list in one of the use >cases draft. I think this would really entail building a data model for >"the entity officially known as the rib." Is the current YANG model a >good solution to the question? It seems like we should answer that >question before writing another one. There is a current YANG draft trying to cover the most basic of a routing table http://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/?include_text =3D1 > >I suspect we'll need either need to extend an existing ones to get where >we want? >=20 > >I think the right place to start might be to explicitly include the >objects that need to be manipulated in each use case. > >Maybe we need a "standard set" of things that need to be included in each >use case? >=20 > >Thoughts? "Cast a wide net for every possible use case" and "Narrow requirements to bite sized chunks" The same principal can be used to define the RIB as well.:-) Start with a vanilla RIB definition consisting of basic common objects, but allow it to be extended for fancy applications. Yi > > >:-) > >Russ > > ><>< >russw@riw.us >riwhite@verisign.com > >On Mar 14, 2013, at 10:34 AM, Robert Raszuk wrote: > >> Hi Scott, >>=20 >>> Why do we need to go beyond defining an interface to the RIB to make >>>your >>> use case work? >>=20 >> I am talking precise about that definition of RIB interface. Not how >> the RIB works in given vendor of network element. That is >> implementation detail. >>=20 >> Basically a list of values one can write or read to/from RIB. Have you >> seen any document with such list yet ? >>=20 >> Cheers, >> R. >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs From dave.hood@ericsson.com Thu Mar 14 08:10:07 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10B411E8281 for ; Thu, 14 Mar 2013 08:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 bXG86LouTtxC for ; Thu, 14 Mar 2013 08:10:06 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7238A11E824A for ; Thu, 14 Mar 2013 08:10:00 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-de-5141e847c7af Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E5.2E.02411.748E1415; Thu, 14 Mar 2013 16:10:00 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 11:09:59 -0400 From: Dave Hood To: "i2rs@ietf.org" Thread-Topic: info vs data models Thread-Index: Ac4gxddAuXFeKBBCRjKpLJWrdHDfFw== Date: Thu, 14 Mar 2013 15:09:58 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA6405F4B6EB@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4B6EBeusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyuXRPlK7HC8dAgzfPeSzWzfjA4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIeTowqWiles+bOEpYHxokgXIyeHhICJxOurPcwQtpjEhXvr 2boYuTiEBI4wSiz79JEdwlnOKPFx9wJGkCo2AQ2JJ5cmM4HYIgLKEgd/9rKC2MICMhJ3N96B iitK7DnfBDSJA8jWk9h2XRwkzCKgKvFjwxmwcl4BX4mGhl1sIDYj0OLvp9aAtTILiEvcejKf CeIgAYkle85DHScq8fLxP1YIW1ni+5xHLBD1+RJfvjazQMwUlDg58wnLBEahWUhGzUJSNgtJ GURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FyFFanFqWm25kuIkRGPbHJNgcdzAu+GR5 iFGag0VJnDfU9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbXtoDbe+QvTOg6/3tKynEW j4nzZ+6/qlvVX7wz+/DCEO4n9U53GxJnNFVfOSU3JU7Zi//SkeyvNTLXMvq/87WW9+Z1Z2lc 3fXSeqrHMoffrOWrt7/hOnRG8MybBv0vF1eeD6koncqX4cAtESYY3b5SzUz43df4utKNM8ul d8Zt0fF5f9Zb/rISS3FGoqEWc1FxIgBeAZQ9SQIAAA== Subject: [i2rs] info vs data models X-BeenThere: i2rs@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: Thu, 14 Mar 2013 15:10:07 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4B6EBeusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There seems to be continuing confusion about info vs data models, including= the current presentation about building a yang data model that can *then* = be converted into an info model. RFC 3444 is worth reading. --_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4B6EBeusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There seems to be continuing confu= sion about info vs data models, including the current presentation about bu= ilding a yang data model that can *then* be converted into an info model.

 

RFC 3444 is worth reading.

--_000_8D15A2BAF93E9C49AB037A0647E5FA6405F4B6EBeusaamb105erics_-- From rraszuk@gmail.com Thu Mar 14 08:14:02 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC41F11E8171 for ; Thu, 14 Mar 2013 08:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HS_INDEX_PARAM=0.001, NO_RELAYS=-0.001] 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 iAgXOR3lMUCf for ; Thu, 14 Mar 2013 08:14:02 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id EB3A211E821C for ; Thu, 14 Mar 2013 08:14:01 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id c13so3095673ieb.23 for ; Thu, 14 Mar 2013 08:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aF+Az1B7jEhZi/NBSkZlg1lYNqsfJJFUAd0/epY23EY=; b=IbYUsA9rr0Wkl2zdycpxKIx05CiCx2kUcbVtDXLO8vogBMWkNhLYwzv3tW+ux+wpa7 kmfcpajRT5ncHA2k+ibOQvjqV+33LKXG+J/phZngT9CwPtHGPzxMAtwMYM6ZXkQ2uOgN iq8bHuw7rW9Ocwalcpv+hFlw8GUkaTJfwEJnPKUf9fupJ3JyR8jsFD19jrIqvwemd1MI 6Yak14bxoYIxRZp/JTe9Kb1TUnGA+goKcBuBHX03N2/Waedq6M3p0EIoir+BAP1Nf1e7 p6L5WKAaTiaONSLCzTV14vKzNcy4BTlF+cCz2a/WjHTvHG6aB9rEFnpi1AWpdrhxT9b1 AzIQ== MIME-Version: 1.0 X-Received: by 10.50.156.133 with SMTP id we5mr2574168igb.51.1363274039971; Thu, 14 Mar 2013 08:13:59 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 08:13:59 -0700 (PDT) In-Reply-To: References: <558AB9CA-4867-461C-8FF8-0733AADB50BC@riw.us> Date: Thu, 14 Mar 2013 16:13:59 +0100 X-Google-Sender-Auth: lsRV6K5Mv6LYyi3_S_zIR9uJOX4 Message-ID: From: Robert Raszuk To: "Yi Yang (yiya)" Content-Type: text/plain; charset=ISO-8859-1 Cc: Russ White , "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 15:14:02 -0000 I have no shadow of a doubt that you can define what needs to be defined. I am however very interested to see that I2RS WG members will agree on those things seamlessly :) R. On Thu, Mar 14, 2013 at 4:09 PM, Yi Yang (yiya) wrote: > > > On 3/14/13 10:44 AM, "Russ White" wrote: > >> >>No, but I did try to address at least a partial list in one of the use >>cases draft. I think this would really entail building a data model for >>"the entity officially known as the rib." Is the current YANG model a >>good solution to the question? It seems like we should answer that >>question before writing another one. > > There is a current YANG draft trying to cover the most basic of a routing > table > > http://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/?include_text > =1 > >> >>I suspect we'll need either need to extend an existing ones to get where >>we want? >> >> >>I think the right place to start might be to explicitly include the >>objects that need to be manipulated in each use case. >> >>Maybe we need a "standard set" of things that need to be included in each >>use case? >> >> >>Thoughts? > > "Cast a wide net for every possible use case" and "Narrow requirements to > bite sized chunks" > > The same principal can be used to define the RIB as well.:-) Start with a > vanilla RIB definition consisting of basic common objects, but allow it to > be extended for fancy applications. > > Yi > > >> >> >>:-) >> >>Russ >> >> >><>< >>russw@riw.us >>riwhite@verisign.com >> >>On Mar 14, 2013, at 10:34 AM, Robert Raszuk wrote: >> >>> Hi Scott, >>> >>>> Why do we need to go beyond defining an interface to the RIB to make >>>>your >>>> use case work? >>> >>> I am talking precise about that definition of RIB interface. Not how >>> the RIB works in given vendor of network element. That is >>> implementation detail. >>> >>> Basically a list of values one can write or read to/from RIB. Have you >>> seen any document with such list yet ? >>> >>> Cheers, >>> R. >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>_______________________________________________ >>i2rs mailing list >>i2rs@ietf.org >>https://www.ietf.org/mailman/listinfo/i2rs > From russw@riw.us Thu Mar 14 08:14:19 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E22411E8278 for ; Thu, 14 Mar 2013 08:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.836 X-Spam-Level: X-Spam-Status: No, score=-0.836 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, 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 aYwfKXkEOBT1 for ; Thu, 14 Mar 2013 08:14:18 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id BC89711E8220 for ; Thu, 14 Mar 2013 08:14:18 -0700 (PDT) Received: from dhcp-13ef.meeting.ietf.org ([130.129.19.239]) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UG9rF-0005QU-2f; Thu, 14 Mar 2013 08:14:17 -0700 References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Russ White Date: Thu, 14 Mar 2013 11:14:15 -0400 To: Robert Raszuk X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 15:14:19 -0000 I wouldn't frame the question in terms of the packet header but the routing t= able... I don't know that the answer comes out different, but... :-) That said, I think a good base set would be: - Dest IP Address - Next hop IP address - Outbound interface - Admin distance - Some form of tags - Table ID We've talked about the ad,in distance being more like a community string tha= n an integer (having multiple parts so you can have several types of metrics= here), but I don't know how useful that would be. I'm all for thinking past= the immediate need and leaving doors open for unthought of things, though. There's also the back channel out of the rib to consider -- specifically, th= ings like, "your route was just overwritten by another process," "a route wa= s just redistributed to you," "the next hop for this route just went away," "= this connected route just failed," and other related stuff. But I think we might need to get the use cases to give us what information t= hey need, and work build a good list from that. Then we can ask the question= , "is there a model that fits already?" :-) Russ <>< russw@riw.us On Mar 14, 2013, at 11:02 AM, Robert Raszuk wrote: > My main question is what L2-L4 fields for the packet lookup I can > program to the 'RIB" by I2RS. Very precise and simple. >=20 > The use case for multiple RIBs is just being shown in the room. L3VPN > PE auto-provisioning ;) >=20 > Best, > R,. >=20 > On Thu, Mar 14, 2013 at 3:58 PM, Scott Whyte wrote: >> On 03/14/2013 07:46 AM, Robert Raszuk wrote: >>>=20 >>> I think we agree that RIB elements for read and write must be clearly >>> defined. And should be extensible. >>>=20 >>> But is RIB abstraction sufficient for I2RS ? >>>=20 >>> For example as we know each VRF contains it's own RIB (different table >>> id). So protocol must be able to also encode which RIB we are talking >>> to. >>>=20 >>> Further who will instantiate the VRF in this case ? Will I2RS be able >>> to create a RIB instance on the fly ? How will we attach such RIB >>> instance to interfaces ? There is dozens of details here without which >>> I am afraid we can't go productively forward. >>=20 >>=20 >> I guess I'm confused now on what you consider propietary implementation >> detail of a RIB, but I'll assume you are still talking strictly about a R= IB >> abstraction and increasing its scope to multiple RIBs communicating with a= >> single I2RS agent. >>=20 >> Not sure about dozens of details, but your four good questions above all >> seem to revolve around a single issue, handling of multiple RIBs, which I= >> think is important to have as a use case. >>=20 >> -Scott >>=20 >>=20 >>=20 >>>=20 >>> Best, >>> R. >>>=20 >>>=20 >>> On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte wrote: >>>>=20 >>>> On 03/14/2013 07:34 AM, Robert Raszuk wrote: >>>>>=20 >>>>>=20 >>>>> Hi Scott, >>>>>=20 >>>>>> Why do we need to go beyond defining an interface to the RIB to make >>>>>> your >>>>>> use case work? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I am talking precise about that definition of RIB interface. Not how >>>>> the RIB works in given vendor of network element. That is >>>>> implementation detail. >>>>>=20 >>>>> Basically a list of values one can write or read to/from RIB. Have you= >>>>> seen any document with such list yet ? >>>>=20 >>>>=20 >>>>=20 >>>> So we agree that what a RIB looks like is out of scope, and we need to >>>> insure extensibility beyond proposed use cases for the actual RIB >>>> interface? >>>> If so I think the group is well on track to get there, as we grind >>>> through >>>> use cases and existing data models. >>>>=20 >>>> -Scott >>>>=20 >>>>>=20 >>>>> Cheers, >>>>> R. >>>>=20 >>>>=20 >>>> -- >>>> People who are essentially without the power to implement their ideas i= n >>>> the >>>> real world must leverage the power of their reputations. >>=20 >>=20 >>=20 >> -- >> People who are essentially without the power to implement their ideas in t= he >> real world must leverage the power of their reputations. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From lhotka@nic.cz Thu Mar 14 08:15:11 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0BC711E8221 for ; Thu, 14 Mar 2013 08:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] 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 6JGAvSU7skgT for ; Thu, 14 Mar 2013 08:15:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id ECBAD11E8220 for ; Thu, 14 Mar 2013 08:15:03 -0700 (PDT) Received: from [IPv6:2001:df8::16:85c6:1503:5f38:692b] (unknown [IPv6:2001:df8:0:16:85c6:1503:5f38:692b]) by mail.nic.cz (Postfix) with ESMTPSA id 11AA413F7D2; Thu, 14 Mar 2013 16:14:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1363274099; bh=31TvNS+kb9am+/LKhmf9zx5Rbpsl1m8uVhGyZo1ThPk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HZDgIhCF4jc3SqF9KAciH/hg7YjXNTaGwUlx5+ilBS0+z/wFKO+d1z66wOfj8Oiv4 WUOqYq3BOhpF0otJRMlu/8NJoQkZCNkVaqoXtzeZ5ry1av0Nz+rhfF+64Ge1AG2jsQ CPX6XE8CpGaDtcfiUrIeCrHI8vvOz5iGuj3EolkU= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 14 Mar 2013 11:15:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <11A9C40F-3C47-448C-8248-F5A7484CE91F@nic.cz> To: Robert Raszuk X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 15:15:12 -0000 On Mar 14, 2013, at 10:58 AM, Robert Raszuk wrote: > Yes from what I understand I2RS aims to interact with "global RIB" aka > inet.X tables and ACLs. Not to protocol local RIBs. Right, but JUNOS documentation calls these inet.X routing tables while = in Cisco IOS terms a routing table already contains only active routes. Lada =20 >=20 > Hence my question what actual data can be read and written to such > RIBs by I2RS. >=20 > Rgs, > R. >=20 >=20 >> On Thu, Mar 14, 2013 at 3:53 PM, Ladislav Lhotka = wrote: >>=20 >> On Mar 14, 2013, at 10:46 AM, Robert Raszuk = wrote: >>=20 >>> I think we agree that RIB elements for read and write must be = clearly >>> defined. And should be extensible. >>>=20 >>> But is RIB abstraction sufficient for I2RS ? >>>=20 >>> For example as we know each VRF contains it's own RIB (different = table >>> id). So protocol must be able to also encode which RIB we are = talking >>> to. >>=20 >> Well, according to RFC 4271, RIB (i.e., Adj-RIBs, Loc_RIB and = Adj-RIBs-Out) are data structures internal to a BGP speaker. I suspect = that what I2RS aims at interacting with is what 4271 calls "Routing = Table". >>=20 >> Lada >>=20 >>>=20 >>> Further who will instantiate the VRF in this case ? Will I2RS be = able >>> to create a RIB instance on the fly ? How will we attach such RIB >>> instance to interfaces ? There is dozens of details here without = which >>> I am afraid we can't go productively forward. >>>=20 >>> Best, >>> R. >>>=20 >>>=20 >>> On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte = wrote: >>>> On 03/14/2013 07:34 AM, Robert Raszuk wrote: >>>>>=20 >>>>> Hi Scott, >>>>>=20 >>>>>> Why do we need to go beyond defining an interface to the RIB to = make your >>>>>> use case work? >>>>>=20 >>>>>=20 >>>>> I am talking precise about that definition of RIB interface. Not = how >>>>> the RIB works in given vendor of network element. That is >>>>> implementation detail. >>>>>=20 >>>>> Basically a list of values one can write or read to/from RIB. Have = you >>>>> seen any document with such list yet ? >>>>=20 >>>>=20 >>>> So we agree that what a RIB looks like is out of scope, and we need = to >>>> insure extensibility beyond proposed use cases for the actual RIB = interface? >>>> If so I think the group is well on track to get there, as we grind = through >>>> use cases and existing data models. >>>>=20 >>>> -Scott >>>>=20 >>>>>=20 >>>>> Cheers, >>>>> R. >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> People who are essentially without the power to implement their = ideas in the >>>> real world must leverage the power of their reputations. >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From rraszuk@gmail.com Thu Mar 14 08:17:34 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5D211E8291 for ; Thu, 14 Mar 2013 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, NO_RELAYS=-0.001] 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 dqevuY3-H09G for ; Thu, 14 Mar 2013 08:17:33 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 94D0D11E8289 for ; Thu, 14 Mar 2013 08:17:33 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id y26so778454iab.37 for ; Thu, 14 Mar 2013 08:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gQvzVGD0SqTgD3EzcTzTbMbfRWJvAflHtLAkJHupN54=; b=VdYWj5Pn5lbIt0DfIEe3l03G5JcYDNvD+97MYSIruFuxjrwDSEQQpskSNffkqmstUg VIRu6PyEN/j7UhG+rRMzgn9OpGVGLIYGkzZnm8B7I3wSrLShGV2AR720zfLHaHRGYn8F B+7wNbrgqfOeMT7aktCT36BoJPNmMa/O1x/kndNRCvRcrFaud//yaHQoYqb6c9Ggd3DY /c9yr6ClGcmAdyPik7Sqmli5ecdHN7G3QEWc+1nI0FOmt89UF/87slN1CIFnXsPqjRtk TXXoft60vFYceYRzUJAe2RD/MjmBGhZapwvwuq7gtY7YF+OyHJoKULYFMGn/oOJlRUW+ 55XQ== MIME-Version: 1.0 X-Received: by 10.50.190.233 with SMTP id gt9mr2483969igc.80.1363274253127; Thu, 14 Mar 2013 08:17:33 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 08:17:32 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> Date: Thu, 14 Mar 2013 16:17:32 +0100 X-Google-Sender-Auth: jo_Etob_Dwlyy3MARdg0Euea9x0 Message-ID: From: Robert Raszuk To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 15:17:34 -0000 Hi Russ ... For me the base set is completely not sufficient for any of the application I would use I2RS for. As example: it is missing match on VLAN, set MPLS VPN label, set MPLS transport label. r. > On Thu, Mar 14, 2013 at 4:14 PM, Russ White wrote: > > I wouldn't frame the question in terms of the packet header but the routi= ng table... I don't know that the answer comes out different, but... :-) > > That said, I think a good base set would be: > > - Dest IP Address > - Next hop IP address > - Outbound interface > - Admin distance > - Some form of tags > - Table ID > > We've talked about the ad,in distance being more like a community string = than an integer (having multiple parts so you can have several types of met= rics here), but I don't know how useful that would be. I'm all for thinking= past the immediate need and leaving doors open for unthought of things, th= ough. > > There's also the back channel out of the rib to consider -- specifically,= things like, "your route was just overwritten by another process," "a rout= e was just redistributed to you," "the next hop for this route just went aw= ay," "this connected route just failed," and other related stuff. > > But I think we might need to get the use cases to give us what informatio= n they need, and work build a good list from that. Then we can ask the ques= tion, "is there a model that fits already?" > > :-) > > Russ > > > <>< > russw@riw.us > > On Mar 14, 2013, at 11:02 AM, Robert Raszuk wrote: > >> My main question is what L2-L4 fields for the packet lookup I can >> program to the 'RIB" by I2RS. Very precise and simple. >> >> The use case for multiple RIBs is just being shown in the room. L3VPN >> PE auto-provisioning ;) >> >> Best, >> R,. >> >> On Thu, Mar 14, 2013 at 3:58 PM, Scott Whyte wrote: >>> On 03/14/2013 07:46 AM, Robert Raszuk wrote: >>>> >>>> I think we agree that RIB elements for read and write must be clearly >>>> defined. And should be extensible. >>>> >>>> But is RIB abstraction sufficient for I2RS ? >>>> >>>> For example as we know each VRF contains it's own RIB (different table >>>> id). So protocol must be able to also encode which RIB we are talking >>>> to. >>>> >>>> Further who will instantiate the VRF in this case ? Will I2RS be able >>>> to create a RIB instance on the fly ? How will we attach such RIB >>>> instance to interfaces ? There is dozens of details here without which >>>> I am afraid we can't go productively forward. >>> >>> >>> I guess I'm confused now on what you consider propietary implementation >>> detail of a RIB, but I'll assume you are still talking strictly about a= RIB >>> abstraction and increasing its scope to multiple RIBs communicating wit= h a >>> single I2RS agent. >>> >>> Not sure about dozens of details, but your four good questions above al= l >>> seem to revolve around a single issue, handling of multiple RIBs, which= I >>> think is important to have as a use case. >>> >>> -Scott >>> >>> >>> >>>> >>>> Best, >>>> R. >>>> >>>> >>>> On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte wrote= : >>>>> >>>>> On 03/14/2013 07:34 AM, Robert Raszuk wrote: >>>>>> >>>>>> >>>>>> Hi Scott, >>>>>> >>>>>>> Why do we need to go beyond defining an interface to the RIB to mak= e >>>>>>> your >>>>>>> use case work? >>>>>> >>>>>> >>>>>> >>>>>> I am talking precise about that definition of RIB interface. Not how >>>>>> the RIB works in given vendor of network element. That is >>>>>> implementation detail. >>>>>> >>>>>> Basically a list of values one can write or read to/from RIB. Have y= ou >>>>>> seen any document with such list yet ? >>>>> >>>>> >>>>> >>>>> So we agree that what a RIB looks like is out of scope, and we need t= o >>>>> insure extensibility beyond proposed use cases for the actual RIB >>>>> interface? >>>>> If so I think the group is well on track to get there, as we grind >>>>> through >>>>> use cases and existing data models. >>>>> >>>>> -Scott >>>>> >>>>>> >>>>>> Cheers, >>>>>> R. >>>>> >>>>> >>>>> -- >>>>> People who are essentially without the power to implement their ideas= in >>>>> the >>>>> real world must leverage the power of their reputations. >>> >>> >>> >>> -- >>> People who are essentially without the power to implement their ideas i= n the >>> real world must leverage the power of their reputations. >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs From adrian@olddog.co.uk Thu Mar 14 08:17:50 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC9E11E8297 for ; Thu, 14 Mar 2013 08:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=0.878, 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 SGmjGAIi8cRF for ; Thu, 14 Mar 2013 08:17:46 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB5A11E8292 for ; Thu, 14 Mar 2013 08:17:46 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2EFHe82014308; Thu, 14 Mar 2013 15:17:43 GMT Received: from webmail.easyspace.com (webmail4.iomartmail.com [10.12.10.174]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2EFHdQ9014292; Thu, 14 Mar 2013 15:17:39 GMT MIME-Version: 1.0 X-Mailer: AtMail PHP 5.7 Message-ID: <47187.1363274259@olddog.co.uk> To: "i2rs@ietf.org" , "Dave Hood" Content-Type: text/plain; charset="utf-8" X-Origin: 130.129.16.183 X-Atmail-Account: adrian@olddog.co.uk Date: Thu, 14 Mar 2013 15:17:39 +0000 From: Adrian Farrel Content-Transfer-Encoding: quoted-printable Subject: Re: [i2rs] info vs data models X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:17:50 -0000 Thanks Dave, I can't emphasise this strongly enough. 3444 is more than "worth reading", = it is mandatory for=20 people wanting to participate in this discussion.=20 It is not a big document. Read it now :-) Adrian On Thu 14/03/13 3:09 PM , "Dave Hood" dave.hood@ericsson.com sent: > There seems to be continuing confusion about info vs data models, > including the current presentation about building a yang data model that > can *THEN* be converted into an info model.=20 >=20 > =C2=A0=20 >=20 > RFC 3444 is worth reading. =20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs [1] >=20 >=20 >=20 > Links: > ------ > [1] > http://webmail.easyspace.com/parse.php?redirect=3Dhttps://www.ietf.org/ma= ilma > n/listinfo/i2rs >=20 From yang.r.yang@gmail.com Thu Mar 14 08:19:09 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FDA11E8221; Thu, 14 Mar 2013 08:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 ezQIKiVYo73w; Thu, 14 Mar 2013 08:19:04 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6695611E81D0; Thu, 14 Mar 2013 08:19:04 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id uo15so2353034pbc.5 for ; Thu, 14 Mar 2013 08:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ER/mSzyRPZAIp1LZ7ULON2nRr9AxRo9nsVSzeX/Ed00=; b=oxhbwL0LB7xGyZ+lEs+vYhxXFXIQ1QgNWpENAl/zONxKuo0V+jSdOx5FWp4hWdnciF 3R7xQxBJxNZHUtntxquAMr6Al2M6sj7fPnqK10Amm6ObLwMCY4EteVsvL5T5uLgf9XW5 NkuJGoiYtN3dqfMpcoC5Qa70/Kf+BAvEy0jE/pJBMpcJ2NUkNPhXXpgAqo8rpTPZUflv 6ByogJvCMsMzwKGWij4Fayat9QwO0fEMAnpUb1TTbT4602aVeD55JBat8dYZI1bnldPv 0DFROBFTH7BW366pnev2CVnXRfcUWrOqg/xkLjgDhuKYYGMdbry1YFDc/QuGETAvhEYX LmEw== MIME-Version: 1.0 X-Received: by 10.68.204.234 with SMTP id lb10mr6808438pbc.64.1363274343987; Thu, 14 Mar 2013 08:19:03 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.68.131.2 with HTTP; Thu, 14 Mar 2013 08:19:03 -0700 (PDT) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6C83@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6C83@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Date: Thu, 14 Mar 2013 11:19:03 -0400 X-Google-Sender-Auth: 74D-VFJ2DOhXl7NojoWZdwwIwuI Message-ID: From: "Y. Richard Yang" To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=047d7b2e4820014bf504d7e40bd6 Cc: "i2rs@ietf.org" , IETF ALTO Subject: Re: [i2rs] Existing northbound topology API: ALTO X-BeenThere: i2rs@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: Thu, 14 Mar 2013 15:19:09 -0000 --047d7b2e4820014bf504d7e40bd6 Content-Type: text/plain; charset=ISO-8859-1 I will add some more pointers to Michael's pointer. ALTO had a side meeting last evening and quite a few extensions appear to me to be relevant to the Topology component of i2rs. A list of related docs and some slides are at: https://www.dropbox.com/sh/vbbmy91nrcpne3i/M-hg-CfI5r Comments on both ALTO and i2rs mailing lists will be very helpful indeed. Richard On Thursday, March 14, 2013, Scharf, Michael (Michael) wrote: > As mentioned on the mic: Here is an analysis how ALTO can expose > service/VPN topologies: > > http://tools.ietf.org/html/draft-scharf-alto-vpn-service-00 > > Comments on the ALTO mailing list would be very welcome. > > Thanks > > Michael > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7b2e4820014bf504d7e40bd6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I will=A0add=A0some more pointers to Michael's pointer.=A0ALTO had a si= de meeting last evening and quite a few extensions appear to me to be=A0rel= evant to the Topology component of i2rs. A list of related docs and some sl= ides are at:

Comments on both ALTO and i= 2rs mailing lists will be very helpful indeed.

Richard
= --047d7b2e4820014bf504d7e40bd6-- From xuxiaohu@huawei.com Thu Mar 14 08:20:27 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550CC11E829D for ; Thu, 14 Mar 2013 08:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 Q8DK0GypmKpr for ; Thu, 14 Mar 2013 08:20:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B8CFF11E82AD for ; Thu, 14 Mar 2013 08:20:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APJ26252; Thu, 14 Mar 2013 15:20:13 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 14 Mar 2013 15:19:34 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 14 Mar 2013 15:20:11 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.179]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Thu, 14 Mar 2013 23:20:08 +0800 From: Xuxiaohu To: Robert Raszuk , Scott Whyte Thread-Topic: [i2rs] RIB definition ... Thread-Index: AQHOIMCzJolsPZxTo0iYe6Frg5UTbpikuoEAgAAB1QCAAAFigIAAA30AgAAA7wCAAIdq5w== Date: Thu, 14 Mar 2013 15:20:08 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F51EAE@NKGEML512-MBS.china.huawei.com> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.29] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 15:20:27 -0000 SW4gc29tZSB1c2UgY2FzZXMsIEludGVyZmFjZSB0byBSb3V0aW5nIFN5c3RlbSBjYW4gYmUgc2Fm ZWx5IGludGVycHJldGVkIGFzICJpbnRlcmZhY2UgdG8gUklCIChSb3V0aW5nIEluZm9ybWF0aW9u IEJhc2UpIi4gSG93ZXZlciwgIGZvciB0aGUgVlBMUyB1c2UgY2FzZSwgc3VjaCBpbnRlcnByZXRh dGlvbiBpcyBub3QgbXVjaCBhY2N1cmF0ZS4gRm9yIGV4YW1wbGUsIGEgY29udHJvbGxlciBuZWVk cyB0byBjcmVhdGUgYSBWUExTIGluc3RhbmNlIGFuZCBib3VuZCBhIGdpdmVuIHBvcnQgdG8gdGhh dCBWUExTIGluc3RhbmNlLCBjYW4gdGhpcyB3cml0ZSBvcGVyYXRpb24gYmUgaW50ZXJwcmV0ZWQg YXMgYSB3cml0ZSBvcGVyYXRpb24gdG8gdGhlICJSSUIiPyBJbiBhZGRpdGlvbiwgYW4gQUNMIHRh YmxlIHcvciBvcGVyYXRpb24gY2FuIG5vdCBiZSBpbnRlcnByZXRlZCBhcyB3L3IgYW4gb3BlcmF0 aW9uIHRvIFJJQiBhcyB3ZWxsLiANCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1IA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGkycnMtYm91bmNlc0Bp ZXRmLm9yZyBbaTJycy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJvYmVydCBSYXN6dWsgW3JvYmVy dEByYXN6dWsubmV0XQ0Kt6LLzcqxvOQ6IDIwMTPE6jPUwjE0yNUgMjM6MDINCrW9OiBTY290dCBX aHl0ZQ0KQ2M6IGkycnNAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbaTJyc10gUklCIGRlZmluaXRpb24g Li4uDQoNCk15IG1haW4gcXVlc3Rpb24gaXMgd2hhdCBMMi1MNCBmaWVsZHMgZm9yIHRoZSBwYWNr ZXQgbG9va3VwIEkgY2FuDQpwcm9ncmFtIHRvIHRoZSAnUklCIiBieSBJMlJTLiBWZXJ5IHByZWNp c2UgYW5kIHNpbXBsZS4NCg0KVGhlIHVzZSBjYXNlIGZvciBtdWx0aXBsZSBSSUJzIGlzIGp1c3Qg YmVpbmcgc2hvd24gaW4gdGhlIHJvb20uIEwzVlBODQpQRSBhdXRvLXByb3Zpc2lvbmluZyA7KQ0K DQpCZXN0LA0KUiwuDQoNCk9uIFRodSwgTWFyIDE0LCAyMDEzIGF0IDM6NTggUE0sIFNjb3R0IFdo eXRlIDxzd2h5dGVAZ29vZ2xlLmNvbT4gd3JvdGU6DQo+IE9uIDAzLzE0LzIwMTMgMDc6NDYgQU0s IFJvYmVydCBSYXN6dWsgd3JvdGU6DQo+Pg0KPj4gSSB0aGluayB3ZSBhZ3JlZSB0aGF0IFJJQiBl bGVtZW50cyBmb3IgcmVhZCBhbmQgd3JpdGUgbXVzdCBiZSBjbGVhcmx5DQo+PiBkZWZpbmVkLiBB bmQgc2hvdWxkIGJlIGV4dGVuc2libGUuDQo+Pg0KPj4gQnV0IGlzIFJJQiBhYnN0cmFjdGlvbiBz dWZmaWNpZW50IGZvciBJMlJTID8NCj4+DQo+PiBGb3IgZXhhbXBsZSBhcyB3ZSBrbm93IGVhY2gg VlJGIGNvbnRhaW5zIGl0J3Mgb3duIFJJQiAoZGlmZmVyZW50IHRhYmxlDQo+PiBpZCkuIFNvIHBy b3RvY29sIG11c3QgYmUgYWJsZSB0byBhbHNvIGVuY29kZSB3aGljaCBSSUIgd2UgYXJlIHRhbGtp bmcNCj4+IHRvLg0KPj4NCj4+IEZ1cnRoZXIgd2hvIHdpbGwgaW5zdGFudGlhdGUgdGhlIFZSRiBp biB0aGlzIGNhc2UgPyBXaWxsIEkyUlMgYmUgYWJsZQ0KPj4gdG8gY3JlYXRlIGEgUklCIGluc3Rh bmNlIG9uIHRoZSBmbHkgPyBIb3cgd2lsbCB3ZSBhdHRhY2ggc3VjaCBSSUINCj4+IGluc3RhbmNl IHRvIGludGVyZmFjZXMgPyBUaGVyZSBpcyBkb3plbnMgb2YgZGV0YWlscyBoZXJlIHdpdGhvdXQg d2hpY2gNCj4+IEkgYW0gYWZyYWlkIHdlIGNhbid0IGdvIHByb2R1Y3RpdmVseSBmb3J3YXJkLg0K Pg0KPg0KPiBJIGd1ZXNzIEknbSBjb25mdXNlZCBub3cgb24gd2hhdCB5b3UgY29uc2lkZXIgcHJv cGlldGFyeSBpbXBsZW1lbnRhdGlvbg0KPiBkZXRhaWwgb2YgYSBSSUIsIGJ1dCBJJ2xsIGFzc3Vt ZSB5b3UgYXJlIHN0aWxsIHRhbGtpbmcgc3RyaWN0bHkgYWJvdXQgYSBSSUINCj4gYWJzdHJhY3Rp b24gYW5kIGluY3JlYXNpbmcgaXRzIHNjb3BlIHRvIG11bHRpcGxlIFJJQnMgY29tbXVuaWNhdGlu ZyB3aXRoIGENCj4gc2luZ2xlIEkyUlMgYWdlbnQuDQo+DQo+IE5vdCBzdXJlIGFib3V0IGRvemVu cyBvZiBkZXRhaWxzLCBidXQgeW91ciBmb3VyIGdvb2QgcXVlc3Rpb25zIGFib3ZlIGFsbA0KPiBz ZWVtIHRvIHJldm9sdmUgYXJvdW5kIGEgc2luZ2xlIGlzc3VlLCBoYW5kbGluZyBvZiBtdWx0aXBs ZSBSSUJzLCB3aGljaCBJDQo+IHRoaW5rIGlzIGltcG9ydGFudCB0byBoYXZlIGFzIGEgdXNlIGNh c2UuDQo+DQo+IC1TY290dA0KPg0KPg0KPg0KPj4NCj4+IEJlc3QsDQo+PiBSLg0KPj4NCj4+DQo+ PiBPbiBUaHUsIE1hciAxNCwgMjAxMyBhdCAzOjQxIFBNLCBTY290dCBXaHl0ZSA8c3doeXRlQGdv b2dsZS5jb20+IHdyb3RlOg0KPj4+DQo+Pj4gT24gMDMvMTQvMjAxMyAwNzozNCBBTSwgUm9iZXJ0 IFJhc3p1ayB3cm90ZToNCj4+Pj4NCj4+Pj4NCj4+Pj4gSGkgU2NvdHQsDQo+Pj4+DQo+Pj4+PiBX aHkgZG8gd2UgbmVlZCB0byBnbyBiZXlvbmQgZGVmaW5pbmcgYW4gaW50ZXJmYWNlIHRvIHRoZSBS SUIgdG8gbWFrZQ0KPj4+Pj4geW91cg0KPj4+Pj4gdXNlIGNhc2Ugd29yaz8NCj4+Pj4NCj4+Pj4N Cj4+Pj4NCj4+Pj4gSSBhbSB0YWxraW5nIHByZWNpc2UgYWJvdXQgdGhhdCBkZWZpbml0aW9uIG9m IFJJQiBpbnRlcmZhY2UuIE5vdCBob3cNCj4+Pj4gdGhlIFJJQiB3b3JrcyBpbiBnaXZlbiB2ZW5k b3Igb2YgbmV0d29yayBlbGVtZW50LiBUaGF0IGlzDQo+Pj4+IGltcGxlbWVudGF0aW9uIGRldGFp bC4NCj4+Pj4NCj4+Pj4gQmFzaWNhbGx5IGEgbGlzdCBvZiB2YWx1ZXMgb25lIGNhbiB3cml0ZSBv ciByZWFkIHRvL2Zyb20gUklCLiBIYXZlIHlvdQ0KPj4+PiBzZWVuIGFueSBkb2N1bWVudCB3aXRo IHN1Y2ggbGlzdCB5ZXQgPw0KPj4+DQo+Pj4NCj4+Pg0KPj4+IFNvIHdlIGFncmVlIHRoYXQgd2hh dCBhIFJJQiBsb29rcyBsaWtlIGlzIG91dCBvZiBzY29wZSwgYW5kIHdlIG5lZWQgdG8NCj4+PiBp bnN1cmUgZXh0ZW5zaWJpbGl0eSBiZXlvbmQgcHJvcG9zZWQgdXNlIGNhc2VzIGZvciB0aGUgYWN0 dWFsIFJJQg0KPj4+IGludGVyZmFjZT8NCj4+PiBJZiBzbyBJIHRoaW5rIHRoZSBncm91cCBpcyB3 ZWxsIG9uIHRyYWNrIHRvIGdldCB0aGVyZSwgYXMgd2UgZ3JpbmQNCj4+PiB0aHJvdWdoDQo+Pj4g dXNlIGNhc2VzIGFuZCBleGlzdGluZyBkYXRhIG1vZGVscy4NCj4+Pg0KPj4+IC1TY290dA0KPj4+ DQo+Pj4+DQo+Pj4+IENoZWVycywNCj4+Pj4gUi4NCj4+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0NCj4+ PiBQZW9wbGUgd2hvIGFyZSBlc3NlbnRpYWxseSB3aXRob3V0IHRoZSBwb3dlciB0byBpbXBsZW1l bnQgdGhlaXIgaWRlYXMgaW4NCj4+PiB0aGUNCj4+PiByZWFsIHdvcmxkIG11c3QgbGV2ZXJhZ2Ug dGhlIHBvd2VyIG9mIHRoZWlyIHJlcHV0YXRpb25zLg0KPg0KPg0KPg0KPiAtLQ0KPiBQZW9wbGUg d2hvIGFyZSBlc3NlbnRpYWxseSB3aXRob3V0IHRoZSBwb3dlciB0byBpbXBsZW1lbnQgdGhlaXIg aWRlYXMgaW4gdGhlDQo+IHJlYWwgd29ybGQgbXVzdCBsZXZlcmFnZSB0aGUgcG93ZXIgb2YgdGhl aXIgcmVwdXRhdGlvbnMuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KaTJycyBtYWlsaW5nIGxpc3QNCmkycnNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw== From russw@riw.us Thu Mar 14 08:21:01 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E3211E8221 for ; Thu, 14 Mar 2013 08:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, 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 AsvvhtmSJ-T3 for ; Thu, 14 Mar 2013 08:21:00 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id B419111E82B1 for ; Thu, 14 Mar 2013 08:20:55 -0700 (PDT) Received: from dhcp-13ef.meeting.ietf.org ([130.129.19.239]) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UG9xe-000660-PV; Thu, 14 Mar 2013 08:20:55 -0700 References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Russ White Date: Thu, 14 Mar 2013 11:20:52 -0400 To: Robert Raszuk X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 15:21:01 -0000 Vlan, I think, might fit into a table ID... ?? MPLS tag I would include under next hop in general (take out IP)... ? :-) Russ <>< russw@riw.us On Mar 14, 2013, at 11:17 AM, Robert Raszuk wrote: > Hi Russ ... >=20 > For me the base set is completely not sufficient for any of the > application I would use I2RS for. >=20 > As example: it is missing match on VLAN, set MPLS VPN label, set MPLS > transport label. >=20 > r. >=20 >> On Thu, Mar 14, 2013 at 4:14 PM, Russ White wrote: >>=20 >> I wouldn't frame the question in terms of the packet header but the routi= ng table... I don't know that the answer comes out different, but... :-) >>=20 >> That said, I think a good base set would be: >>=20 >> - Dest IP Address >> - Next hop IP address >> - Outbound interface >> - Admin distance >> - Some form of tags >> - Table ID >>=20 >> We've talked about the ad,in distance being more like a community string t= han an integer (having multiple parts so you can have several types of metri= cs here), but I don't know how useful that would be. I'm all for thinking pa= st the immediate need and leaving doors open for unthought of things, though= . >>=20 >> There's also the back channel out of the rib to consider -- specifically,= things like, "your route was just overwritten by another process," "a route= was just redistributed to you," "the next hop for this route just went away= ," "this connected route just failed," and other related stuff. >>=20 >> But I think we might need to get the use cases to give us what informatio= n they need, and work build a good list from that. Then we can ask the quest= ion, "is there a model that fits already?" >>=20 >> :-) >>=20 >> Russ >>=20 >>=20 >> <>< >> russw@riw.us >>=20 >> On Mar 14, 2013, at 11:02 AM, Robert Raszuk wrote: >>=20 >>> My main question is what L2-L4 fields for the packet lookup I can >>> program to the 'RIB" by I2RS. Very precise and simple. >>>=20 >>> The use case for multiple RIBs is just being shown in the room. L3VPN >>> PE auto-provisioning ;) >>>=20 >>> Best, >>> R,. >>>=20 >>> On Thu, Mar 14, 2013 at 3:58 PM, Scott Whyte wrote: >>>> On 03/14/2013 07:46 AM, Robert Raszuk wrote: >>>>>=20 >>>>> I think we agree that RIB elements for read and write must be clearly >>>>> defined. And should be extensible. >>>>>=20 >>>>> But is RIB abstraction sufficient for I2RS ? >>>>>=20 >>>>> For example as we know each VRF contains it's own RIB (different table= >>>>> id). So protocol must be able to also encode which RIB we are talking >>>>> to. >>>>>=20 >>>>> Further who will instantiate the VRF in this case ? Will I2RS be able >>>>> to create a RIB instance on the fly ? How will we attach such RIB >>>>> instance to interfaces ? There is dozens of details here without which= >>>>> I am afraid we can't go productively forward. >>>>=20 >>>>=20 >>>> I guess I'm confused now on what you consider propietary implementation= >>>> detail of a RIB, but I'll assume you are still talking strictly about a= RIB >>>> abstraction and increasing its scope to multiple RIBs communicating wit= h a >>>> single I2RS agent. >>>>=20 >>>> Not sure about dozens of details, but your four good questions above al= l >>>> seem to revolve around a single issue, handling of multiple RIBs, which= I >>>> think is important to have as a use case. >>>>=20 >>>> -Scott >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Best, >>>>> R. >>>>>=20 >>>>>=20 >>>>> On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte wrote= : >>>>>>=20 >>>>>> On 03/14/2013 07:34 AM, Robert Raszuk wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> Hi Scott, >>>>>>>=20 >>>>>>>> Why do we need to go beyond defining an interface to the RIB to mak= e >>>>>>>> your >>>>>>>> use case work? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I am talking precise about that definition of RIB interface. Not how= >>>>>>> the RIB works in given vendor of network element. That is >>>>>>> implementation detail. >>>>>>>=20 >>>>>>> Basically a list of values one can write or read to/from RIB. Have y= ou >>>>>>> seen any document with such list yet ? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> So we agree that what a RIB looks like is out of scope, and we need t= o >>>>>> insure extensibility beyond proposed use cases for the actual RIB >>>>>> interface? >>>>>> If so I think the group is well on track to get there, as we grind >>>>>> through >>>>>> use cases and existing data models. >>>>>>=20 >>>>>> -Scott >>>>>>=20 >>>>>>>=20 >>>>>>> Cheers, >>>>>>> R. >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> People who are essentially without the power to implement their ideas= in >>>>>> the >>>>>> real world must leverage the power of their reputations. >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> People who are essentially without the power to implement their ideas i= n the >>>> real world must leverage the power of their reputations. >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From tnadeau@juniper.net Thu Mar 14 08:24:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A07511E823C for ; Thu, 14 Mar 2013 08:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 evdx9dZEi-Zf for ; Thu, 14 Mar 2013 08:24:04 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id B075311E81D1 for ; Thu, 14 Mar 2013 08:23:54 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUUHriQnsH/IfX3zO6zdtg+cG2Ak7P1CA@postini.com; Thu, 14 Mar 2013 08:23:54 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 14 Mar 2013 08:18:50 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 14 Mar 2013 08:18:50 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.15) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 14 Mar 2013 08:28:10 -0700 Received: from mail224-tx2-R.bigfish.com (10.9.14.230) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Mar 2013 15:18:49 +0000 Received: from mail224-tx2 (localhost [127.0.0.1]) by mail224-tx2-R.bigfish.com (Postfix) with ESMTP id 70D3494019A for ; Thu, 14 Mar 2013 15:18:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -16 X-BigFish: PS-16(z426fnz98dI9371Ic85fhzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dh18c673h8275bhz2dh2a8h668h839hbe3hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail224-tx2 (localhost.localdomain [127.0.0.1]) by mail224-tx2 (MessageSwitch) id 136327427940452_24398; Thu, 14 Mar 2013 15:17:59 +0000 (UTC) Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.231]) by mail224-tx2.bigfish.com (Postfix) with ESMTP id 9F886CC00E9; Thu, 14 Mar 2013 15:17:54 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Mar 2013 15:17:53 +0000 Received: from CH1PRD0511MB420.namprd05.prod.outlook.com ([169.254.9.245]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0275.006; Thu, 14 Mar 2013 15:17:52 +0000 From: Thomas Nadeau To: Dave Hood Thread-Topic: [i2rs] info vs data models Thread-Index: AQHOIMcYUYwCJ+kj0kyUdqZ3CQ7w/w== Date: Thu, 14 Mar 2013 15:17:52 +0000 Message-ID: References: <8D15A2BAF93E9C49AB037A0647E5FA6405F4B6EB@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA6405F4B6EB@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.137.94.58] Content-Type: multipart/alternative; boundary="_000_CC984DC563114C5CB97FF5CEAE232BADjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "i2rs@ietf.org" Subject: Re: [i2rs] info vs data models X-BeenThere: i2rs@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: Thu, 14 Mar 2013 15:24:05 -0000 --_000_CC984DC563114C5CB97FF5CEAE232BADjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable while its somewhat preferable to start with the info model, you certainly c= an go in the direction described. tools exist for the automation of this to= o. Tom On Mar 14, 2013, at 11:12 AM, "Dave Hood" > wrote: There seems to be continuing confusion about info vs data models, including= the current presentation about building a yang data model that can *then* = be converted into an info model. RFC 3444 is worth reading. _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_CC984DC563114C5CB97FF5CEAE232BADjunipernet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
while its somewhat preferable to start with the info model, you certai= nly can go in the direction described. tools exist for the automation of th= is too.

Tom 

On Mar 14, 2013, at 11:12 AM, "Dave Hood" <dave.hood@ericsson.com> wrote:

There seems to be continuing confu= sion about info vs data models, including the current presentation about bu= ilding a yang data model that can *then* be converted into an info model.

 

RFC 3444 is worth reading.

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ie= tf.org/mailman/listinfo/i2rs
--_000_CC984DC563114C5CB97FF5CEAE232BADjunipernet_-- From rraszuk@gmail.com Thu Mar 14 08:24:12 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77F411E82B7 for ; Thu, 14 Mar 2013 08:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 ew6Hj65ntz+4 for ; Thu, 14 Mar 2013 08:24:12 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6B111E8290 for ; Thu, 14 Mar 2013 08:24:12 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id c11so3218770ieb.29 for ; Thu, 14 Mar 2013 08:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=27soV+y/DhtVGLV/B99TqNR4Yfpup+xXJMuf/ftSZ2U=; b=uEQBLoxkOH6Cbifk8pc86l55nmm1diWfecPORS9vRQm5AS3RIWIagj1WV+mDARTzyY TxWEEpSB170/Z4Hp/WwuwNqaflMZnedY3UpYv223YESn7EYicntcKA5DMyPZwFawanMO GpVCBc8tOgQ8CeWm3tyGNgg/VZ8I15CefrNbzV17PR2NicgRZHXWDuLw4ZigNnCYt4+G 9qCNBxOFgbYr0w3gdYrDAOYKKF7N3XOnso/aaegvsRWayaN4248ERodpP9cTGBya8bJD bSx0P0WrZRzbJh19KiQ/wG3arID6rFVoXfTRJt3gPAHpjnEbXgoYLyQM5CspbRaU9+7V Spjg== MIME-Version: 1.0 X-Received: by 10.50.57.168 with SMTP id j8mr20763062igq.51.1363274651220; Thu, 14 Mar 2013 08:24:11 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 08:24:11 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> Date: Thu, 14 Mar 2013 16:24:11 +0100 X-Google-Sender-Auth: cdTx_Z3IIdtM9JD0lTsWfLBRA9Y Message-ID: From: Robert Raszuk To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 15:24:13 -0000 > Vlan, I think, might fit into a table ID... ?? Well it depends who binds this VLAN to a table ID on the network element. > MPLS tag I would include under next hop in general (take out IP)... ? Well for transport MPLS analogy yes, but for application MPLS label (example VPN label) this is not really a next hop property. r. From russw@riw.us Thu Mar 14 09:47:52 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700C111E8110 for ; Thu, 14 Mar 2013 09:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.103 X-Spam-Level: X-Spam-Status: No, score=-1.103 tagged_above=-999 required=5 tests=[AWL=0.100, 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 X6kNc3zT4HaL for ; Thu, 14 Mar 2013 09:47:51 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id E26A911E80E7 for ; Thu, 14 Mar 2013 09:47:51 -0700 (PDT) Received: from dhcp-13ef.meeting.ietf.org ([130.129.19.239]) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UGBJm-0003hj-Q4; Thu, 14 Mar 2013 09:47:51 -0700 References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Russ White Date: Thu, 14 Mar 2013 12:47:49 -0400 To: Robert Raszuk X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 16:47:52 -0000 Actually, several folks talked at lunch, and defining the data model first m= ight be precisely the wrong thing to do... Let me just throw it out for disc= ussion-- Is it better to define the information needed to forward a packet as a data m= odel, so we simply leave the problem of defining a "rib," etc., as something= we can ignore? In other words, if we start from the packet end, do we simpl= ify our problem in a major way? :-) Russ <>< russw@riw.us On Mar 14, 2013, at 11:24 AM, Robert Raszuk wrote: >> Vlan, I think, might fit into a table ID... ?? >=20 > Well it depends who binds this VLAN to a table ID on the network element. >=20 >> MPLS tag I would include under next hop in general (take out IP)... ? >=20 > Well for transport MPLS analogy yes, but for application MPLS label > (example VPN label) this is not really a next hop property. >=20 > r. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From ju1738@att.com Thu Mar 14 10:35:20 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A349821F90F5 for ; Thu, 14 Mar 2013 10:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 2JkhzCOLdgbj for ; Thu, 14 Mar 2013 10:35:16 -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 A943D21F90F1 for ; Thu, 14 Mar 2013 10:35:16 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 45a02415.2aab08a60940.222146.00-508.620227.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 14 Mar 2013 17:35:16 +0000 (UTC) X-MXL-Hash: 51420a54770e27da-4833fa3486a72ccf5079d7340c9129b8b0d07a84 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 35a02415.0.222137.00-499.620194.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 14 Mar 2013 17:35:16 +0000 (UTC) X-MXL-Hash: 51420a54561fd8b6-5318d1d8e1f6833cde2e7c0476d91b27eaa05b8f 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 r2EHZE9l018942; Thu, 14 Mar 2013 13:35:15 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2EHZAVT018899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 13:35:13 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 14 Mar 2013 17:34:56 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 13:34:55 -0400 From: "UTTARO, JAMES" To: "'Xuxiaohu'" , Robert Raszuk , "Scott Whyte" Thread-Topic: [i2rs] RIB definition ... Thread-Index: AQHOIMUfobcabF7aF0S5MYDZFa+Y3ZilkFYA///iITA= Date: Thu, 14 Mar 2013 17:34:55 +0000 Message-ID: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F51EAE@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F51EAE@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.120.154] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 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=2.0 cv=C4teP3z+ c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=4TgIERKGEI8A:10 a=L2kbtXBQjhkA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=_l4uJm6h9gAA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=O_51BKbUSokA:10 a=48vgC7mUAAAA:8 a=2clOPd4PAAAA:8] X-AnalysisOut: [ a=1XWaLZrsAAAA:8 a=oTmJcunP_dn9A3hDAw0A:9 a=mFyHDrcPJccA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=bDUki_mJ7DgA:10 a=UTB_XpHje0EA:10 a] X-AnalysisOut: [=QlJu0piXUmjhTdc2:21 a=EzDHzmmP7nJ0mJ87:21] Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 17:35:20 -0000 YW5kIHRoZW4gYXNzb2NpYXRlIHRoZSByaWdodCBsYWJlbCBibG9ja3MgKCBCR1AgRmxhdm9yICkg d2hpY2ggaXMgZGVyaXZlZCBieSBvdGhlciBpbmZvIGFzIHRvIHRoZSBkZWZpbml0aW9uIG9mIHRo ZSBjb250ZXh0Li4uLiBJIHRoaW5rIGl0IG1heSBiZSBiZXR0ZXIgdG8gaGF2ZSB0aGUgY29udHJv bGxlciBpbmZvcm0gdGhlIGRpc3RyaWJ1dGVkIHByb3RvY29sIGFzIHRvIHRoZSBhY3Rpb24gdG8g YmUgdGFrZW4uLg0KDQpKaW0gVXR0YXJvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBpMnJzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBYdXhpYW9odQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDE0LCAyMDEzIDEx OjIwIEFNDQpUbzogUm9iZXJ0IFJhc3p1azsgU2NvdHQgV2h5dGUNCkNjOiBpMnJzQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW2kycnNdIFJJQiBkZWZpbml0aW9uIC4uLg0KDQpJbiBzb21lIHVzZSBj YXNlcywgSW50ZXJmYWNlIHRvIFJvdXRpbmcgU3lzdGVtIGNhbiBiZSBzYWZlbHkgaW50ZXJwcmV0 ZWQgYXMgImludGVyZmFjZSB0byBSSUIgKFJvdXRpbmcgSW5mb3JtYXRpb24gQmFzZSkiLiBIb3dl dmVyLCAgZm9yIHRoZSBWUExTIHVzZSBjYXNlLCBzdWNoIGludGVycHJldGF0aW9uIGlzIG5vdCBt dWNoIGFjY3VyYXRlLiBGb3IgZXhhbXBsZSwgYSBjb250cm9sbGVyIG5lZWRzIHRvIGNyZWF0ZSBh IFZQTFMgaW5zdGFuY2UgYW5kIGJvdW5kIGEgZ2l2ZW4gcG9ydCB0byB0aGF0IFZQTFMgaW5zdGFu Y2UsIGNhbiB0aGlzIHdyaXRlIG9wZXJhdGlvbiBiZSBpbnRlcnByZXRlZCBhcyBhIHdyaXRlIG9w ZXJhdGlvbiB0byB0aGUgIlJJQiI/IEluIGFkZGl0aW9uLCBhbiBBQ0wgdGFibGUgdy9yIG9wZXJh dGlvbiBjYW4gbm90IGJlIGludGVycHJldGVkIGFzIHcvciBhbiBvcGVyYXRpb24gdG8gUklCIGFz IHdlbGwuIA0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUgDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCreivP7IyzogaTJycy1ib3VuY2VzQGlldGYub3JnIFtpMnJz LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUm9iZXJ0IFJhc3p1ayBbcm9iZXJ0QHJhc3p1ay5uZXRd DQq3osvNyrG85DogMjAxM8TqM9TCMTTI1SAyMzowMg0Ktb06IFNjb3R0IFdoeXRlDQpDYzogaTJy c0BpZXRmLm9yZw0K1vfM4jogUmU6IFtpMnJzXSBSSUIgZGVmaW5pdGlvbiAuLi4NCg0KTXkgbWFp biBxdWVzdGlvbiBpcyB3aGF0IEwyLUw0IGZpZWxkcyBmb3IgdGhlIHBhY2tldCBsb29rdXAgSSBj YW4NCnByb2dyYW0gdG8gdGhlICdSSUIiIGJ5IEkyUlMuIFZlcnkgcHJlY2lzZSBhbmQgc2ltcGxl Lg0KDQpUaGUgdXNlIGNhc2UgZm9yIG11bHRpcGxlIFJJQnMgaXMganVzdCBiZWluZyBzaG93biBp biB0aGUgcm9vbS4gTDNWUE4NClBFIGF1dG8tcHJvdmlzaW9uaW5nIDspDQoNCkJlc3QsDQpSLC4N Cg0KT24gVGh1LCBNYXIgMTQsIDIwMTMgYXQgMzo1OCBQTSwgU2NvdHQgV2h5dGUgPHN3aHl0ZUBn b29nbGUuY29tPiB3cm90ZToNCj4gT24gMDMvMTQvMjAxMyAwNzo0NiBBTSwgUm9iZXJ0IFJhc3p1 ayB3cm90ZToNCj4+DQo+PiBJIHRoaW5rIHdlIGFncmVlIHRoYXQgUklCIGVsZW1lbnRzIGZvciBy ZWFkIGFuZCB3cml0ZSBtdXN0IGJlIGNsZWFybHkNCj4+IGRlZmluZWQuIEFuZCBzaG91bGQgYmUg ZXh0ZW5zaWJsZS4NCj4+DQo+PiBCdXQgaXMgUklCIGFic3RyYWN0aW9uIHN1ZmZpY2llbnQgZm9y IEkyUlMgPw0KPj4NCj4+IEZvciBleGFtcGxlIGFzIHdlIGtub3cgZWFjaCBWUkYgY29udGFpbnMg aXQncyBvd24gUklCIChkaWZmZXJlbnQgdGFibGUNCj4+IGlkKS4gU28gcHJvdG9jb2wgbXVzdCBi ZSBhYmxlIHRvIGFsc28gZW5jb2RlIHdoaWNoIFJJQiB3ZSBhcmUgdGFsa2luZw0KPj4gdG8uDQo+ Pg0KPj4gRnVydGhlciB3aG8gd2lsbCBpbnN0YW50aWF0ZSB0aGUgVlJGIGluIHRoaXMgY2FzZSA/ IFdpbGwgSTJSUyBiZSBhYmxlDQo+PiB0byBjcmVhdGUgYSBSSUIgaW5zdGFuY2Ugb24gdGhlIGZs eSA/IEhvdyB3aWxsIHdlIGF0dGFjaCBzdWNoIFJJQg0KPj4gaW5zdGFuY2UgdG8gaW50ZXJmYWNl cyA/IFRoZXJlIGlzIGRvemVucyBvZiBkZXRhaWxzIGhlcmUgd2l0aG91dCB3aGljaA0KPj4gSSBh bSBhZnJhaWQgd2UgY2FuJ3QgZ28gcHJvZHVjdGl2ZWx5IGZvcndhcmQuDQo+DQo+DQo+IEkgZ3Vl c3MgSSdtIGNvbmZ1c2VkIG5vdyBvbiB3aGF0IHlvdSBjb25zaWRlciBwcm9waWV0YXJ5IGltcGxl bWVudGF0aW9uDQo+IGRldGFpbCBvZiBhIFJJQiwgYnV0IEknbGwgYXNzdW1lIHlvdSBhcmUgc3Rp bGwgdGFsa2luZyBzdHJpY3RseSBhYm91dCBhIFJJQg0KPiBhYnN0cmFjdGlvbiBhbmQgaW5jcmVh c2luZyBpdHMgc2NvcGUgdG8gbXVsdGlwbGUgUklCcyBjb21tdW5pY2F0aW5nIHdpdGggYQ0KPiBz aW5nbGUgSTJSUyBhZ2VudC4NCj4NCj4gTm90IHN1cmUgYWJvdXQgZG96ZW5zIG9mIGRldGFpbHMs IGJ1dCB5b3VyIGZvdXIgZ29vZCBxdWVzdGlvbnMgYWJvdmUgYWxsDQo+IHNlZW0gdG8gcmV2b2x2 ZSBhcm91bmQgYSBzaW5nbGUgaXNzdWUsIGhhbmRsaW5nIG9mIG11bHRpcGxlIFJJQnMsIHdoaWNo IEkNCj4gdGhpbmsgaXMgaW1wb3J0YW50IHRvIGhhdmUgYXMgYSB1c2UgY2FzZS4NCj4NCj4gLVNj b3R0DQo+DQo+DQo+DQo+Pg0KPj4gQmVzdCwNCj4+IFIuDQo+Pg0KPj4NCj4+IE9uIFRodSwgTWFy IDE0LCAyMDEzIGF0IDM6NDEgUE0sIFNjb3R0IFdoeXRlIDxzd2h5dGVAZ29vZ2xlLmNvbT4gd3Jv dGU6DQo+Pj4NCj4+PiBPbiAwMy8xNC8yMDEzIDA3OjM0IEFNLCBSb2JlcnQgUmFzenVrIHdyb3Rl Og0KPj4+Pg0KPj4+Pg0KPj4+PiBIaSBTY290dCwNCj4+Pj4NCj4+Pj4+IFdoeSBkbyB3ZSBuZWVk IHRvIGdvIGJleW9uZCBkZWZpbmluZyBhbiBpbnRlcmZhY2UgdG8gdGhlIFJJQiB0byBtYWtlDQo+ Pj4+PiB5b3VyDQo+Pj4+PiB1c2UgY2FzZSB3b3JrPw0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBJ IGFtIHRhbGtpbmcgcHJlY2lzZSBhYm91dCB0aGF0IGRlZmluaXRpb24gb2YgUklCIGludGVyZmFj ZS4gTm90IGhvdw0KPj4+PiB0aGUgUklCIHdvcmtzIGluIGdpdmVuIHZlbmRvciBvZiBuZXR3b3Jr IGVsZW1lbnQuIFRoYXQgaXMNCj4+Pj4gaW1wbGVtZW50YXRpb24gZGV0YWlsLg0KPj4+Pg0KPj4+ PiBCYXNpY2FsbHkgYSBsaXN0IG9mIHZhbHVlcyBvbmUgY2FuIHdyaXRlIG9yIHJlYWQgdG8vZnJv bSBSSUIuIEhhdmUgeW91DQo+Pj4+IHNlZW4gYW55IGRvY3VtZW50IHdpdGggc3VjaCBsaXN0IHll dCA/DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gU28gd2UgYWdyZWUgdGhhdCB3aGF0IGEgUklCIGxvb2tz IGxpa2UgaXMgb3V0IG9mIHNjb3BlLCBhbmQgd2UgbmVlZCB0bw0KPj4+IGluc3VyZSBleHRlbnNp YmlsaXR5IGJleW9uZCBwcm9wb3NlZCB1c2UgY2FzZXMgZm9yIHRoZSBhY3R1YWwgUklCDQo+Pj4g aW50ZXJmYWNlPw0KPj4+IElmIHNvIEkgdGhpbmsgdGhlIGdyb3VwIGlzIHdlbGwgb24gdHJhY2sg dG8gZ2V0IHRoZXJlLCBhcyB3ZSBncmluZA0KPj4+IHRocm91Z2gNCj4+PiB1c2UgY2FzZXMgYW5k IGV4aXN0aW5nIGRhdGEgbW9kZWxzLg0KPj4+DQo+Pj4gLVNjb3R0DQo+Pj4NCj4+Pj4NCj4+Pj4g Q2hlZXJzLA0KPj4+PiBSLg0KPj4+Pg0KPj4+DQo+Pj4NCj4+PiAtLQ0KPj4+IFBlb3BsZSB3aG8g YXJlIGVzc2VudGlhbGx5IHdpdGhvdXQgdGhlIHBvd2VyIHRvIGltcGxlbWVudCB0aGVpciBpZGVh cyBpbg0KPj4+IHRoZQ0KPj4+IHJlYWwgd29ybGQgbXVzdCBsZXZlcmFnZSB0aGUgcG93ZXIgb2Yg dGhlaXIgcmVwdXRhdGlvbnMuDQo+DQo+DQo+DQo+IC0tDQo+IFBlb3BsZSB3aG8gYXJlIGVzc2Vu dGlhbGx5IHdpdGhvdXQgdGhlIHBvd2VyIHRvIGltcGxlbWVudCB0aGVpciBpZGVhcyBpbiB0aGUN Cj4gcmVhbCB3b3JsZCBtdXN0IGxldmVyYWdlIHRoZSBwb3dlciBvZiB0aGVpciByZXB1dGF0aW9u cy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppMnJz IG1haWxpbmcgbGlzdA0KaTJyc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pMnJzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KaTJycyBtYWlsaW5nIGxpc3QNCmkycnNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0K From akatlas@gmail.com Thu Mar 14 10:45:18 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4131911E8146 for ; Thu, 14 Mar 2013 10:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 FhoHXR7T7XpJ for ; Thu, 14 Mar 2013 10:45:17 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id ADB5011E813F for ; Thu, 14 Mar 2013 10:45:17 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id c11so3380523ieb.1 for ; Thu, 14 Mar 2013 10:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Qc2xNxW4Pjbvca/+j6zpqvsPut3U1Thf0KZy1zjP+2k=; b=UQ2tKNO/X24OmY2Yyf0EI8Azo+bjo7R2W+BMHQA7QHroQ/Ur2Je+ow8Gmy517Yv7bk /i2BC4wiDcsKAz4qOYHL2JeUsYsAWnZuQ5mesfoguh9DhWpagMj3mTBtpwbWlzsjHqqw bu/EcGlzfELz7EVSXgaq8IdIoExarJxp0sgm/2gvnRxNLme6WWzkFh4zTD9urePL8qDU rM1eZ10ptUHlScy5CfPANLBvAbNWVclwRzh/OtBjn9hfFAbGkCw4gjEbVo4VCsv9JZjB IPxeWs5d4Q24vWQPUx10pCzVE69ALjv+q7Y5Li+2nOoUTTmFStV988XQeEUYILipgtwi ftTg== MIME-Version: 1.0 X-Received: by 10.50.47.168 with SMTP id e8mr3185359ign.50.1363282982211; Thu, 14 Mar 2013 10:43:02 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Thu, 14 Mar 2013 10:43:02 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> Date: Thu, 14 Mar 2013 13:43:02 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 17:45:18 -0000 Rob, Yes - there is lots of work to do. Exactly what is needed in the information models is something I'm hoping the use-cases will help with. The framework gives a first concept of the type of data that I thought would describe a route for the RIB (also RIB layer - not just IPv4/IPv6 RIB). The case of routing on destination IP address plus an L4 port is different, of course - that is asking for NEW functionality in the forwarding plane from what is commonly there beyond support via ACLs/PBRs. I don't personally see i2rs as providing the necessary translation mechanism - but that's with the WG chair hat off. Alia On Thu, Mar 14, 2013 at 10:46 AM, Robert Raszuk wrote: > I think we agree that RIB elements for read and write must be clearly > defined. And should be extensible. > > But is RIB abstraction sufficient for I2RS ? > > For example as we know each VRF contains it's own RIB (different table > id). So protocol must be able to also encode which RIB we are talking > to. > > Further who will instantiate the VRF in this case ? Will I2RS be able > to create a RIB instance on the fly ? How will we attach such RIB > instance to interfaces ? There is dozens of details here without which > I am afraid we can't go productively forward. > > Best, > R. > > > On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte wrote: >> On 03/14/2013 07:34 AM, Robert Raszuk wrote: >>> >>> Hi Scott, >>> >>>> Why do we need to go beyond defining an interface to the RIB to make your >>>> use case work? >>> >>> >>> I am talking precise about that definition of RIB interface. Not how >>> the RIB works in given vendor of network element. That is >>> implementation detail. >>> >>> Basically a list of values one can write or read to/from RIB. Have you >>> seen any document with such list yet ? >> >> >> So we agree that what a RIB looks like is out of scope, and we need to >> insure extensibility beyond proposed use cases for the actual RIB interface? >> If so I think the group is well on track to get there, as we grind through >> use cases and existing data models. >> >> -Scott >> >>> >>> Cheers, >>> R. >>> >> >> >> -- >> People who are essentially without the power to implement their ideas in the >> real world must leverage the power of their reputations. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From akatlas@gmail.com Thu Mar 14 10:46:39 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA0711E80E9 for ; Thu, 14 Mar 2013 10:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, NO_RELAYS=-0.001] 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 MDex6RKSTgAm for ; Thu, 14 Mar 2013 10:46:38 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A85FB11E8110 for ; Thu, 14 Mar 2013 10:46:35 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id k10so3381131iea.33 for ; Thu, 14 Mar 2013 10:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=AP6KgfNf5U1NdjA4z/Rv5GIOqHPRh/NtSlqgjEOxu90=; b=HbdKKslDYZeHOsc2Deea/tOOKuuXDlRh5fdHesNsL5DbXxarKzZkpUIfNVzYP4RNu1 6X56VDYn6OM7kAw/YsmXrJjRychP9BW/xD4ldf5rtCVPjrukirzRP6mOL+p6Rpa0zwNh J+lSB40RbnnhCiYHxyXP3m83XOOBTYMCxgT8gcuIFDpmMGd47lWEvwxmF47jymS2mKqg lB+x2w1dXRrixIFKUZN8qTyEOufMckNyrYQCciDhTq9EZWGdXZc30HbBGLabY7konK9t XLoWM+ajHZpC5Hbw1Utnz9ibe53r2WGFj71XPVweEXUxEBpNqJj+zhDj5N6ka4IAP7nT 4PCA== MIME-Version: 1.0 X-Received: by 10.50.17.166 with SMTP id p6mr15424255igd.12.1363283195285; Thu, 14 Mar 2013 10:46:35 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Thu, 14 Mar 2013 10:46:35 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> Date: Thu, 14 Mar 2013 13:46:35 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Russ White , "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 17:46:39 -0000 I do see setting an MPLS label as a characteristic of a next-hop. The concern will be describing capabilities reasonably without a rat-hole. This is doing L3 routing - so VLAN matching seems out; while there may be PWE3 or L2VPN type use-cases eventually, I've not seen them yet. Alia On Thu, Mar 14, 2013 at 11:17 AM, Robert Raszuk wrote: > Hi Russ ... > > For me the base set is completely not sufficient for any of the > application I would use I2RS for. > > As example: it is missing match on VLAN, set MPLS VPN label, set MPLS > transport label. > > r. > >> On Thu, Mar 14, 2013 at 4:14 PM, Russ White wrote: >> >> I wouldn't frame the question in terms of the packet header but the rout= ing table... I don't know that the answer comes out different, but... :-) >> >> That said, I think a good base set would be: >> >> - Dest IP Address >> - Next hop IP address >> - Outbound interface >> - Admin distance >> - Some form of tags >> - Table ID >> >> We've talked about the ad,in distance being more like a community string= than an integer (having multiple parts so you can have several types of me= trics here), but I don't know how useful that would be. I'm all for thinkin= g past the immediate need and leaving doors open for unthought of things, t= hough. >> >> There's also the back channel out of the rib to consider -- specifically= , things like, "your route was just overwritten by another process," "a rou= te was just redistributed to you," "the next hop for this route just went a= way," "this connected route just failed," and other related stuff. >> >> But I think we might need to get the use cases to give us what informati= on they need, and work build a good list from that. Then we can ask the que= stion, "is there a model that fits already?" >> >> :-) >> >> Russ >> >> >> <>< >> russw@riw.us >> >> On Mar 14, 2013, at 11:02 AM, Robert Raszuk wrote: >> >>> My main question is what L2-L4 fields for the packet lookup I can >>> program to the 'RIB" by I2RS. Very precise and simple. >>> >>> The use case for multiple RIBs is just being shown in the room. L3VPN >>> PE auto-provisioning ;) >>> >>> Best, >>> R,. >>> >>> On Thu, Mar 14, 2013 at 3:58 PM, Scott Whyte wrote: >>>> On 03/14/2013 07:46 AM, Robert Raszuk wrote: >>>>> >>>>> I think we agree that RIB elements for read and write must be clearly >>>>> defined. And should be extensible. >>>>> >>>>> But is RIB abstraction sufficient for I2RS ? >>>>> >>>>> For example as we know each VRF contains it's own RIB (different tabl= e >>>>> id). So protocol must be able to also encode which RIB we are talking >>>>> to. >>>>> >>>>> Further who will instantiate the VRF in this case ? Will I2RS be able >>>>> to create a RIB instance on the fly ? How will we attach such RIB >>>>> instance to interfaces ? There is dozens of details here without whic= h >>>>> I am afraid we can't go productively forward. >>>> >>>> >>>> I guess I'm confused now on what you consider propietary implementatio= n >>>> detail of a RIB, but I'll assume you are still talking strictly about = a RIB >>>> abstraction and increasing its scope to multiple RIBs communicating wi= th a >>>> single I2RS agent. >>>> >>>> Not sure about dozens of details, but your four good questions above a= ll >>>> seem to revolve around a single issue, handling of multiple RIBs, whic= h I >>>> think is important to have as a use case. >>>> >>>> -Scott >>>> >>>> >>>> >>>>> >>>>> Best, >>>>> R. >>>>> >>>>> >>>>> On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte wrot= e: >>>>>> >>>>>> On 03/14/2013 07:34 AM, Robert Raszuk wrote: >>>>>>> >>>>>>> >>>>>>> Hi Scott, >>>>>>> >>>>>>>> Why do we need to go beyond defining an interface to the RIB to ma= ke >>>>>>>> your >>>>>>>> use case work? >>>>>>> >>>>>>> >>>>>>> >>>>>>> I am talking precise about that definition of RIB interface. Not ho= w >>>>>>> the RIB works in given vendor of network element. That is >>>>>>> implementation detail. >>>>>>> >>>>>>> Basically a list of values one can write or read to/from RIB. Have = you >>>>>>> seen any document with such list yet ? >>>>>> >>>>>> >>>>>> >>>>>> So we agree that what a RIB looks like is out of scope, and we need = to >>>>>> insure extensibility beyond proposed use cases for the actual RIB >>>>>> interface? >>>>>> If so I think the group is well on track to get there, as we grind >>>>>> through >>>>>> use cases and existing data models. >>>>>> >>>>>> -Scott >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> R. >>>>>> >>>>>> >>>>>> -- >>>>>> People who are essentially without the power to implement their idea= s in >>>>>> the >>>>>> real world must leverage the power of their reputations. >>>> >>>> >>>> >>>> -- >>>> People who are essentially without the power to implement their ideas = in the >>>> real world must leverage the power of their reputations. >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From rraszuk@gmail.com Thu Mar 14 10:50:21 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D74F21F8E95 for ; Thu, 14 Mar 2013 10:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] 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 wU6lGSqzUKRd for ; Thu, 14 Mar 2013 10:50:21 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E55F321F8E5C for ; Thu, 14 Mar 2013 10:50:20 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id c13so3319734ieb.23 for ; Thu, 14 Mar 2013 10:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vdheaD+gVaf6zOkXjCtznfOIyGUrUwDCI6L5z0q/RnQ=; b=PGGY+r5r8grbDtcWpqP7AFEyKe8SxuYSwiy+hRL0lr2hn1OP2l1VF8dI5PFSi9/XPQ n4VyARIuPoD29UHls7fo7Zh3lDb5M9bua8tO7GUYuo4TIBYG8GVci7Wr6vsRGGkalrJd IMgBcMCYJdi1lG9Rx2bPZrWXetV4krLjPyQCsMup9Jn2U1LNnzK6mJEY7IWnFiJn1EdX cMnENEvdiByoMwAignAIpw8BC3Xqxp4cXKNo88nj0AYWT6GpPebTRtGQCoVyFWC3h1Bf nW8LAPBWpNViOn1jiVuCWxbX/13iiWDvCcdFmUwrGuF38AdFbAVaefaVszUHSnnBhion j1vQ== MIME-Version: 1.0 X-Received: by 10.50.178.36 with SMTP id cv4mr3067998igc.98.1363283420554; Thu, 14 Mar 2013 10:50:20 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 10:50:20 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> Date: Thu, 14 Mar 2013 18:50:20 +0100 X-Google-Sender-Auth: REdO31qI0U1nQzmIZMg8QTOq_m4 Message-ID: From: Robert Raszuk To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 Cc: Russ White , "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 17:50:21 -0000 > I do see setting an MPLS label as a characteristic of a next-hop. The > concern will be describing capabilities reasonably without a rat-hole. As I said transport label yes .. VPN label no. Also how about IP GRE /IPv6 and other encapsulations ? This is prerequisite for any service or application today. > This is doing L3 routing - so VLAN matching seems out; while there may > be PWE3 or L2VPN type use-cases eventually, I've not seen them yet. I think you have missed my point. I am talking about L3. Imagine L3VPN PE ... I want to configure the service using I2RS ... you have had use case for this even presented today. So I must match on the incoming interface (physical or logical) to make sure propor RIB table is used for packet lookup. Best regards, R. From bensons@queuefull.net Thu Mar 14 10:54:00 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940CF21F8995 for ; Thu, 14 Mar 2013 10:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, 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 VjRFUBXvOYzB for ; Thu, 14 Mar 2013 10:53:56 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE9821F8952 for ; Thu, 14 Mar 2013 10:53:54 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id 1so1440843qee.30 for ; Thu, 14 Mar 2013 10:53:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=TXfyJfpFK9eoWvbMlKJ5PH5vATJHIlMhCvloW5IrBKI=; b=eURH4zPefSCD508A9RMTb5bS+fQnykD1vNGGIC/xYqGBtjKR+Tsy/ly3q9W6Q+Azi6 0b90/cSvZ/9tSnPW4ieNnGRghUqKQVtLm5WT8y0s4PPbfKRqbIPMJLpkvJbnseiJBEEs XeY+n1Sa6il9Bo3TaHNR9KKdVpO9Vk5wiSeT4msMQ1xsE67CmatEjvJAlyy9SZ7zbhW0 QBqMCeufsbI1MiOCyg7LWphtOEpxWCfyaHQU0f4IMYUnWfdVuHUiF6ZWKljyB2ijhyr/ WqtgpOXXLulTKpL7+pPYZFJXl1RfhCWjvgCX+FzGxhdlEpsS22+jq8ZS+rKrC3RJtsxw rCYA== X-Received: by 10.224.219.69 with SMTP id ht5mr3512869qab.88.1363283633718; Thu, 14 Mar 2013 10:53:53 -0700 (PDT) Received: from wasteland.local (westford-nat.juniper.net. [66.129.232.2]) by mx.google.com with ESMTPS id ku2sm4412937qeb.4.2013.03.14.10.53.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 10:53:52 -0700 (PDT) Message-ID: <51420EAD.1070903@queuefull.net> Date: Thu, 14 Mar 2013 13:53:49 -0400 From: Benson Schliesser User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Alia Atlas References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlEml0j8bnfmaDMVNMXDEsl2N/JjZ5Q/GAxg8B2enpOIR0LODO/7ZNs8CHX5+K55/LL//z8 Cc: Russ White , "i2rs@ietf.org" , Robert Raszuk , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 17:54:00 -0000 I think it depends if and/or how we decouple traffic-bearing interfaces from the RIB... Do we want the information model to represent ingress/egress labels, VLANs, etc as fields in the RIB, attributes of the RIB (or of various tables), or attributes of interfaces? Is the information model the same for ingress vs egress traffic? I have opinions, of course. But I'm open-minded. Cheers, -Benson On 3/14/13 1:46 PM, Alia Atlas wrote: > I do see setting an MPLS label as a characteristic of a next-hop. The > concern will be describing capabilities reasonably without a rat-hole. > > This is doing L3 routing - so VLAN matching seems out; while there may > be PWE3 or L2VPN type use-cases eventually, I've not seen them yet. > > Alia > > On Thu, Mar 14, 2013 at 11:17 AM, Robert Raszuk wrote: >> Hi Russ ... >> >> For me the base set is completely not sufficient for any of the >> application I would use I2RS for. >> >> As example: it is missing match on VLAN, set MPLS VPN label, set MPLS >> transport label. >> >> r. >> >>> On Thu, Mar 14, 2013 at 4:14 PM, Russ White wrote: >>> >>> I wouldn't frame the question in terms of the packet header but the routing table... I don't know that the answer comes out different, but... :-) >>> >>> That said, I think a good base set would be: >>> >>> - Dest IP Address >>> - Next hop IP address >>> - Outbound interface >>> - Admin distance >>> - Some form of tags >>> - Table ID >>> >>> We've talked about the ad,in distance being more like a community string than an integer (having multiple parts so you can have several types of metrics here), but I don't know how useful that would be. I'm all for thinking past the immediate need and leaving doors open for unthought of things, though. >>> >>> There's also the back channel out of the rib to consider -- specifically, things like, "your route was just overwritten by another process," "a route was just redistributed to you," "the next hop for this route just went away," "this connected route just failed," and other related stuff. >>> >>> But I think we might need to get the use cases to give us what information they need, and work build a good list from that. Then we can ask the question, "is there a model that fits already?" >>> >>> :-) >>> >>> Russ >>> >>> >>> <>< >>> russw@riw.us >>> >>> On Mar 14, 2013, at 11:02 AM, Robert Raszuk wrote: >>> >>>> My main question is what L2-L4 fields for the packet lookup I can >>>> program to the 'RIB" by I2RS. Very precise and simple. >>>> >>>> The use case for multiple RIBs is just being shown in the room. L3VPN >>>> PE auto-provisioning ;) >>>> >>>> Best, >>>> R,. >>>> >>>> On Thu, Mar 14, 2013 at 3:58 PM, Scott Whyte wrote: >>>>> On 03/14/2013 07:46 AM, Robert Raszuk wrote: >>>>>> I think we agree that RIB elements for read and write must be clearly >>>>>> defined. And should be extensible. >>>>>> >>>>>> But is RIB abstraction sufficient for I2RS ? >>>>>> >>>>>> For example as we know each VRF contains it's own RIB (different table >>>>>> id). So protocol must be able to also encode which RIB we are talking >>>>>> to. >>>>>> >>>>>> Further who will instantiate the VRF in this case ? Will I2RS be able >>>>>> to create a RIB instance on the fly ? How will we attach such RIB >>>>>> instance to interfaces ? There is dozens of details here without which >>>>>> I am afraid we can't go productively forward. >>>>> >>>>> I guess I'm confused now on what you consider propietary implementation >>>>> detail of a RIB, but I'll assume you are still talking strictly about a RIB >>>>> abstraction and increasing its scope to multiple RIBs communicating with a >>>>> single I2RS agent. >>>>> >>>>> Not sure about dozens of details, but your four good questions above all >>>>> seem to revolve around a single issue, handling of multiple RIBs, which I >>>>> think is important to have as a use case. >>>>> >>>>> -Scott >>>>> >>>>> >>>>> >>>>>> Best, >>>>>> R. >>>>>> >>>>>> >>>>>> On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte wrote: >>>>>>> On 03/14/2013 07:34 AM, Robert Raszuk wrote: >>>>>>>> >>>>>>>> Hi Scott, >>>>>>>> >>>>>>>>> Why do we need to go beyond defining an interface to the RIB to make >>>>>>>>> your >>>>>>>>> use case work? >>>>>>>> >>>>>>>> >>>>>>>> I am talking precise about that definition of RIB interface. Not how >>>>>>>> the RIB works in given vendor of network element. That is >>>>>>>> implementation detail. >>>>>>>> >>>>>>>> Basically a list of values one can write or read to/from RIB. Have you >>>>>>>> seen any document with such list yet ? >>>>>>> >>>>>>> >>>>>>> So we agree that what a RIB looks like is out of scope, and we need to >>>>>>> insure extensibility beyond proposed use cases for the actual RIB >>>>>>> interface? >>>>>>> If so I think the group is well on track to get there, as we grind >>>>>>> through >>>>>>> use cases and existing data models. >>>>>>> >>>>>>> -Scott >>>>>>> >>>>>>>> Cheers, >>>>>>>> R. >>>>>>> >>>>>>> -- >>>>>>> People who are essentially without the power to implement their ideas in >>>>>>> the >>>>>>> real world must leverage the power of their reputations. >>>>> >>>>> >>>>> -- >>>>> People who are essentially without the power to implement their ideas in the >>>>> real world must leverage the power of their reputations. >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From davei@otd.com Thu Mar 14 10:58:54 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DF611E8115 for ; Thu, 14 Mar 2013 10:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] 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 QAZC3RlH1Wye for ; Thu, 14 Mar 2013 10:58:53 -0700 (PDT) Received: from penn.otd.com (unknown [IPv6:2001:470:7:55b::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2212D11E8110 for ; Thu, 14 Mar 2013 10:58:53 -0700 (PDT) Received: from [IPv6:2001:df8:0:16:9def:1611:7cc:e6fd] ([IPv6:2001:df8:0:16:9def:1611:7cc:e6fd]) (authenticated bits=0) by penn.otd.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id r2EHwjOw005141 for ; Thu, 14 Mar 2013 13:58:47 -0400 Message-ID: <51420FD4.6090006@otd.com> Date: Thu, 14 Mar 2013 13:58:44 -0400 From: Dave Israel User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: i2rs@ietf.org References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-otd-MailScanner-Information: Please contact the ISP for more information X-otd-MailScanner-ID: r2EHwjOw005141 X-otd-MailScanner: Found to be clean X-otd-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1, required 5, autolearn=not spam, ALL_TRUSTED -1.00) X-otd-MailScanner-From: davei@otd.com X-otd-MailScanner-Watermark: 1363888728.79961@IzAjOg5qm0V2TXXc+wdVxg Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 17:58:54 -0000 On 03/14/2013 01:50 PM, Robert Raszuk wrote: >> This is doing L3 routing - so VLAN matching seems out; while there may >> be PWE3 or L2VPN type use-cases eventually, I've not seen them yet. > I think you have missed my point. I am talking about L3. Imagine L3VPN > PE ... I want to configure the service using I2RS ... you have had use > case for this even presented today. So I must match on the incoming > interface (physical or logical) to make sure propor RIB table is used > for packet lookup. Well, arguably, the routing table you're in is already determined by the inbound interface. Your inbound interface is already part of a vrf/logical system/etc. You might be able to use i2rs to request that your interface be moved from one routing table to another, but that sounds more like a job for NetCONF-style configuration than I2RS-style ephemeral routing table manipulation. From rraszuk@gmail.com Thu Mar 14 11:00:02 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A100811E80F2 for ; Thu, 14 Mar 2013 11:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, NO_RELAYS=-0.001] 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 tFAQiHdC6oMC for ; Thu, 14 Mar 2013 11:00:01 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 012F711E80DF for ; Thu, 14 Mar 2013 11:00:00 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id 16so3411112iea.36 for ; Thu, 14 Mar 2013 11:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zg64Hyz0KAIxUMV02sXFSYAQOCsTkE1/ZdpIKXbqvg0=; b=Z5Y90gl2R0RPR15x2sQzm6XI7t0LdCyBmJxyu0dpXgzlIOR/YSCpS5tsoE46aFS7Tc WDcjhP2GqaFFm+N0dQEVsW7FG12K4OB/uZTDBw8XbAN9Es65eE9p4zfT7sVMqqgidq9a aWUKOTQpcPi23rHfF7JmNemsMphiciLN2eMJzMDH8qzbjJ6Nn+ujISy68gclgd6BXzId nRea0OTpZIRCFNbI2W/c/Nd7Tzv1GYjwcZrxLQgvHeZdMOgzRrCnMbDV68u4CXbepjfu vPi3aJTl59quHNmiIPfkxidtxAYMXXcwcm2QiK4qguumw6pTYFAv9vJKjAFK4+RhD/lX fvcw== MIME-Version: 1.0 X-Received: by 10.50.156.133 with SMTP id we5mr3151097igb.51.1363284000640; Thu, 14 Mar 2013 11:00:00 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 11:00:00 -0700 (PDT) In-Reply-To: <51420EAD.1070903@queuefull.net> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420EAD.1070903@queuefull.net> Date: Thu, 14 Mar 2013 19:00:00 +0100 X-Google-Sender-Auth: 4143UPwG0pbLm_zXDvNyjgr_08I Message-ID: From: Robert Raszuk To: Benson Schliesser Content-Type: text/plain; charset=ISO-8859-1 Cc: Russ White , "i2rs@ietf.org" , Scott Whyte , Alia Atlas Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 18:00:02 -0000 Hi Benson, I think this is excellent point. And as said I also think this is extremely important to move forward. In other words I am just afraid that when junisco is talking about RIB they are talking about current global RIB model which obviously is completely not sufficient to realize/provision network wide services by I2RS protocol alone. So I just hope that we define base interface to network element which will allow to address all use cases (even those already documented by the drafts on the table). Best, R. > On Thu, Mar 14, 2013 at 6:53 PM, Benson Schliesser wrote: > I think it depends if and/or how we decouple traffic-bearing interfaces from > the RIB... Do we want the information model to represent ingress/egress > labels, VLANs, etc as fields in the RIB, attributes of the RIB (or of > various tables), or attributes of interfaces? Is the information model the > same for ingress vs egress traffic? > > I have opinions, of course. But I'm open-minded. > > Cheers, > -Benson > > > > On 3/14/13 1:46 PM, Alia Atlas wrote: >> >> I do see setting an MPLS label as a characteristic of a next-hop. The >> concern will be describing capabilities reasonably without a rat-hole. >> >> This is doing L3 routing - so VLAN matching seems out; while there may >> be PWE3 or L2VPN type use-cases eventually, I've not seen them yet. >> >> Alia >> >> On Thu, Mar 14, 2013 at 11:17 AM, Robert Raszuk wrote: >>> >>> Hi Russ ... >>> >>> For me the base set is completely not sufficient for any of the >>> application I would use I2RS for. >>> >>> As example: it is missing match on VLAN, set MPLS VPN label, set MPLS >>> transport label. >>> >>> r. >>> >>>> On Thu, Mar 14, 2013 at 4:14 PM, Russ White wrote: >>>> >>>> I wouldn't frame the question in terms of the packet header but the >>>> routing table... I don't know that the answer comes out different, but... >>>> :-) >>>> >>>> That said, I think a good base set would be: >>>> >>>> - Dest IP Address >>>> - Next hop IP address >>>> - Outbound interface >>>> - Admin distance >>>> - Some form of tags >>>> - Table ID >>>> >>>> We've talked about the ad,in distance being more like a community string >>>> than an integer (having multiple parts so you can have several types of >>>> metrics here), but I don't know how useful that would be. I'm all for >>>> thinking past the immediate need and leaving doors open for unthought of >>>> things, though. >>>> >>>> There's also the back channel out of the rib to consider -- >>>> specifically, things like, "your route was just overwritten by another >>>> process," "a route was just redistributed to you," "the next hop for this >>>> route just went away," "this connected route just failed," and other related >>>> stuff. >>>> >>>> But I think we might need to get the use cases to give us what >>>> information they need, and work build a good list from that. Then we can ask >>>> the question, "is there a model that fits already?" >>>> >>>> :-) >>>> >>>> Russ >>>> >>>> >>>> <>< >>>> russw@riw.us >>>> >>>> On Mar 14, 2013, at 11:02 AM, Robert Raszuk wrote: >>>> >>>>> My main question is what L2-L4 fields for the packet lookup I can >>>>> program to the 'RIB" by I2RS. Very precise and simple. >>>>> >>>>> The use case for multiple RIBs is just being shown in the room. L3VPN >>>>> PE auto-provisioning ;) >>>>> >>>>> Best, >>>>> R,. >>>>> >>>>> On Thu, Mar 14, 2013 at 3:58 PM, Scott Whyte wrote: >>>>>> >>>>>> On 03/14/2013 07:46 AM, Robert Raszuk wrote: >>>>>>> >>>>>>> I think we agree that RIB elements for read and write must be clearly >>>>>>> defined. And should be extensible. >>>>>>> >>>>>>> But is RIB abstraction sufficient for I2RS ? >>>>>>> >>>>>>> For example as we know each VRF contains it's own RIB (different >>>>>>> table >>>>>>> id). So protocol must be able to also encode which RIB we are talking >>>>>>> to. >>>>>>> >>>>>>> Further who will instantiate the VRF in this case ? Will I2RS be able >>>>>>> to create a RIB instance on the fly ? How will we attach such RIB >>>>>>> instance to interfaces ? There is dozens of details here without >>>>>>> which >>>>>>> I am afraid we can't go productively forward. >>>>>> >>>>>> >>>>>> I guess I'm confused now on what you consider propietary >>>>>> implementation >>>>>> detail of a RIB, but I'll assume you are still talking strictly about >>>>>> a RIB >>>>>> abstraction and increasing its scope to multiple RIBs communicating >>>>>> with a >>>>>> single I2RS agent. >>>>>> >>>>>> Not sure about dozens of details, but your four good questions above >>>>>> all >>>>>> seem to revolve around a single issue, handling of multiple RIBs, >>>>>> which I >>>>>> think is important to have as a use case. >>>>>> >>>>>> -Scott >>>>>> >>>>>> >>>>>> >>>>>>> Best, >>>>>>> R. >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte >>>>>>> wrote: >>>>>>>> >>>>>>>> On 03/14/2013 07:34 AM, Robert Raszuk wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Scott, >>>>>>>>> >>>>>>>>>> Why do we need to go beyond defining an interface to the RIB to >>>>>>>>>> make >>>>>>>>>> your >>>>>>>>>> use case work? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I am talking precise about that definition of RIB interface. Not >>>>>>>>> how >>>>>>>>> the RIB works in given vendor of network element. That is >>>>>>>>> implementation detail. >>>>>>>>> >>>>>>>>> Basically a list of values one can write or read to/from RIB. Have >>>>>>>>> you >>>>>>>>> seen any document with such list yet ? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> So we agree that what a RIB looks like is out of scope, and we need >>>>>>>> to >>>>>>>> insure extensibility beyond proposed use cases for the actual RIB >>>>>>>> interface? >>>>>>>> If so I think the group is well on track to get there, as we grind >>>>>>>> through >>>>>>>> use cases and existing data models. >>>>>>>> >>>>>>>> -Scott >>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> R. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> People who are essentially without the power to implement their >>>>>>>> ideas in >>>>>>>> the >>>>>>>> real world must leverage the power of their reputations. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> People who are essentially without the power to implement their ideas >>>>>> in the >>>>>> real world must leverage the power of their reputations. >>>>> >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > From akatlas@gmail.com Thu Mar 14 11:00:53 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E3711E8158 for ; Thu, 14 Mar 2013 11:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] 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 VoUx54rSL4Dn for ; Thu, 14 Mar 2013 11:00:52 -0700 (PDT) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFF211E8129 for ; Thu, 14 Mar 2013 11:00:52 -0700 (PDT) Received: by mail-ia0-f180.google.com with SMTP id f27so2325284iae.39 for ; Thu, 14 Mar 2013 11:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Rx994OB0zlYUOXRv/1g4NE3R41t272VM9wCHdJSQ0yw=; b=IOh5h38bYACNAcD25J2fYXGaCfKiqVqPM5gsz2GZXzoR/Siehs+0GoqJK3le6S1Dmt /bYBTLVV0cNrGw3VAO2vbfEgP6J+bOHLsak2saqW/5oq9PWXNJnDZkwAz5F3Whjsejeq DLwVQSEHz1f2OKY0MGrYABheVCJtb1/4N9E3VvE3UG5FVk0R31P8J4q+0Wz+8I97SXS/ IOARMt0iq5hXaTz/JVVhXQMpSUrDNb3JyeKIvtMS9XzY+3+lIErv0Zq6CnBBMIVwjBuB xuHmZ4TkL8SaqQal/USUBnJxle7qtJpvr+XAaMFhwNH0MDe63kLXeR272BppMTwhvWDK Oejg== MIME-Version: 1.0 X-Received: by 10.50.17.166 with SMTP id p6mr15472499igd.12.1363284052166; Thu, 14 Mar 2013 11:00:52 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Thu, 14 Mar 2013 11:00:52 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> Date: Thu, 14 Mar 2013 14:00:52 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Cc: Russ White , "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 18:00:53 -0000 In-line On Thu, Mar 14, 2013 at 1:50 PM, Robert Raszuk wrote: >> I do see setting an MPLS label as a characteristic of a next-hop. The >> concern will be describing capabilities reasonably without a rat-hole. > > As I said transport label yes .. VPN label no. Also how about IP GRE > /IPv6 and other encapsulations ? This is prerequisite for any service > or application today. [Alia] For the VPN label, I think that depends - I could see a VPN-specific RIB that outputs the VPN label and transport label. And YES, of course, other encapsulations are needed and of interest. There's capability negotiation. In the Framework draft Sec 4.1.1: " Encapsulation: Associated with each primary next-hop can be details on the type of encapsulation for the packet. Such encapsulation could be MPLS, GRE, etc. as supported by the router. " WRITE UP YOUR USE-CASES and DESCRIBE what functionality you need! >> This is doing L3 routing - so VLAN matching seems out; while there may >> be PWE3 or L2VPN type use-cases eventually, I've not seen them yet. > > I think you have missed my point. I am talking about L3. Imagine L3VPN > PE ... I want to configure the service using I2RS ... you have had use > case for this even presented today. So I must match on the incoming > interface (physical or logical) to make sure propor RIB table is used > for packet lookup. [Alia] Sure - you need to be able to write to different tables in the RIB - of course. Look in the framework draft - in Sec 4.1.1 " Route Table Context: There can be different route table contexts in the RIB. Examples include multiple protocols (e.g. IPv4, IPv6), multiple topologies, different uses, and multiple networks (e.g. VRF tables for VPNs). Appropriate application-level abstractions are required to describe the desired route table context. " Best Regards, Alia P.S. How was the remote participation? From rraszuk@gmail.com Thu Mar 14 11:02:59 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EE211E8158 for ; Thu, 14 Mar 2013 11:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] 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 vSrm6oeeGAI5 for ; Thu, 14 Mar 2013 11:02:59 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 60DFA11E8110 for ; Thu, 14 Mar 2013 11:02:59 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id 10so3399343ied.16 for ; Thu, 14 Mar 2013 11:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=k5DBytrm9vozFgFiicrxASjPyXTl3CNfiBbDo8MBgP4=; b=hSBBtfAg0F3rlwN9QBwUPOXErYx9q2Z/yyZbOwG169tD+OM+isym7l9daDkaH0F3Ke eGDBpJVCvSpzodoLNP+NlUBj9mNvPG5XyvsAcLftuirXsJvrOSr0DYRI7IYC4mRSuqJU QwpD8Rs6f5Qc4fTyM5xKwEhCISmOLNXRj3AmtXa2cFEKsOpLMia4h3doTfLC0SXR79UT YhnutCsA1/CM42PQ2nylPDMMSF/V6DvxOehboO174tSvlEs9nrL7ZdkzQW+K4R2dfcGa LjAFybSCssSwp3fT8ODWtaDR04o54KZvgie4gqdDEFpcAFrQa3JvLvFbCrw+7dsokqUT lIlQ== MIME-Version: 1.0 X-Received: by 10.50.47.200 with SMTP id f8mr21398536ign.98.1363284178837; Thu, 14 Mar 2013 11:02:58 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 11:02:58 -0700 (PDT) In-Reply-To: <51420FD4.6090006@otd.com> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420FD4.6090006@otd.com> Date: Thu, 14 Mar 2013 19:02:58 +0100 X-Google-Sender-Auth: 4iNAt0B3rgXuXADRONPSPl8yJwk Message-ID: From: Robert Raszuk To: Dave Israel Content-Type: text/plain; charset=ISO-8859-1 Cc: i2rs@ietf.org Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 18:03:00 -0000 Ahhh so you are stating that to provision services on the network in vendor neutral way I will not be able to use I2RS by design ? Is this already agreed point that NETCONF (or any other form of configuration) will be required anyway in addition to I2RS for any complete service provisioning ? Thx, R. > On Thu, Mar 14, 2013 at 6:58 PM, Dave Israel wrote: > > On 03/14/2013 01:50 PM, Robert Raszuk wrote: >>> >>> This is doing L3 routing - so VLAN matching seems out; while there may >>> be PWE3 or L2VPN type use-cases eventually, I've not seen them yet. >> >> I think you have missed my point. I am talking about L3. Imagine L3VPN >> PE ... I want to configure the service using I2RS ... you have had use >> case for this even presented today. So I must match on the incoming >> interface (physical or logical) to make sure propor RIB table is used >> for packet lookup. > > > Well, arguably, the routing table you're in is already determined by the > inbound interface. Your inbound interface is already part of a vrf/logical > system/etc. You might be able to use i2rs to request that your interface be > moved from one routing table to another, but that sounds more like a job for > NetCONF-style configuration than I2RS-style ephemeral routing table > manipulation. > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From akatlas@gmail.com Thu Mar 14 11:03:44 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF0011E80D9 for ; Thu, 14 Mar 2013 11:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] 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 Ri2Nr4Fxi5Pm for ; Thu, 14 Mar 2013 11:03:43 -0700 (PDT) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id BFCCF21F8DDA for ; Thu, 14 Mar 2013 11:03:43 -0700 (PDT) Received: by mail-ia0-f181.google.com with SMTP id o25so97820iad.12 for ; Thu, 14 Mar 2013 11:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Fjb3tg+19Jvl/q3LQOnhUgmYEsdQWw4/rW7piCPosQw=; b=TtQIk1nG4XlGMzY4ILH/e4COxHvf3Btr9cOL6l3pryhvyI92k0KmYZgSKmnoMyKTKN ahO+DJawZFvQ82vV4Rqbf93pdodgXcQW5PBUowBsardoe9Zi1Iv4/C/RqGEO9595l7bw Aw8n44Y3jPbB4sm8BUTijF9DV/0sykOwzh5RB4uPpGstmILL7TJwQQ+8bDpzsF0bALZb uM3J+W/6P0geHhrZ09F4HCYaa2jv7U7qVrLMyH47FIkP6V3vX/ib1a7vbtQItrXTLhnj M+lEHRyk4d2ScI1dBnHMwisUkxLTesgvWRnJQZAZ0zRX+QOrUf2YtDg7V6D5QbDSBsUW zZtA== MIME-Version: 1.0 X-Received: by 10.50.36.199 with SMTP id s7mr21620441igj.56.1363284223371; Thu, 14 Mar 2013 11:03:43 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Thu, 14 Mar 2013 11:03:43 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> Date: Thu, 14 Mar 2013 14:03:43 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Cc: Russ White , "i2rs@ietf.org" , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 18:03:44 -0000 On the matching, I was specifically talking about matching on VLAN; of course, if a VLAN defines an L3 interface that feeds into a particular RIB specific to that interface, that is - to my mind/abstractions - different from matching on a VLAN tag. YES - the results might be similar, but less generality. Alia On Thu, Mar 14, 2013 at 1:50 PM, Robert Raszuk wrote: >> I do see setting an MPLS label as a characteristic of a next-hop. The >> concern will be describing capabilities reasonably without a rat-hole. > > As I said transport label yes .. VPN label no. Also how about IP GRE > /IPv6 and other encapsulations ? This is prerequisite for any service > or application today. > >> This is doing L3 routing - so VLAN matching seems out; while there may >> be PWE3 or L2VPN type use-cases eventually, I've not seen them yet. > > I think you have missed my point. I am talking about L3. Imagine L3VPN > PE ... I want to configure the service using I2RS ... you have had use > case for this even presented today. So I must match on the incoming > interface (physical or logical) to make sure propor RIB table is used > for packet lookup. > > Best regards, > R. From akatlas@gmail.com Thu Mar 14 11:04:00 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7883B11E8161 for ; Thu, 14 Mar 2013 11:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] 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 VoT2Io8D78zt for ; Thu, 14 Mar 2013 11:03:59 -0700 (PDT) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4760511E8158 for ; Thu, 14 Mar 2013 11:03:59 -0700 (PDT) Received: by mail-ia0-f179.google.com with SMTP id x24so2350273iak.24 for ; Thu, 14 Mar 2013 11:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mhzoht6YxjQ4PLvDCIUTVOcbvQtMNcCRTwvdUCkrOfA=; b=ry+8FF2cfuGmdn1Pqo1sAJeH/EiKwt+mx+UrveGat7j4KMTRK2oLkWdnZV31Gj11km Ff4/LhdjWa+iR4o43pwCgdHpbcCNkpjx+gkhGQLuZCON3QK/WPEFB9Ml6iGJGSuUK0SB aj4Migr5Fd40tQIm8YdEfn70dLT/I+KpaSmj/XALNa8Si5AfqXuR4lBkhmaHGSDdJBKt WJYMP8GfmGUv161yCsUqDrCs9RVUoxk7Vr7HT7pHq1BqZy4PHBnIRVPleVnmqIg3PDkb y05hF8O6WA6dlrbidd3Tf1nq5yHwZasSZxdZF+yNm9cexf3Ye+Z87LN5OThk+Og78xdM Lh/g== MIME-Version: 1.0 X-Received: by 10.50.191.133 with SMTP id gy5mr21854222igc.50.1363284238928; Thu, 14 Mar 2013 11:03:58 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Thu, 14 Mar 2013 11:03:58 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420FD4.6090006@otd.com> Date: Thu, 14 Mar 2013 14:03:58 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Cc: Dave Israel , i2rs@ietf.org Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 18:04:00 -0000 Of course not On Thu, Mar 14, 2013 at 2:02 PM, Robert Raszuk wrote: > Ahhh so you are stating that to provision services on the network in > vendor neutral way I will not be able to use I2RS by design ? > > Is this already agreed point that NETCONF (or any other form of > configuration) will be required anyway in addition to I2RS for any > complete service provisioning ? > > Thx, > R. > >> On Thu, Mar 14, 2013 at 6:58 PM, Dave Israel wrote: >> >> On 03/14/2013 01:50 PM, Robert Raszuk wrote: >>>> >>>> This is doing L3 routing - so VLAN matching seems out; while there may >>>> be PWE3 or L2VPN type use-cases eventually, I've not seen them yet. >>> >>> I think you have missed my point. I am talking about L3. Imagine L3VPN >>> PE ... I want to configure the service using I2RS ... you have had use >>> case for this even presented today. So I must match on the incoming >>> interface (physical or logical) to make sure propor RIB table is used >>> for packet lookup. >> >> >> Well, arguably, the routing table you're in is already determined by the >> inbound interface. Your inbound interface is already part of a vrf/logical >> system/etc. You might be able to use i2rs to request that your interface be >> moved from one routing table to another, but that sounds more like a job for >> NetCONF-style configuration than I2RS-style ephemeral routing table >> manipulation. >> >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From akatlas@gmail.com Thu Mar 14 11:05:48 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2D011E8155 for ; Thu, 14 Mar 2013 11:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] 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 z1rhLS-2Nlrt for ; Thu, 14 Mar 2013 11:05:36 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id DE4FD11E8110 for ; Thu, 14 Mar 2013 11:05:35 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id y10so115098iak.23 for ; Thu, 14 Mar 2013 11:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5Oi87szHwGfCWOqX+b5k3UUDmcPvP5M3TfMP5NvkCoc=; b=D+OZoRgwBhsix4p+obW6O8YLJUlGJWmH2YR/jlA5w9g74l4k4QO9OOF1O0n3OTTe3y 1P99TC8WGU7yINaTUmPoyuEx6yC+3elnLawmOEAIAXwFwK6PX5lJ20XuKJSCl++rDsP8 7iQszsOY6qF9yEZoi3gShdahWmTrrTTD1JF4n/6PFx9vqASohNHGnUNFi7pvSyV/EVVe 9TmOOCVZGQa581pxBhgdwUu1Cgj4VQrdyYqk+Gar7j7KwKxfYKTW7aBAoqZ3zHvRYk7w a7U4AalyGseHOKjmTDJ8u9JwpVRehcqmKM3c8nmOmZLfHsQbMScipRHpwsQcnSAth8gI Cfqw== MIME-Version: 1.0 X-Received: by 10.50.119.102 with SMTP id kt6mr3096006igb.12.1363284335457; Thu, 14 Mar 2013 11:05:35 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Thu, 14 Mar 2013 11:05:35 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420FD4.6090006@otd.com> Date: Thu, 14 Mar 2013 14:05:35 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Cc: Dave Israel , i2rs@ietf.org Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 18:05:48 -0000 I should add if we don't have WRITTEN USE-CASES that describe the needs in terms of information and functionality and the purpose and so on, then YES - you are likely to see a much narrower scope that may not meet your specific use-cases. Alia On Thu, Mar 14, 2013 at 2:02 PM, Robert Raszuk wrote: > Ahhh so you are stating that to provision services on the network in > vendor neutral way I will not be able to use I2RS by design ? > > Is this already agreed point that NETCONF (or any other form of > configuration) will be required anyway in addition to I2RS for any > complete service provisioning ? > > Thx, > R. > >> On Thu, Mar 14, 2013 at 6:58 PM, Dave Israel wrote: >> >> On 03/14/2013 01:50 PM, Robert Raszuk wrote: >>>> >>>> This is doing L3 routing - so VLAN matching seems out; while there may >>>> be PWE3 or L2VPN type use-cases eventually, I've not seen them yet. >>> >>> I think you have missed my point. I am talking about L3. Imagine L3VPN >>> PE ... I want to configure the service using I2RS ... you have had use >>> case for this even presented today. So I must match on the incoming >>> interface (physical or logical) to make sure propor RIB table is used >>> for packet lookup. >> >> >> Well, arguably, the routing table you're in is already determined by the >> inbound interface. Your inbound interface is already part of a vrf/logical >> system/etc. You might be able to use i2rs to request that your interface be >> moved from one routing table to another, but that sounds more like a job for >> NetCONF-style configuration than I2RS-style ephemeral routing table >> manipulation. >> >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From rraszuk@gmail.com Thu Mar 14 11:06:31 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250D011E8191 for ; Thu, 14 Mar 2013 11:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.728 X-Spam-Level: X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 Rqg4PoGzwjFn for ; Thu, 14 Mar 2013 11:06:30 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 908EC11E817C for ; Thu, 14 Mar 2013 11:06:30 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id 10so3403612ied.2 for ; Thu, 14 Mar 2013 11:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dQnkFo8I5pWCODmYjBN66YmKc5fHmmg62iLhsMw+F9w=; b=zpdrErf4r+zSJxFRDxrsbV6VLhPczfiUp4e5NV30ersVzcKy05RSC1accieQ21zHaf /jPoM2v6HNxoN/p4GeORl3qypKos2M3O5/H7hZZfzL6AJN9aUoSDUAMkdyN4gNvJj+hE NLf7flXZ0Zl6oa9HsUoY4WgEzJ9ZoEQ4IcfZ1sSphBTCEgAOTeukBdrHousyqlQY2bVb I3sQsgfe3+6nOvXK5gnJ/87YTpesebPWMX8GFVdIs/lg4FbpZXTn/Lso6m7wfmcPaFR8 J95JQNvIxb9GlUTQV96TdJg6XGRb8A00hcHYKv6geu/7Cj1/UIIHsV6MvQ5YFRamnDgF 6xKA== MIME-Version: 1.0 X-Received: by 10.50.57.168 with SMTP id j8mr21326755igq.51.1363284390208; Thu, 14 Mar 2013 11:06:30 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 11:06:30 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420FD4.6090006@otd.com> Date: Thu, 14 Mar 2013 19:06:30 +0100 X-Google-Sender-Auth: l2KoKHjGrz0wRo3yjBgvVWcQkR8 Message-ID: From: Robert Raszuk To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 Cc: Dave Israel , i2rs@ietf.org Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 18:06:31 -0000 Which one is the "Of course not" ? Thx, R. PS. Remote participation in I2RS was just great. Pity that only Ed's slides were posted timely before the meeting. On Thu, Mar 14, 2013 at 7:03 PM, Alia Atlas wrote: > Of course not > > On Thu, Mar 14, 2013 at 2:02 PM, Robert Raszuk wrote: >> Ahhh so you are stating that to provision services on the network in >> vendor neutral way I will not be able to use I2RS by design ? >> >> Is this already agreed point that NETCONF (or any other form of >> configuration) will be required anyway in addition to I2RS for any >> complete service provisioning ? >> >> Thx, >> R. From akatlas@gmail.com Thu Mar 14 11:12:11 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECB511E81B5 for ; Thu, 14 Mar 2013 11:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 wrPWgw50drZ4 for ; Thu, 14 Mar 2013 11:12:11 -0700 (PDT) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2785F11E81AC for ; Thu, 14 Mar 2013 11:12:11 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id j5so2415328iaf.28 for ; Thu, 14 Mar 2013 11:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GhziC5rq6GbrCshj5QQbClKu2oXyd9J1jCAD5+kPPUc=; b=R3DGgPro6/hZ8Ea9MSjI9LhyG+yDB0Im0nOMKbWZgEfw84tnNc0E1Nnp9Sj0KiK7TG 6f2kQY+zeYlEA3+z1NfRDOsSIfOnaDD1XZBzz5Psj6oPpwWrUdt8y/z891RvcOSo13Jj VDzWZq7GTLNMELFEtuSAppB9846d+D/L/SjPjdMBZ8eDr+kZD/15Z113yOSOQA4BE53x KL3Hvv97a/4DTZB1HpV8K9k6Er+4g7Tp+cY+iYOqsqR9AC1JYcu2gFAYDpCCiYrgVPEa Im/+ynQbWtY8T/usHlNdwfKPc9mvjdYciyCN+QMQlylZ45RudYM/awFrKZVI/aoQWzKf k3cw== MIME-Version: 1.0 X-Received: by 10.50.36.199 with SMTP id s7mr21647621igj.56.1363284728594; Thu, 14 Mar 2013 11:12:08 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Thu, 14 Mar 2013 11:12:08 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420FD4.6090006@otd.com> Date: Thu, 14 Mar 2013 14:12:08 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Cc: Dave Israel , i2rs@ietf.org Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 18:12:11 -0000 On Thu, Mar 14, 2013 at 2:06 PM, Robert Raszuk wrote: > Which one is the "Of course not" ? [Alia] The idea that it is somehow pre-decided that configuration via Netconf or a different protocol will be required. > Thx, > R. > > PS. Remote participation in I2RS was just great. Pity that only Ed's > slides were posted timely before the meeting. [Alia] I'm glad that the remote participation went well. I was a bit concerned since we had no jabber comments during the discussions. We'll do better on slides availability next time. I did send out the functional analysis as email to the list well in advance to try and kickstart the conversation. > > > On Thu, Mar 14, 2013 at 7:03 PM, Alia Atlas wrote: >> Of course not >> >> On Thu, Mar 14, 2013 at 2:02 PM, Robert Raszuk wrote: >>> Ahhh so you are stating that to provision services on the network in >>> vendor neutral way I will not be able to use I2RS by design ? >>> >>> Is this already agreed point that NETCONF (or any other form of >>> configuration) will be required anyway in addition to I2RS for any >>> complete service provisioning ? >>> >>> Thx, >>> R. From rraszuk@gmail.com Thu Mar 14 11:12:37 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99C811E81B0 for ; Thu, 14 Mar 2013 11:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] 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 2qAkTF3mLAnL for ; Thu, 14 Mar 2013 11:12:37 -0700 (PDT) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3595E11E81AB for ; Thu, 14 Mar 2013 11:12:37 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id j5so2415796iaf.28 for ; Thu, 14 Mar 2013 11:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PW63LGXCqytNtUHen31JqaUF/OZsmGGh+T1FYdUt1I0=; b=gWR5iMPLZanUpFEcx1VGAwq6+f8oCzBFsy73G+pMcxousftpL2h6VUnR7J2Yo/7CkX lTY/AxD3AmIUn4+L+uSHIg7DbhAI59dqf7ye5+xDpi04vIiT5M5IjfGOGoe/Bt9UXEwo 5XvRfw5N9D9ZvtGXhU7SAwPwwYwWrKsgPWNSf1x5zkjIC05tbGxIbs0AVD8EJR8kB1cH VQhYFeGNayNPjqDAjFqHTQCRIB85+a1rWaQxlRp3Nigg65AJH67ReYjxVtJn10yD5clr cgF0FclJMqGTkHypw/yRxhFkT0nfeYKml3L+RuNj+b5x3/XTxmpfDji7nvLnhMpypKlA sScQ== MIME-Version: 1.0 X-Received: by 10.43.135.68 with SMTP id if4mr2730024icc.44.1363284756850; Thu, 14 Mar 2013 11:12:36 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 11:12:36 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420FD4.6090006@otd.com> Date: Thu, 14 Mar 2013 19:12:36 +0100 X-Google-Sender-Auth: EFCN7-s2yRMMNPzAp7hhDg5OvoQ Message-ID: From: Robert Raszuk To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 Cc: Dave Israel , i2rs@ietf.org Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 18:12:37 -0000 I think L3VPN PE application I am referring too is already contained in http://tools.ietf.org/html/draft-hu-i2rs-overlay-use-case-00 Thx, R. On Thu, Mar 14, 2013 at 7:05 PM, Alia Atlas wrote: > I should add > > if we don't have WRITTEN USE-CASES that describe the needs in terms of > information and functionality and the purpose and so on, then YES - > you are likely to see a much narrower scope that may not meet your > specific use-cases. > > Alia > > On Thu, Mar 14, 2013 at 2:02 PM, Robert Raszuk wrote: >> Ahhh so you are stating that to provision services on the network in >> vendor neutral way I will not be able to use I2RS by design ? >> >> Is this already agreed point that NETCONF (or any other form of >> configuration) will be required anyway in addition to I2RS for any >> complete service provisioning ? >> >> Thx, >> R. >> >>> On Thu, Mar 14, 2013 at 6:58 PM, Dave Israel wrote: >>> >>> On 03/14/2013 01:50 PM, Robert Raszuk wrote: >>>>> >>>>> This is doing L3 routing - so VLAN matching seems out; while there may >>>>> be PWE3 or L2VPN type use-cases eventually, I've not seen them yet. >>>> >>>> I think you have missed my point. I am talking about L3. Imagine L3VPN >>>> PE ... I want to configure the service using I2RS ... you have had use >>>> case for this even presented today. So I must match on the incoming >>>> interface (physical or logical) to make sure propor RIB table is used >>>> for packet lookup. >>> >>> >>> Well, arguably, the routing table you're in is already determined by the >>> inbound interface. Your inbound interface is already part of a vrf/logical >>> system/etc. You might be able to use i2rs to request that your interface be >>> moved from one routing table to another, but that sounds more like a job for >>> NetCONF-style configuration than I2RS-style ephemeral routing table >>> manipulation. >>> >>> >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs From ietfc@btconnect.com Thu Mar 14 11:14:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A567711E80E9 for ; Thu, 14 Mar 2013 11:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, J_CHICKENPOX_23=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 dZ8sPZia5fNq for ; Thu, 14 Mar 2013 11:14:05 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id F365A11E80E7 for ; Thu, 14 Mar 2013 11:14:04 -0700 (PDT) Received: from mail173-co9-R.bigfish.com (10.236.132.231) by CO9EHSOBE028.bigfish.com (10.236.130.91) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Mar 2013 18:14:04 +0000 Received: from mail173-co9 (localhost [127.0.0.1]) by mail173-co9-R.bigfish.com (Postfix) with ESMTP id 3A7711801F9; Thu, 14 Mar 2013 18:14:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zzbb2dI98dI9371I542I1432I168aJzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL8275dh8275bhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah304l1155h) Received: from mail173-co9 (localhost.localdomain [127.0.0.1]) by mail173-co9 (MessageSwitch) id 1363284842290590_23766; Thu, 14 Mar 2013 18:14:02 +0000 (UTC) Received: from CO9EHSMHS021.bigfish.com (unknown [10.236.132.250]) by mail173-co9.bigfish.com (Postfix) with ESMTP id 423FD340047; Thu, 14 Mar 2013 18:14:02 +0000 (UTC) Received: from DB3PRD0711HT003.eurprd07.prod.outlook.com (157.56.254.197) by CO9EHSMHS021.bigfish.com (10.236.130.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Mar 2013 18:14:01 +0000 Received: from DB3PRD0210HT003.eurprd02.prod.outlook.com (157.56.253.69) by pod51017.outlook.com (10.255.183.36) with Microsoft SMTP Server (TLS) id 14.16.263.1; Thu, 14 Mar 2013 18:13:57 +0000 Message-ID: <00e601ce20df$274bd4c0$4001a8c0@gateway.2wire.net> From: t.petch To: Robert Raszuk References: <5141DF65.6000508@google.com><5141E18A.5010909@google.com><11A9C40F-3C47-448C-8248-F5A7484CE91F@nic.cz> Date: Thu, 14 Mar 2013 18:09:53 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.69] X-FOPE-CRA-SourceIpAddress: 157.56.254.197 X-FOPE-CRA-DRYRUN: 1207119;1 X-FOPE-BFA-SENDER: ietfc@btconnect.com X-FOPE-BFA-RECEIVER: swhyte@google.com X-FOPE-BFA-RECEIVER: i2rs@ietf.org X-FOPE-BFA-RECEIVER: robert@raszuk.net X-OriginatorOrg: btconnect.com Cc: i2rs@ietf.org, Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 18:14:05 -0000 ----- Original Message ----- From: "Robert Raszuk" To: "Ladislav Lhotka" Cc: ; "Scott Whyte" Sent: Thursday, March 14, 2013 2:58 PM > Yes from what I understand I2RS aims to interact with "global RIB" aka > inet.X tables and ACLs. Not to protocol local RIBs. In which case, perhaps that is interacting with the FIB and not the RIBs, that is a RIB is the database of information that an instance of a routing protocol needs to do what it does, such as calculating the best route for some meaning of the word best. For OSPF, that would be a database of LSAs, for BGP it would include MED, LOCAL_PREF and so on, as well s AFI/SAFI, next hop etc. So, not to protocol local RIBs, because RIBs are protocol local:-) Tom Petch > > Hence my question what actual data can be read and written to such > RIBs by I2RS. > > Rgs, > R. > > > > On Thu, Mar 14, 2013 at 3:53 PM, Ladislav Lhotka wrote: > > > > On Mar 14, 2013, at 10:46 AM, Robert Raszuk wrote: > > > >> I think we agree that RIB elements for read and write must be clearly > >> defined. And should be extensible. > >> > >> But is RIB abstraction sufficient for I2RS ? > >> > >> For example as we know each VRF contains it's own RIB (different table > >> id). So protocol must be able to also encode which RIB we are talking > >> to. > > > > Well, according to RFC 4271, RIB (i.e., Adj-RIBs, Loc_RIB and Adj-RIBs-Out) are data structures internal to a BGP speaker. I suspect that what I2RS aims at interacting with is what 4271 calls "Routing Table". > > > > Lada > > > >> > >> Further who will instantiate the VRF in this case ? Will I2RS be able > >> to create a RIB instance on the fly ? How will we attach such RIB > >> instance to interfaces ? There is dozens of details here without which > >> I am afraid we can't go productively forward. > >> > >> Best, > >> R. > >> > >> > >> On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte wrote: > >>> On 03/14/2013 07:34 AM, Robert Raszuk wrote: > >>>> > >>>> Hi Scott, > >>>> > >>>>> Why do we need to go beyond defining an interface to the RIB to make your > >>>>> use case work? > >>>> > >>>> > >>>> I am talking precise about that definition of RIB interface. Not how > >>>> the RIB works in given vendor of network element. That is > >>>> implementation detail. > >>>> > >>>> Basically a list of values one can write or read to/from RIB. Have you > >>>> seen any document with such list yet ? > >>> > >>> > >>> So we agree that what a RIB looks like is out of scope, and we need to > >>> insure extensibility beyond proposed use cases for the actual RIB interface? > >>> If so I think the group is well on track to get there, as we grind through > >>> use cases and existing data models. > >>> > >>> -Scott > >>> > >>>> > >>>> Cheers, > >>>> R. > >>>> > >>> > >>> > >>> -- > >>> People who are essentially without the power to implement their ideas in the > >>> real world must leverage the power of their reputations. > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From akatlas@gmail.com Thu Mar 14 11:19:26 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB77D11E815B for ; Thu, 14 Mar 2013 11:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 tSWucG19iMzs for ; Thu, 14 Mar 2013 11:19:26 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 13D5411E80BF for ; Thu, 14 Mar 2013 11:19:26 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id k14so3410933iea.27 for ; Thu, 14 Mar 2013 11:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gdJNOSv09yDxhMTmwpY0TtZcmctDvzYP0lRo6h1kKOU=; b=xPjY0CXn+o9/B+lMayOyxjKkoBnCpSk7Jvje+fNXD3XuuskQ06tBtjrKpbIyfhnlZL w0HUMBj6A5VOk0Nsk9G0rPbpy50RMgJ3oNKwYdtjRYinOggR5qZDqgESeW22pglyU/FJ +pSPz+RzJQkDQUb8V6epUGby+JUeb3Jf2aslwxsGDM7yi1UJNfDuZbp+/lt0efXVQMxf JZL7rYAFytQ7Rfwt+lqNg24dwO6xgbGVSgxFLMcxzbijceehXhLgLbsxjTOCCqlZdCE9 psP6FiyajW65RMS1H6cPjo+Xw4gCN/WUaNz1FIrKSEVpjpIDTSFCrNRIPKUaQdktV9I6 v9ig== MIME-Version: 1.0 X-Received: by 10.50.191.133 with SMTP id gy5mr21904880igc.50.1363285165717; Thu, 14 Mar 2013 11:19:25 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Thu, 14 Mar 2013 11:19:25 -0700 (PDT) In-Reply-To: References: <9001D75E-039A-4C9C-9854-F62C0A21EA5E@riw.us> Date: Thu, 14 Mar 2013 14:19:25 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Cc: Russ White , "i2rs@ietf.org" Subject: Re: [i2rs] Centralized vs distributed I2RS use model X-BeenThere: i2rs@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: Thu, 14 Mar 2013 18:19:26 -0000 It is interesting to discuss whether we need a draft discussing some examples in the range and scope of architectures of network applications that might be using i2rs. I think we all come with different ideas of what might be sane/safe/needed - but want to leave lots of room for innovation in that ecosystem. Alia On Thu, Mar 14, 2013 at 10:53 AM, Robert Raszuk wrote: > Ok then I think we all agree on this. > > Thread closed. (That was incredibly quick :). > > Cheers, > R. > > On Thu, Mar 14, 2013 at 3:47 PM, Russ White wrote: >> >> IMHO, the answer should be "we're not defining a model that works only centralized or distributed, but a just a model --use it any way you like." >> >> :-) >> >> Russ >> >> <>< >> russw@riw.us >> riwhite@verisign.com >> >> On Mar 14, 2013, at 10:13 AM, Robert Raszuk wrote: >> >>> Hi, >>> >>> I think I am hearing quite clearly from most of the presentations that >>> there is sort of opinion that I2RS talks to RIBs from some form of >>> centralized controllers/route servers/topology collectors etc ... >>> >>> Does this mean that I can't use I2RS in completely distributed manner >>> without any central controller ? >>> >>> Note that more and more modern routers and switches gives customers >>> x86 local compute facilities on the box. So I can easily imagine that >>> I write a distributed application which communicates box to box at the >>> application level and installs locally via I2RS interface it's >>> "routes" to RIB. >>> >>> Is this model of operation out of scope of this WG ? >>> >>> Best regards, >>> R. >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From davei@otd.com Thu Mar 14 11:26:19 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133BF11E818B for ; Thu, 14 Mar 2013 11:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 EJDHYSyHiTar for ; Thu, 14 Mar 2013 11:26:15 -0700 (PDT) Received: from teller.otd.com (teller.otd.com [IPv6:2001:470:8:55b:a00:20ff:fe8a:27dd]) by ietfa.amsl.com (Postfix) with ESMTP id B9D3711E811B for ; Thu, 14 Mar 2013 11:26:14 -0700 (PDT) Received: from [IPv6:2001:df8:0:16:9def:1611:7cc:e6fd] ([IPv6:2001:df8:0:16:9def:1611:7cc:e6fd]) (authenticated bits=0) by teller.otd.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id r2EIQ6Tb003043; Thu, 14 Mar 2013 14:26:08 -0400 Message-ID: <5142163E.4040605@otd.com> Date: Thu, 14 Mar 2013 14:26:06 -0400 From: Dave Israel User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Robert Raszuk References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420FD4.6090006@otd.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-otd-MailScanner-Information: Please contact the ISP for more information X-otd-MailScanner-ID: r2EIQ6Tb003043 X-otd-MailScanner: Found to be clean X-otd-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.001, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_40 -0.00) X-otd-MailScanner-From: davei@otd.com X-otd-MailScanner-Watermark: 1363890370.15511@1LYlxaKvweBDPQuEmUrGmg Cc: i2rs@ietf.org Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 18:26:19 -0000 On 03/14/2013 02:02 PM, Robert Raszuk wrote: > Ahhh so you are stating that to provision services on the network in > vendor neutral way I will not be able to use I2RS by design ? > > Is this already agreed point that NETCONF (or any other form of > configuration) will be required anyway in addition to I2RS for any > complete service provisioning ? I don't think there are many already agreed points anywhere outside the charter itself. So don't worry if I think something you don't like; I'm at least as likely to be wrong as anybody else. Still, I am inclined to think that RIB manipulation is separate from permanent configuration. And while you could run a service by hand-configuring your RIBs everywhere with I2RS (with either a persistent I2RB state or reconfiguration on reboot from the controller), it doesn't seem like the *right* way to do it. It makes more sense to establish your normal behavior through the existing configuration mechanisms (CLI, NETCONF, etc), and then use I2RS to manipulate it. -Dave From rraszuk@gmail.com Thu Mar 14 11:34:18 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C046521F90CE for ; Thu, 14 Mar 2013 11:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 u-OXB8+tNPJ7 for ; Thu, 14 Mar 2013 11:34:18 -0700 (PDT) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2391421F90D4 for ; Thu, 14 Mar 2013 11:34:18 -0700 (PDT) Received: by mail-ia0-f177.google.com with SMTP id y25so2421390iay.36 for ; Thu, 14 Mar 2013 11:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oWKS0UvJ8McKozBrcyYrtY8xrhW6LiO1jDnaA3Cfaew=; b=uS8GHiwEo8twaCos0pYsi1aQg+Ke4audys4rt2RDzc9FKcGxH98UXT73FslT96QGmE U86M9z4yjyRkwcOCRHB730Mybc2PzXMo/SGa/1cAEDLWye18PldH0ZsdkdUBNwOXUeeS gG+RH5Gc0hS4xiWxRcExdlCUdUMxmvmYOa3pWCToU8FQCNvuj9GDcU1IttwLzVBlcYv8 3L4IK21oB0ZeyKGtuHdnE5/Tl9p1jpOGmaEi9y80Iw2wMIV+kivlxzv2V5RwYCg9snP3 HLj3E1vqezaX6PQxBc0SDjb1VK+W8gowheovgznw/DTd0ssgM/qrvMl57QUk4FxE39b1 aRdg== MIME-Version: 1.0 X-Received: by 10.50.178.36 with SMTP id cv4mr3215563igc.98.1363286057723; Thu, 14 Mar 2013 11:34:17 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 11:34:17 -0700 (PDT) In-Reply-To: <5142163E.4040605@otd.com> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420FD4.6090006@otd.com> <5142163E.4040605@otd.com> Date: Thu, 14 Mar 2013 19:34:17 +0100 X-Google-Sender-Auth: qb14EmCLm-bMffKHQaL1lnbmLNA Message-ID: From: Robert Raszuk To: Dave Israel Content-Type: text/plain; charset=ISO-8859-1 Cc: i2rs@ietf.org Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 18:34:18 -0000 Actually I am not arguing against permanent vs ephemeral states on network element in fact I agree it is needed. The only worry is that once you talk about two sort of provisioning channels for a given service - perhaps independent from each other - there will always be need for synchronization. Example: I can not modify/add/delete entries in RIB context X if this context X was not yet provisioned .. those classic sort of issues. Thx, R. > On Thu, Mar 14, 2013 at 7:26 PM, Dave Israel wrote: > > On 03/14/2013 02:02 PM, Robert Raszuk wrote: >> >> Ahhh so you are stating that to provision services on the network in >> vendor neutral way I will not be able to use I2RS by design ? >> >> Is this already agreed point that NETCONF (or any other form of >> configuration) will be required anyway in addition to I2RS for any >> complete service provisioning ? > > > I don't think there are many already agreed points anywhere outside the > charter itself. So don't worry if I think something you don't like; I'm at > least as likely to be wrong as anybody else. > > Still, I am inclined to think that RIB manipulation is separate from > permanent configuration. And while you could run a service by > hand-configuring your RIBs everywhere with I2RS (with either a persistent > I2RB state or reconfiguration on reboot from the controller), it doesn't > seem like the *right* way to do it. It makes more sense to establish your > normal behavior through the existing configuration mechanisms (CLI, NETCONF, > etc), and then use I2RS to manipulate it. > > -Dave > From mn1921@att.com Thu Mar 14 13:11:58 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8727B11E8202 for ; Thu, 14 Mar 2013 13:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 JXXqM3RkRo+E for ; Thu, 14 Mar 2013 13:11:58 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id B243C11E815E for ; Thu, 14 Mar 2013 13:11:57 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id d0f22415.0.294715.00-462.828629.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 14 Mar 2013 20:11:57 +0000 (UTC) X-MXL-Hash: 51422f0d468ac26c-bf18ce3934bcf23854913c5ea5b90b6c60f71100 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 r2EKBubp016295; Thu, 14 Mar 2013 16:11:57 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2EKBn3M016139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 16:11:52 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 14 Mar 2013 20:11:34 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 16:11:20 -0400 From: "NAPIERALA, MARIA H" To: Dave Israel , Robert Raszuk Thread-Topic: [i2rs] RIB definition ... Thread-Index: AQHOINve5PzXheM2u0anxFdUg77JwZiluiAAgAACWQCAAAEvAIAABnYA///Z/NA= Date: Thu, 14 Mar 2013 20:10:59 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E0114B653@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420FD4.6090006@otd.com> <5142163E.4040605@otd.com> In-Reply-To: <5142163E.4040605@otd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.19.230] 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=2.0 cv=Fs6yCRXq c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=i-D4eiayz9cA:10 a=L2kbtXBQjhkA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=O_51BKbUSokA:10 a=48vgC7mUAAAA:8 a=tKSsZWHXHn42-n] X-AnalysisOut: [-Rn4wA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 20:11:59 -0000 Is i2rs intended to be an API between provisioning system and a router/netw= ork? If yes, then why wouldn't it include the interface-to-routing table as= sociation? Maria > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of > Dave Israel > Sent: Thursday, March 14, 2013 2:26 PM > To: Robert Raszuk > Cc: i2rs@ietf.org > Subject: Re: [i2rs] RIB definition ... >=20 > On 03/14/2013 02:02 PM, Robert Raszuk wrote: > > Ahhh so you are stating that to provision services on the network in > > vendor neutral way I will not be able to use I2RS by design ? > > > > Is this already agreed point that NETCONF (or any other form of > > configuration) will be required anyway in addition to I2RS for any > > complete service provisioning ? >=20 > I don't think there are many already agreed points anywhere outside the > charter itself. So don't worry if I think something you don't like; > I'm > at least as likely to be wrong as anybody else. >=20 > Still, I am inclined to think that RIB manipulation is separate from > permanent configuration. And while you could run a service by > hand-configuring your RIBs everywhere with I2RS (with either a > persistent I2RB state or reconfiguration on reboot from the > controller), > it doesn't seem like the *right* way to do it. It makes more sense to > establish your normal behavior through the existing configuration > mechanisms (CLI, NETCONF, etc), and then use I2RS to manipulate it. >=20 > -Dave >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From davei@otd.com Thu Mar 14 13:16:34 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585C811E81CE for ; Thu, 14 Mar 2013 13:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 QcfCQ+QC9bFN for ; Thu, 14 Mar 2013 13:16:33 -0700 (PDT) Received: from teller.otd.com (teller.otd.com [IPv6:2001:470:8:55b:a00:20ff:fe8a:27dd]) by ietfa.amsl.com (Postfix) with ESMTP id 9264611E81B0 for ; Thu, 14 Mar 2013 13:16:33 -0700 (PDT) Received: from [IPv6:2001:df8:0:16:9def:1611:7cc:e6fd] ([IPv6:2001:df8:0:16:9def:1611:7cc:e6fd]) (authenticated bits=0) by teller.otd.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id r2EKGQjV005292 for ; Thu, 14 Mar 2013 16:16:27 -0400 Message-ID: <5142301A.8030302@otd.com> Date: Thu, 14 Mar 2013 16:16:26 -0400 From: Dave Israel User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "i2rs@ietf.org" References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420FD4.6090006@otd.com> <5142163E.4040605@otd.com> <1D70D757A2C9D54D83B4CBD7625FA80E0114B610@MISOUT7MSGUSR9I.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E0114B610@MISOUT7MSGUSR9I.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-otd-MailScanner-Information: Please contact the ISP for more information X-otd-MailScanner-ID: r2EKGQjV005292 X-otd-MailScanner: Found to be clean X-otd-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1, required 5, autolearn=not spam, ALL_TRUSTED -1.00) X-otd-MailScanner-From: davei@otd.com X-otd-MailScanner-Watermark: 1363896988.3712@zBtzuij10erEJB+VjtoeOA Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 20:16:34 -0000 On 03/14/2013 04:04 PM, NAPIERALA, MARIA H wrote: > Is i2rs intended to be an API between provisioning system and a router/network? If yes, then why wouldn't it include the interface-to-routing table association? I'd disagree with your first statement. I don't believe that I2RS is intended to be an API to connect a provisioning system to a router/network. It is intended to be an interface through which the RIB of a router can be directly manipulated. A provisioning system might be one use case of such an interface, but I would not call it the intent of I2RS. From mn1921@att.com Thu Mar 14 13:31:56 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B975F11E81A1 for ; Thu, 14 Mar 2013 13:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 vNpPBOC0IX60 for ; Thu, 14 Mar 2013 13:31:56 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id D8E7B11E812B for ; Thu, 14 Mar 2013 13:31:55 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id bb332415.0.287651.00-424.812027.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 14 Mar 2013 20:31:55 +0000 (UTC) X-MXL-Hash: 514233bb6d4776bd-73b3684c6f276ab17ab7604a564a2e10554e8036 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 r2EKVsdk004669; Thu, 14 Mar 2013 16:31:55 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2EKVkp2004580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 16:31:51 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 14 Mar 2013 20:31:33 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 16:31:32 -0400 From: "NAPIERALA, MARIA H" To: Dave Israel , "i2rs@ietf.org" Thread-Topic: [i2rs] RIB definition ... Thread-Index: AQHOINve5PzXheM2u0anxFdUg77JwZiluiAAgAACWQCAAAEvAIAABnYA///URPCAAEqQAP//v2vA Date: Thu, 14 Mar 2013 20:31:32 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E0114B6CA@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420FD4.6090006@otd.com> <5142163E.4040605@otd.com> <1D70D757A2C9D54D83B4CBD7625FA80E0114B610@MISOUT7MSGUSR9I.ITServices.sbc.com> <5142301A.8030302@otd.com> In-Reply-To: <5142301A.8030302@otd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.19.230] 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=2.0 cv=Kpr6LxqN c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=i-D4eiayz9cA:10 a=L2kbtXBQjhkA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=O_51BKbUSokA:10 a=48vgC7mUAAAA:8 a=VmkAbeiXdXEwuX] X-AnalysisOut: [gziEMA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 20:31:56 -0000 Dave, What are the intended use cases for i2rs?=20 Maria > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of > Dave Israel > Sent: Thursday, March 14, 2013 4:16 PM > To: i2rs@ietf.org > Subject: Re: [i2rs] RIB definition ... >=20 >=20 > On 03/14/2013 04:04 PM, NAPIERALA, MARIA H wrote: > > Is i2rs intended to be an API between provisioning system and a > router/network? If yes, then why wouldn't it include the interface-to- > routing table association? >=20 > I'd disagree with your first statement. I don't believe that I2RS is > intended to be an API to connect a provisioning system to a > router/network. It is intended to be an interface through which the > RIB > of a router can be directly manipulated. A provisioning system might > be > one use case of such an interface, but I would not call it the intent > of > I2RS. >=20 >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From mach.chen@huawei.com Thu Mar 14 13:54:50 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1255411E81A8 for ; Thu, 14 Mar 2013 13:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 JIzMQe1Pt3Gt for ; Thu, 14 Mar 2013 13:54:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DC72711E81F0 for ; Thu, 14 Mar 2013 13:54:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APJ43156; Thu, 14 Mar 2013 20:54:46 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 14 Mar 2013 20:54:09 +0000 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 14 Mar 2013 20:54:45 +0000 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.4]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 15 Mar 2013 04:54:39 +0800 From: Mach Chen To: Robert Raszuk , Alia Atlas Thread-Topic: [i2rs] RIB definition ... Thread-Index: AQHOIL5N11PBsr+1wUWFW8fCA49np5ikuc2AgAAAuACAAAHWAIAAAWKAgAADfQCAAADvAIAAA2yAgAAA6wCAACmkgIAAAQ0AgAACWACAAAEvAIAAALuAgAAB9gCAALCiXQ== Date: Thu, 14 Mar 2013 20:54:38 +0000 Message-ID: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420FD4.6090006@otd.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.47.144.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Dave Israel , "i2rs@ietf.org" Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 20:54:50 -0000 Here is another draft that intends to cover the VN (VLAN, L2VPN, L3VPN, etc= .) and VC (TE LSP, PW, etc.) applications http://tools.ietf.org/html/draft-hares-use-case-vn-vc-00 Best regards, Mach ________________________________________ From: i2rs-bounces@ietf.org [i2rs-bounces@ietf.org] on behalf of Robert Ras= zuk [robert@raszuk.net] Sent: Friday, March 15, 2013 2:12 To: Alia Atlas Cc: Dave Israel; i2rs@ietf.org Subject: Re: [i2rs] RIB definition ... I think L3VPN PE application I am referring too is already contained in http://tools.ietf.org/html/draft-hu-i2rs-overlay-use-case-00 Thx, R. On Thu, Mar 14, 2013 at 7:05 PM, Alia Atlas wrote: > I should add > > if we don't have WRITTEN USE-CASES that describe the needs in terms of > information and functionality and the purpose and so on, then YES - > you are likely to see a much narrower scope that may not meet your > specific use-cases. > > Alia > > On Thu, Mar 14, 2013 at 2:02 PM, Robert Raszuk wrote: >> Ahhh so you are stating that to provision services on the network in >> vendor neutral way I will not be able to use I2RS by design ? >> >> Is this already agreed point that NETCONF (or any other form of >> configuration) will be required anyway in addition to I2RS for any >> complete service provisioning ? >> >> Thx, >> R. >> >>> On Thu, Mar 14, 2013 at 6:58 PM, Dave Israel wrote: >>> >>> On 03/14/2013 01:50 PM, Robert Raszuk wrote: >>>>> >>>>> This is doing L3 routing - so VLAN matching seems out; while there ma= y >>>>> be PWE3 or L2VPN type use-cases eventually, I've not seen them yet. >>>> >>>> I think you have missed my point. I am talking about L3. Imagine L3VPN >>>> PE ... I want to configure the service using I2RS ... you have had use >>>> case for this even presented today. So I must match on the incoming >>>> interface (physical or logical) to make sure propor RIB table is used >>>> for packet lookup. >>> >>> >>> Well, arguably, the routing table you're in is already determined by th= e >>> inbound interface. Your inbound interface is already part of a vrf/log= ical >>> system/etc. You might be able to use i2rs to request that your interfa= ce be >>> moved from one routing table to another, but that sounds more like a jo= b for >>> NetCONF-style configuration than I2RS-style ephemeral routing table >>> manipulation. >>> >>> >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs= From rrice@broadcom.com Thu Mar 14 14:00:04 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F19E11E81B0 for ; Thu, 14 Mar 2013 14:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DMVGZ+0aKclo for ; Thu, 14 Mar 2013 14:00:03 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8975F11E80D7 for ; Thu, 14 Mar 2013 14:00:03 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 14 Mar 2013 13:55:45 -0700 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.11) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Thu, 14 Mar 2013 13:59:57 -0700 Received: from SJEXCHMB13.corp.ad.broadcom.com ( [fe80::9d40:1e86:a7dc:c46a]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Thu, 14 Mar 2013 13:59:54 -0700 From: "Rob (William) Rice" To: "i2rs@ietf.org" Thread-Topic: Three characteristics of an operation Thread-Index: Ac4g6I6TU6zo2EgmQKmlxD+P8Yctjw== Date: Thu, 14 Mar 2013 20:59:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7D5CE6DB3C02089680-01-01 Content-Type: multipart/alternative; boundary=_000_DA52363A1FF16D46A4F6AD9836FB586604093727SJEXCHMB13corpa_ Subject: [i2rs] Three characteristics of an operation X-BeenThere: i2rs@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: Thu, 14 Mar 2013 21:00:04 -0000 --_000_DA52363A1FF16D46A4F6AD9836FB586604093727SJEXCHMB13corpa_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Alia's functional analysis presentation at today's I2RS meeting proposed th= ree characteristics to an operation: Start-Time (immediate, temporal, triggered) Persistence across reboots (permanent, ephemeral) Duration/State-expiration (unbounded, temporal) I'd like to ask about the option to set a start (and presumably stop) time = and the option to specify a duration. I assume the intention is to support = these options for every item of I2RS installed state or configuration. I am= wondering whether these time-based options are an essential part of the I2= RS interface? Could we not simply require the client to install or remove t= he state/configuration at the desired time, thus eliminating the additional= complexity in the I2RS interface itself and moving complexity from the net= work device to the controller? Are there use cases where the client cannot = take action at the desired time? (I get the reason for triggered events.) Thanks, Rob --_000_DA52363A1FF16D46A4F6AD9836FB586604093727SJEXCHMB13corpa_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Alia’s functional analysis presentation at today&#= 8217;s I2RS meeting proposed three characteristics to an operation:

 

Start-Time (immediate, temporal, triggered)

Persistence across reboots (permanent, ephemeral)

Duration/State-expiration (unbounded, temporal)

 

I’d like to ask about the option to set a start (a= nd presumably stop) time and the option to specify a duration. I assume the= intention is to support these options for every item of I2RS installed state or configuration. I am wondering whether these time-based = options are an essential part of the I2RS interface? Could we not simply re= quire the client to install or remove the state/configuration at the desire= d time, thus eliminating the additional complexity in the I2RS interface itself and moving complexity from the net= work device to the controller? Are there use cases where the client cannot = take action at the desired time?

 

(I get the reason for triggered events.)

 

Thanks,

 

Rob

--_000_DA52363A1FF16D46A4F6AD9836FB586604093727SJEXCHMB13corpa_-- From davei@otd.com Thu Mar 14 14:01:24 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6328C11E81F0 for ; Thu, 14 Mar 2013 14:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 YLUpv9GMiV8B for ; Thu, 14 Mar 2013 14:01:23 -0700 (PDT) Received: from penn.otd.com (unknown [IPv6:2001:470:7:55b::2]) by ietfa.amsl.com (Postfix) with ESMTP id 81F6E11E8165 for ; Thu, 14 Mar 2013 14:01:23 -0700 (PDT) Received: from [IPv6:2001:df8:0:16:9def:1611:7cc:e6fd] ([IPv6:2001:df8:0:16:9def:1611:7cc:e6fd]) (authenticated bits=0) by penn.otd.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id r2EL16P4009213; Thu, 14 Mar 2013 17:01:07 -0400 Message-ID: <51423A91.3030706@otd.com> Date: Thu, 14 Mar 2013 17:01:05 -0400 From: Dave Israel User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5141E5A0.7000001@google.com> <51420FD4.6090006@otd.com> <5142163E.4040605@otd.com> <1D70D757A2C9D54D83B4CBD7625FA80E0114B610@MISOUT7MSGUSR9I.ITServices.sbc.com> <5142301A.8030302@otd.com> <1D70D757A2C9D54D83B4CBD7625FA80E0114B6CA@MISOUT7MSGUSR9I.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E0114B6CA@MISOUT7MSGUSR9I.ITServices.sbc.com> Content-Type: multipart/alternative; boundary="------------000108000403030205060806" X-otd-MailScanner-Information: Please contact the ISP for more information X-otd-MailScanner-ID: r2EL16P4009213 X-otd-MailScanner: Found to be clean X-otd-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.999, required 5, autolearn=not spam, ALL_TRUSTED -1.00, HTML_MESSAGE 0.00) X-otd-MailScanner-From: davei@otd.com X-otd-MailScanner-Watermark: 1363899671.00533@CNJelzhY+Oh4ppgkROZwYA Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Thu, 14 Mar 2013 21:01:24 -0000 This is a multi-part message in MIME format. --------------000108000403030205060806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/14/2013 04:31 PM, NAPIERALA, MARIA H wrote: > Dave, > > What are the intended use cases for i2rs? > I think we're all here to come up with those. The charter lists the following: o Interactions with the Routing Information Base (RIB). Allowing read and write access to the RIB, but no direct access to the Forwarding Information Base (FIB). o Control and analysis of the operation of the Border Gateway Protocol (BGP) including the setting and activation of policies related to the protocol. o Control, optimization, and choice of traffic exit points from networks based on more information than provided by the dynamic control plane. o Distributed reaction to network-based attacks through rapid modification of the control plane behavior to reroute traffic for one destination while leaving standard mechanisms (filters, metrics, and policy) in place for other routes. o Service layer routing to improve on existing hub-and-spoke traffic. o The ability to extract information about topology from the network. Injection and creation of topology will not be considered as an initial work item. Some use cases I can come up with for such a system include: * Polling the state of the network to determine the exact path the RIB believes a packet should take, edge to edge. * Traffic engineering by identifying an overloaded link and overriding the next hop for some subset of traffic. Or even more generalized traffic engineering: an autonomous controller that uses analytics to determine what endpoints currently need the most bandwidth and automatically allocate bandwidth to those applications, whether across the backbone or across the datacenter. * Setting up policy routing for traffic matching a particular application to optimize performance; for example, pulling best-effort traffic to a longer path when load on a link is causing jitter in real time media. * Finding routes that are not active in the RIB, due to higher administrative distance, and overriding that decision. For example, imagine a situation where you are running OSPF and RIP on a router. Among other things, you receive a default route and another network, say 192.0.2.0/24, via both protocols. You want to believe the RIP route for 192.0.2.0/24 and OSPF for default. Using I2RS, you set a lower distance for only the RIP route. (There's lots of mechanics with this one, including I2RS telling you when the table has changed, so you can intercede again if you have to.) * Attack mitigation by routing traffic to a victim IP to either the bit bucket or a middlebox that can filter bad traffic from good. * Modifying preference on BGP routes in real time to balance traffic ratios, prefer financially less expensive links, manipulate your 95th percentile traffic rate, etc. * Tracking a route oscillation or similar event as it happens to help determine the source. I'm sure there are plenty more... --------------000108000403030205060806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/14/2013 04:31 PM, NAPIERALA, MARIA H wrote:
Dave,

What are the intended use cases for i2rs?

I think we're all here to come up with those.  The charter lists the following:

o Interactions with the Routing Information Base (RIB). Allowing read
and write access to the RIB, but no direct access to the Forwarding
Information Base (FIB).

o Control and analysis of the operation of the Border Gateway Protocol
(BGP) including the setting and activation of policies related to
the protocol.

o Control, optimization, and choice of traffic exit points from
networks based on more information than provided by the dynamic
control plane.

o Distributed reaction to network-based attacks through rapid
modification of the control plane behavior to reroute traffic for
one destination while leaving standard mechanisms (filters, metrics,
and policy) in place for other routes.

o Service layer routing to improve on existing hub-and-spoke traffic.

o The ability to extract information about topology from the network.

Injection and creation of topology will not be considered as an initial work item.

Some use cases I can come up with for such a system include:

* Polling the state of the network to determine the exact path the RIB believes a packet should take, edge to edge.

* Traffic engineering by identifying an overloaded link and overriding the next hop for some subset of traffic.  Or even more generalized traffic engineering: an autonomous controller that uses analytics to determine what endpoints currently need the most bandwidth and automatically allocate bandwidth to those applications, whether across the backbone or across the datacenter.

* Setting up policy routing for traffic matching a particular application to optimize performance; for example, pulling best-effort traffic to a longer path when load on a link is causing jitter in real time media.

* Finding routes that are not active in the RIB, due to higher administrative distance, and overriding that decision.  For example, imagine a situation where you are running OSPF and RIP on a router.  Among other things, you receive a default route and another network, say 192.0.2.0/24, via both protocols.  You want to believe the RIP route for 192.0.2.0/24 and OSPF for default.  Using I2RS, you set a lower distance for only the RIP route.  (There's lots of mechanics with this one, including I2RS telling you when the table has changed, so you can intercede again if you have to.)

* Attack mitigation by routing traffic to a victim IP to either the bit bucket or a middlebox that can filter bad traffic from good.

* Modifying preference on BGP routes in real time to balance traffic ratios, prefer financially less expensive links, manipulate your 95th percentile traffic rate, etc.

* Tracking a route oscillation or similar event as it happens to help determine the source.

I'm sure there are plenty more...


--------------000108000403030205060806-- From ghanwani@gmail.com Mon Mar 18 13:12:25 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2866721F90DB for ; Mon, 18 Mar 2013 13:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 vn7QH1gx0+TY for ; Mon, 18 Mar 2013 13:12:24 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8790921F90D7 for ; Mon, 18 Mar 2013 13:12:24 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id ha11so3274150vcb.16 for ; Mon, 18 Mar 2013 13:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8UAvWa4cLDsMclIsg/uwvknUkzQJzned36lP+EiNl6Q=; b=s0f+hW8A2xq7eUaFwZXYiibXPm25tgJ0A86tTpwZegiz6Uc9G1WpF7E8aeqA83BcYe XnIUQZcqmD262MnkIDkzyI7M1QzWEFly4qPtdRBNsmIL7vzrsg8xafBFshzRhQxOQ5uk eXm6H3sfbPnTTlGvTVBSxgoE5brRR7iM7vwFG/Aq/UnypWEAItuoNRUFbLSibbBbZcs6 Ksy/M+yVORkuvOu4S8IPhxaFYr6Y04hH+7aeKgqMh4tzPowv3zyruflH3Z5GIY/+Ekka zZbaAHUMr6T1LFxR/0GaUmDx1lGrM0QhWRkinc7dsvcWNgvvZMgpq4BTYqI5R2pYbLnt Umxw== MIME-Version: 1.0 X-Received: by 10.52.180.195 with SMTP id dq3mr19470928vdc.9.1363637544028; Mon, 18 Mar 2013 13:12:24 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.58.241.170 with HTTP; Mon, 18 Mar 2013 13:12:23 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> Date: Mon, 18 Mar 2013 13:12:23 -0700 X-Google-Sender-Auth: HUNLuz74vcR9LR3ELosdnvs2C-k Message-ID: From: Anoop Ghanwani To: Alia Atlas Content-Type: multipart/alternative; boundary=bcaec51969f36a180b04d8389b2b Cc: "i2rs@ietf.org" , Robert Raszuk , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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, 18 Mar 2013 20:12:25 -0000 --bcaec51969f36a180b04d8389b2b Content-Type: text/plain; charset=ISO-8859-1 Hi Alia, On Thu, Mar 14, 2013 at 10:43 AM, Alia Atlas wrote: > > The framework gives a first concept of the type of data that I thought > would describe a route for the RIB (also RIB layer - not just > IPv4/IPv6 RIB). > > The case of routing on destination IP address plus an L4 port is > different, of course - that is asking for NEW functionality in the > forwarding plane from what is commonly there beyond support via > ACLs/PBRs. I don't personally see i2rs as providing the necessary > translation mechanism - but that's with the WG chair hat off. > What makes IPDA+L4 port any different in terms of forwarding plane than what is offered by ACLs/PBRs. Isn't that just a subset of what is already offered in the forwarding plane? Anoop --bcaec51969f36a180b04d8389b2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alia,

On Thu, Mar 14, 2013 at 10:43 AM= , Alia Atlas <akatlas@gmail.com> wrote:

The framework gives a first concept of the type of data that I thought
would describe a route for the RIB (also RIB layer - not just
IPv4/IPv6 RIB).

The case of routing on destination IP address plus an L4 port is
different, of course - that is asking for NEW functionality in the
forwarding plane from what is commonly there beyond support via
ACLs/PBRs. =A0 I don't personally see i2rs as providing the necessary translation mechanism - but that's with the WG chair hat off.

What makes IPDA+L4 port any different in terms o= f forwarding plane
than what is offered by ACLs/PBRs. =A0Isn'= t that just a subset of what
is already offered in the forwarding plane?

A= noop=A0
--bcaec51969f36a180b04d8389b2b-- From ietf@meetecho.com Sat Mar 16 09:54:28 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D2F21F8901 for ; Sat, 16 Mar 2013 09:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 Y8XxKMPWiQDk for ; Sat, 16 Mar 2013 09:54:27 -0700 (PDT) Received: from smtpdg2.aruba.it (smtpdg220.aruba.it [62.149.158.220]) by ietfa.amsl.com (Postfix) with ESMTP id B9C6A21F88E3 for ; Sat, 16 Mar 2013 09:54:26 -0700 (PDT) Received: from dell-tcastaldi ([87.16.35.204]) by smtpcmd01.ad.aruba.it with bizsmtp id CGuP1l00G4QFnDT01GuQad; Sat, 16 Mar 2013 17:54:24 +0100 Date: Sat, 16 Mar 2013 12:54:19 -0400 (EDT) From: Meetecho Team To: i2rs@ietf.org Message-ID: <15842168.1.1363452859366.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_5143025.1363452859319" X-Mailman-Approved-At: Tue, 19 Mar 2013 12:50:14 -0700 Subject: [i2rs] I2RS session recording available X-BeenThere: i2rs@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: Sat, 16 Mar 2013 16:54:28 -0000 ------=_Part_0_5143025.1363452859319 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the I2RS WG session at IETF 86 is available at the following URL: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#I2RS In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_5143025.1363452859319-- From akatlas@gmail.com Wed Mar 20 02:00:17 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9642821F8F5C for ; Wed, 20 Mar 2013 02:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 6TnmBT7cFRG3 for ; Wed, 20 Mar 2013 02:00:17 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0C71B21F8F53 for ; Wed, 20 Mar 2013 02:00:16 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id 17so1804170iea.12 for ; Wed, 20 Mar 2013 02:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2VRrZCRlTFfvjIrGX/6jBwToRG4Py1jdmZdhAKhAPBQ=; b=ysxbJCX/DRd0kKJmKeO0XCpD1fEl6Fq2FatHRFhmDA+a+BiQ+UZE5ewAAiytlahhxu aZDFmHPYjDMFf88D+jnnfRg+Ygl2VxPuTuzZ8uffMk6RguieoZcOGhu8xTNmXnGuqjTf smjppa0g1AhT7vxWk3TW9+DhKoBhyZz6HDdqrSVX0PGlp+qkFvA+tWP+cZjP21Q55Vvb CAWtRlORw089DvIql+CGdZZoz2epm+YWewkPFHY97kHh+T2RwB9mdd1hSie3Bq6mffi1 7l6ig8lhom1X1ZOpuND/LHdO1AWhoCGb2Uff5502x2sYh+5rqMqa3kRjJjFSAG1viDKz tHNw== MIME-Version: 1.0 X-Received: by 10.50.47.168 with SMTP id e8mr3842299ign.50.1363770016618; Wed, 20 Mar 2013 02:00:16 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Wed, 20 Mar 2013 02:00:16 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Wed, 20 Mar 2013 02:00:16 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> Date: Wed, 20 Mar 2013 05:00:16 -0400 Message-ID: From: Alia Atlas To: Anoop Ghanwani Content-Type: multipart/alternative; boundary=14dae9340ab16561e404d85773a0 Cc: i2rs@ietf.org, Robert Raszuk , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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, 20 Mar 2013 09:00:17 -0000 --14dae9340ab16561e404d85773a0 Content-Type: text/plain; charset=ISO-8859-1 Robert specifically asked about this capability NOT via PBR/ACL. Alia On Mar 18, 2013 9:12 PM, "Anoop Ghanwani" wrote: > Hi Alia, > > On Thu, Mar 14, 2013 at 10:43 AM, Alia Atlas wrote: > >> >> The framework gives a first concept of the type of data that I thought >> would describe a route for the RIB (also RIB layer - not just >> IPv4/IPv6 RIB). >> >> The case of routing on destination IP address plus an L4 port is >> different, of course - that is asking for NEW functionality in the >> forwarding plane from what is commonly there beyond support via >> ACLs/PBRs. I don't personally see i2rs as providing the necessary >> translation mechanism - but that's with the WG chair hat off. >> > > What makes IPDA+L4 port any different in terms of forwarding plane > than what is offered by ACLs/PBRs. Isn't that just a subset of what > is already offered in the forwarding plane? > > Anoop > --14dae9340ab16561e404d85773a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Robert specifically asked about this capability NOT via PBR/= ACL.

Alia

On Mar 18, 2013 9:12 PM, "Anoop Ghanwani&qu= ot; <anoop@alumni.duke.edu&= gt; wrote:
Hi Alia,

On Thu, Mar 14, 2013 at 10:43 AM= , Alia Atlas <akatlas@gmail.com> wrote:

The framework gives a first concept of the type of data that I thought
would describe a route for the RIB (also RIB layer - not just
IPv4/IPv6 RIB).

The case of routing on destination IP address plus an L4 port is
different, of course - that is asking for NEW functionality in the
forwarding plane from what is commonly there beyond support via
ACLs/PBRs. =A0 I don't personally see i2rs as providing the necessary translation mechanism - but that's with the WG chair hat off.

What makes IPDA+L4 port any different in terms o= f forwarding plane
than what is offered by ACLs/PBRs. =A0Isn'= t that just a subset of what
is already offered in the forwarding plane?

A= noop=A0
--14dae9340ab16561e404d85773a0-- From lhotka@nic.cz Wed Mar 20 02:51:46 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2137A21F8A41 for ; Wed, 20 Mar 2013 02:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] 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 JGtyzw8nIFVl for ; Wed, 20 Mar 2013 02:51:45 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id C084121F8A2A for ; Wed, 20 Mar 2013 02:51:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 0714A540472; Wed, 20 Mar 2013 10:51:41 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyHrmE9sV3mL; Wed, 20 Mar 2013 10:51:37 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 8BEEC54029E; Wed, 20 Mar 2013 10:51:27 +0100 (CET) From: Ladislav Lhotka To: Alia Atlas , Anoop Ghanwani In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Wed, 20 Mar 2013 10:51:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: i2rs@ietf.org, Robert Raszuk , Scott Whyte Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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, 20 Mar 2013 09:51:46 -0000 Alia Atlas writes: > Robert specifically asked about this capability NOT via PBR/ACL. > Any comments about the approach of draft-ietf-netmod-routing-cfg-09? A route is defined there as an extensible container, and future modules (e.g., those defining data models for routing protocols) are expected to augment this container with new attributes. This augmentation is described in sec. 4.4.2 (Defining New Routing Protocols), and and example is shown in Appendix B for RIP. It means that the definion of route is not fixed but depends on the modules supported by the device. Thanks, Lada > Alia > On Mar 18, 2013 9:12 PM, "Anoop Ghanwani" wrote: > >> Hi Alia, >> >> On Thu, Mar 14, 2013 at 10:43 AM, Alia Atlas wrote: >> >>> >>> The framework gives a first concept of the type of data that I thought >>> would describe a route for the RIB (also RIB layer - not just >>> IPv4/IPv6 RIB). >>> >>> The case of routing on destination IP address plus an L4 port is >>> different, of course - that is asking for NEW functionality in the >>> forwarding plane from what is commonly there beyond support via >>> ACLs/PBRs. I don't personally see i2rs as providing the necessary >>> translation mechanism - but that's with the WG chair hat off. >>> >> >> What makes IPDA+L4 port any different in terms of forwarding plane >> than what is offered by ACLs/PBRs. Isn't that just a subset of what >> is already offered in the forwarding plane? >> >> Anoop >> > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From russw@riw.us Wed Mar 20 06:02:55 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE1421F8D55 for ; Wed, 20 Mar 2013 06:02:55 -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 H4TssDeo8FwD for ; Wed, 20 Mar 2013 06:02:54 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id A3C6721F8C97 for ; Wed, 20 Mar 2013 06:02:54 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=[192.168.100.75]) by da31.namelessnet.net with esmtpa (Exim 4.80) (envelope-from ) id 1UIIfO-0006Uo-2w for i2rs@ietf.org; Wed, 20 Mar 2013 06:02:54 -0700 Message-ID: <5149B386.8020504@riw.us> Date: Wed, 20 Mar 2013 09:03:02 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: i2rs@ietf.org References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> In-Reply-To: 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: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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, 20 Mar 2013 13:02:55 -0000 > Any comments about the approach of draft-ietf-netmod-routing-cfg-09? I've commented on this draft in the past... IMHO: - It's not well enough defined for what we really want to get to here. - It doesn't seem to be well organized For instance --why is there a difference between "rw main-routing-tables," and "rw routing-tables?" When would I choose to use one or the other? Where are the routing filters mentioned as a separate "thing" applied, and how are they applied? What are the elements of the filter object? What's the point of the "recipient routing table," piece of this model (since we're talking about data, not an action)? Why should "connected routes," and "static routes," be explicitly called out as different "types" of routing protocols? How are they special? > A route is defined there as an extensible container, and future modules (e.g., those defining data models for routing protocols) are expected to augment this container with new attributes. This augmentation is described in sec. 4.4.2 (Defining New Routing Protocols), and and example is shown in Appendix B for RIP. > > It means that the definion of route is not fixed but depends on the modules supported by the device. Which isn't going to work if you're actually trying to insert routes to a number of different devices across a diverse network... All of which is what went into my thinking about moving to a different sort of model -- Rather than asking how to model a RIB, what if we tried to model the information needed to actually forward a packet at layer 3? In other words: - These are the tuples needed to build a solid routing table entry from which the device can build forwarding table entries - Add in the pieces we need for "policy," particularly the idea of preference (called admin distance in cisco, for instance) Is there anything else we would need? The other option is to simply realize there's no "right" model here. Just choose one that works, and move on with life. Otherwise, we're going to bog down in arguing about models, rather than getting real work done... And I'd really like to move to the "get real work done" phase of things, rather than chatting about different models for the next several years. :-) :-) Russ From akatlas@gmail.com Wed Mar 20 06:55:03 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAD721F8D6A for ; Wed, 20 Mar 2013 06:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 5ic+8OrALp+B for ; Wed, 20 Mar 2013 06:55:02 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9B721F8D3C for ; Wed, 20 Mar 2013 06:55:02 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id fs13so3008966lab.36 for ; Wed, 20 Mar 2013 06:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CO1MaofJNqIL4u4fJ8FerSeFXuz5MIEUJi5fdMu9IqA=; b=jvKJ5GOIfTdoh5FTbU3zquLxkj3ErXQa4oYtnzRCLc8acADT9AK6W5J5y/RyA12Vlv R7I4WOVgjMf2oGtcysa2vQ8CTk/MpeS2uBfSp0M7qTPyR2FSfJDlxLV9RswWTWIRiYCH H3R+tYhvhmj6ePcv7KJfuAutipFnzFZswYeHevte8RLABK0YLzCgeSDn9hS8nOrTvYj0 iukZrQeCc91LB1QFjFeZg6iMiAjctNgSsk+fxqztHgevm2ZxUpsfJDUl8w6JOr+xXD1l cRX6adM0SFFtjsjvhmakXM3tSvkZZ7bcC9Jk8/Dq7l1qkYNW7eJNpvMzchM6lG+hUMzH dMLA== MIME-Version: 1.0 X-Received: by 10.152.144.105 with SMTP id sl9mr5491759lab.4.1363787701389; Wed, 20 Mar 2013 06:55:01 -0700 (PDT) Received: by 10.112.111.73 with HTTP; Wed, 20 Mar 2013 06:55:01 -0700 (PDT) Received: by 10.112.111.73 with HTTP; Wed, 20 Mar 2013 06:55:01 -0700 (PDT) In-Reply-To: <5149B386.8020504@riw.us> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5149B386.8020504@riw.us> Date: Wed, 20 Mar 2013 09:55:01 -0400 Message-ID: From: Alia Atlas To: Russ White Content-Type: multipart/alternative; boundary=e89a8f22c5bd7d91f904d85b914a Cc: i2rs@ietf.org Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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, 20 Mar 2013 13:55:03 -0000 --e89a8f22c5bd7d91f904d85b914a Content-Type: text/plain; charset=ISO-8859-1 First, while it is interesting to look at YANG models, what we need to be thinking about in i2rs is information models - and how well different data modeling languages meet those needs. More comments in-line (ruthlessly cut) On Mar 20, 2013 2:02 PM, "Russ White" wrote: > Rather than asking how to model a RIB, what if we tried to model the > information needed to actually forward a packet at layer 3? In other words: > > - These are the tuples needed to build a solid routing table entry from > which the device can build forwarding table entries > - Add in the pieces we need for "policy," particularly the idea of > preference (called admin distance in cisco, for instance) [Alia] I don't think that the forwarding info is quite the set we need, but I would really like to see even a minimal information model for what the RIB service info model should look like. For instance, in addition to admin-preference, we need the multiple route-tables, ways of putting traffic in other than by just dest IP address, what events can be registered for, etc. > Is there anything else we would need? > > The other option is to simply realize there's no "right" model here. > Just choose one that works, and move on with life. [Alia] yes, get a small set of sufficient info to meet a basic set of use-cases and define & use it. It can always be extended later if and as necessary. Alia --e89a8f22c5bd7d91f904d85b914a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

First, while it is interesting to look at YANG models, what = we need to be thinking about in i2rs is information models - and how well d= ifferent data modeling languages meet those needs.

More comments in-line (ruthlessly cut)

On Mar 20, 2013 2:02 PM, "Russ White" <russw@riw.us> wrote:
> Rather than asking how to model a RIB, what if we tried to model the > information needed to actually forward a packet at layer 3? In other w= ords:
>
> - These are the tuples needed to build a solid routing table entry fro= m
> which the device can build forwarding table entries
> - Add in the pieces we need for "policy," particularly the i= dea of
> preference (called admin distance in cisco, for instance)

[Alia] I don't think that the forwarding info is quite t= he set we need, but I would really like to see even a minimal information m= odel for what the RIB service info model should look like.=A0 For instance,= in addition to admin-preference, we need the multiple route-tables, ways o= f putting traffic in other than by just dest IP address, what events can be= registered for, etc.

> Is there anything else we would need?
>
> The other option is to simply realize there's no "right"= model here.
> Just choose one that works, and move on with life.

[Alia] yes, get a small set of sufficient info to meet a bas= ic set of use-cases and define & use it.=A0 It can always be extended l= ater if and as necessary.

Alia

--e89a8f22c5bd7d91f904d85b914a-- From lhotka@nic.cz Wed Mar 20 09:17:47 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FBF21F8667 for ; Wed, 20 Mar 2013 09:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] 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 R61nTJGY7kqH for ; Wed, 20 Mar 2013 09:17:47 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id A5D5421F843F for ; Wed, 20 Mar 2013 09:17:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 1F666540472; Wed, 20 Mar 2013 17:17:45 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycOL-Dpyvy8t; Wed, 20 Mar 2013 17:17:33 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id F2C8754023E; Wed, 20 Mar 2013 17:17:28 +0100 (CET) From: Ladislav Lhotka To: Russ White , i2rs@ietf.org In-Reply-To: <5149B386.8020504@riw.us> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5149B386.8020504@riw.us> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Wed, 20 Mar 2013 17:17:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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, 20 Mar 2013 16:17:48 -0000 Hi Russ, thanks for reading the draft (again). My responses are inline. Russ White writes: >> Any comments about the approach of draft-ietf-netmod-routing-cfg-09? > > I've commented on this draft in the past... > > IMHO: > > - It's not well enough defined for what we really want to get to here. There are certainly (intentional) gaps that will have to be filled, but IMO the data model could serve as a basis for I2RS, too. Unless, of course, you think something is wrong with it, in which case I'd like to hear the details so that we can improve it. I do believe though that we should eventually work, as much as possible, with the same data models - after all, the underlying router will be the same for both NETCONF and I2RS. > - It doesn't seem to be well organized > > For instance --why is there a difference between "rw > main-routing-tables," and "rw routing-tables?" When would I choose to > use one or the other? Unfortunately, it is not sufficient to look just at the graphical representation of the data tree in sec. 4. In the "ietf-routing" YANG module (sec. 6), you can see that "main-routing-table" is essentially only a *pointer* to a routing table. Its purpose is the following: There must be at least one routing table per address family, but there may be more, either built-in or user-defined. Each router instance then uses the "main-routing-table" pointers for designating the main routing table for each AF. Main routing tables are special in that - direct routes are always installed in them, - by default, all routing protocols instances are connected to them (this can be reconfigured). Incidentally, until rev. -05 of the draft, the main routing tables were distinguished from the others by special prescribed names such as "main-ipv4-unicast", but then Wes Hardaker in his review objected (see http://www.ietf.org/mail-archive/web/netmod/current/msg07106.html, item 3) that using magic names was a bad idea. So we finally agreed to use an explicit pointer. > > Where are the routing filters mentioned as a separate "thing" applied, > and how are they applied? What are the elements of the filter object? The draft doesn't include any data model for specifying route filters. When the NETMOD WG was discussing the current charter, I actually proposed that the routing model would also include route filtering, but the prevailing opinion was that this task was too complicated and better left to experts. And indeed, it will IMO be pretty difficult to come up with a vendor-neutral filter specification that can be mapped somehow to the existing route filtering frameworks. So yes, the "route-filter" entries in the current data model are mere placeholders, and the plan is that one or more route filtering data models will be developed and plugged into the prepared slots via augmentation (which IMO is one of YANG's killer features). What the existing data model does specify are the places where route filters can be applied. It is - between a routing protocol and its connected routing table, and - between a routing table and its recipient routing tables. I had the impression from the previous discussion in this ML that this might suffice for I2RS purposes. > > What's the point of the "recipient routing table," piece of this model > (since we're talking about data, not an action)? Some implementations (Cisco IOS) use the concept of "redistributing" routes directly between routing protocol instances while others (JUNOS, BIRD routing daemon) let each protocol first put its routes into a routing table and then pass it form there to other protocols, routing tables or the forwarding table. I believe the latter approach is more general. So, using this data model, the standard redistribution of routes from "proto A" to "proto B" will be configured like this: +---------+ +---------+ | proto A | | proto B | +---------+ +---------+ | ^ | ^ v | v | +---------+ +---------+ | table A |--------->| table B | +---------+ +---------+ Here, table A/B is the connected routing table for proto A/B, respectively, and table B is a recipient routing table for table A. A route filter can be applied at every edge in the above graph. > > Why should "connected routes," and "static routes," be explicitly called > out as different "types" of routing protocols? How are they special? It is not our invention, JUNOS and BIRD deal with direct and static routes in terms of routing (pseudo-)protocols. As for the "direct" pseudo-protocol, it requires no configuration and can actually appear only in the "source-protocol" attribute of routes. On the other hand, "static" instances have to be configured - their configuration inlcudes the list of static routes that will then appear in routing tables with source protocol set to "static". > >> A route is defined there as an extensible container, and future modules (e.g., those defining data models for routing protocols) are expected to augment this container with new attributes. This augmentation is described in sec. 4.4.2 (Defining New Routing Protocols), and and example is shown in Appendix B for RIP. >> >> It means that the definion of route is not fixed but depends on the modules supported by the device. > > Which isn't going to work if you're actually trying to insert routes to > a number of different devices across a diverse network... If the network is heterogeneous, it it IMO quite appropriate to make use of specific capabilities of each type of device. In NETCONF this can be easily done because each device starts the session with advertising its capabilities to the manager. Why this isn't going to work in I2RS? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From akatlas@juniper.net Fri Mar 22 05:08:17 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A54D21F8AC1 for ; Fri, 22 Mar 2013 05:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 dflAWgiJ1+38 for ; Fri, 22 Mar 2013 05:08:16 -0700 (PDT) Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6F32321F85D6 for ; Fri, 22 Mar 2013 05:08:15 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUUxJria1+gJ8cU0pV8ZiIGQzZFvAcitf@postini.com; Fri, 22 Mar 2013 05:08:16 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 22 Mar 2013 05:04:16 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 22 Mar 2013 05:04:13 -0700 Received: from CO9EHSOBE007.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 22 Mar 2013 05:13:27 -0700 Received: from mail138-co9-R.bigfish.com (10.236.132.252) by CO9EHSOBE007.bigfish.com (10.236.130.70) with Microsoft SMTP Server id 14.1.225.23; Fri, 22 Mar 2013 12:04:12 +0000 Received: from mail138-co9 (localhost [127.0.0.1]) by mail138-co9-R.bigfish.com (Postfix) with ESMTP id CD839200252 for ; Fri, 22 Mar 2013 12:04:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 2 X-BigFish: PS2(z569dhzc857hzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz18c673h8275bhz2dh2a8h668h839hbe3hd24hf0ah10d2h1288h12a5h12bdh137ah1441h1537h153bh162dh1631h1758h18deh18e1h1946h19b5h1ad9h1b0ah17ej1155h) Received: from mail138-co9 (localhost.localdomain [127.0.0.1]) by mail138-co9 (MessageSwitch) id 1363953851345353_26798; Fri, 22 Mar 2013 12:04:11 +0000 (UTC) Received: from CO9EHSMHS006.bigfish.com (unknown [10.236.132.253]) by mail138-co9.bigfish.com (Postfix) with ESMTP id 2FFD914007E for ; Fri, 22 Mar 2013 12:04:11 +0000 (UTC) Received: from BY2PRD0510HT004.namprd05.prod.outlook.com (157.56.236.101) by CO9EHSMHS006.bigfish.com (10.236.130.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 22 Mar 2013 12:04:09 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.54]) by BY2PRD0510HT004.namprd05.prod.outlook.com ([10.255.84.39]) with mapi id 14.16.0275.006; Fri, 22 Mar 2013 12:04:09 +0000 From: Alia Atlas To: "i2rs@ietf.org" Thread-Topic: Interim meeting Thread-Index: Ac4m9VuLX4TrFDPxSvK9ThSBXgqyxQ== Date: Fri, 22 Mar 2013 12:04:08 +0000 Message-ID: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [::] Content-Type: multipart/alternative; boundary="_000_7g6u39a4hv4a61c1ivkgnlja1363953476769emailandroidcom_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [i2rs] Interim meeting X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alia Atlas List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 12:08:17 -0000 --_000_7g6u39a4hv4a61c1ivkgnlja1363953476769emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RWQgYW5kIEkgd291bGQgbGlrZSB0byBoYXZlIGFuIGludGVyaW0gbWVldGluZyBpbiBtaWQtQXBy aWwgaW4gdGhlIE1vdW50YWluIFZpZXcvU3Vubnl2YWxlLCBDQSBhcmVhLiBXZSBhcmUgdHJ5aW5n IHRvIHRpbWUgaXQgZm9yIGFyb3VuZCB0aGUgT3BlbiBOZXR3b3JraW5nIFN1bW1pdCwgYnV0IG5v dCBjb25mbGljdGluZyB3aXRoIHRoYXQgb3IgdGhlIE9ORiB3b3JrZGF5cy4NCg0KV2UgbmVlZCB0 byBhbm5vdW5jZSBpdCA0IHdlZWtzIGluIGFkdmFuY2UuICBVbmxlc3MsIHdlIGFubm91bmNlIHRv ZGF5IGZvciB0aGUgYWZ0ZXJub29uL2V2ZW5pbmcgb2YgQXByaWwgMTkgKG9yIGludG8gQXByaWwg MjApLCB3ZSBhcmUgbG9va2luZyBhdCBBcHJpbCAyMi8yMy4gIE9waW5pb25zIEFTQVAgZnJvbSB0 aG9zZSB3aG8gd291bGQgYXR0ZW5kIHdvdWxkIGJlIHF1aXRlIHVzZWZ1bC4NCg0KSW4gcGFydGlj dWxhciwgaXMgdGhpcyBhIGdvb2QgdGltZS9wbGFjZT8NCg0KV2Ugd2FudCB0aGUgaW50ZXJpbSB0 byBmb2N1cyBvbiB0aGUgdXNlLWNhc2VzICYgZnVuY3Rpb25hbGl0eSBmb3IgaTJycy4gICBJIGV4 cGVjdCB0aGF0IHdlJ2xsIGFzayBhdHRlbmRlZXMgdG8gcGljayBhIHNldCBvZiB1c2UtY2FzZXMg dG8gYmUgaW4gYSBkZXNpZ24tZ3JvdXAgYmVmb3JlICYgZHVyaW5nIHRoZSBtZWV0aW5nIHRvIGRp c2N1c3MgJiB0aGVuIHByZXNlbnQgdG8gdGhlIGxhcmdlciBncm91cC4gIE1vcmUgZGV0YWlscyB0 byBmb2xsb3cgc29vbi4NCg0KUmVnYXJkcywNCkFsaWENCg== --_000_7g6u39a4hv4a61c1ivkgnlja1363953476769emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <20A63811F4888F48AABC4985E72F4198@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KRWQgYW5kIEkgd291 bGQgbGlrZSB0byBoYXZlIGFuIGludGVyaW0gbWVldGluZyBpbiBtaWQtQXByaWwgaW4gdGhlIE1v dW50YWluIFZpZXcvU3Vubnl2YWxlLCBDQSBhcmVhLiBXZSBhcmUgdHJ5aW5nIHRvIHRpbWUgaXQg Zm9yIGFyb3VuZCB0aGUgT3BlbiBOZXR3b3JraW5nIFN1bW1pdCwgYnV0IG5vdCBjb25mbGljdGlu ZyB3aXRoIHRoYXQgb3IgdGhlIE9ORiB3b3JrZGF5cy4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PldlIG5lZWQgdG8gYW5ub3VuY2UgaXQgNCB3ZWVrcyBpbiBhZHZhbmNlLiAmbmJzcDtVbmxlc3Ms IHdlIGFubm91bmNlIHRvZGF5IGZvciB0aGUgYWZ0ZXJub29uL2V2ZW5pbmcgb2YgQXByaWwgMTkg KG9yIGludG8gQXByaWwgMjApLCB3ZSBhcmUgbG9va2luZyBhdCBBcHJpbCAyMi8yMy4gJm5ic3A7 T3BpbmlvbnMgQVNBUCBmcm9tIHRob3NlIHdobyB3b3VsZCBhdHRlbmQgd291bGQgYmUgcXVpdGUg dXNlZnVsLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW4gcGFydGljdWxhciwgaXMg dGhpcyBhIGdvb2QgdGltZS9wbGFjZT88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pldl IHdhbnQgdGhlIGludGVyaW0gdG8gZm9jdXMgb24gdGhlIHVzZS1jYXNlcyAmYW1wOyBmdW5jdGlv bmFsaXR5IGZvciBpMnJzLiAmbmJzcDsgSSBleHBlY3QgdGhhdCB3ZSdsbCBhc2sgYXR0ZW5kZWVz IHRvIHBpY2sgYSBzZXQgb2YgdXNlLWNhc2VzIHRvIGJlIGluIGEgZGVzaWduLWdyb3VwIGJlZm9y ZSAmYW1wOyBkdXJpbmcgdGhlIG1lZXRpbmcgdG8gZGlzY3VzcyAmYW1wOyB0aGVuIHByZXNlbnQg dG8gdGhlIGxhcmdlciBncm91cC4gJm5ic3A7TW9yZSBkZXRhaWxzIHRvIGZvbGxvdw0KIHNvb24u PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5BbGlh PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7g6u39a4hv4a61c1ivkgnlja1363953476769emailandroidcom_-- From cdl@asgaard.org Fri Mar 22 05:11:22 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7C421F8AD5 for ; Fri, 22 Mar 2013 05:11:20 -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 YbCKpVP-vbGX for ; Fri, 22 Mar 2013 05:11:18 -0700 (PDT) Received: from smtp4.emailarray.com (smtp4.emailarray.com [65.39.216.22]) by ietfa.amsl.com (Postfix) with ESMTP id 98FBB21F8AD1 for ; Fri, 22 Mar 2013 05:11:18 -0700 (PDT) Received: (qmail 4350 invoked by uid 89); 22 Mar 2013 12:11:17 -0000 Received: from unknown (HELO ?204.29.150.161?) (Y2RsQGFzZ2FhcmQub3JnQDUwLjc2LjM0LjE4NQ==) (POLARISLOCAL) by smtp4.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Mar 2013 12:11:16 -0000 From: "Christopher LILJENSTOLPE" To: "Alia Atlas" Date: Fri, 22 Mar 2013 05:11:13 -0700 Message-ID: <6C075F9C-BC8A-483D-B7AF-4A190A707CC4@asgaard.org> In-Reply-To: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_BD66EBC3-A504-4569-AEF5-257DF745DD8A_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.5.3r3271) X-PolarisMail-Flags: x Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 12:11:23 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_BD66EBC3-A504-4569-AEF5-257DF745DD8A_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Supposedly, on 2013-Mar-22, at 05.04 PDT(-0700), someone claiming to be A= lia Atlas scribed: > Ed and I would like to have an interim meeting in mid-April in the Moun= tain View/Sunnyvale, CA area. We are trying to time it for around the Ope= n Networking Summit, but not conflicting with that or the ONF workdays. > > We need to announce it 4 weeks in advance. Unless, we announce today f= or the afternoon/evening of April 19 (or into April 20), we are looking a= t April 22/23. Opinions ASAP from those who would attend would be quite = useful. > > In particular, is this a good time/place? works for me > > We want the interim to focus on the use-cases & functionality for i2rs.= I expect that we'll ask attendees to pick a set of use-cases to be in = a design-group before & during the meeting to discuss & then present to t= he larger group. More details to follow soon. > Christopher > Regards, > Alia > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf Check my calendar availability: https://tungle.me/cdl --=_MailMate_BD66EBC3-A504-4569-AEF5-257DF745DD8A_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJRTEphAAoJEGmx2Mt/+Iw/u+UH/22AQFIoCSdnBHV+S9w+8+In s7OiA86xwcmAaagYk54kdN8y6hpMC7f9rUOZvoh+7w9kJCgHWRa8NXETTkHzBOyo 8Z/NxIjf45xRe2SyV2KBwDLzH1fSO4GvjK05Eoo08aSnt9nCe+NdNi9nSH4OiR8I cji1uOnv4QyLbxhb9ahLV/EDjiVpO9rh+dPDW8G32F/x9vEGztJUyetd4MlOgHJB nrCaeIf0jDwwSXagHFia88fPosTNrkNisMwQq9U0W8Gd+QIh4sD9vy8yIWqFv5kq 8mZhbNaYv+CXjUg7BlmgDNQkoTV42fuqhIDajGNEZ6aGE2N/AEAYFghVHoX4AxY= =WCRt -----END PGP SIGNATURE----- --=_MailMate_BD66EBC3-A504-4569-AEF5-257DF745DD8A_=-- From rraszuk@gmail.com Fri Mar 22 05:13:21 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CC421F86CE for ; Fri, 22 Mar 2013 05:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 WlQWZGvlrg1O for ; Fri, 22 Mar 2013 05:13:20 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C005221F8514 for ; Fri, 22 Mar 2013 05:13:20 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id at1so743354iec.13 for ; Fri, 22 Mar 2013 05:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZNX4a/Z9KUrnZ7jF4ftynga5THQp2qSjwTjkx6QbYug=; b=UMT+AWDh8KrdTRRlFWjVgRWTOpur+0VjSdx8Nc2GYeyfKCOZb2/uQDp/EuUEdGEeuP yW6oQqYPZcq5d90xwszYXfJF2Z/7orSynb8/kMCH3BeCVGhoyFNjHetn6ab/CUCTQkiU h7hFHfQSoMiSfV/zMJTc4RsHZQCu9JieM3qTbFkr3rDFSE38fc7ezfgfhHLbiVYOxKhT NNaRDDV5VHAU5YPP5CIsxCEjPrFTyEZs5mH6sCgI6RIQN47JDhBgwwycjhXSgCog0JOQ Rq1MB8eRaFZGp+xaw3ITcDh3G+LXp7QRXket9TTSGBErf92ZaZFY6isknlVAI/Urbt6U qbeQ== MIME-Version: 1.0 X-Received: by 10.50.47.200 with SMTP id f8mr4596551ign.98.1363954400416; Fri, 22 Mar 2013 05:13:20 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Fri, 22 Mar 2013 05:13:20 -0700 (PDT) In-Reply-To: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> Date: Fri, 22 Mar 2013 13:13:20 +0100 X-Google-Sender-Auth: tdzTHcscT7ZK7vmnDY2Gi3-0aZg Message-ID: From: Robert Raszuk To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 12:13:21 -0000 > April 22/23 @ Bay Area Perfect location and timing ! +1. Thx, Robert. > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas wrote: > > Ed and I would like to have an interim meeting in mid-April in the Mountain > View/Sunnyvale, CA area. We are trying to time it for around the Open > Networking Summit, but not conflicting with that or the ONF workdays. > > We need to announce it 4 weeks in advance. Unless, we announce today for > the afternoon/evening of April 19 (or into April 20), we are looking at > April 22/23. Opinions ASAP from those who would attend would be quite > useful. > > In particular, is this a good time/place? > > We want the interim to focus on the use-cases & functionality for i2rs. I > expect that we'll ask attendees to pick a set of use-cases to be in a > design-group before & during the meeting to discuss & then present to the > larger group. More details to follow soon. > > Regards, > Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From akatlas@gmail.com Fri Mar 22 05:27:10 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC8121F84D4 for ; Fri, 22 Mar 2013 05:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 BxBC3kS3LBXF for ; Fri, 22 Mar 2013 05:27:09 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id BA1AC21F8528 for ; Fri, 22 Mar 2013 05:27:09 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id k11so4663262iea.38 for ; Fri, 22 Mar 2013 05:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7Egq2XWQM9n9FpuEhjEk8Gr4tip4uKLQldqYL+s9oaA=; b=fvOhzQUBDKQR6Dl5J3f1yPphDBi3tA1D3CJw3POLaswqB6tKJP4zy0CXQLYTzXza/h FiSrxLocesvFliaP1LeHrwg9z+rv2WTJI07yoKjRi1GLN1EKZ+llzy8dWErvDOISopU2 Cx5pbNXSHSyBxfS6LWlytcoZxHYemc+/yEo//YP41iFV8oku4tqQsiefabz640CxvTpO P2Co92TBfUaC93bKbCfZB6K8+GjJiBpjlJ4yc9JRV7gtkQub2lrVFvULCT7TxESZzu0O AAJGIdSL6KclccisdK9S692sYM2xI/UfT4/mAiLuV0P3ojRxNxQh5jSeCN78vNiVtK8R IZiw== MIME-Version: 1.0 X-Received: by 10.50.36.199 with SMTP id s7mr4724682igj.56.1363955229324; Fri, 22 Mar 2013 05:27:09 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Fri, 22 Mar 2013 05:27:09 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Fri, 22 Mar 2013 05:27:09 -0700 (PDT) In-Reply-To: References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> Date: Fri, 22 Mar 2013 08:27:09 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: multipart/alternative; boundary=14dae9340d03ef0a1304d88292cc Cc: i2rs@ietf.org, akatlas@juniper.net Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 12:27:10 -0000 --14dae9340d03ef0a1304d88292cc Content-Type: text/plain; charset=ISO-8859-1 I am specifically trying to determine if there is strong interest in the Friday April 19 & April 20 vs. April 22-23. Alia On Mar 22, 2013 1:13 PM, "Robert Raszuk" wrote: > > April 22/23 @ Bay Area > > Perfect location and timing ! +1. > > Thx, > Robert. > > > > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas wrote: > > > > Ed and I would like to have an interim meeting in mid-April in the > Mountain > > View/Sunnyvale, CA area. We are trying to time it for around the Open > > Networking Summit, but not conflicting with that or the ONF workdays. > > > > We need to announce it 4 weeks in advance. Unless, we announce today for > > the afternoon/evening of April 19 (or into April 20), we are looking at > > April 22/23. Opinions ASAP from those who would attend would be quite > > useful. > > > > In particular, is this a good time/place? > > > > We want the interim to focus on the use-cases & functionality for i2rs. > I > > expect that we'll ask attendees to pick a set of use-cases to be in a > > design-group before & during the meeting to discuss & then present to the > > larger group. More details to follow soon. > > > > Regards, > > Alia > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --14dae9340d03ef0a1304d88292cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I am specifically trying to determine if there is strong int= erest in the Friday April 19 & April 20 vs. April 22-23.

Alia

On Mar 22, 2013 1:13 PM, "Robert Raszuk&quo= t; <robert@raszuk.net> wrote= :
> April 22/23 @ Bay Area

Perfect location and timing ! =A0+1.

Thx,
Robert.


> On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas <akatlas@juniper.net> wrote:
>
> Ed and I would like to have an interim meeting in mid-April in the Mou= ntain
> View/Sunnyvale, CA area. We are trying to time it for around the Open<= br> > Networking Summit, but not conflicting with that or the ONF workdays.<= br> >
> We need to announce it 4 weeks in advance. =A0Unless, we announce toda= y for
> the afternoon/evening of April 19 (or into April 20), we are looking a= t
> April 22/23. =A0Opinions ASAP from those who would attend would be qui= te
> useful.
>
> In particular, is this a good time/place?
>
> We want the interim to focus on the use-cases & functionality for = i2rs. =A0 I
> expect that we'll ask attendees to pick a set of use-cases to be i= n a
> design-group before & during the meeting to discuss & then pre= sent to the
> larger group. =A0More details to follow soon.
>
> Regards,
> Alia
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs
--14dae9340d03ef0a1304d88292cc-- From jeff.tantsura@ericsson.com Fri Mar 22 05:34:13 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142D321F8B5E for ; Fri, 22 Mar 2013 05:34:13 -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 Va2SIW18PM7v for ; Fri, 22 Mar 2013 05:34:12 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 729CF21F8B51 for ; Fri, 22 Mar 2013 05:34:12 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-d6-514c4fc33de8 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 6E.98.02411.3CF4C415; Fri, 22 Mar 2013 13:34:11 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 08:34:11 -0400 From: Jeff Tantsura To: Robert Raszuk Thread-Topic: [i2rs] Interim meeting Thread-Index: Ac4m9VuLX4TrFDPxSvK9ThSBXgqyxQAIs/IA///CxHY= Date: Fri, 22 Mar 2013 12:34:10 +0000 Message-ID: <626668BE-0992-4090-B2A6-00751F94671E@ericsson.com> References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyuXRPiO5hf59Ag+fnTS2+XkuzWDfjA4tF 08ImZgdmjyVLfjJ5XG+6yu6xe+MCpgDmKC6blNSczLLUIn27BK6MxQdnsRZM5a5oW/iarYHx O0cXIyeHhICJxOQ5rSwQtpjEhXvr2boYuTiEBI4wSrz4+JgdwlnOKLHl1QuwKjYBA4n/346D 2SICqhKdJx4xg9jMAq4Sey69Zu1i5OAQFlCW+LHODaJEReLrhSNsELaVxKq7T8FsFqDWW58v sILYvAL2EgdX/2CE2NXNKPFq836w+ZwCgRLX9+wDsxmBrvt+ag0TxC5xiVtP5jNBXC0gsWTP eWYIW1Ti5eN/rBA1OhILdn9ig7C1JZYtfM0MsUxQ4uTMJywTGEVnIRk1C0nLLCQts5C0LGBk WcXIUVqcWpabbmS4iREYIcck2Bx3MC74ZHmIUZqDRUmcN9T1QoCQQHpiSWp2ampBalF8UWlO avEhRiYOTqkGRtlEheM8JtERjmUnAsweM23/JyLLrMcUu/BcopTXubWfrG25v1p4lNYd+Cja uc+1UFBWLvnWHJ0XqXluR0Nn1DUe1sr3DpkRvvzRcY3K4ssmPwwXbi7VnJjdeX9VfeAk63v9 0SUJKz98+sF/usXc23VLmdBSbYEPEnzrJ775ahanmMeS9cVWiaU4I9FQi7moOBEAtBvw7F4C AAA= Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 12:34:13 -0000 +1 Regards, Jeff On Mar 22, 2013, at 1:13 PM, "Robert Raszuk" wrote: >> April 22/23 @ Bay Area >=20 > Perfect location and timing ! +1. >=20 > Thx, > Robert. >=20 >=20 >> On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas wrote: >>=20 >> Ed and I would like to have an interim meeting in mid-April in the Mount= ain >> View/Sunnyvale, CA area. We are trying to time it for around the Open >> Networking Summit, but not conflicting with that or the ONF workdays. >>=20 >> We need to announce it 4 weeks in advance. Unless, we announce today fo= r >> the afternoon/evening of April 19 (or into April 20), we are looking at >> April 22/23. Opinions ASAP from those who would attend would be quite >> useful. >>=20 >> In particular, is this a good time/place? >>=20 >> We want the interim to focus on the use-cases & functionality for i2rs. = I >> expect that we'll ask attendees to pick a set of use-cases to be in a >> design-group before & during the meeting to discuss & then present to th= e >> larger group. More details to follow soon. >>=20 >> Regards, >> Alia >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From bensons@queuefull.net Fri Mar 22 06:18:37 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11A321F8A85 for ; Fri, 22 Mar 2013 06:18:37 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 aRUYjWjhxYfR for ; Fri, 22 Mar 2013 06:18:37 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 95D9521F8A53 for ; Fri, 22 Mar 2013 06:18:36 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hn17so1658375wib.0 for ; Fri, 22 Mar 2013 06:18:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=fGZhpK5QBsRs/YzKTmjRyi+6ssE98eJ/yv/FnvgK9DE=; b=ZPGzf4FPDBBZubUHCFLfQ/ZtsKQi8Cq1Ebiphj0hJvZGr6hHsoz685nrjbBnBBzDOE co2kh17gD2EMcwZyu7qicx5U5QPN0tCA16p77aBxgBF2J6TPMZaV0PV/DyNzXnz8bsD8 dwYnUzlcmbZvZp0dXrEQy9FtWCu4pK7arGpGonkUFdh3B+Q+cXWa1tkTAlnGrRbHYlpR 3wONeVopibbHRNwEKITr94K1ZjE6ZICATkD+Ndn2Q6tL7qRfEvCkmOgJZC6xq7AP4Mxh qkQgZ8G81dOfNczB5DfzlmCkAkDVxUn5fUyWB2oEJRupTrTwnmRqdRnkuBc6ifXOuaEc 1tXg== X-Received: by 10.194.57.137 with SMTP id i9mr3067156wjq.18.1363958315659; Fri, 22 Mar 2013 06:18:35 -0700 (PDT) References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> From: Benson Schliesser Mime-Version: 1.0 (1.0) In-Reply-To: Date: Fri, 22 Mar 2013 14:18:33 +0100 Message-ID: <5155033007707097189@unknownmsgid> To: Alia Atlas Content-Type: multipart/alternative; boundary=047d7ba97d20e4d37a04d8834a75 X-Gm-Message-State: ALoCoQmLJeIf5emnxq9o4or+RP7nasKcrF7+InF6r2nb8qKhBO6mqvAPfy9YqtwE520s/clDR65O Cc: "i2rs@ietf.org" , "akatlas@juniper.net" , Robert Raszuk Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 13:18:37 -0000 --047d7ba97d20e4d37a04d8834a75 Content-Type: text/plain; charset=ISO-8859-1 The NFV #2 meeting is scheduled for 22-23 April and the ONS meeting (and Member Workday) is 16-18 April (if I recall correctly). So, even though I'd really like to go home over the weekend, I guess the 19-20 April dates would work best. :) Cheers, -Benson On Mar 22, 2013, at 13:27, Alia Atlas wrote: I am specifically trying to determine if there is strong interest in the Friday April 19 & April 20 vs. April 22-23. Alia On Mar 22, 2013 1:13 PM, "Robert Raszuk" wrote: > > April 22/23 @ Bay Area > > Perfect location and timing ! +1. > > Thx, > Robert. > > > > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas wrote: > > > > Ed and I would like to have an interim meeting in mid-April in the > Mountain > > View/Sunnyvale, CA area. We are trying to time it for around the Open > > Networking Summit, but not conflicting with that or the ONF workdays. > > > > We need to announce it 4 weeks in advance. Unless, we announce today for > > the afternoon/evening of April 19 (or into April 20), we are looking at > > April 22/23. Opinions ASAP from those who would attend would be quite > > useful. > > > > In particular, is this a good time/place? > > > > We want the interim to focus on the use-cases & functionality for i2rs. > I > > expect that we'll ask attendees to pick a set of use-cases to be in a > > design-group before & during the meeting to discuss & then present to the > > larger group. More details to follow soon. > > > > Regards, > > Alia > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --047d7ba97d20e4d37a04d8834a75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The NFV #2 meeting is scheduled fo= r 22-23 April and the ONS meeting (and Member Workday) is 16-18 April (if I= recall correctly). So, even though I'd really like to go home over the= weekend, I guess the 19-20 April dates would work best. :)

Cheers,
-Benson


= On Mar 22, 2013, at 13:27, Alia Atlas <akatlas@gmail.com> wrote:

I am specifically trying to determine if there is stron= g interest in the Friday April 19 & April 20 vs. April 22-23.

Alia

On Mar 22, 2013 1:13 PM, "Robert Raszuk&quo= t; <robert@raszuk.net> wrote= :
> April 22/23 @ Bay Area

Perfect location and timing ! =A0+1.

Thx,
Robert.


> On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas <akatlas@juniper.net> wrote:
>
> Ed and I would like to have an interim meeting in mid-April in the Mou= ntain
> View/Sunnyvale, CA area. We are trying to time it for around the Open<= br> > Networking Summit, but not conflicting with that or the ONF workdays.<= br> >
> We need to announce it 4 weeks in advance. =A0Unless, we announce toda= y for
> the afternoon/evening of April 19 (or into April 20), we are looking a= t
> April 22/23. =A0Opinions ASAP from those who would attend would be qui= te
> useful.
>
> In particular, is this a good time/place?
>
> We want the interim to focus on the use-cases & functionality for = i2rs. =A0 I
> expect that we'll ask attendees to pick a set of use-cases to be i= n a
> design-group before & during the meeting to discuss & then pre= sent to the
> larger group. =A0More details to follow soon.
>
> Regards,
> Alia
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs
___________________= ____________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mai= lman/listinfo/i2rs
--047d7ba97d20e4d37a04d8834a75-- From tnadeau@juniper.net Fri Mar 22 06:34:58 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D81D21F85BF for ; Fri, 22 Mar 2013 06:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 wBMJXiTB1T+2 for ; Fri, 22 Mar 2013 06:34:57 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 677F321F8501 for ; Fri, 22 Mar 2013 06:34:57 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUUxeAQvQZ61PNCgnDrFKmWkqeyEKD9LM@postini.com; Fri, 22 Mar 2013 06:34:57 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 22 Mar 2013 06:31:40 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 22 Mar 2013 06:31:39 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 22 Mar 2013 06:40:53 -0700 Received: from mail34-co1-R.bigfish.com (10.243.78.252) by CO1EHSOBE006.bigfish.com (10.243.66.69) with Microsoft SMTP Server id 14.1.225.23; Fri, 22 Mar 2013 13:31:39 +0000 Received: from mail34-co1 (localhost [127.0.0.1]) by mail34-co1-R.bigfish.com (Postfix) with ESMTP id 7889230025D for ; Fri, 22 Mar 2013 13:31:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz98dI9371Ic85fh1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahz8dhz8275ch1033IL8275dh18c673h8275bhz2dh2a8h668h839hbe3hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail34-co1 (localhost.localdomain [127.0.0.1]) by mail34-co1 (MessageSwitch) id 1363959097592515_6512; Fri, 22 Mar 2013 13:31:37 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.231]) by mail34-co1.bigfish.com (Postfix) with ESMTP id 8E4FE460057; Fri, 22 Mar 2013 13:31:37 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 22 Mar 2013 13:31:36 +0000 Received: from CH1PRD0511MB420.namprd05.prod.outlook.com ([169.254.9.245]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0275.006; Fri, 22 Mar 2013 13:31:36 +0000 From: Thomas Nadeau To: Alia Atlas Thread-Topic: [i2rs] Interim meeting Thread-Index: Ac4m9VuLX4TrFDPxSvK9ThSBXgqyxQAAUi4AAAB7h4AAAkAvqg== Date: Fri, 22 Mar 2013 13:31:35 +0000 Message-ID: References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.109.192] Content-Type: multipart/alternative; boundary="_000_CBF92149C58B4EC6B76CC1315D86D25Cjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%RASZUK.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "i2rs@ietf.org" , Alia Atlas , Robert Raszuk Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 13:34:58 -0000 --_000_CBF92149C58B4EC6B76CC1315D86D25Cjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable while nice because its the week after ons that conflicts with nfv. also fo= r those at ons the week before it might be thought staying in town for 2 we= eks. Tom On Mar 22, 2013, at 13:27, "Alia Atlas" > wrote: I am specifically trying to determine if there is strong interest in the Fr= iday April 19 & April 20 vs. April 22-23. Alia On Mar 22, 2013 1:13 PM, "Robert Raszuk" > wrote: > April 22/23 @ Bay Area Perfect location and timing ! +1. Thx, Robert. > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas > wrote: > > Ed and I would like to have an interim meeting in mid-April in the Mounta= in > View/Sunnyvale, CA area. We are trying to time it for around the Open > Networking Summit, but not conflicting with that or the ONF workdays. > > We need to announce it 4 weeks in advance. Unless, we announce today for > the afternoon/evening of April 19 (or into April 20), we are looking at > April 22/23. Opinions ASAP from those who would attend would be quite > useful. > > In particular, is this a good time/place? > > We want the interim to focus on the use-cases & functionality for i2rs. = I > expect that we'll ask attendees to pick a set of use-cases to be in a > design-group before & during the meeting to discuss & then present to the > larger group. More details to follow soon. > > Regards, > Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_CBF92149C58B4EC6B76CC1315D86D25Cjunipernet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
while nice because its the week after ons that conflicts with nfv. &nb= sp;also for those at ons the week before it might be thought staying in tow= n for 2 weeks.

Tom 

On Mar 22, 2013, at 13:27, "Alia Atlas" <akatlas@gmail.com> wrote:

I am specifically trying to determine if there is strong int= erest in the Friday April 19 & April 20 vs. April 22-23.

Alia

On Mar 22, 2013 1:13 PM, "Robert Raszuk&quo= t; <robert@raszuk.net> wrote= :
> April 22/23 @ Bay Area

Perfect location and timing !  +1.

Thx,
Robert.


> On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas <akatlas@juniper.net> wrote:
>
> Ed and I would like to have an interim meeting in mid-April in the Mou= ntain
> View/Sunnyvale, CA area. We are trying to time it for around the Open<= br> > Networking Summit, but not conflicting with that or the ONF workdays.<= br> >
> We need to announce it 4 weeks in advance.  Unless, we announce t= oday for
> the afternoon/evening of April 19 (or into April 20), we are looking a= t
> April 22/23.  Opinions ASAP from those who would attend would be = quite
> useful.
>
> In particular, is this a good time/place?
>
> We want the interim to focus on the use-cases & functionality for = i2rs.   I
> expect that we'll ask attendees to pick a set of use-cases to be in a<= br> > design-group before & during the meeting to discuss & then pre= sent to the
> larger group.  More details to follow soon.
>
> Regards,
> Alia
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ie= tf.org/mailman/listinfo/i2rs
--_000_CBF92149C58B4EC6B76CC1315D86D25Cjunipernet_-- From jmh@joelhalpern.com Fri Mar 22 07:33:48 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17D321F8AA8 for ; Fri, 22 Mar 2013 07:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, 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 UQ4nnekUpIqF for ; Fri, 22 Mar 2013 07:33:48 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 4B46121F8A85 for ; Fri, 22 Mar 2013 07:33:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 2BBB61C0054F; Fri, 22 Mar 2013 07:33:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-233.clppva.east.verizon.net [70.106.135.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9AAE71C0054B; Fri, 22 Mar 2013 07:33:47 -0700 (PDT) Message-ID: <514C6BC5.4080006@joelhalpern.com> Date: Fri, 22 Mar 2013 10:33:41 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Alia Atlas References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> In-Reply-To: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 14:33:49 -0000 Later that week would be better for me, but I will try to attend even if it is the 22/23rd. Yours, Joel On 3/22/2013 8:04 AM, Alia Atlas wrote: > Ed and I would like to have an interim meeting in mid-April in the > Mountain View/Sunnyvale, CA area. We are trying to time it for around > the Open Networking Summit, but not conflicting with that or the ONF > workdays. > > We need to announce it 4 weeks in advance. Unless, we announce today > for the afternoon/evening of April 19 (or into April 20), we are looking > at April 22/23. Opinions ASAP from those who would attend would be > quite useful. > > In particular, is this a good time/place? > > We want the interim to focus on the use-cases & functionality for i2rs. > I expect that we'll ask attendees to pick a set of use-cases to be in > a design-group before & during the meeting to discuss & then present to > the larger group. More details to follow soon. > > Regards, > Alia > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From jeff.tantsura@ericsson.com Fri Mar 22 07:37:42 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236A321F8A85 for ; Fri, 22 Mar 2013 07:37:42 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 YkdqE7maJwC7 for ; Fri, 22 Mar 2013 07:37:41 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA4621F8A47 for ; Fri, 22 Mar 2013 07:37:41 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-64-514c6cb4066d Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id AC.4F.02411.4BC6C415; Fri, 22 Mar 2013 15:37:41 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 10:37:36 -0400 From: Jeff Tantsura To: Alia Atlas Thread-Topic: [i2rs] Interim meeting Thread-Index: Ac4m9VuLX4TrFDPxSvK9ThSBXgqyxQAIs/IAAAB7iID//+FkCg== Date: Fri, 22 Mar 2013 14:37:35 +0000 Message-ID: <629C610C-207D-42D9-B315-FE7B72D61D76@ericsson.com> References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_629C610C207D42D9B315FE7B72D61D76ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPoO7WHJ9Ag/e7WS0+PbzEbPH1WprF uhkfWCyaFjYxO7B47Jx1l91jyZKfTB7Xm66ye+zeuIApgCWKyyYlNSezLLVI3y6BK+PZxFus BR1aFZ9m/mVvYHyp3MXIySEhYCLRuHANM4QtJnHh3nq2LkYuDiGBI4wSHZvWsUI4yxklrkw+ xgpSxSZgIPH/23GWLkYODhEBJYmpL4VBwswCpRJ7Fl9gBwkLCyhL/FjnBhIWEVCR+HrhCBuE 7SQx/d1mJhCbRUBVYunjo4wgNq+AvUTfpcdMEKsuMUp8OvICrIFTIFDi47LVYEWMQMd9P7WG CWKXuMStJ/OZII4WkFiy5zzUA6ISLx//Y4WoSZb41zqHGWKBoMTJmU9YJjCKzELSPgtJ2Swk ZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZbrqR4SZGYIwdk2Bz3MG44JPl IUZpDhYlcd5Q1wsBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjlPt24tf7651WaeS+Oyhjx +R5m7365sT/t0dLK7I1vI01Nlr7KUSvfybKmk7XU9fSFucnSVzb6NnxjOrT1TVzs2akHr80p +/1j+/fNT0qDvTcGRbB9DJkq9P5NlWgGs9WBXOluZ836ZwvUzz2MfuXtdGzD/m8iUmH8E6q6 Pvy/PK9kwsdpbMunK7EUZyQaajEXFScCAIGLpop/AgAA Cc: "i2rs@ietf.org" , "akatlas@juniper.net" , Robert Raszuk Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 14:37:42 -0000 --_000_629C610C207D42D9B315FE7B72D61D76ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Both dates work for me, however preferably 22-23. Regards, Jeff On Mar 22, 2013, at 1:27 PM, "Alia Atlas" > wrote: I am specifically trying to determine if there is strong interest in the Fr= iday April 19 & April 20 vs. April 22-23. Alia On Mar 22, 2013 1:13 PM, "Robert Raszuk" > wrote: > April 22/23 @ Bay Area Perfect location and timing ! +1. Thx, Robert. > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas > wrote: > > Ed and I would like to have an interim meeting in mid-April in the Mounta= in > View/Sunnyvale, CA area. We are trying to time it for around the Open > Networking Summit, but not conflicting with that or the ONF workdays. > > We need to announce it 4 weeks in advance. Unless, we announce today for > the afternoon/evening of April 19 (or into April 20), we are looking at > April 22/23. Opinions ASAP from those who would attend would be quite > useful. > > In particular, is this a good time/place? > > We want the interim to focus on the use-cases & functionality for i2rs. = I > expect that we'll ask attendees to pick a set of use-cases to be in a > design-group before & during the meeting to discuss & then present to the > larger group. More details to follow soon. > > Regards, > Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_629C610C207D42D9B315FE7B72D61D76ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Both dates work for me,
however preferably 22-23.

Regards,
Jeff

On Mar 22, 2013, at 1:27 PM, "Alia Atlas" <akatlas@gmail.com> wrote:

I am specifically trying to determine if there is strong int= erest in the Friday April 19 & April 20 vs. April 22-23.

Alia

On Mar 22, 2013 1:13 PM, "Robert Raszuk&quo= t; <robert@raszuk.net> wrote= :
> April 22/23 @ Bay Area

Perfect location and timing !  +1.

Thx,
Robert.


> On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas <akatlas@juniper.net> wrote:
>
> Ed and I would like to have an interim meeting in mid-April in the Mou= ntain
> View/Sunnyvale, CA area. We are trying to time it for around the Open<= br> > Networking Summit, but not conflicting with that or the ONF workdays.<= br> >
> We need to announce it 4 weeks in advance.  Unless, we announce t= oday for
> the afternoon/evening of April 19 (or into April 20), we are looking a= t
> April 22/23.  Opinions ASAP from those who would attend would be = quite
> useful.
>
> In particular, is this a good time/place?
>
> We want the interim to focus on the use-cases & functionality for = i2rs.   I
> expect that we'll ask attendees to pick a set of use-cases to be in a<= br> > design-group before & during the meeting to discuss & then pre= sent to the
> larger group.  More details to follow soon.
>
> Regards,
> Alia
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ie= tf.org/mailman/listinfo/i2rs
--_000_629C610C207D42D9B315FE7B72D61D76ericssoncom_-- From jmh@joelhalpern.com Fri Mar 22 07:43:32 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A6621F8BA1 for ; Fri, 22 Mar 2013 07:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 kPwrW1Fi3av8 for ; Fri, 22 Mar 2013 07:43:32 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBED21F8B9C for ; Fri, 22 Mar 2013 07:43:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 1BFE91C0308C; Fri, 22 Mar 2013 07:43:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-233.clppva.east.verizon.net [70.106.135.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 3E8C41C0308A; Fri, 22 Mar 2013 07:43:31 -0700 (PDT) Message-ID: <514C6E0D.9020908@joelhalpern.com> Date: Fri, 22 Mar 2013 10:43:25 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Alia Atlas References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org, akatlas@juniper.net, Robert Raszuk Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 14:43:32 -0000 The earlier it is, he harder it will be for me to arrange the trip. Other than that, I have no objection to working Saturday (or Saturday and Sunday.) Yours, Joel On 3/22/2013 8:27 AM, Alia Atlas wrote: > I am specifically trying to determine if there is strong interest in the > Friday April 19 & April 20 vs. April 22-23. > > Alia > > On Mar 22, 2013 1:13 PM, "Robert Raszuk" > wrote: > > > April 22/23 @ Bay Area > > Perfect location and timing ! +1. > > Thx, > Robert. > > > > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas > wrote: > > > > Ed and I would like to have an interim meeting in mid-April in > the Mountain > > View/Sunnyvale, CA area. We are trying to time it for around the Open > > Networking Summit, but not conflicting with that or the ONF workdays. > > > > We need to announce it 4 weeks in advance. Unless, we announce > today for > > the afternoon/evening of April 19 (or into April 20), we are > looking at > > April 22/23. Opinions ASAP from those who would attend would be > quite > > useful. > > > > In particular, is this a good time/place? > > > > We want the interim to focus on the use-cases & functionality for > i2rs. I > > expect that we'll ask attendees to pick a set of use-cases to be in a > > design-group before & during the meeting to discuss & then > present to the > > larger group. More details to follow soon. > > > > Regards, > > Alia > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From wassim.haddad@ericsson.com Fri Mar 22 07:55:04 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D453021F867D for ; Fri, 22 Mar 2013 07:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 xfieHq8Qrc0c for ; Fri, 22 Mar 2013 07:55:04 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 164F621F867A for ; Fri, 22 Mar 2013 07:55:04 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-0a-514c70c76015 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 2F.60.02411.7C07C415; Fri, 22 Mar 2013 15:55:03 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 10:55:02 -0400 From: Wassim Haddad To: Jeff Tantsura Thread-Topic: [i2rs] Interim meeting Thread-Index: Ac4m9VuLX4TrFDPxSvK9ThSBXgqyxQAIs/IAAAB7iID//+FkCoAAR+0A Date: Fri, 22 Mar 2013 14:55:02 +0000 Message-ID: References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> <629C610C-207D-42D9-B315-FE7B72D61D76@ericsson.com> In-Reply-To: <629C610C-207D-42D9-B315-FE7B72D61D76@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-F3CE15DF-8C16-453C-B211-3E89F353A0B7"; protocol="application/pkcs7-signature" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyuXRPoO7xAp9Ag1erDC0+PbzEbPH1WprF uhkfWCyaFjYxO7B47Jx1l91jyZKfTB7Xm66ye+zeuIApgCWKyyYlNSezLLVI3y6BK2PK10vM BbPcKnbNvMLewHjSrouRk0NCwETiWNMeNghbTOLCvfVANheHkMARRomLT5YzQTjLGSX+H3jH DlLFJmAg8XX5WVYQW0RAT2Lfn05WkCJmgcOMEpdm/wQq4uAQFlCW+LHODaJGReLrhSNsIGER ATeJHSszQMIsAqoSv54tZAKxeQXsJR5MeAw2Xkigi0ni5kU1EJtTwEHiwdpdjCA2I9Bx30+t AatnFhCXuPVkPhPE0SISDy+ehnpAVOLl439Q50xmlPj0bRPUAkGJkzOfsExgFJmFpH8WsrpZ SOogiuIlju/pYYaw5SW2v50DZHMA2ToSkxcyQoS1JZYtfA1VoiHR+W0iK6pyENtaYsavg2wQ tqnE66MfoXoVJaZ0P2RfwMizipGjtDi1LDfdyHATIzC6j0mwOe5gXPDJ8hCjNAeLkjhvqOuF ACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MNav0FFrWKO6WKQ00WuSp9GzupccctqXX9V7k K35fF9J6V0/077otGW3fGoyf/hSMn7Uyse0iy9ujVrs8K3fZc318Wn9UIEg4Y1L6jktxgoyW e6T6xBTLN8zTs5uosUrUiltqg0vChdfs99YUZYfFP3689OmuN76ZsnM2nlh97OZOnym+Xu9C lFiKMxINtZiLihMBgCKXurwCAAA= Cc: "i2rs@ietf.org" , Wassim Haddad , "akatlas@juniper.net" , Robert Raszuk , Alia Atlas Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 14:55:05 -0000 --Apple-Mail-F3CE15DF-8C16-453C-B211-3E89F353A0B7 Content-Type: multipart/alternative; boundary=Apple-Mail-2A1A7344-90AE-4B3A-8EF7-C31B1222A622 Content-Transfer-Encoding: 7bit --Apple-Mail-2A1A7344-90AE-4B3A-8EF7-C31B1222A622 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 Wassim H. Sent from my iPhone On Mar 22, 2013, at 15:38, "Jeff Tantsura" wrot= e: > Both dates work for me, > however preferably 22-23. >=20 > Regards, > Jeff >=20 > On Mar 22, 2013, at 1:27 PM, "Alia Atlas" wrote: >=20 >> I am specifically trying to determine if there is strong interest in the = Friday April 19 & April 20 vs. April 22-23. >>=20 >> Alia >>=20 >> On Mar 22, 2013 1:13 PM, "Robert Raszuk" wrote: >>> > April 22/23 @ Bay Area >>>=20 >>> Perfect location and timing ! +1. >>>=20 >>> Thx, >>> Robert. >>>=20 >>>=20 >>> > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas wrot= e: >>> > >>> > Ed and I would like to have an interim meeting in mid-April in the Mou= ntain >>> > View/Sunnyvale, CA area. We are trying to time it for around the Open >>> > Networking Summit, but not conflicting with that or the ONF workdays. >>> > >>> > We need to announce it 4 weeks in advance. Unless, we announce today f= or >>> > the afternoon/evening of April 19 (or into April 20), we are looking a= t >>> > April 22/23. Opinions ASAP from those who would attend would be quite= >>> > useful. >>> > >>> > In particular, is this a good time/place? >>> > >>> > We want the interim to focus on the use-cases & functionality for i2rs= . I >>> > expect that we'll ask attendees to pick a set of use-cases to be in a >>> > design-group before & during the meeting to discuss & then present to t= he >>> > larger group. More details to follow soon. >>> > >>> > Regards, >>> > Alia >>> > >>> > _______________________________________________ >>> > i2rs mailing list >>> > i2rs@ietf.org >>> > https://www.ietf.org/mailman/listinfo/i2rs >>> > >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail-2A1A7344-90AE-4B3A-8EF7-C31B1222A622 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
+1


Wassim H.

Sent from my iPhone

On Mar 22, 2013, at 15:38, "Jeff Tantsura" <jeff.tantsura@ericsson.com> wrote:

Both dates work for me,
however preferably 22-23.

Regards,
Jeff

On Mar 22, 2013, at 1:27 PM, "Alia Atlas" <akatlas@gmail.com> wrote:

I am specifically trying to determine if there is strong interest in the Friday April 19 & April 20 vs. April 22-23.

Alia

On Mar 22, 2013 1:13 PM, "Robert Raszuk" <robert@raszuk.net> wrote:
> April 22/23 @ Bay Area

Perfect location and timing !  +1.

Thx,
Robert.


> On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas <akatlas@juniper.net> wrote:
>
> Ed and I would like to have an interim meeting in mid-April in the Mountain
> View/Sunnyvale, CA area. We are trying to time it for around the Open
> Networking Summit, but not conflicting with that or the ONF workdays.
>
> We need to announce it 4 weeks in advance.  Unless, we announce today for
> the afternoon/evening of April 19 (or into April 20), we are looking at
> April 22/23.  Opinions ASAP from those who would attend would be quite
> useful.
>
> In particular, is this a good time/place?
>
> We want the interim to focus on the use-cases & functionality for i2rs.   I
> expect that we'll ask attendees to pick a set of use-cases to be in a
> design-group before & during the meeting to discuss & then present to the
> larger group.  More details to follow soon.
>
> Regards,
> Alia
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
--Apple-Mail-2A1A7344-90AE-4B3A-8EF7-C31B1222A622-- --Apple-Mail-F3CE15DF-8C16-453C-B211-3E89F353A0B7 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEMzCCBC8w ggMXoAMCAQICEEsT0774h8pPcwPnuDLeUUMwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDAzMzAxODIz NDBaFw0xMzAzMzAxODIzMzdaMGgxETAPBgNVBAoMCEVyaWNzc29uMRYwFAYDVQQDDA1XYXNzaW0g SGFkZGFkMRAwDgYDVQQFEwdld2FzaGFkMSkwJwYJKoZIhvcNAQkBFhp3YXNzaW0uaGFkZGFkQGVy aWNzc29uLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwhbvns8nRIfMqBzMIYtVsh9p PMqieEKmX3HwjUkR82kGvcoJvb1NbXyO2jucyergVeNF0F3pSgjTJkdvTBHYQhiHOKauVqRjmdSB Jcdb5H2aPjVXKlGw/BZvixe7m+zOk3TdE4Ln0Aw2ZPh9deacCgkknPKUCQq+KMOtetGyPpECAwEA AaOCAYYwggGCMIHABgNVHR8EgbgwgbUwgbKgga+ggayGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEu Y29tL0VyaWNzc29uTkxJbmRpdmlkdWFsQ0EwMS5jcmyGcWxkYXA6Ly9sZGFwLnRydXN0LnRlbGlh LmNvbS9jbj1Fcmljc3NvbiUyME5MJTIwSW5kaXZpZHVhbCUyMENBMDEsbz1Fcmljc3Nvbj9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlMCUGA1UdEQQeMByBGndhc3NpbS5oYWRk YWRAZXJpY3Nzb24uY29tMEYGA1UdIAQ/MD0wOwYGKoVwawEBMDEwLwYIKwYBBQUHAgEWI2h0dHA6 Ly93d3cuZXJpY3Nzb24uY29tL2xlZ2FsLnNodG1sMB0GA1UdDgQWBBTqddQ5pEKVXhGm48HVzc0/ hXtRkzAfBgNVHSMEGDAWgBSWJ8O43qVfXUQ+OVLlRbF2X2MwmzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQEFBQADggEBAH+CrRJM2GiRfddo3Js+4AtvmipHkXWS6U/u4oW17FONKhJkNAxh0/VE moUaXIVBaC9333NWugdMl2OITlfDUs2ODQJUb1rGF+tWhbDevMsnyR0s/2Om7hmfNr3vmLSMEIGC M9DjH80tzFc9xzWDHae33Mt8K0/uNYamhrcue7tE/UoFmtdLmkQ8f+qiMYfVzLguE+u6NmvXWiM1 +H01SvXPPYBjttNu4xYUsfLa1jGKjYhDGhcJhsmhDTvtWSqo7nDDlTIwpQ7sfuZo5k+iZ7GHcw9E KFxM8XFgyqaRKnzq4w5kt/GvZpgARJF/sl8KFKJZUz7VMZdXGOqNGdjaidExggISMIICDgIBATBN MDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB MDECEEsT0774h8pPcwPnuDLeUUMwCQYFKw4DAhoFAKCCARswGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzIyMTQ1NTAzWjAjBgkqhkiG9w0BCQQxFgQUwxJpALAn 0bItAVkAxg6Ev6/sfiQwXAYJKwYBBAGCNxAEMU8wTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIG A1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhBLE9O++IfKT3MD57gy3lFDMF4GCyqG SIb3DQEJEAILMU+gTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQTAxAhBLE9O++IfKT3MD57gy3lFDMA0GCSqGSIb3DQEBAQUABIGAUK7sOzgM ho4PnGUOovGQNG6v21fghsYW7ur+EQ5J1hpCidGLDTSWEi8yphXeGkmDizlzGasNHA2kvdGeBigV afn3kBTex7dmWY/fFuZw1IIO3D6FqF64tA3QdDv4I+Ry/hgs4alnNGLRf1AsyLE3hqnItcDRNIdj SyLrRYh9tJ0AAAAAAAA= --Apple-Mail-F3CE15DF-8C16-453C-B211-3E89F353A0B7-- From jmh@joelhalpern.com Fri Mar 22 07:57:25 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2888D21F85DA for ; Fri, 22 Mar 2013 07:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 KvMnSfCr6yQk for ; Fri, 22 Mar 2013 07:57:24 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 99E7D21F8526 for ; Fri, 22 Mar 2013 07:57:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 83C581C0794; Fri, 22 Mar 2013 07:57:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-233.clppva.east.verizon.net [70.106.135.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D3A911C003D; Fri, 22 Mar 2013 07:57:23 -0700 (PDT) Message-ID: <514C714D.3020504@joelhalpern.com> Date: Fri, 22 Mar 2013 10:57:17 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Alia Atlas References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 14:57:25 -0000 Note: The ONF Member work day is actually two days, April 18th and 19th. Thus, having the meeting on the 19th would actually collide with the ONF work session. That does not seem to me to be a good dea. Yours, Joel On 3/22/2013 8:27 AM, Alia Atlas wrote: > I am specifically trying to determine if there is strong interest in the > Friday April 19 & April 20 vs. April 22-23. > > Alia > > On Mar 22, 2013 1:13 PM, "Robert Raszuk" > wrote: > > > April 22/23 @ Bay Area > > Perfect location and timing ! +1. > > Thx, > Robert. > > > > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas > wrote: > > > > Ed and I would like to have an interim meeting in mid-April in > the Mountain > > View/Sunnyvale, CA area. We are trying to time it for around the Open > > Networking Summit, but not conflicting with that or the ONF workdays. > > > > We need to announce it 4 weeks in advance. Unless, we announce > today for > > the afternoon/evening of April 19 (or into April 20), we are > looking at > > April 22/23. Opinions ASAP from those who would attend would be > quite > > useful. > > > > In particular, is this a good time/place? > > > > We want the interim to focus on the use-cases & functionality for > i2rs. I > > expect that we'll ask attendees to pick a set of use-cases to be in a > > design-group before & during the meeting to discuss & then > present to the > > larger group. More details to follow soon. > > > > Regards, > > Alia > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From zali@cisco.com Fri Mar 22 08:03:10 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E4E21F8BA1 for ; Fri, 22 Mar 2013 08:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 7IeIJTgk76hy for ; Fri, 22 Mar 2013 08:03:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 86F7221F8B7E for ; Fri, 22 Mar 2013 08:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4347; q=dns/txt; s=iport; t=1363964589; x=1365174189; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=6sCGQZxMY3MLZB+wuNbfGCqCTGokYyVNNbFZC5mbFd0=; b=aPVSzaYp8o1NxnwHoatHV2pTzhXUDTEo9Ker+oohMyuxBS7y0Ikjqsqy e8QGdpbAiD4IeLRUgrIfWEcxx9123+nEroyD3IvXV5GP46oNSFDro1eGw Mmk3FMVjJrsq9Jd3lcDP4XZJAs6dT/kZKmbvX5OGcNVdmGkAujt3CxPm7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGlyTFGtJXG8/2dsb2JhbABDhBvBNYFlFnSCIAQBAQEEgQsBCAQKAwMBAgsdORQJCAEBBAESCIVBB4ImHsI8jmEgBhKCX2EDp2iDCoIo X-IronPort-AV: E=Sophos;i="4.84,892,1355097600"; d="scan'208,217";a="187428654" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 22 Mar 2013 15:02:55 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2MF2tTM021057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 15:02:55 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 10:02:55 -0500 From: "Zafar Ali (zali)" To: Alia Atlas , "i2rs@ietf.org" Thread-Topic: [i2rs] Interim meeting Thread-Index: Ac4m9VuLX4TrFDPxSvK9ThSBXgqyxQAIVoSA Date: Fri, 22 Mar 2013 15:02:54 +0000 Message-ID: In-Reply-To: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.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 x-originating-ip: [10.86.247.51] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D3B6F112xmbrcdx14ciscocom_" MIME-Version: 1.0 Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 15:03:10 -0000 --_000_B6585D85A128FD47857D0FD58D8120D3B6F112xmbrcdx14ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi: Are you planning to have remote participation via WebEx or similar? Thanks Regards =85 Zafar From: Alia Atlas > Reply-To: Alia Atlas > Date: Friday, March 22, 2013 8:04 AM To: "i2rs@ietf.org" > Subject: [i2rs] Interim meeting Ed and I would like to have an interim meeting in mid-April in the Mountain= View/Sunnyvale, CA area. We are trying to time it for around the Open Netw= orking Summit, but not conflicting with that or the ONF workdays. We need to announce it 4 weeks in advance. Unless, we announce today for t= he afternoon/evening of April 19 (or into April 20), we are looking at Apri= l 22/23. Opinions ASAP from those who would attend would be quite useful. In particular, is this a good time/place? We want the interim to focus on the use-cases & functionality for i2rs. I= expect that we'll ask attendees to pick a set of use-cases to be in a desi= gn-group before & during the meeting to discuss & then present to the large= r group. More details to follow soon. Regards, Alia --_000_B6585D85A128FD47857D0FD58D8120D3B6F112xmbrcdx14ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <424FD117167EE64CB329EA7DE9139567@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi:

Are you planning to have remote participation via WebEx or similar?&nb= sp;

Thanks

Regards =85 Zafar

From: Alia Atlas <akatlas@juniper.net>
Reply-To: Alia Atlas <akatlas@juniper.net>
Date: Friday, March 22, 2013 8:04 A= M
To: "i2rs@ietf.org" <i2rs@i= etf.org>
Subject: [i2rs] Interim meeting

Ed and I would like to have an interim meeting in mid-April in the Mou= ntain View/Sunnyvale, CA area. We are trying to time it for around the Open= Networking Summit, but not conflicting with that or the ONF workdays.

We need to announce it 4 weeks in advance.  Unless, we announce t= oday for the afternoon/evening of April 19 (or into April 20), we are looki= ng at April 22/23.  Opinions ASAP from those who would attend would be= quite useful.

In particular, is this a good time/place?

We want the interim to focus on the use-cases & functionality for = i2rs.   I expect that we'll ask attendees to pick a set of use-cases t= o be in a design-group before & during the meeting to discuss & the= n present to the larger group.  More details to follow soon.

Regards,
Alia
 --_000_B6585D85A128FD47857D0FD58D8120D3B6F112xmbrcdx14ciscocom_-- From sriganeshkini@gmail.com Fri Mar 22 08:14:40 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7417621F8F01 for ; Fri, 22 Mar 2013 08:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 xoB629aO8uZA for ; Fri, 22 Mar 2013 08:14:39 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6422021F8D1A for ; Fri, 22 Mar 2013 08:14:26 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fo13so7361846lab.24 for ; Fri, 22 Mar 2013 08:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GSECWUyt0Z5Ovgp+hJvRH0ChILBcjIaxlVo+/hY1NQA=; b=CHFGuNSFxEhmhBE7qxxFA5uyLaxkqFD/JSeEKbe2cR8n32MXN36qRr73+zHqQCNHrG z8iES/2PVO93DRAjdSmBp1ieEwpT1F9IOTGqwlXISnuT/ONos+oPwgxkru3GAfPW9CZl KqC4cJwosir3t4r0o8hAE3qBD5+y6bMjU0I9xTq12ciLboT/5K0XvGkLXQubHehS9YUX Q+Pjq5tYgCjHZr8+4WWVcMZ93nIo9YSs3A2hI5+w3UgkbRtd8rsGUvbEJouJUFAHnBnm EkJ4Ok3xmul3jOvtewNrjkgWaT9bFrRnvTeczzTcdMZqB3ToQtw/6QCupEDdxftQO+Xr QOLQ== MIME-Version: 1.0 X-Received: by 10.112.36.2 with SMTP id m2mr1301585lbj.100.1363965265245; Fri, 22 Mar 2013 08:14:25 -0700 (PDT) Sender: sriganeshkini@gmail.com Received: by 10.114.16.197 with HTTP; Fri, 22 Mar 2013 08:14:25 -0700 (PDT) In-Reply-To: References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> Date: Fri, 22 Mar 2013 08:14:25 -0700 X-Google-Sender-Auth: 3d4JJOIYfCIpZ1KiL0fatmyM1gs Message-ID: From: Sriganesh Kini To: Alia Atlas Content-Type: multipart/alternative; boundary=f46d042445321f000c04d884e981 Cc: "i2rs@ietf.org" , "akatlas@juniper.net" , Robert Raszuk Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 15:14:40 -0000 --f46d042445321f000c04d884e981 Content-Type: text/plain; charset=UTF-8 Any of these days work for me. - Sri On Friday, March 22, 2013, Alia Atlas wrote: > I am specifically trying to determine if there is strong interest in the > Friday April 19 & April 20 vs. April 22-23. > > Alia > On Mar 22, 2013 1:13 PM, "Robert Raszuk" > > wrote: > >> > April 22/23 @ Bay Area >> >> Perfect location and timing ! +1. >> >> Thx, >> Robert. >> >> >> > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas > >> wrote: >> > >> > Ed and I would like to have an interim meeting in mid-April in the >> Mountain >> > View/Sunnyvale, CA area. We are trying to time it for around the Open >> > Networking Summit, but not conflicting with that or the ONF workdays. >> > >> > We need to announce it 4 weeks in advance. Unless, we announce today >> for >> > the afternoon/evening of April 19 (or into April 20), we are looking at >> > April 22/23. Opinions ASAP from those who would attend would be quite >> > useful. >> > >> > In particular, is this a good time/place? >> > >> > We want the interim to focus on the use-cases & functionality for i2rs. >> I >> > expect that we'll ask attendees to pick a set of use-cases to be in a >> > design-group before & during the meeting to discuss & then present to >> the >> > larger group. More details to follow soon. >> > >> > Regards, >> > Alia >> > >> > _______________________________________________ >> > i2rs mailing list >> > i2rs@ietf.org >> > https://www.ietf.org/mailman/listinfo/i2rs >> > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > -- - Sri --f46d042445321f000c04d884e981 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Any of these days work for me.

- Sri
On Friday, March 22, 2013, Alia Atlas wrote:

I am specifically trying to determine if there is strong int= erest in the Friday April 19 & April 20 vs. April 22-23.

Alia

On Mar 22, 2013 1:13 PM, "Robert Raszuk&quo= t; <robert@raszuk.net> wrote:
> April 22/23 @ Bay Area

Perfect location and timing ! =C2=A0+1.

Thx,
Robert.


> On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas <a= katlas@juniper.net> wrote:
>
> Ed and I would like to have an interim meeting in mid-April in the Mou= ntain
> View/Sunnyvale, CA area. We are trying to time it for around the Open<= br> > Networking Summit, but not conflicting with that or the ONF workdays.<= br> >
> We need to announce it 4 weeks in advance. =C2=A0Unless, we announce t= oday for
> the afternoon/evening of April 19 (or into April 20), we are looking a= t
> April 22/23. =C2=A0Opinions ASAP from those who would attend would be = quite
> useful.
>
> In particular, is this a good time/place?
>
> We want the interim to focus on the use-cases & functionality for = i2rs. =C2=A0 I
> expect that we'll ask attendees to pick a set of use-cases to be i= n a
> design-group before & during the meeting to discuss & then pre= sent to the
> larger group. =C2=A0More details to follow soon.
>
> Regards,
> Alia
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs


--
- Sri
--f46d042445321f000c04d884e981-- From akatlas@gmail.com Fri Mar 22 08:28:24 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C67121F8904 for ; Fri, 22 Mar 2013 08:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 HHpvXr1UPp+x for ; Fri, 22 Mar 2013 08:28:23 -0700 (PDT) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCD821F86D3 for ; Fri, 22 Mar 2013 08:28:23 -0700 (PDT) Received: by mail-ia0-f175.google.com with SMTP id y26so3671368iab.34 for ; Fri, 22 Mar 2013 08:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=A5ZTcE6eggAt5JLHfAOyrmFcgB+L2E7+CCh+xdZIJP8=; b=HcDrswkW2Pp0MldnrXLMJI4Wtf3U1NZ1Ra42f0asLk7M2L1SUCGeuYnJMSwap/iy/B CLm2K0pMhsNQeLexjoBjV8otca2zB6eqAU/ATKJHGB5pjIM2bGHYqhYBwigA6cqELOol i3ylxCavl2CrFWJHOR7kY5QLHVv+lky2WvLaQgzD7O+yRg/VgSiItaHM9bNlpcMIvGNe lfYmDSFBfMsftGGVj6bL3nSiut+QA3NpU9lTiqVPcG/vuP6pOAm3ec/znmvFXdh+c2RM B9GwqobP2PVVMElShRiQ5mrziYKIb3qwW6iwslqIO04XhbNPrss3xIIP22595Lx2W10c QYoA== MIME-Version: 1.0 X-Received: by 10.50.47.168 with SMTP id e8mr1502973ign.50.1363966103104; Fri, 22 Mar 2013 08:28:23 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Fri, 22 Mar 2013 08:28:22 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Fri, 22 Mar 2013 08:28:22 -0700 (PDT) In-Reply-To: <514C714D.3020504@joelhalpern.com> References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> <514C714D.3020504@joelhalpern.com> Date: Fri, 22 Mar 2013 11:28:22 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=14dae9340ab10fb35a04d8851bff Cc: i2rs@ietf.org Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 15:28:24 -0000 --14dae9340ab10fb35a04d8851bff Content-Type: text/plain; charset=ISO-8859-1 Yes, the ONF workday finishes at 1:30pm on Friday. I'm getting the sense that April 22/23 works better for most people, with a slight concern for overlapping NFV#2. Alia On Mar 22, 2013 3:57 PM, "Joel M. Halpern" wrote: > Note: The ONF Member work day is actually two days, April 18th and 19th. > Thus, having the meeting on the 19th would actually collide with the ONF > work session. That does not seem to me to be a good dea. > > Yours, > Joel > > On 3/22/2013 8:27 AM, Alia Atlas wrote: > >> I am specifically trying to determine if there is strong interest in the >> Friday April 19 & April 20 vs. April 22-23. >> >> Alia >> >> On Mar 22, 2013 1:13 PM, "Robert Raszuk" > > wrote: >> >> > April 22/23 @ Bay Area >> >> Perfect location and timing ! +1. >> >> Thx, >> Robert. >> >> >> > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas > > wrote: >> > >> > Ed and I would like to have an interim meeting in mid-April in >> the Mountain >> > View/Sunnyvale, CA area. We are trying to time it for around the >> Open >> > Networking Summit, but not conflicting with that or the ONF >> workdays. >> > >> > We need to announce it 4 weeks in advance. Unless, we announce >> today for >> > the afternoon/evening of April 19 (or into April 20), we are >> looking at >> > April 22/23. Opinions ASAP from those who would attend would be >> quite >> > useful. >> > >> > In particular, is this a good time/place? >> > >> > We want the interim to focus on the use-cases & functionality for >> i2rs. I >> > expect that we'll ask attendees to pick a set of use-cases to be >> in a >> > design-group before & during the meeting to discuss & then >> present to the >> > larger group. More details to follow soon. >> > >> > Regards, >> > Alia >> > >> > ______________________________**_________________ >> > i2rs mailing list >> > i2rs@ietf.org >> > https://www.ietf.org/mailman/**listinfo/i2rs >> > >> ______________________________**_________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/**listinfo/i2rs >> >> >> >> ______________________________**_________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/**listinfo/i2rs >> >> --14dae9340ab10fb35a04d8851bff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Yes, the ONF workday finishes at 1:30pm on Friday.=A0=A0 I&#= 39;m getting the sense that April 22/23 works better for most people, with = a slight concern for overlapping NFV#2.

Alia

On Mar 22, 2013 3:57 PM, "Joel M. Halpern&q= uot; <jmh@joelhalpern.com>= wrote:
Note: The ONF Member work day is actually two days, April 18th and 19th. Thus, having the meeting on the 19th would actually collide with the ONF wo= rk session. =A0That does not seem to me to be a good dea.

Yours,
Joel

On 3/22/2013 8:27 AM, Alia Atlas wrote:
I am specifically trying to determine if there is strong interest in the Friday April 19 & April 20 vs. April 22-23.

Alia

On Mar 22, 2013 1:13 PM, "Robert Raszuk" <robert@raszuk.net
<mailto:robert@ra= szuk.net>> wrote:

=A0 =A0 =A0> April 22/23 @ Bay Area

=A0 =A0 Perfect location and timing ! =A0+1.

=A0 =A0 Thx,
=A0 =A0 Robert.


=A0 =A0 =A0> On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas <akatlas@juniper.net
=A0 =A0 <mailto:akatlas@juniper.net>> wrote:
=A0 =A0 =A0>
=A0 =A0 =A0> Ed and I would like to have an interim meeting in mid-April= in
=A0 =A0 the Mountain
=A0 =A0 =A0> View/Sunnyvale, CA area. We are trying to time it for aroun= d the Open
=A0 =A0 =A0> Networking Summit, but not conflicting with that or the ONF= workdays.
=A0 =A0 =A0>
=A0 =A0 =A0> We need to announce it 4 weeks in advance. =A0Unless, we an= nounce
=A0 =A0 today for
=A0 =A0 =A0> the afternoon/evening of April 19 (or into April 20), we ar= e
=A0 =A0 looking at
=A0 =A0 =A0> April 22/23. =A0Opinions ASAP from those who would attend w= ould be
=A0 =A0 quite
=A0 =A0 =A0> useful.
=A0 =A0 =A0>
=A0 =A0 =A0> In particular, is this a good time/place?
=A0 =A0 =A0>
=A0 =A0 =A0> We want the interim to focus on the use-cases & functio= nality for
=A0 =A0 i2rs. =A0 I
=A0 =A0 =A0> expect that we'll ask attendees to pick a set of use-ca= ses to be in a
=A0 =A0 =A0> design-group before & during the meeting to discuss &am= p; then
=A0 =A0 present to the
=A0 =A0 =A0> larger group. =A0More details to follow soon.
=A0 =A0 =A0>
=A0 =A0 =A0> Regards,
=A0 =A0 =A0> Alia
=A0 =A0 =A0>
=A0 =A0 =A0> _______________________________________________
=A0 =A0 =A0> i2rs mailing list
=A0 =A0 =A0> i2rs@iet= f.org <mailto:i2r= s@ietf.org>
=A0 =A0 =A0> https://www.ietf.org/mailman/listinfo/i2rs
=A0 =A0 =A0>
=A0 =A0 _______________________________________________
=A0 =A0 i2rs mailing list
=A0 =A0 i2rs@ietf.org <mailto:i2rs@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/listinfo/i2rs



_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--14dae9340ab10fb35a04d8851bff-- From akatlas@gmail.com Fri Mar 22 08:29:37 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84FF21F86D9 for ; Fri, 22 Mar 2013 08:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 DxKDJCgf8dlO for ; Fri, 22 Mar 2013 08:29:37 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 20C6121F86D3 for ; Fri, 22 Mar 2013 08:29:37 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id c11so4998119ieb.1 for ; Fri, 22 Mar 2013 08:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wazm17gsxqM/l/gjZHlIBqs61hZjyNff5makoUGu0BU=; b=0VikQawI2ePvpSKDgOj+0KY6AWs7PuAbTURzIAeZEHZ7mIfAf/F+szXHw44en+iI4x /zwiayfcAi8xdKlokzjNdeAIeyrHpZ4x9RyBD1hTmXuLdFmvEsASybXnOxWk2bSzpBwC AzGdqGnf8hdr42aRrLDUnZMBOSv13ONXtWIlPXSdL0FG9xNvo6McsU/PBdtnEGNcb3Bg uaXwf8CMAhFadxGTnpiFqXaYfJtsGktcTmLWVWITQsprcgfuy8pBf77ejufkXwQHSdMx 9NJVoElZPb0Ym6ZmaPg3YYgJsgEWmGGBI9tz1ftGoc0cTwgA4mc/Yd9UDgnNrojPSXz0 tRwQ== MIME-Version: 1.0 X-Received: by 10.50.191.133 with SMTP id gy5mr5237399igc.50.1363966176785; Fri, 22 Mar 2013 08:29:36 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Fri, 22 Mar 2013 08:29:36 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Fri, 22 Mar 2013 08:29:36 -0700 (PDT) In-Reply-To: References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> Date: Fri, 22 Mar 2013 11:29:36 -0400 Message-ID: From: Alia Atlas To: "Zafar Ali (zali)" Content-Type: multipart/alternative; boundary=14dae934071973fbf604d8851f84 Cc: i2rs@ietf.org, akatlas@juniper.net Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 15:29:37 -0000 --14dae934071973fbf604d8851f84 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, we need to figure out remote participation, but there should be some mechanism - and probably 1 or more remote design-groups. Alia On Mar 22, 2013 4:03 PM, "Zafar Ali (zali)" wrote: > Hi: > > Are you planning to have remote participation via WebEx or similar? > > Thanks > > Regards =85 Zafar > > From: Alia Atlas > Reply-To: Alia Atlas > Date: Friday, March 22, 2013 8:04 AM > To: "i2rs@ietf.org" > Subject: [i2rs] Interim meeting > > Ed and I would like to have an interim meeting in mid-April in the > Mountain View/Sunnyvale, CA area. We are trying to time it for around the > Open Networking Summit, but not conflicting with that or the ONF workdays= . > > We need to announce it 4 weeks in advance. Unless, we announce today > for the afternoon/evening of April 19 (or into April 20), we are looking = at > April 22/23. Opinions ASAP from those who would attend would be quite > useful. > > In particular, is this a good time/place? > > We want the interim to focus on the use-cases & functionality for i2rs. > I expect that we'll ask attendees to pick a set of use-cases to be in a > design-group before & during the meeting to discuss & then present to the > larger group. More details to follow soon. > > Regards, > Alia > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --14dae934071973fbf604d8851f84 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Yes, we need to figure out remote participation,=A0 but ther= e should be some mechanism - and probably 1 or more remote design-groups.

Alia

On Mar 22, 2013 4:03 PM, "Zafar Ali (zali)&= quot; <zali@cisco.com> wrote:
Hi:

Are you planning to have remote participation via WebEx or similar?=A0=

Thanks

Regards =85 Zafar

From: Alia Atlas <akatlas@juniper.net>
Reply-To: Alia Atlas <akatlas@juniper.net><= br> Date: Friday, March 22, 2013 8:04 A= M
To: "i2rs@ietf.org" <i2rs@ietf.org>
Subject: [i2rs] Interim meeting

Ed and I would like to have an interim meeting in mid-April in the Mou= ntain View/Sunnyvale, CA area. We are trying to time it for around the Open= Networking Summit, but not conflicting with that or the ONF workdays.

We need to announce it 4 weeks in advance. =A0Unless, we announce toda= y for the afternoon/evening of April 19 (or into April 20), we are looking = at April 22/23. =A0Opinions ASAP from those who would attend would be quite= useful.

In particular, is this a good time/place?

We want the interim to focus on the use-cases & functionality for = i2rs. =A0 I expect that we'll ask attendees to pick a set of use-cases = to be in a design-group before & during the meeting to discuss & th= en present to the larger group. =A0More details to follow soon.

Regards,
Alia

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--14dae934071973fbf604d8851f84-- From jmedved@cisco.com Fri Mar 22 08:30:14 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E5121F8D3C for ; Fri, 22 Mar 2013 08:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.932 X-Spam-Level: X-Spam-Status: No, score=-8.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666] 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 TauHuKhbuE6M for ; Fri, 22 Mar 2013 08:30:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B74A621F8E1E for ; Fri, 22 Mar 2013 08:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8776; q=dns/txt; s=iport; t=1363966212; x=1365175812; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=sJZqN2vBqoaX96QOoiZkQjQjzc6tkWgv4SjVkXPUJB8=; b=MWfalRD7xYdx24ELnwKiQYQ4DvLrXV5KiCa5K7rgKxVWiG3T+Hz7ciGb 127HbfZ8QGks93dJPOyw5SzqE7bNBYrgqArYDgh3tRT7gLhNKeEPSlPN/ qaMe6nDksXZmrGzHsK5VCe7NJpCsiXy7qSSK32K/Ak/FHLVE/PgaWyuZ6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAMl3TFGtJV2c/2dsb2JhbABDhBvBNoFlFnSCJAEBAQMBAQEBawsFDQEIDgoKHSgGCxQRAQEEAQ0FCId6AwkGDLhSDYlXBIxIghktBAeCX2EDlQSNSYUbgTGBWYIo X-IronPort-AV: E=Sophos;i="4.84,892,1355097600"; d="scan'208,217";a="190474917" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 22 Mar 2013 15:30:07 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2MFU6m3011270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 15:30:07 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.82]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 10:30:06 -0500 From: "Jan Medved (jmedved)" To: Alia Atlas , "Joel M. Halpern" Thread-Topic: [i2rs] Interim meeting Thread-Index: Ac4m9VuLX4TrFDPxSvK9ThSBXgqyxQAKzGMAAAB7iIAABT5MgAABFegA//+LH4A= Date: Fri, 22 Mar 2013 15:30:06 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.27.7.164] Content-Type: multipart/alternative; boundary="_000_ACC8AB2D98C05F4E9FBDA092017D97FC15191F1Axmbalnx10ciscoc_" MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 15:30:14 -0000 --_000_ACC8AB2D98C05F4E9FBDA092017D97FC15191F1Axmbalnx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for April 22/23. /Jan On 3/22/13 8:28 AM, "Alia Atlas" > wrote: Yes, the ONF workday finishes at 1:30pm on Friday. I'm getting the sense = that April 22/23 works better for most people, with a slight concern for ov= erlapping NFV#2. Alia On Mar 22, 2013 3:57 PM, "Joel M. Halpern" > wrote: Note: The ONF Member work day is actually two days, April 18th and 19th. Thus, having the meeting on the 19th would actually collide with the ONF wo= rk session. That does not seem to me to be a good dea. Yours, Joel On 3/22/2013 8:27 AM, Alia Atlas wrote: I am specifically trying to determine if there is strong interest in the Friday April 19 & April 20 vs. April 22-23. Alia On Mar 22, 2013 1:13 PM, "Robert Raszuk" >> wrote: > April 22/23 @ Bay Area Perfect location and timing ! +1. Thx, Robert. > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas >> wrote: > > Ed and I would like to have an interim meeting in mid-April in the Mountain > View/Sunnyvale, CA area. We are trying to time it for around the Ope= n > Networking Summit, but not conflicting with that or the ONF workdays= . > > We need to announce it 4 weeks in advance. Unless, we announce today for > the afternoon/evening of April 19 (or into April 20), we are looking at > April 22/23. Opinions ASAP from those who would attend would be quite > useful. > > In particular, is this a good time/place? > > We want the interim to focus on the use-cases & functionality for i2rs. I > expect that we'll ask attendees to pick a set of use-cases to be in = a > design-group before & during the meeting to discuss & then present to the > larger group. More details to follow soon. > > Regards, > Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_ACC8AB2D98C05F4E9FBDA092017D97FC15191F1Axmbalnx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
+1 for April 22/23.


/Jan


On 3/22/13 8:28 AM, "Alia Atlas" <akatlas@gmail.com> wrote:

Yes, the ONF workday finishes at 1:30pm on Friday. &nbs= p; I'm getting the sense that April 22/23 works better for most people, wit= h a slight concern for overlapping NFV#2.

Alia

On Mar 22, 2013 3:57 PM, "Joel M. Halpern&q= uot; <jmh@joelhalpern.com>= wrote:
Note: The ONF Member work day is actually two days, April 18th and 19th. Thus, having the meeting on the 19th would actually collide with the ONF wo= rk session.  That does not seem to me to be a good dea.

Yours,
Joel

On 3/22/2013 8:27 AM, Alia Atlas wrote:
I am specifically trying to determine if there is strong interest in the Friday April 19 & April 20 vs. April 22-23.

Alia

On Mar 22, 2013 1:13 PM, "Robert Raszuk" <robert@raszuk.net
<mailto:robert@ra= szuk.net>> wrote:

     > April 22/23 @ Bay Area

    Perfect location and timing !  +1.

    Thx,
    Robert.


     > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas <akatlas@juniper.net<= /a>
    <mailto:akatlas@juniper.net>> wrote:
     >
     > Ed and I would like to have an interim meeting in = mid-April in
    the Mountain
     > View/Sunnyvale, CA area. We are trying to time it = for around the Open
     > Networking Summit, but not conflicting with that o= r the ONF workdays.
     >
     > We need to announce it 4 weeks in advance.  U= nless, we announce
    today for
     > the afternoon/evening of April 19 (or into April 2= 0), we are
    looking at
     > April 22/23.  Opinions ASAP from those who wo= uld attend would be
    quite
     > useful.
     >
     > In particular, is this a good time/place?
     >
     > We want the interim to focus on the use-cases &= ; functionality for
    i2rs.   I
     > expect that we'll ask attendees to pick a set of u= se-cases to be in a
     > design-group before & during the meeting to di= scuss & then
    present to the
     > larger group.  More details to follow soon.      >
     > Regards,
     > Alia
     >
     > ___________________________________________= ____
     > i2rs mailing list
     > i2rs@ietf.org <mailto:i2rs@ietf.org>
     > https://www.ietf.org/mailman/listinfo/i2rs
     >
    _______________________________________________
    i2rs mailing list
    i2rs@ietf.= org <mailto:i2rs@= ietf.org>
    https://www.ietf.org/mailman/listinfo/i2rs



_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

 --_000_ACC8AB2D98C05F4E9FBDA092017D97FC15191F1Axmbalnx10ciscoc_-- From christian.martin@mac.com Fri Mar 22 08:32:16 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654EA21F85DA for ; Fri, 22 Mar 2013 08:32:16 -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 69NgRFtquJYM for ; Fri, 22 Mar 2013 08:32:12 -0700 (PDT) Received: from nk11p03mm-asmtp001.mac.com (nk11p03mm-asmtp001.mac.com [17.158.232.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5267021F85BC for ; Fri, 22 Mar 2013 08:32:12 -0700 (PDT) Received: from dhcp-10-131-24-97.cisco.com (rtp-isp-nat1.cisco.com [64.102.254.33]) by nk11p03mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MK2007WFJ5MNFC0@nk11p03mm-asmtp001.mac.com> for i2rs@ietf.org; Fri, 22 Mar 2013 15:32:12 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-03-22_04:2013-03-22, 2013-03-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=3 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1302030000 definitions=main-1303220102 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Christian Martin In-reply-to: Date: Fri, 22 Mar 2013 11:32:10 -0400 Content-transfer-encoding: quoted-printable Message-id: <9F9CA5BF-8F05-43D7-8238-3FBE7DDF5937@mac.com> References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> To: Robert Raszuk X-Mailer: Apple Mail (2.1499) Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 15:32:16 -0000 +1 for April 22-23 -Chris On Mar 22, 2013, at 8:13 AM, Robert Raszuk wrote: >> April 22/23 @ Bay Area >=20 > Perfect location and timing ! +1. >=20 > Thx, > Robert. >=20 >=20 >> On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas = wrote: >>=20 >> Ed and I would like to have an interim meeting in mid-April in the = Mountain >> View/Sunnyvale, CA area. We are trying to time it for around the Open >> Networking Summit, but not conflicting with that or the ONF workdays. >>=20 >> We need to announce it 4 weeks in advance. Unless, we announce today = for >> the afternoon/evening of April 19 (or into April 20), we are looking = at >> April 22/23. Opinions ASAP from those who would attend would be = quite >> useful. >>=20 >> In particular, is this a good time/place? >>=20 >> We want the interim to focus on the use-cases & functionality for = i2rs. I >> expect that we'll ask attendees to pick a set of use-cases to be in a >> design-group before & during the meeting to discuss & then present to = the >> larger group. More details to follow soon. >>=20 >> Regards, >> Alia >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From keyupate@cisco.com Fri Mar 22 10:48:29 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DB221F8F4A for ; Fri, 22 Mar 2013 10:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 cF-i0RD2liAm for ; Fri, 22 Mar 2013 10:48:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DF07421F8F41 for ; Fri, 22 Mar 2013 10:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7898; q=dns/txt; s=iport; t=1363974505; x=1365184105; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=GJnXg7vdt9sQwwKO2JI+H0HNMltMfMM5DKMVVpmohg8=; b=MV5ZnFCTJDjKOIThhPwTlR6JdiXcpxfT2xw3Qv5YKHXrfeLATp/vS8aQ 0mUex8VPDxZ2AgQAzXq/u/nlhPNQn6wqsZrFMQzXl5+MJ/C22PIAvGTZl AqgZJNJCKdcCD3QDzOm+Vu+8PSK/vQFGTnDRY50UvfUY5iJdTyQgtJcB6 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFANOYTFGtJXHB/2dsb2JhbABDhBvBOYFlFnSCJAEBAQMBAQEBawsFDQEIEQMBAgEKHSgGCxQJCAEBBAENBQiHegMJBgy4QQ2JVwSMSIIZIAYHBAeCX2EDlQSNSYUbgwqCKA X-IronPort-AV: E=Sophos;i="4.84,893,1355097600"; d="scan'208,217";a="190486601" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 22 Mar 2013 17:48:04 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2MHm4F8005761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 17:48:04 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.252]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 12:48:03 -0500 From: "Keyur Patel (keyupate)" To: Jeff Tantsura , Alia Atlas Thread-Topic: [i2rs] Interim meeting Thread-Index: Ac4m9VuLX4TrFDPxSvK9ThSBXgqyxQAKzGMAAAB7iIAABI4qgP//1Y+A Date: Fri, 22 Mar 2013 17:48:03 +0000 Message-ID: <4931A85EED76CA48BD52F2D94E7FAB0E0A1418@xmb-aln-x09.cisco.com> In-Reply-To: <629C610C-207D-42D9-B315-FE7B72D61D76@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.173] Content-Type: multipart/alternative; boundary="_000_4931A85EED76CA48BD52F2D94E7FAB0E0A1418xmbalnx09ciscocom_" MIME-Version: 1.0 Cc: "i2rs@ietf.org" , "akatlas@juniper.net" , Robert Raszuk Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 17:48:29 -0000 --_000_4931A85EED76CA48BD52F2D94E7FAB0E0A1418xmbalnx09ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1. Regards, Keyur From: Jeff Tantsura > Date: Fri, 22 Mar 2013 14:37:35 +0000 To: Alia Atlas > Cc: "i2rs@ietf.org" >, "akatlas@juniper.net" >, Robert Raszuk > Subject: Re: [i2rs] Interim meeting Both dates work for me, however preferably 22-23. Regards, Jeff On Mar 22, 2013, at 1:27 PM, "Alia Atlas" > wrote: I am specifically trying to determine if there is strong interest in the Fr= iday April 19 & April 20 vs. April 22-23. Alia On Mar 22, 2013 1:13 PM, "Robert Raszuk" > wrote: > April 22/23 @ Bay Area Perfect location and timing ! +1. Thx, Robert. > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas > wrote: > > Ed and I would like to have an interim meeting in mid-April in the Mounta= in > View/Sunnyvale, CA area. We are trying to time it for around the Open > Networking Summit, but not conflicting with that or the ONF workdays. > > We need to announce it 4 weeks in advance. Unless, we announce today for > the afternoon/evening of April 19 (or into April 20), we are looking at > April 22/23. Opinions ASAP from those who would attend would be quite > useful. > > In particular, is this a good time/place? > > We want the interim to focus on the use-cases & functionality for i2rs. = I > expect that we'll ask attendees to pick a set of use-cases to be in a > design-group before & during the meeting to discuss & then present to the > larger group. More details to follow soon. > > Regards, > Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf= .org https://www.ietf.org/mailman/listinfo/i2rs --_000_4931A85EED76CA48BD52F2D94E7FAB0E0A1418xmbalnx09ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4F8E78FA2FBFD74188A5EE078B320D9E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
+1.

Regards,
Keyur

From: Jeff Tantsura <jeff.tantsura@ericsson.com>
Date: Fri, 22 Mar 2013 14:37:35 = 3;0000
To: Alia Atlas <akatlas@gmail.com>
Cc: "i2rs@ietf.org" <i2rs@i= etf.org>, "akatlas@junip= er.net" <akatlas@juniper= .net>, Robert Raszuk <robert@raszuk.net>
Subject: Re: [i2rs] Interim meeting=

Both dates work for me,
however preferably 22-23.

Regards,
Jeff

I am specifically trying to determine if there is strong int= erest in the Friday April 19 & April 20 vs. April 22-23.

Alia

On Mar 22, 2013 1:13 PM, "Robert Raszuk&quo= t; <robert@raszuk.net> wrote= :
> April 22/23 @ Bay Area

Perfect location and timing !  +1.

Thx,
Robert.


> On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas <akatlas@juniper.net> wrote:
>
> Ed and I would like to have an interim meeting in mid-April in the Mou= ntain
> View/Sunnyvale, CA area. We are trying to time it for around the Open<= br> > Networking Summit, but not conflicting with that or the ONF workdays.<= br> >
> We need to announce it 4 weeks in advance.  Unless, we announce t= oday for
> the afternoon/evening of April 19 (or into April 20), we are looking a= t
> April 22/23.  Opinions ASAP from those who would attend would be = quite
> useful.
>
> In particular, is this a good time/place?
>
> We want the interim to focus on the use-cases & functionality for = i2rs.   I
> expect that we'll ask attendees to pick a set of use-cases to be in a<= br> > design-group before & during the meeting to discuss & then pre= sent to the
> larger group.  More details to follow soon.
>
> Regards,
> Alia
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ie= tf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list i2rs@ietf.org ht= tps://www.ietf.org/mailman/listinfo/i2rs --_000_4931A85EED76CA48BD52F2D94E7FAB0E0A1418xmbalnx09ciscocom_-- From yihuan@cisco.com Fri Mar 22 11:49:13 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30DF21F8F22 for ; Fri, 22 Mar 2013 11:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.154 X-Spam-Level: X-Spam-Status: No, score=-7.154 tagged_above=-999 required=5 tests=[AWL=3.444, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Bbu5+G0FWxmR for ; Fri, 22 Mar 2013 11:49:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DE70121F8E7D for ; Fri, 22 Mar 2013 11:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10060; q=dns/txt; s=iport; t=1363978153; x=1365187753; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=MulvxJLtOFZMT/acy0cGRXr9gU0/qd81HsJmFsDtVS4=; b=JsjDvnj0WM9jwOxg0ELf5vXBj/+QDGIRDW1A1O8L74REDeMIqYJdU2YT Hat5G7fotUqWSWxL0xNgeHIdxNGHZ4qQ/2ISeasGK6VYl5XajaE3rfb3n FLA3A9D+4Am+qPiFadglVaelc62pxQL9dxtSK62QTvDMvIKgsEbPW7gSd k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFymTFGtJV2a/2dsb2JhbABDhBvBOoFlFnSCJAEBAQMBAQEBawsFDQEIEQMBAgEKHSgGCxQJCAEBBAENBQiHegMJBgy4Ng2JVwSMSIIZIAYHBAeCX2EDlQSNSYUbgwqCKA X-IronPort-AV: E=Sophos;i="4.84,893,1355097600"; d="scan'208,217";a="190480221" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 22 Mar 2013 18:49:12 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2MInCuB029205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 18:49:12 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 13:49:11 -0500 From: "Lisa Huang (yihuan)" To: "Keyur Patel (keyupate)" , Jeff Tantsura , Alia Atlas Thread-Topic: [i2rs] Interim meeting Thread-Index: Ac4m9VuLX4TrFDPxSvK9ThSBXgqyxQAKzGMAAAB7iIAABI4qgP//1Y+A///7YAA= Date: Fri, 22 Mar 2013 18:49:10 +0000 Message-ID: <559E176269AD64429F1582D4EB94F86FCD6B41@xmb-aln-x03.cisco.com> In-Reply-To: <4931A85EED76CA48BD52F2D94E7FAB0E0A1418@xmb-aln-x09.cisco.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 x-originating-ip: [10.154.203.136] Content-Type: multipart/alternative; boundary="_000_559E176269AD64429F1582D4EB94F86FCD6B41xmbalnx03ciscocom_" MIME-Version: 1.0 Cc: "i2rs@ietf.org" , "akatlas@juniper.net" , Robert Raszuk Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 18:49:14 -0000 --_000_559E176269AD64429F1582D4EB94F86FCD6B41xmbalnx03ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Lisa From: "Keyur Patel (keyupate)" > Date: Friday, March 22, 2013 10:48 AM To: Jeff Tantsura >, Alia Atlas > Cc: "i2rs@ietf.org" >, "akatlas@juniper.net" >, Robert Raszuk > Subject: Re: [i2rs] Interim meeting +1. Regards, Keyur From: Jeff Tantsura > Date: Fri, 22 Mar 2013 14:37:35 +0000 To: Alia Atlas > Cc: "i2rs@ietf.org" >, "akatlas@juniper.net" >, Robert Raszuk > Subject: Re: [i2rs] Interim meeting Both dates work for me, however preferably 22-23. Regards, Jeff On Mar 22, 2013, at 1:27 PM, "Alia Atlas" > wrote: I am specifically trying to determine if there is strong interest in the Fr= iday April 19 & April 20 vs. April 22-23. Alia On Mar 22, 2013 1:13 PM, "Robert Raszuk" > wrote: > April 22/23 @ Bay Area Perfect location and timing ! +1. Thx, Robert. > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas > wrote: > > Ed and I would like to have an interim meeting in mid-April in the Mounta= in > View/Sunnyvale, CA area. We are trying to time it for around the Open > Networking Summit, but not conflicting with that or the ONF workdays. > > We need to announce it 4 weeks in advance. Unless, we announce today for > the afternoon/evening of April 19 (or into April 20), we are looking at > April 22/23. Opinions ASAP from those who would attend would be quite > useful. > > In particular, is this a good time/place? > > We want the interim to focus on the use-cases & functionality for i2rs. = I > expect that we'll ask attendees to pick a set of use-cases to be in a > design-group before & during the meeting to discuss & then present to the > larger group. More details to follow soon. > > Regards, > Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf= .org https://www.ietf.org/mailman/listinfo/i2rs --_000_559E176269AD64429F1582D4EB94F86FCD6B41xmbalnx03ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
+1
Lisa

From: "Keyur Patel (keyupate)&= quot; <keyupate@cisco.com><= br> Date: Friday, March 22, 2013 10:48 = AM
To: Jeff Tantsura <jeff.tantsura@ericsson.com>, Alia A= tlas <akatlas@gmail.com>
Cc: "i2rs@ietf.org" <i2rs@i= etf.org>, "akatlas@junip= er.net" <akatlas@juniper= .net>, Robert Raszuk <robert@raszuk.net>
Subject: Re: [i2rs] Interim meeting=

+1.

Regards,
Keyur

Both dates work for me,
however preferably 22-23.

Regards,
Jeff

I am specifically trying to determine if there is strong int= erest in the Friday April 19 & April 20 vs. April 22-23.

Alia

On Mar 22, 2013 1:13 PM, "Robert Raszuk&quo= t; <robert@raszuk.net> wrote= :
> April 22/23 @ Bay Area

Perfect location and timing !  +1.

Thx,
Robert.


> On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas <akatlas@juniper.net> wrote:
>
> Ed and I would like to have an interim meeting in mid-April in the Mou= ntain
> View/Sunnyvale, CA area. We are trying to time it for around the Open<= br> > Networking Summit, but not conflicting with that or the ONF workdays.<= br> >
> We need to announce it 4 weeks in advance.  Unless, we announce t= oday for
> the afternoon/evening of April 19 (or into April 20), we are looking a= t
> April 22/23.  Opinions ASAP from those who would attend would be = quite
> useful.
>
> In particular, is this a good time/place?
>
> We want the interim to focus on the use-cases & functionality for = i2rs.   I
> expect that we'll ask attendees to pick a set of use-cases to be in a<= br> > design-group before & during the meeting to discuss & then pre= sent to the
> larger group.  More details to follow soon.
>
> Regards,
> Alia
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ie= tf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list i2rs@ietf.org ht= tps://www.ietf.org/mailman/listinfo/i2rs
 --_000_559E176269AD64429F1582D4EB94F86FCD6B41xmbalnx03ciscocom_-- From samita.chakrabarti@ericsson.com Fri Mar 22 11:57:12 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE0E21F8499 for ; Fri, 22 Mar 2013 11:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ZLd+W1e7Vrtv for ; Fri, 22 Mar 2013 11:57:12 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id D7D1821F846C for ; Fri, 22 Mar 2013 11:57:11 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-66-514ca987bd9b Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 02.20.02411.789AC415; Fri, 22 Mar 2013 19:57:11 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 14:57:10 -0400 From: Samita Chakrabarti To: "Joel M. Halpern" , Alia Atlas Thread-Topic: [i2rs] Interim meeting Thread-Index: Ac4m9VuLX4TrFDPxSvK9ThSBXgqyxQAIs/IAAAB7iIAABT5MgAAACHMQ Date: Fri, 22 Mar 2013 18:57:09 +0000 Message-ID: References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> <514C714D.3020504@joelhalpern.com> In-Reply-To: <514C714D.3020504@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXSPn277Sp9AgwUHZC0+PbzEbLFuxgcW i4+n3jA5MHvsnHWX3WPJkp9MHuemfGcMYI7isklJzcksSy3St0vgynix+CVTwXXGijUH+1ga GGcxdjFyckgImEhMXXyaBcIWk7hwbz1bFyMXh5DAEUaJiw+vskM4yxkl1i2fwQpSxSZgJdHR u4cdxBYR8Jb42t4IZjMLKEtMfLmfDcQWBrJfrzsKVaMi8fXCETYI203iye12MJtFQFWiv/Ui E4jNCzTnzptbYFcICfxklNj00RTE5hTQl3j/bQ0ziM0IdN33U2uYIHaJS9x6Mp8J4moBiSV7 zjND2KISLx//Y4WwlSWWPNnPAlGvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUWwWkrGzkLTM QtIyC0nLAkaWVYwcpcWpZbnpRoabGIGxc0yCzXEH44JPlocYpTlYlMR5Q10vBAgJpCeWpGan phakFsUXleakFh9iZOLglGpgtPxSXi39Sfp2xOSzp/g4fy5+xTSTWdzdwG1ry96gicJhdnNz 57wO2KN/sdI9o+jQ1g/7WkrSjT7dZ/l49m3L5449oumLmHfUyK5xUFqgkr2n5eXBLSWa1ye8 ldZbEaz1rf4qb4Qvs/c8ye0Zc+fOffk1oqdthbVw4pI3PJ3Ljj57v7S/t8ysQomlOCPRUIu5 qDgRAPWu+RlrAgAA Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 18:57:12 -0000 =20 > > On Mar 22, 2013 1:13 PM, "Robert Raszuk" > wrote: > > > April 22/23 @ Bay Area > > Perfect location and timing ! +1. +1 -Samita= From edc@google.com Fri Mar 22 12:20:55 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5924321F9002 for ; Fri, 22 Mar 2013 12:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.769 X-Spam-Level: X-Spam-Status: No, score=-101.769 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 yY4LymV6fVmo for ; Fri, 22 Mar 2013 12:20:54 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 663B021F8FF5 for ; Fri, 22 Mar 2013 12:20:54 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id o45so3769188wer.9 for ; Fri, 22 Mar 2013 12:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=nDQ7QFF0Py+h/8tZ7qSVhxRd/pVuNr2eh9PkL55a+U4=; b=oW8ATq67pMCg8KdYPhDUA5/l3noufLmk0vcfNztZKNT5vXi6Ijz1+Vk++/F/CvpmrT Mqa0TbXCz3V9f/8LqBhhFE20kWFjGVkg7tjPcngsOuMBjim0Cm9gFE7VgifqpcIu+cuI hA0zGO1BSZZ1VIPz7fzcwVH+hH75pV3DRfpGO/4nCr26TKlvP9SPqxH/RRHRtdKvsYC9 vQK5GYyKFRKvLSF3fgKgWM20f/KuWFaBTbcKV/6kxJejK7uOykg7hoaiu849WzTXI7r6 ImAAjjIuD/gZJpO0yyYzeAREH0plD7hpSXe/t1WlgaP6bNsG1EnhMEME/mAldSU2D2m8 tLxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=nDQ7QFF0Py+h/8tZ7qSVhxRd/pVuNr2eh9PkL55a+U4=; b=fF4m7t6m/S/o7QxXuymZP0gck/kNj5ei4pbBpCqn3zgoLQFucVtiBJ1TxqnLBezLf6 P9g1XwmUmAASmNsi8+xXI2QDUWlEbdnlCaVnRlIkmDNsfAKWtprXxLHwVkqlaq3ZexSA HLd4q+s0pBgJm//EHeGT79wMqofF5cKLl6Zp2bae0/2ib1splioCL3cvMifZ3Z2CFlrf I7NLqm///WP3u+rI+Gi9grlYBuVqHKd0C5EpZhgrWC7KNmctxqBWyip5EnPeZyGDJag5 X2s13kHEhudSAodLG8H+438M5jHgNLTFRjbi76vYNBJKISCjGfAXDnt60GZ7xpwKuo7R Y6fw== X-Received: by 10.194.133.198 with SMTP id pe6mr5307533wjb.9.1363980053360; Fri, 22 Mar 2013 12:20:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.83.195 with HTTP; Fri, 22 Mar 2013 12:20:13 -0700 (PDT) In-Reply-To: References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> From: Edward Crabbe Date: Fri, 22 Mar 2013 12:20:13 -0700 Message-ID: To: "Zafar Ali (zali)" Content-Type: multipart/alternative; boundary=089e01175f7d8fd1fd04d8885a51 X-Gm-Message-State: ALoCoQln0zqEBN+mbDo+pmwM7NDDXKh72jfwjJtKvUoXRD1j+/kbqkJG/l3qouU8WmiCxqgB3tCeF9pXA6Z+1FVXBo8Mh8il9a4UkeMUsrhtwylHMEnlvOXaJqruMeL//+AL/+b/zn5ziLClGG6q92mEcoWdK4EeG99EuJ8rZcoxZqsXdrHC6c25fPRDeToJPa3gBS7uXAPv Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 19:20:55 -0000 --089e01175f7d8fd1fd04d8885a51 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We'll get something set up, be it google hangout, webex, or simple conference call. On Fri, Mar 22, 2013 at 8:02 AM, Zafar Ali (zali) wrote: > Hi: > > Are you planning to have remote participation via WebEx or similar? > > Thanks > > Regards =85 Zafar > > From: Alia Atlas > Reply-To: Alia Atlas > Date: Friday, March 22, 2013 8:04 AM > To: "i2rs@ietf.org" > Subject: [i2rs] Interim meeting > > Ed and I would like to have an interim meeting in mid-April in the > Mountain View/Sunnyvale, CA area. We are trying to time it for around the > Open Networking Summit, but not conflicting with that or the ONF workdays= . > > We need to announce it 4 weeks in advance. Unless, we announce today > for the afternoon/evening of April 19 (or into April 20), we are looking = at > April 22/23. Opinions ASAP from those who would attend would be quite > useful. > > In particular, is this a good time/place? > > We want the interim to focus on the use-cases & functionality for i2rs. > I expect that we'll ask attendees to pick a set of use-cases to be in a > design-group before & during the meeting to discuss & then present to the > larger group. More details to follow soon. > > Regards, > Alia > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --089e01175f7d8fd1fd04d8885a51 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
We'll get something set up, be it google hangout, webe= x, or simple conference call. =A0


<= div class=3D"gmail_quote">On Fri, Mar 22, 2013 at 8:02 AM, Zafar Ali (zali)= <= zali@cisco.com> wrote:
Hi:

Are you planning to have remote participation via WebEx or similar?=A0=

Thanks

Regards =85 Zafar

From: Alia Atlas <akatlas@juniper.net>
Reply-To: Alia Atlas <akatlas@juniper.net><= br> Date: Friday, March 22, 2013 8:04 A= M
To: "i2rs@ietf.org" <i2rs@ietf.org>
Subject: [i2rs] Interim meeting

Ed and I would like to have an interim meeting in mid-April in the Mou= ntain View/Sunnyvale, CA area. We are trying to time it for around the Open= Networking Summit, but not conflicting with that or the ONF workdays.

We need to announce it 4 weeks in advance. =A0Unless, we announce toda= y for the afternoon/evening of April 19 (or into April 20), we are looking = at April 22/23. =A0Opinions ASAP from those who would attend would be quite= useful.

In particular, is this a good time/place?

We want the interim to focus on the use-cases & functionality for = i2rs. =A0 I expect that we'll ask attendees to pick a set of use-cases = to be in a design-group before & during the meeting to discuss & th= en present to the larger group. =A0More details to follow soon.

Regards,
Alia

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs


--089e01175f7d8fd1fd04d8885a51-- From edc@google.com Fri Mar 22 12:25:57 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9092221F8E77 for ; Fri, 22 Mar 2013 12:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.81 X-Spam-Level: X-Spam-Status: No, score=-101.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 W6UFdaMG3Tdf for ; Fri, 22 Mar 2013 12:25:56 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3835F21F8E41 for ; Fri, 22 Mar 2013 12:25:55 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hj8so1055380wib.14 for ; Fri, 22 Mar 2013 12:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=OE+rRgtD+yydinN7UgBrp5HYoUAPX73iBoIHHdvcrTo=; b=gumpGp/v1ai6MviBkgjr0+Pty0sjyzuiAwReB4SyFVnwDJzuwJ2kaqTk/yzuhmnPhN z+ROPvHHSx8cCn0vM0G+z73RuMs3RhRXqtYFn8ngh8IC1jnjyqT61SXkJXd2U/CsRyZV J2krKr0f5cimlvnw0Hwx7T5nAZAQD3Q1hYQC7SgdwTQa4qI2O3tDPRi0WSnHwUASGvCU hKZLWAoM76aDXAe/0052IciORkdKRMfs5GgQ1lyp9uRJfH+iU8nl9LO68O6FgOrlt5Ki Ww1ddgRCBK1Kp8TTyCm8UBXltR7tunGa77ICc7hiwVnIJPnwTaooxRM7RF+30L1DGh2C Ldmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=OE+rRgtD+yydinN7UgBrp5HYoUAPX73iBoIHHdvcrTo=; b=M3ruyCrX/bUkX7F+dXwrv7HDvaVHh18isv4hO5OwYsaj/pCcXuNIzyoXD1yJcwVpLu rPKiCNje6ISF3FuPo1KTucmIkQHpC6lWRWQnQAKXYU2+oswiK5ldt1NDdZXO9EY6qQOH ZG9PAFWDUfxWfsGHYgBkRNOEDPxbrX1uAAfbr2vdQNlLj302Rf53sD/C8LQ7+vdFfdSW 9nFR/BhSsZ71FXmp/zUG9qKvaZLCM5evqLnP53CHWCLnhKvXpAxiM7YgDK1q74Uqj22I 1sHBOqVGA8puQ163e0nl+aEmM8zYLb2o/U6UhDO6BrM9TArFkpJooO7eTcYnEiL1wUjv VBng== X-Received: by 10.181.12.5 with SMTP id em5mr5078900wid.24.1363980355171; Fri, 22 Mar 2013 12:25:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.83.195 with HTTP; Fri, 22 Mar 2013 12:25:13 -0700 (PDT) In-Reply-To: References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> From: Edward Crabbe Date: Fri, 22 Mar 2013 12:25:13 -0700 Message-ID: To: "Zafar Ali (zali)" Content-Type: multipart/alternative; boundary=f46d043c7c588d134104d8886cc4 X-Gm-Message-State: ALoCoQkcZBoyA/iKwxVMsceThlZJ9iDGSUPjatXR/SClrto+QW8ZEyXPitGPpjnSHtRj7XpDqrTofwdQwhoHkevTtYKl+L7+mLji/ts4Zc4Fv03976YL4FZkPJFi1PLOg+dJ3lf97m8Dt8N9899Bmx//h3NXXpCsWl20jdcebuy74TOqXVgebg7LyOc69VV6vwksv6uBmkn3 Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 19:25:57 -0000 --f46d043c7c588d134104d8886cc4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So rather than attempt to track everyone's responses via email, I've set up a quick poll: http://doodle.com/hdpuqr7ffduf8nm8 Please fill out the dates you're available. Thanks very much, -ed On Fri, Mar 22, 2013 at 12:20 PM, Edward Crabbe wrote: > We'll get something set up, be it google hangout, webex, or simple > conference call. > > > On Fri, Mar 22, 2013 at 8:02 AM, Zafar Ali (zali) wrote: > >> Hi: >> >> Are you planning to have remote participation via WebEx or similar? >> >> Thanks >> >> Regards =85 Zafar >> >> From: Alia Atlas >> Reply-To: Alia Atlas >> Date: Friday, March 22, 2013 8:04 AM >> To: "i2rs@ietf.org" >> Subject: [i2rs] Interim meeting >> >> Ed and I would like to have an interim meeting in mid-April in the >> Mountain View/Sunnyvale, CA area. We are trying to time it for around th= e >> Open Networking Summit, but not conflicting with that or the ONF workday= s. >> >> We need to announce it 4 weeks in advance. Unless, we announce today >> for the afternoon/evening of April 19 (or into April 20), we are looking= at >> April 22/23. Opinions ASAP from those who would attend would be quite >> useful. >> >> In particular, is this a good time/place? >> >> We want the interim to focus on the use-cases & functionality for i2rs. >> I expect that we'll ask attendees to pick a set of use-cases to be in = a >> design-group before & during the meeting to discuss & then present to th= e >> larger group. More details to follow soon. >> >> Regards, >> Alia >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > --f46d043c7c588d134104d8886cc4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
So rather than attempt to track everyone's responses v= ia email, I've set up a quick poll:


Please fill out the dates you're available.

Thanks very much,

<= /div>
=A0 -ed=A0


On Fri, Mar 22, 2013 at 12:20 PM, Edward Crabbe <edc@google.com> wrote:
We'll get something set up, be it google hangout, webe= x, or simple conference call. =A0


<= div class=3D"gmail_quote">
On Fri, Mar 22, 2013 at 8:= 02 AM, Zafar Ali (zali) <zali@cisco.com> wrote:
Hi:

Are you planning to have remote participation via WebEx or similar?=A0=

Thanks

Regards =85 Zafar

From: Alia Atlas <akatlas@juniper.net>
Reply-To: Alia Atlas <akatlas@juniper.net><= br> Date: Friday, March 22, 2013 8:04 A= M
To: "i2rs@ietf.org" <i2rs@ietf.org>
Subject: [i2rs] Interim meeting

Ed and I would like to have an interim meeting in mid-April in the Mou= ntain View/Sunnyvale, CA area. We are trying to time it for around the Open= Networking Summit, but not conflicting with that or the ONF workdays.

We need to announce it 4 weeks in advance. =A0Unless, we announce toda= y for the afternoon/evening of April 19 (or into April 20), we are looking = at April 22/23. =A0Opinions ASAP from those who would attend would be quite= useful.

In particular, is this a good time/place?

We want the interim to focus on the use-cases & functionality for = i2rs. =A0 I expect that we'll ask attendees to pick a set of use-cases = to be in a design-group before & during the meeting to discuss & th= en present to the larger group. =A0More details to follow soon.

Regards,
Alia

_________________________________________= ______
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs



--f46d043c7c588d134104d8886cc4-- From edc@google.com Fri Mar 22 12:49:43 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25B521F8F17 for ; Fri, 22 Mar 2013 12:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 0o+NTQPfIQIl for ; Fri, 22 Mar 2013 12:49:43 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id C957F21F8F08 for ; Fri, 22 Mar 2013 12:49:42 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id c10so160966wiw.13 for ; Fri, 22 Mar 2013 12:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=9fQHTNvLbO1CARcFpsLlF5CAd0Tzt1mbhG5zgQYf1Zw=; b=FSsvqbQCbx68iS87oe+AjaGKlbmK8ClccNSctRHof4bzVLlAHQWQhPwszEM+043m8B 5/YOwtLLDauyU+7AG3eTGtX60tE+0g3fDBugw8k0p9W1MV+rUd1sYCGVyqOm4UREpiIa lq4svkJwRiZQPg7qFPnI9YcyDbYonXSli1HH5IFm0B3ii0gCIxz+wPIOJPxDycbaoryu Rd2+yptyqgSv8ljeSjnsSo8LFnoMx/CKOjPzaQdcnqQPByCleRUJ2Rmgjz2iloz3Ni+K Y8UE+0zC5bkUkPGFFFDIrksizrUvMHeBV2en2rdL5JkqZCfsW1Ycjo0wNFTs1e00smma lR/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=9fQHTNvLbO1CARcFpsLlF5CAd0Tzt1mbhG5zgQYf1Zw=; b=DmsU9d1shwTPjyaj5MBJkAmJ020JqHW+BcKImAok+vDLjILBW2IvKv0N2KtEZFcBN+ KZysVjCHV/TneVfiHYqbN7eI102znovNQgkb7Qu3LeU7j9U05vhdWyUdw9p3+5QoVwiy UxAP+x+rPV3SlqzSUk4y2C9nCkrH6o51bScLMqkfAZtklEnlzDJufRgfeZZMGpe5u3ah GchCmf/xgcpBXlX11ZuRRwBUmgU/vjcL4rxtZlQZSSSXbI4PN7Nw/cutq9UGDl61fEoS fYF/NOqgo0TCm73/BBoZtGmgyZZ0WhOGaRQtkGNSHfM8i7IXikWyfMw2QR1PBfwq2EAO L/pw== X-Received: by 10.180.12.33 with SMTP id v1mr13439670wib.24.1363981781935; Fri, 22 Mar 2013 12:49:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.83.195 with HTTP; Fri, 22 Mar 2013 12:49:01 -0700 (PDT) From: Edward Crabbe Date: Fri, 22 Mar 2013 12:49:01 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2409297bf7004d888c14b X-Gm-Message-State: ALoCoQkWPoGgKZ5APm5nEFHN8l5HytDPH7HzPImOQJ9WFxyEU4tbbPslWOiuHyuyTySHK8Qg8/+B0gUMdAirMDnGnT+LF1N7LkZ9DfqKv51ZVqLLDHboRGy/kCv52ajlAD7VlBeeENAvSI8/15+P+phamCVigThKc40X91zZ3mnby/c2IxVFJ+IWLXtk6jN1RCOpd4wIz6n+ Subject: [i2rs] Interim meeting poll X-BeenThere: i2rs@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, 22 Mar 2013 19:49:43 -0000 --001a11c2409297bf7004d888c14b Content-Type: text/plain; charset=ISO-8859-1 Hey all; Rather than attempt to track everyone's responses re: interim meeting dates via email, I've set up a quick poll: http://doodle.com/hdpuqr7ffduf8nm8 Please fill out the dates you're available ASAP so we can hit the 4 week announcement deadline. Thanks very much, -ed --001a11c2409297bf7004d888c14b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hey all;

Rather than attempt t= o track everyone's responses re: interim meeting dates via email, I'= ;ve set up a quick poll:


Please= fill out the dates you're available ASAP so we can hit the 4 week anno= uncement deadline.

Thanks= very much,

=A0 -= ed=A0
--001a11c2409297bf7004d888c14b-- From alex@cisco.com Fri Mar 22 13:13:46 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F4A21F8FED for ; Fri, 22 Mar 2013 13:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 lmgSnEP+OC2Q for ; Fri, 22 Mar 2013 13:13:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 79D9721F8489 for ; Fri, 22 Mar 2013 13:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1975; q=dns/txt; s=iport; t=1363983225; x=1365192825; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=M6lUi0LdSDgNLHOMbp81YWPj17Jpvw3oZGhLxyN4t5I=; b=V5gavOTs2H3XTPoGUfC5zBT0+1xN6B8fs9M6JibOvM/N1XTdjqi4Cvlh X7MU4hAEKwZ8kv0ymjb3svbUxz1ReRsJd7GMimdTrVU/yf1oO/7XTNLBg V0Ycqc5YhbVrXfljTKEKu2Oat5hBWrVto6O9e0jAQbzER/m9LjWfF16O9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOW6TFGtJXG8/2dsb2JhbABDxVeBZRZ0giQBAQEDAQEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgBAQQBDQUIiAYGDMIPBI5hJgsHBoJZYQOnaIMKgig X-IronPort-AV: E=Sophos;i="4.84,893,1355097600"; d="scan'208";a="190539353" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 22 Mar 2013 20:13:45 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2MKDiT2017251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 20:13:44 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.147]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 15:13:44 -0500 From: "Alexander Clemm (alex)" To: Christian Martin , Robert Raszuk Thread-Topic: [i2rs] Interim meeting Thread-Index: Ac4m9VuLX4TrFDPxSvK9ThSBXgqyxQAKzGMAAAbxtQAAALeQwA== Date: Fri, 22 Mar 2013 20:13:44 +0000 Message-ID: References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> <9F9CA5BF-8F05-43D7-8238-3FBE7DDF5937@mac.com> In-Reply-To: <9F9CA5BF-8F05-43D7-8238-3FBE7DDF5937@mac.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 20:13:46 -0000 +1 for April 22-23 as well The week prior is spring break at our kids' school, other parents may have = conflicts as well --- Alex -----Original Message----- From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Chr= istian Martin Sent: Friday, March 22, 2013 8:32 AM To: Robert Raszuk Cc: i2rs@ietf.org; Alia Atlas Subject: Re: [i2rs] Interim meeting +1 for April 22-23 -Chris On Mar 22, 2013, at 8:13 AM, Robert Raszuk wrote: >> April 22/23 @ Bay Area >=20 > Perfect location and timing ! +1. >=20 > Thx, > Robert. >=20 >=20 >> On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas wrote: >>=20 >> Ed and I would like to have an interim meeting in mid-April in the=20 >> Mountain View/Sunnyvale, CA area. We are trying to time it for around=20 >> the Open Networking Summit, but not conflicting with that or the ONF wor= kdays. >>=20 >> We need to announce it 4 weeks in advance. Unless, we announce today=20 >> for the afternoon/evening of April 19 (or into April 20), we are=20 >> looking at April 22/23. Opinions ASAP from those who would attend=20 >> would be quite useful. >>=20 >> In particular, is this a good time/place? >>=20 >> We want the interim to focus on the use-cases & functionality for i2rs. = I >> expect that we'll ask attendees to pick a set of use-cases to be in a=20 >> design-group before & during the meeting to discuss & then present to=20 >> the larger group. More details to follow soon. >>=20 >> Regards, >> Alia >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From yiya@cisco.com Fri Mar 22 13:41:13 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBA421F93CD for ; Fri, 22 Mar 2013 13:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 96LjUfvpbt4k for ; Fri, 22 Mar 2013 13:41:12 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6508921F925B for ; Fri, 22 Mar 2013 13:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=930; q=dns/txt; s=iport; t=1363984872; x=1365194472; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=kbwDyVYz50Y3UVJRD0MZ7yH0TmEmYbEv/gOUkYU7lJQ=; b=kmo8lKoT4FmynqJ7BxT2/Baf1lsNkJBvueCcjjuMgViqE4sd8ncAfRRh FaaTFMnYG1+oOEKUNeMM5eI+/1dv62wimAKxrm2QQbeRm8N4go4iVrzCL ilF7lc713vij0KkHTY5pJK6czHdvk2GTm8tbtJdYkhwuhR4EDZUG4O4uS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQFABTATFGtJXG//2dsb2JhbABDh2a9dYFlFnSCJgEEOlEBCA4UFEIlAQEEARIIiAzCIY5hOIJfYQOnaIMKgig X-IronPort-AV: E=Sophos;i="4.84,893,1355097600"; d="scan'208";a="190551620" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 22 Mar 2013 20:41:12 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2MKfCRw019313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 20:41:12 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.252]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 15:41:11 -0500 From: "Yi Yang (yiya)" To: Alia Atlas , "i2rs@ietf.org" Thread-Topic: [i2rs] Interim meeting Thread-Index: Ac4m9VuLX4TrFDPxSvK9ThSBXgqyxQAUJwEA Date: Fri, 22 Mar 2013 20:41:11 +0000 Message-ID: In-Reply-To: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.116.75.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 22 Mar 2013 20:41:13 -0000 Or beginning of May instead? :-) Yi On 3/22/13 8:04 AM, "Alia Atlas" wrote: > > > >Ed and I would like to have an interim meeting in mid-April in the >Mountain View/Sunnyvale, CA area. We are trying to time it for around the >Open Networking Summit, but not conflicting with that or the ONF workdays. > > >We need to announce it 4 weeks in advance. Unless, we announce today for >the afternoon/evening of April 19 (or into April 20), we are looking at >April 22/23. Opinions ASAP from those who would attend would be quite >useful. > > >In particular, is this a good time/place? > > >We want the interim to focus on the use-cases & functionality for i2rs. >I expect that we'll ask attendees to pick a set of use-cases to be in a >design-group before & during the meeting to discuss & then present to the >larger group. More details to follow > soon. > > >Regards, >Alia From edc@google.com Fri Mar 22 17:10:09 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E9721F8C7D for ; Fri, 22 Mar 2013 17:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 A-eUSgkm7QLg for ; Fri, 22 Mar 2013 17:10:06 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2865A21F8FF7 for ; Fri, 22 Mar 2013 17:10:04 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr12so899012wgb.11 for ; Fri, 22 Mar 2013 17:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=+hTMrxqVoCXLAkJiZDt2WJvIum9N5zTged2TFj0TC1o=; b=ni8hK1wjOdKBkEhcRk45agqXGuCsPLX7pCMPeMUj/gm7yMOg45+i4g5Vc2iG9a+Qvz +bU3fnKbqdKyj5t5wZVSo25zsae5VDZEU/6LyhKacsFCnMtT5tlVED3rac8kIG7MfLTT YIQgK5/FhkSOxdRUxTdKVs0IVOZ5DnXcWnEIsNZANvvrszy7ESFqEh29Vbe8A3W7EeVq xG5XlY8OLph/XTpQ68c2M8aK73k1y21Grm+N/Z/r/Yvsk7BXVwfQmrGUx/y6RUCoiprj basehTMATHPke3r/jKXtYOpH9rGw0vy1D0IiqhofEylaa1poGv+TLMunAU+FY1ePSw44 H1fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=+hTMrxqVoCXLAkJiZDt2WJvIum9N5zTged2TFj0TC1o=; b=EurcafBM2YZR1EPzmpSe4olii5fscIlpg8vbY3N3PpQPuH7qUJE/b63LwbP0+3wMWs MklbGUqrFvzHDKqAffAzxh2uA/9PiR/ugVqNDKs2uc1tt28cX8WmdkBaa8+agpL6EcwA IGp8IwoEGex31U6vHR0g+1kVLr5fbu+w0AiizxPG3L+XON3H0m0cSlXLl6rrzDHfjYyy p5eshVr2efANSkjuLW5zCaZaCF/9ioOrAS1+J9hDKPtAYjNAH2DB5Jv3qX3pylDyc1wA 4x2cTMIU3ygR3Sm2xATXNv0DL+/vzTtohuWb8kq86zu4UMrzjCcDD772gQhuYSF1QULM UxlA== X-Received: by 10.181.12.5 with SMTP id em5mr6020083wid.24.1363997404335; Fri, 22 Mar 2013 17:10:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.83.195 with HTTP; Fri, 22 Mar 2013 17:09:23 -0700 (PDT) In-Reply-To: References: From: Edward Crabbe Date: Fri, 22 Mar 2013 17:09:23 -0700 Message-ID: To: "i2rs@ietf.org" , "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=f46d043c7c58c2a86704d88c64bb X-Gm-Message-State: ALoCoQnywTIp4TWJ5xq3NJWsWzu0JwWwcqI7UIohCOe6wUxO6zUp1kzorzYstOZsFDmJCZs0wK6jSLjHsPiqBqWHuDbnV90dZmRWxkP/imp3U1HfAzk2X9wxv5u29wNcfLd+7N2sylH1DefdzdohjFg8FDYQFtP2DyhqnPPzfEC3/0AuYZo8XvVR8B0xoT8OMWs9Mp6PzAEW Subject: Re: [i2rs] Interim meeting poll X-BeenThere: i2rs@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: Sat, 23 Mar 2013 00:10:10 -0000 --f46d043c7c58c2a86704d88c64bb Content-Type: text/plain; charset=ISO-8859-1 So people seem to be leaning towards 4/22-23. Let's put a stake in the ground for those two dates, pending Adrian's approval. A more official announcement will be forthcoming. On Fri, Mar 22, 2013 at 12:49 PM, Edward Crabbe wrote: > > Hey all; > > Rather than attempt to track everyone's responses re: interim meeting > dates via email, I've set up a quick poll: > > http://doodle.com/hdpuqr7ffduf8nm8 > > Please fill out the dates you're available ASAP so we can hit the 4 week > announcement deadline. > > Thanks very much, > > -ed > --f46d043c7c58c2a86704d88c64bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So people seem to be leaning towards 4/22-23. =A0Let's= put a stake in the ground for those two dates, pending Adrian's approv= al. =A0A more official announcement will be forthcoming. =A0


On Fri, Mar 22, 2013 at 12:49 PM, Edward= Crabbe <edc@google.com> wrote:

Hey all;

Rather than attempt to track everyone&#= 39;s responses re: interim meeting dates via email, I've set up a quick= poll:


Please= fill out the dates you're available ASAP so we can hit the 4 week anno= uncement deadline.

Thanks= very much,

=A0 -= ed=A0

--f46d043c7c58c2a86704d88c64bb-- From russw@riw.us Sat Mar 23 07:32:57 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D790B21F88EA for ; Sat, 23 Mar 2013 07:32: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 LLELZdNTzI8B for ; Sat, 23 Mar 2013 07:32:57 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 350D421F88B9 for ; Sat, 23 Mar 2013 07:32:57 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=[192.168.100.52]) by da31.namelessnet.net with esmtpa (Exim 4.80) (envelope-from ) id 1UJPVA-0005f0-GY for i2rs@ietf.org; Sat, 23 Mar 2013 07:32:56 -0700 Message-ID: <514DBD23.6010501@riw.us> Date: Sat, 23 Mar 2013 10:33:07 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: i2rs@ietf.org References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5149B386.8020504@riw.us> In-Reply-To: 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: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Sat, 23 Mar 2013 14:32:57 -0000 > There are certainly (intentional) gaps that will have to be filled, but IMO the data model could serve as a basis for I2RS, too. Unless, of course, you think something is wrong with it, in which case I'd like to hear the details so that we can improve it. I do believe though that we should eventually work, as much as possible, with the same data models - after all, the underlying router will be the same for both NETCONF and I2RS. Well, what I would prefer is something that is smaller and lighter, and definite in what it touches, but leaves room for development in later iterations. In other words, I would probably prefer a bottom up approach, rather than a top down one. >> What's the point of the "recipient routing table," piece of this model >> (since we're talking about data, not an action)? > > Some implementations (Cisco IOS) use the concept of "redistributing" routes directly between routing protocol instances while others (JUNOS, BIRD routing daemon) let each protocol first put its routes into a routing table and then pass it form there to other protocols, routing tables or the forwarding table. I believe the latter approach is more general. Actually, no. Cisco IOS doesn't redistribute directly between routing instance, it only redistributes from the routing table into a protocol. I don't want to get into a lot of mechanics, but while the user interface implies direct redistribution, this simply isn't how it's done in the code. Redistribution is, in all the implementations I know of, effectively a filter the receiving protocol puts into the RIB/protocol interface to say, "when you get a new route matching these criteria (with the source protocol being a criteria), send the route information as well." I could be wrong about this -- I don't know every implementation as well as I should -- but I'm pretty sure this is how it's always coded. Even in the case of import/export, what happens is normal redistribution followed by an inter protocol callback to get the information the routing table doesn't have (to fill in metrics and the like). So... I think we can model all of these as a part of the policy between the RIB and each protocol -- we don't need a separate and special "channel." >> Why should "connected routes," and "static routes," be explicitly called >> out as different "types" of routing protocols? How are they special? > > It is not our invention, JUNOS and BIRD deal with direct and static routes in terms of routing (pseudo-)protocols. As for the "direct" pseudo-protocol, it requires no configuration and can actually appear only in the "source-protocol" attribute of routes. On the other hand, "static" instances have to be configured - their configuration inlcudes the list of static routes that will then appear in routing tables with source protocol set to "static". But if they're both just another flavor of a protocol, why not just call them a protocol with some special bits, rather than calling them a different "kind" of protocol process? That's one of the points, to me, of working from the bottom up -- don't make distinctions at the model level that can be made more simply by flipping some property bits at a lower level. >>> It means that the definion of route is not fixed but depends on the modules supported by the device. >> >> Which isn't going to work if you're actually trying to insert routes to >> a number of different devices across a diverse network... > > If the network is heterogeneous, it it IMO quite appropriate to make use of specific capabilities of each type of device. In NETCONF this can be easily done because each device starts the session with advertising its capabilities to the manager. Why this isn't going to work in I2RS? But it means we're back to square one --any off box process that wants to work with the local RIB on a wide variety of boxes must poke through the documentation (almost never complete, by intention) of each of those boxes, and build an internal data model that can be used for that individual box. This lays the problem of data modeling squarely on the shoulders of the application developer. I'd prefer a least common denominator set of things we know we need to build a RIB (not a forwarding table a RIB), from the start, and then build where we see more stuff we can do in the future. Start small and grow up, don't start big and try to fill out the details --IMHO. :-) Russ From lhotka@nic.cz Sat Mar 23 09:08:23 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAA321F8939 for ; Sat, 23 Mar 2013 09:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] 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 mI7xCN3oIvFe for ; Sat, 23 Mar 2013 09:08:22 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD7E21F8936 for ; Sat, 23 Mar 2013 09:08:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id ABFDE540196; Sat, 23 Mar 2013 17:08:15 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-YW+ialjOEl; Sat, 23 Mar 2013 17:08:10 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B9C26540087; Sat, 23 Mar 2013 17:08:04 +0100 (CET) From: Ladislav Lhotka To: Russ White , i2rs@ietf.org In-Reply-To: <514DBD23.6010501@riw.us> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5149B386.8020504@riw.us> <514DBD23.6010501@riw.us> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Sat, 23 Mar 2013 17:08:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Sat, 23 Mar 2013 16:08:23 -0000 Russ White writes: >> There are certainly (intentional) gaps that will have to be filled, but IMO the data model could serve as a basis for I2RS, too. Unless, of course, you think something is wrong with it, in which case I'd like to hear the details so that we can improve it. I do believe though that we should eventually work, as much as possible, with the same data models - after all, the underlying router will be the same for both NETCONF and I2RS. > > Well, what I would prefer is something that is smaller and lighter, and > definite in what it touches, but leaves room for development in later > iterations. In other words, I would probably prefer a bottom up > approach, rather than a top down one. The decision between top-down and bottom-up is always difficult, but in this case we hardly had any choice. One reason is technical: YANG is essentially designed for the top-down approach. One module defines the top-level skeleton and other modules can then fill in details via augmentation. Another reason is that the initial (core) YANG modules have been developed by the NETMOD WG, in order to break the chicken-and-egg problem. And we couldn't start with a very specialized stuff such as routing protocols, this should be left to experts in other WGs. Most of the complexity is a consequence of the stated objective that vendors should be able to map this data model to their proprietary models and/or CLI logic. > >>> What's the point of the "recipient routing table," piece of this model >>> (since we're talking about data, not an action)? >> >> Some implementations (Cisco IOS) use the concept of "redistributing" routes directly between routing protocol instances while others (JUNOS, BIRD routing daemon) let each protocol first put its routes into a routing table and then pass it form there to other protocols, routing tables or the forwarding table. I believe the latter approach is more general. > > Actually, no. Cisco IOS doesn't redistribute directly between routing > instance, it only redistributes from the routing table into a protocol. > I don't want to get into a lot of mechanics, but while the user > interface implies direct redistribution, this simply isn't how it's done > in the code. Either way, it can be represented using the data model. > > Redistribution is, in all the implementations I know of, effectively a > filter the receiving protocol puts into the RIB/protocol interface to > say, "when you get a new route matching these criteria (with the source > protocol being a criteria), send the route information as well." I could > be wrong about this -- I don't know every implementation as well as I > should -- but I'm pretty sure this is how it's always coded. An implementation is free to stick to just one routing table (per address family) and then it is exactly as you write: all protocol have no choice but to connect to this table and most of the complexity goes away. > > Even in the case of import/export, what happens is normal redistribution > followed by an inter protocol callback to get the information the > routing table doesn't have (to fill in metrics and the like). > > So... I think we can model all of these as a part of the policy between > the RIB and each protocol -- we don't need a separate and special > "channel." The data model allows for multiple routing tables per address family, because this is what some implementations support. As I said, you are free to limit yourself to a single RIB/routing table and then there is no such channel, and what remains are only import and export filters between the single RIB and each routing protocol. > >>> Why should "connected routes," and "static routes," be explicitly called >>> out as different "types" of routing protocols? How are they special? >> >> It is not our invention, JUNOS and BIRD deal with direct and static routes in terms of routing (pseudo-)protocols. As for the "direct" pseudo-protocol, it requires no configuration and can actually appear only in the "source-protocol" attribute of routes. On the other hand, "static" instances have to be configured - their configuration inlcudes the list of static routes that will then appear in routing tables with source protocol set to "static". > > But if they're both just another flavor of a protocol, why not just call > them a protocol with some special bits, rather than calling them a > different "kind" of protocol process? That's one of the points, to me, > of working from the bottom up -- don't make distinctions at the model > level that can be made more simply by flipping some property bits at a > lower level. I am not sure I understand what you mean but, as a matter of fact, the two pseudo-protocols are *not* modelled as a different kind of protocol. For instance, configurations of "static" and "bgp" protocol instances will be entries of the same "routing-protocol" list. > >>>> It means that the definion of route is not fixed but depends on the modules supported by the device. >>> >>> Which isn't going to work if you're actually trying to insert routes to >>> a number of different devices across a diverse network... >> >> If the network is heterogeneous, it it IMO quite appropriate to make use of specific capabilities of each type of device. In NETCONF this can be easily done because each device starts the session with advertising its capabilities to the manager. Why this isn't going to work in I2RS? > > But it means we're back to square one --any off box process that wants > to work with the local RIB on a wide variety of boxes must poke through > the documentation (almost never complete, by intention) of each of those > boxes, and build an internal data model that can be used for that > individual box. This lays the problem of data modeling squarely on the > shoulders of the application developer. If the off-box process uses NETCONF/YANG, it can learn the capabilities of each box from their hello packets, and then peruse the machine-readable representation of their data models. > > I'd prefer a least common denominator set of things we know we need to > build a RIB (not a forwarding table a RIB), from the start, and then > build where we see more stuff we can do in the future. Nothing prevents you from using the common denominator if it is sufficient. Cheers, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Sat Mar 23 14:16:36 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F239721F859D for ; Sat, 23 Mar 2013 14:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 blxrTmOiyEI1 for ; Sat, 23 Mar 2013 14:16:35 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 80BF521F857E for ; Sat, 23 Mar 2013 14:16:35 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id e14so4322566iej.16 for ; Sat, 23 Mar 2013 14:16:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=pRj7OYdWAZr/RnExr/WNBXGyh8pjG4wG6wSWlgWs5IM=; b=NnwnWGneYQLIQwMTLpyYK5pNYwp32yk+TJwJm3TSdYU9ijbngf/gq80CzJcv2jNkcS +filvLrxKVeUDpJWAgKioZMGfTDiXMvPiu3oYy+VQXLUJ14sRCIyzfPCvINwVFqUtZMc R7l9fgHxgUB6rBFXjfUFCu955Oa7lYWz3c+HA34Mm6D0tDFDgkeFRLnmxlzmoXR/a1hD jeQPvQdRwtnp2XXf5kEwyiTncimGvRvoN1f1+GdKYnYrlSAMxuUbuKJg+PK5g3f6jnF8 RLd9P4E23mKKiY6u1A+OF77fQPw0j1FEAFZAtFWhOcXoqiW9MYSMv3vCanr0lfLnOi+I 5SKA== MIME-Version: 1.0 X-Received: by 10.50.17.131 with SMTP id o3mr4346243igd.112.1364073394986; Sat, 23 Mar 2013 14:16:34 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Sat, 23 Mar 2013 14:16:34 -0700 (PDT) In-Reply-To: <514DBD23.6010501@riw.us> References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5149B386.8020504@riw.us> <514DBD23.6010501@riw.us> Date: Sat, 23 Mar 2013 14:16:34 -0700 Message-ID: From: Andy Bierman To: Russ White Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmDGZPQQp/RQby4eTYW8dE9B+F33G8Dx0lqSoXiOTFWIOcTX768QGwcotQBfsSoDf4r+3EZ Cc: i2rs@ietf.org Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Sat, 23 Mar 2013 21:16:36 -0000 On Sat, Mar 23, 2013 at 7:33 AM, Russ White wrote: > >..... > But it means we're back to square one --any off box process that wants > to work with the local RIB on a wide variety of boxes must poke through > the documentation (almost never complete, by intention) of each of those > boxes, and build an internal data model that can be used for that > individual box. This lays the problem of data modeling squarely on the > shoulders of the application developer. > > I'd prefer a least common denominator set of things we know we need to > build a RIB (not a forwarding table a RIB), from the start, and then > build where we see more stuff we can do in the future. > > Start small and grow up, don't start big and try to fill out the details > --IMHO. This is an important point. Do you want a framework that is filled in by vendors (and possibly SDOs) that may be different on each platform, or do you want a common API that provides basic functionality that all vendors must implement? Or both? It's too early to be reviewing YANG modules for I2RS but it would be good to know the direction the API is headed. > Russ Andy From akatlas@gmail.com Sat Mar 23 14:30:33 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586B821F8936 for ; Sat, 23 Mar 2013 14:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 gIepn4zVGRmV for ; Sat, 23 Mar 2013 14:30:32 -0700 (PDT) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A8B3E21F877A for ; Sat, 23 Mar 2013 14:30:32 -0700 (PDT) Received: by mail-ia0-f171.google.com with SMTP id z13so4558627iaz.30 for ; Sat, 23 Mar 2013 14:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=10eGOm0xY9zmm8YpG6GzPdsjaa9jQeXMW1fXW8pl/dI=; b=H+fIcgCqBqjROoMUkyFM2+FdfQK+Ktkd3ufHR7tAcF0CoMMHbs1/ZgnumHXKI1HfB+ pWYeLPmMzsqenLlKoLxCnYh3lJar4HMEyxJlZOoMobWc4tgDtsa05zgMb18cYsXHCRii +E5Qd5iTLWWcTRqD8kqI4lY5wR2Sr1IlxCjN1y2WgTFynGD/N0hIhhrZTQuPOlFIz7b5 iEdEDW2UYuAPgB9Utb0a1Zr8zj1HAiKVTmVp/0EmLMT9qy8RGVvWKY7AWaok6ctUiEAd jZdqGxlgVwKvUI5lEYcuvsOZ4LIGjSJ2IfmRkgGJoE8DjM0biiUm+qNYlpEpMhkyZy9P 1ftA== MIME-Version: 1.0 X-Received: by 10.50.17.166 with SMTP id p6mr7912443igd.12.1364074232306; Sat, 23 Mar 2013 14:30:32 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Sat, 23 Mar 2013 14:30:32 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Sat, 23 Mar 2013 14:30:32 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5149B386.8020504@riw.us> <514DBD23.6010501@riw.us> Date: Sat, 23 Mar 2013 17:30:32 -0400 Message-ID: From: Alia Atlas To: Andy Bierman Content-Type: multipart/alternative; boundary=14dae9340cc910652104d89e4802 Cc: Russ White , i2rs@ietf.org Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Sat, 23 Mar 2013 21:30:33 -0000 --14dae9340cc910652104d89e4802 Content-Type: text/plain; charset=ISO-8859-1 On Mar 23, 2013 10:16 PM, "Andy Bierman" wrote: > > On Sat, Mar 23, 2013 at 7:33 AM, Russ White wrote: > > > >..... > > But it means we're back to square one --any off box process that wants > > to work with the local RIB on a wide variety of boxes must poke through > > the documentation (almost never complete, by intention) of each of those > > boxes, and build an internal data model that can be used for that > > individual box. This lays the problem of data modeling squarely on the > > shoulders of the application developer. > > > > I'd prefer a least common denominator set of things we know we need to > > build a RIB (not a forwarding table a RIB), from the start, and then > > build where we see more stuff we can do in the future. > > > > Start small and grow up, don't start big and try to fill out the details > > --IMHO. > > > This is an important point. > Do you want a framework that is filled in by vendors > (and possibly SDOs) that may be different on each platform, > or do you want a common API that provides basic functionality > that all vendors must implement? Or both? [Alia] A common API that provides basic functionality that all vendors must implement. Having it extensible for different features is desirable. > > It's too early to be reviewing YANG modules for I2RS > but it would be good to know the direction the API is headed. [Alia] Absolutely too early, but not for information models. > > > Russ > > Andy > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --14dae9340cc910652104d89e4802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 23, 2013 10:16 PM, "Andy Bierman" <andy@yumaworks.com> wrote:
>
> On Sat, Mar 23, 2013 at 7:33 AM, Russ White <russw@riw.us> wrote:
> >
> >.....
> > But it means we're back to square one --any off box process t= hat wants
> > to work with the local RIB on a wide variety of boxes must poke t= hrough
> > the documentation (almost never complete, by intention) of each o= f those
> > boxes, and build an internal data model that can be used for that=
> > individual box. This lays the problem of data modeling squarely o= n the
> > shoulders of the application developer.
> >
> > I'd prefer a least common denominator set of things we know w= e need to
> > build a RIB (not a forwarding table a RIB), from the start, and t= hen
> > build where we see more stuff we can do in the future.
> >
> > Start small and grow up, don't start big and try to fill out = the details
> > --IMHO.
>
>
> This is an important point.
> Do you want a framework that is filled in by vendors
> (and possibly SDOs) that may be different on each platform,
> or do you want a common API that provides basic functionality
> that all vendors must implement? Or both?

[Alia] A common API that provides basic functionality that a= ll vendors must implement.=A0=A0 Having it extensible for different feature= s is desirable.

>
> It's too early to be reviewing YANG modules for I2RS
> but it would be good to know the direction the API is headed.

[Alia]=A0 Absolutely too early, but not for information mode= ls.

>
> > Russ
>
> Andy
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.iet= f.org/mailman/listinfo/i2rs

--14dae9340cc910652104d89e4802-- From rraszuk@gmail.com Sat Mar 23 14:49:03 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59E421F8936 for ; Sat, 23 Mar 2013 14:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 XCVtg9H45Z0b for ; Sat, 23 Mar 2013 14:49:03 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C46D621F86C9 for ; Sat, 23 Mar 2013 14:49:02 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id fe20so9354581lab.15 for ; Sat, 23 Mar 2013 14:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JiAFwz0GPYyD83ec6irzKrvzeuU85q2PV++WltXXaOM=; b=XrBjlH+RRm8isF4mYf/jlRJiYzLcLLiWnGeJBn9z0+QzaOB3gVw0qRsMAWMS/5kqIR azTWo3DCF8dipEX16BmnKL1RuDNrlf25IgKHg4yWoguXKtsjZUaP7HBMbgf3HWuts8Yw 20QphcMLZxqAbncWyYFyHrz1JscV8WNaHX/nOTj21HgYueu/+nvnOQ1sr6i96Xv4Erub SvugGasxXraai5wJ2E68ZtFd8lAa+pvRECuqTgU7yW3vzW1MLFjIAOjiaehZN+elpzJk uBM9A81Vc8luBfb9zAfXTJuyW5fhBpd8y6NfB87ZAqn+Ck440u64RbY1L59Z+FS1Woh4 WAPQ== MIME-Version: 1.0 X-Received: by 10.152.145.134 with SMTP id su6mr3315379lab.35.1364075341521; Sat, 23 Mar 2013 14:49:01 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.112.29.199 with HTTP; Sat, 23 Mar 2013 14:49:01 -0700 (PDT) In-Reply-To: References: <5141DF65.6000508@google.com> <5141E18A.5010909@google.com> <5149B386.8020504@riw.us> <514DBD23.6010501@riw.us> Date: Sat, 23 Mar 2013 22:49:01 +0100 X-Google-Sender-Auth: extewdRwkjgaTAMX_tuBFv5Sln0 Message-ID: From: Robert Raszuk To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: Russ White , i2rs@ietf.org Subject: Re: [i2rs] RIB definition ... X-BeenThere: i2rs@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: Sat, 23 Mar 2013 21:49:03 -0000 Hi Andy, >> Start small and grow up, don't start big and try to fill out the details >> --IMHO. > > This is an important point. > Do you want a framework that is filled in by vendors > (and possibly SDOs) that may be different on each platform, > or do you want a common API that provides basic functionality > that all vendors must implement? Or both? FWIW it seems neither to me. If I2RS interface is to become significant in the industry it must support most common applications which are required by actual operators - both for WAN, MAN, LAN, access and DCs. If it will lack basic primitives which folks expect it to have I am afraid it's use will be limited to bits and pieces demos at various conferences and NOGs which I think is not what I2RG WG is aiming for. So the approach to go by use cases seems wise provided all interested parties will or can submit their use cases. Especially "can" is important here as number of operators are at the design or development phase of number of new services which are competitive and can not be shared in public. With that one could observe that OF does offer much lower level of interface to data plane and could be used or worked on without exposing your future services. That's why I have started this thread asking for RIB interface definition to be able to sense if what is currently on the table has potential of being useful for projects I am involved with or not. Best, R. From deepanshu.gautam@huawei.com Sun Mar 24 19:32:39 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E2321F8AA6 for ; Sun, 24 Mar 2013 19:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gtWZeGqA8A7Q for ; Sun, 24 Mar 2013 19:32:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D942721F8AC8 for ; Sun, 24 Mar 2013 19:32:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APT20051; Mon, 25 Mar 2013 02:32:36 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Mar 2013 02:32:27 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Mar 2013 02:32:31 +0000 Received: from NKGEML501-MBX.china.huawei.com ([169.254.1.19]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Mon, 25 Mar 2013 10:32:27 +0800 From: Deepanshu Gautam To: Alia Atlas , "Joel M. Halpern" Thread-Topic: [i2rs] Interim meeting Thread-Index: Ac4m9VuLX4TrFDPxSvK9ThSBXgqyxf//fHUAgAAD3ICAACnygIAACLAA//ub85A= Date: Mon, 25 Mar 2013 02:32:26 +0000 Message-ID: References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> <514C714D.3020504@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.138.73.28] Content-Type: multipart/alternative; boundary="_000_DA22857AC9F15C469BB47FE88C02012963279FCFnkgeml501mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 25 Mar 2013 02:32:39 -0000 --_000_DA22857AC9F15C469BB47FE88C02012963279FCFnkgeml501mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would prefer 19-20, I light of clash with NFV#2 Regards Deepanshu Gautam Senior Engineer, Service Standards, Huawei O: +86 25 56620008 M: +8613585147627 From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Ali= a Atlas Sent: Friday, March 22, 2013 11:28 PM To: Joel M. Halpern Cc: i2rs@ietf.org Subject: Re: [i2rs] Interim meeting Yes, the ONF workday finishes at 1:30pm on Friday. I'm getting the sense = that April 22/23 works better for most people, with a slight concern for ov= erlapping NFV#2. Alia On Mar 22, 2013 3:57 PM, "Joel M. Halpern" > wrote: Note: The ONF Member work day is actually two days, April 18th and 19th. Thus, having the meeting on the 19th would actually collide with the ONF wo= rk session. That does not seem to me to be a good dea. Yours, Joel On 3/22/2013 8:27 AM, Alia Atlas wrote: I am specifically trying to determine if there is strong interest in the Friday April 19 & April 20 vs. April 22-23. Alia On Mar 22, 2013 1:13 PM, "Robert Raszuk" >> wrote: > April 22/23 @ Bay Area Perfect location and timing ! +1. Thx, Robert. > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas >> wrote: > > Ed and I would like to have an interim meeting in mid-April in the Mountain > View/Sunnyvale, CA area. We are trying to time it for around the Ope= n > Networking Summit, but not conflicting with that or the ONF workdays= . > > We need to announce it 4 weeks in advance. Unless, we announce today for > the afternoon/evening of April 19 (or into April 20), we are looking at > April 22/23. Opinions ASAP from those who would attend would be quite > useful. > > In particular, is this a good time/place? > > We want the interim to focus on the use-cases & functionality for i2rs. I > expect that we'll ask attendees to pick a set of use-cases to be in = a > design-group before & during the meeting to discuss & then present to the > larger group. More details to follow soon. > > Regards, > Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_DA22857AC9F15C469BB47FE88C02012963279FCFnkgeml501mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would prefer 19-20, I l= ight of clash with NFV#2

 <= /p>

Regards=

 <= /p>

Deepanshu Gautam

Senior Engineer, Service S= tandards, Huawei

O: +86 25 56620008 M: = +8613585147627

 <= /p>

From: i2rs-bou= nces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Friday, March 22, 2013 11:28 PM
To: Joel M. Halpern
Cc: i2rs@ietf.org
Subject: Re: [i2rs] Interim meeting

 

Yes, the ONF workday finishes at 1:30pm on Friday.   I'm getti= ng the sense that April 22/23 works better for most people, with a slight c= oncern for overlapping NFV#2.

Alia

On Mar 22, 2013 3:57 PM, "Joel M. Halpern"= <jmh@joelhalpern.com> wro= te:

Note: The ONF Member work day is actually two days, = April 18th and 19th.
Thus, having the meeting on the 19th would actually collide with the ONF wo= rk session.  That does not seem to me to be a good dea.

Yours,
Joel

On 3/22/2013 8:27 AM, Alia Atlas wrote:

I am specifically try= ing to determine if there is strong interest in the
Friday April 19 & April 20 vs. April 22-23.

Alia

On Mar 22, 2013 1:13 PM, "Robert Raszuk" <robert@raszuk.net
<mailto:robert@ra= szuk.net>> wrote:

     > April 22/23 @ Bay Area

    Perfect location and timing !  +1.

    Thx,
    Robert.


     > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas <akatlas@juniper.net<= /a>
    <mailto:akatlas@juniper.net>> wrote:
     >
     > Ed and I would like to have an interim meeting in = mid-April in
    the Mountain
     > View/Sunnyvale, CA area. We are trying to time it = for around the Open
     > Networking Summit, but not conflicting with that o= r the ONF workdays.
     >
     > We need to announce it 4 weeks in advance.  U= nless, we announce
    today for
     > the afternoon/evening of April 19 (or into April 2= 0), we are
    looking at
     > April 22/23.  Opinions ASAP from those who wo= uld attend would be
    quite
     > useful.
     >
     > In particular, is this a good time/place?
     >
     > We want the interim to focus on the use-cases &= ; functionality for
    i2rs.   I
     > expect that we'll ask attendees to pick a set of u= se-cases to be in a
     > design-group before & during the meeting to di= scuss & then
    present to the
     > larger group.  More details to follow soon.      >
     > Regards,
     > Alia
     >
     > _______________________________________________      > i2rs mailing list
     > i2rs@ietf.org <mailto:i2rs@ietf.org>
     > https://www.ietf.org/mailman/listinfo/i2rs
     >
    _______________________________________________
    i2rs mailing list
    i2rs@ietf.= org <mailto:i2rs@= ietf.org>
    https://www.ietf.org/mailman/listinfo/i2rs



_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--_000_DA22857AC9F15C469BB47FE88C02012963279FCFnkgeml501mbxchi_-- From iesg-secretary@ietf.org Mon Mar 25 05:30:51 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB0821F8E74; Mon, 25 Mar 2013 05:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.091 X-Spam-Level: X-Spam-Status: No, score=-101.091 tagged_above=-999 required=5 tests=[AWL=1.509, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 n9s+nU9sTpT6; Mon, 25 Mar 2013 05:30:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B6E21F8E66; Mon, 25 Mar 2013 05:30:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130325123050.21399.94426.idtracker@ietfa.amsl.com> Date: Mon, 25 Mar 2013 05:30:50 -0700 Cc: i2rs@ietf.org Subject: [i2rs] I2RS Working Group Interim Meeting April 22-23, 2013 X-BeenThere: i2rs@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, 25 Mar 2013 12:30:51 -0000 I2RS WG Interim Details = Dates/Times: 22-23 April 2013 (9:00 am - 5:00 pm PDT) = Location: Mountainview or Sunnyvale, California (hosted by Google or Junipe= r) = Registration: For planning purposes only. = Remote Participation: via Webex Please see the I2RS mailing list for further details and agenda. From lucy.yong@huawei.com Mon Mar 25 08:57:54 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7324521F8D23 for ; Mon, 25 Mar 2013 08:57:54 -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 eXINegc7cRNk for ; Mon, 25 Mar 2013 08:57:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A816D21F8D29 for ; Mon, 25 Mar 2013 08:57:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APT81594; Mon, 25 Mar 2013 15:57:50 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Mar 2013 15:57:37 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Mar 2013 23:57:45 +0800 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.122]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Mon, 25 Mar 2013 08:57:38 -0700 From: Lucy yong To: "'Edward Crabbe'" , Alia Atlas Thread-Topic: [i2rs] I2RS Working Group Interim Meeting April 22-23, 2013 Thread-Index: AQHOKVScDMPoTXr06kq33wfIxyIdP5i2j+YA Date: Mon, 25 Mar 2013 15:57:37 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4523D127@dfweml509-mbx.china.huawei.com> References: <20130325123050.21399.94426.idtracker@ietfa.amsl.com> In-Reply-To: <20130325123050.21399.94426.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "i2rs@ietf.org" Subject: Re: [i2rs] I2RS Working Group Interim Meeting April 22-23, 2013 X-BeenThere: i2rs@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, 25 Mar 2013 15:57:54 -0000 Do you provide the facility for remote participating? Lucy > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of > IESG Secretary > Sent: Monday, March 25, 2013 7:31 AM > To: IETF Announcement List > Cc: i2rs@ietf.org > Subject: [i2rs] I2RS Working Group Interim Meeting April 22-23, 2013 >=20 >=20 > I2RS WG Interim Details >=20 > Dates/Times: 22-23 April 2013 (9:00 am - 5:00 pm PDT) >=20 > Location: Mountainview or Sunnyvale, California (hosted by Google or > Juniper) >=20 > Registration: For planning purposes only. >=20 > Remote Participation: via Webex >=20 > Please see the I2RS mailing list for further details and agenda. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From yihuan@cisco.com Mon Mar 25 09:29:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FA111E80D1 for ; Mon, 25 Mar 2013 09:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 3p4J48j3n87Y for ; Mon, 25 Mar 2013 09:29:05 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 402B721F8C9A for ; Mon, 25 Mar 2013 09:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1103; q=dns/txt; s=iport; t=1364228945; x=1365438545; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=4H8EVZBNk63E8UN4pnI6qb7/j1E3c7l6ec8Wh11yr4U=; b=JmNnFQnAqmcNVoHAx1AYPIHb8+ja3kVuVN8+WFViqfdQmdqEuQ7Y5QCl 5BUjqYvcxAVfcjlAZeX3dzK4ZCcPs4s5mWBPSdjgkGIV+zAdDpWJUHavX nwehIpT1FmacT8b80nFuZsVOwDMP09i+ripv++8hOQCNMO5k2ydCWkjUU 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACR6UFGtJXG8/2dsb2JhbABDxWaCBRZ0giQBAQEEAQEBNzQLDAYBCBEEAQELFAkuCxQJCAIEAQ0FCIgMDMMCBI5nJgsHBoJZYQOna4MKgig X-IronPort-AV: E=Sophos;i="4.84,905,1355097600"; d="scan'208";a="191218817" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 25 Mar 2013 16:29:05 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2PGT4xD004086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Mar 2013 16:29:04 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 25 Mar 2013 11:29:04 -0500 From: "Lisa Huang (yihuan)" To: Lucy yong , "'Edward Crabbe'" , "Alia Atlas" Thread-Topic: [i2rs] I2RS Working Group Interim Meeting April 22-23, 2013 Thread-Index: AQHOKVSl0FiNMKqBmEqO4IWdDQpF75i25BmA//+TbgA= Date: Mon, 25 Mar 2013 16:29:03 +0000 Message-ID: <559E176269AD64429F1582D4EB94F86FCD9357@xmb-aln-x03.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4523D127@dfweml509-mbx.china.huawei.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 x-originating-ip: [10.154.213.167] Content-Type: text/plain; charset="us-ascii" Content-ID: <0804C1014CD4324AA93C09BBDCDB6B75@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] I2RS Working Group Interim Meeting April 22-23, 2013 X-BeenThere: i2rs@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, 25 Mar 2013 16:29:05 -0000 Remote Participation: via Webex On 3/25/13 8:57 AM, "Lucy yong" wrote: >Do you provide the facility for remote participating? >Lucy > >> -----Original Message----- >> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of >> IESG Secretary >> Sent: Monday, March 25, 2013 7:31 AM >> To: IETF Announcement List >> Cc: i2rs@ietf.org >> Subject: [i2rs] I2RS Working Group Interim Meeting April 22-23, 2013 >>=20 >>=20 >> I2RS WG Interim Details >>=20 >> Dates/Times: 22-23 April 2013 (9:00 am - 5:00 pm PDT) >>=20 >> Location: Mountainview or Sunnyvale, California (hosted by Google or >> Juniper) >>=20 >> Registration: For planning purposes only. >>=20 >> Remote Participation: via Webex >>=20 >> Please see the I2RS mailing list for further details and agenda. >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs From akatlas@gmail.com Tue Mar 26 05:37:42 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3429B21F8A41 for ; Tue, 26 Mar 2013 05:37:42 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 nEy2SXoMtNnr for ; Tue, 26 Mar 2013 05:37:41 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 50ABB21F8A55 for ; Tue, 26 Mar 2013 05:37:38 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id x14so8558307ief.7 for ; Tue, 26 Mar 2013 05:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dVuMPs9o4KnefuwlMEElsDMk6FgdrOqBLbgX7ZGgY0c=; b=yeJSAwzCpTGbf2tjo5IePCkIUjKKhVG9cScaNKQ0crvAlfNZAtmShVP+KWWUB5bpBh vtEKyEjCQO5OfCFpCNSeUW8x85pTNK14xjWNZ0gjZmvdAkw7TPFUTGpVEHfgL/Z+nSTB Bix97YLwrQN3X/k95WnWbt0hlNzxX9QsctodXAlYQ5MmlnO1dCtHhz1buma9A1SL9Pzv M2shalfhzp4cj1y86W/ie6JIg3Xxas2LmsKiO0DYLx3up8ThBUYr5e62ZfSDwmA/xgQ8 0ktlCcjRF0phdhjUhKjdLuzNAkEON0h0IxF8tKHW6rzJE6K2yRC4UZwA8SGF7/UJkptD Znyg== MIME-Version: 1.0 X-Received: by 10.50.47.168 with SMTP id e8mr1266240ign.50.1364301457889; Tue, 26 Mar 2013 05:37:37 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Tue, 26 Mar 2013 05:37:37 -0700 (PDT) Received: by 10.64.44.169 with HTTP; Tue, 26 Mar 2013 05:37:37 -0700 (PDT) In-Reply-To: References: <7g6u39a4hv4a61c1ivkgnlja.1363953476769@email.android.com> <514C714D.3020504@joelhalpern.com> Date: Tue, 26 Mar 2013 08:37:37 -0400 Message-ID: From: Alia Atlas To: Deepanshu Gautam Content-Type: multipart/alternative; boundary=14dae9340ab1c3a1aa04d8d32fe3 Cc: i2rs@ietf.org, "Joel M. Halpern" Subject: Re: [i2rs] Interim meeting X-BeenThere: i2rs@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, 26 Mar 2013 12:37:42 -0000 --14dae9340ab1c3a1aa04d8d32fe3 Content-Type: text/plain; charset=ISO-8859-1 We can't do the 19/20th now - we need 4 weeks for the announcement and the consensus favored April 22/23. Alia I would prefer 19-20, I light of clash with NFV#2**** ** ** Regards**** ** ** *Deepanshu Gautam* Senior Engineer, Service Standards, Huawei**** O: +86 25 56620008 M: +8613585147627**** ** ** *From:* i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Alia Atlas *Sent:* Friday, March 22, 2013 11:28 PM *To:* Joel M. Halpern *Cc:* i2rs@ietf.org *Subject:* Re: [i2rs] Interim meeting**** ** ** Yes, the ONF workday finishes at 1:30pm on Friday. I'm getting the sense that April 22/23 works better for most people, with a slight concern for overlapping NFV#2.**** Alia**** On Mar 22, 2013 3:57 PM, "Joel M. Halpern" wrote:**** Note: The ONF Member work day is actually two days, April 18th and 19th. Thus, having the meeting on the 19th would actually collide with the ONF work session. That does not seem to me to be a good dea. Yours, Joel On 3/22/2013 8:27 AM, Alia Atlas wrote:**** I am specifically trying to determine if there is strong interest in the Friday April 19 & April 20 vs. April 22-23. Alia On Mar 22, 2013 1:13 PM, "Robert Raszuk" > wrote: > April 22/23 @ Bay Area Perfect location and timing ! +1. Thx, Robert. > On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas > wrote: > > Ed and I would like to have an interim meeting in mid-April in the Mountain > View/Sunnyvale, CA area. We are trying to time it for around the Open > Networking Summit, but not conflicting with that or the ONF workdays. > > We need to announce it 4 weeks in advance. Unless, we announce today for > the afternoon/evening of April 19 (or into April 20), we are looking at > April 22/23. Opinions ASAP from those who would attend would be quite > useful. > > In particular, is this a good time/place? > > We want the interim to focus on the use-cases & functionality for i2rs. I > expect that we'll ask attendees to pick a set of use-cases to be in a > design-group before & during the meeting to discuss & then present to the > larger group. More details to follow soon. > > Regards, > Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs**** --14dae9340ab1c3a1aa04d8d32fe3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

We can't do the 19/20th now - we need 4 weeks for the an= nouncement and the consensus favored April 22/23.

Alia

I would prefer 19-20, I l= ight of clash with NFV#2

=A0<= /p>

Regards

=A0<= /p>

Deepanshu Gautam=

Senior Engineer, Service S= tandards, Huawei

O: +86 25 56620008 M: +8613585147627

=A0<= /p>

From: i2rs-bounces@ietf.org [mailto:i2rs-= bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Friday, March 22, 2013 11:28 PM
To: Joel M. Halpern
Cc: i2rs@ietf.org=
Subject: Re: [i2rs] Interim meeting

=A0

Yes, the ONF workday finishes at 1:30pm on Friday.=A0=A0 I'm getting= the sense that April 22/23 works better for most people, with a slight con= cern for overlapping NFV#2.

Alia

On Mar 22, 2013 3:57 PM, "Joel M. Halpern"= <jmh@joelhalpe= rn.com> wrote:

Note: The ONF Member work day is actually two days, = April 18th and 19th.
Thus, having the meeting on the 19th would actually collide with the ONF wo= rk session. =A0That does not seem to me to be a good dea.

Yours,
Joel

On 3/22/2013 8:27 AM, Alia Atlas wrote:

I am specifically try= ing to determine if there is strong interest in the
Friday April 19 & April 20 vs. April 22-23.

Alia

On Mar 22, 2013 1:13 PM, "Robert Raszuk" <robert@raszuk.net
<mailto:robert@ra= szuk.net>> wrote:

=A0 =A0 =A0> April 22/23 @ Bay Area

=A0 =A0 Perfect location and timing ! =A0+1.

=A0 =A0 Thx,
=A0 =A0 Robert.


=A0 =A0 =A0> On Fri, Mar 22, 2013 at 1:04 PM, Alia Atlas <akatlas@juniper.net
=A0 =A0 <mailto:akatlas@juniper.net>> wrote:
=A0 =A0 =A0>
=A0 =A0 =A0> Ed and I would like to have an interim meeting in mid-April= in
=A0 =A0 the Mountain
=A0 =A0 =A0> View/Sunnyvale, CA area. We are trying to time it for aroun= d the Open
=A0 =A0 =A0> Networking Summit, but not conflicting with that or the ONF= workdays.
=A0 =A0 =A0>
=A0 =A0 =A0> We need to announce it 4 weeks in advance. =A0Unless, we an= nounce
=A0 =A0 today for
=A0 =A0 =A0> the afternoon/evening of April 19 (or into April 20), we ar= e
=A0 =A0 looking at
=A0 =A0 =A0> April 22/23. =A0Opinions ASAP from those who would attend w= ould be
=A0 =A0 quite
=A0 =A0 =A0> useful.
=A0 =A0 =A0>
=A0 =A0 =A0> In particular, is this a good time/place?
=A0 =A0 =A0>
=A0 =A0 =A0> We want the interim to focus on the use-cases & functio= nality for
=A0 =A0 i2rs. =A0 I
=A0 =A0 =A0> expect that we'll ask attendees to pick a set of use-ca= ses to be in a
=A0 =A0 =A0> design-group before & during the meeting to discuss &am= p; then
=A0 =A0 present to the
=A0 =A0 =A0> larger group. =A0More details to follow soon.
=A0 =A0 =A0>
=A0 =A0 =A0> Regards,
=A0 =A0 =A0> Alia
=A0 =A0 =A0>
=A0 =A0 =A0> _______________________________________________
=A0 =A0 =A0> i2rs mailing list
=A0 =A0 =A0> i2rs@iet= f.org <mailto:i2r= s@ietf.org>
=A0 =A0 =A0> https://www.ietf.org/mailman/listinfo/i2rs
=A0 =A0 =A0>
=A0 =A0 _______________________________________________
=A0 =A0 i2rs mailing list
=A0 =A0 i2rs@ietf.org <mailto:i2rs@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/listinfo/i2rs



_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--14dae9340ab1c3a1aa04d8d32fe3-- From edc@google.com Fri Mar 29 13:53:20 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D77821F8F20 for ; Fri, 29 Mar 2013 13:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 sr32d8NV5TlR for ; Fri, 29 Mar 2013 13:53:19 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id AE73621F8F1A for ; Fri, 29 Mar 2013 13:53:15 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so702648wgg.0 for ; Fri, 29 Mar 2013 13:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=yO01kTDkd/Kr7fP8Fw/3fIatpcIGsID27tDi3Xs+n9s=; b=Dxfhi8cSQ3VNWA/LD6gf0JGBtlaDNMHsUIarZ2YQeDpGxzb3XipDXHdW1dC0Oa4byF EsCk8gABz+tKHQluFIgs4sBmLXNFd7uXTPHAxIeV9KsoEXE6ZB0YcQqxKYq7empELVAo L0mLGHuB2VXh4AoP10b2P3rK8QYMxh8pUQVHxSDXnmkZZTDfVckTEeVP+7y/0o0SQ6Gs ZFjGaUB9RoSEa1XqgekCC1+KE18RjCVNCVxdmwmykFkcfu6i4QmJZD3+kb7CnpSGO4i8 0kmYGAvmBQDnKdSl1DVAtDj5PqZoTIQlNth9yoPfOMElhvNkEWcb7IvuLi42ilW3o6g9 dOkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=yO01kTDkd/Kr7fP8Fw/3fIatpcIGsID27tDi3Xs+n9s=; b=Ypbm87tjGfd3yoaetBWj/S508vToDX713ioBPAltuV3sehk4X+pLyBegkhJVca21IT CwWhNEyfP5ixHq7m+PU2JtxteONukaMOmpdQPAz01gzmQhJVwnVr7Qy+QbqdfghRFVBy Tg2tYglMcb26sTfb/jvfVL0FbhkoFxtw0m3JxTUGN2mFxv+yo1U1zLmObBzIXytvivG1 6MZJ4G/RZkt7zvgwL/plmYqtnXaSW34VnCysNMYlnPcuLVojgsNfmbmjdApx4hT6zp08 E+o/ir88Yr9uA9QTrJ33eFUAu6yyfHAB9g1NCjHPDXwgHvN+ipGG/sBjimlx2znkyq+m /U+w== X-Received: by 10.194.120.169 with SMTP id ld9mr5511405wjb.24.1364590394899; Fri, 29 Mar 2013 13:53:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.44.195 with HTTP; Fri, 29 Mar 2013 13:52:34 -0700 (PDT) From: Edward Crabbe Date: Fri, 29 Mar 2013 13:52:34 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f642c14c098ce04d9167508 X-Gm-Message-State: ALoCoQnfK2KkYwREJllm+YM6m1mkzkG2EwYYWlbZNQ6WZN6qXLelRR6636C8sB4VmOgu6j+vTu3+SU0WmuMTmv0RbJg+Q+iFSqMLdgY6hVJHDe23PaHZNW4OqsBnryN3mzyjB6Y43eB2Oz+Rd5/DToN8RaQQHBt8eT9dWsRkS8TVSQL+x3QwJwlbOLGrmWzt3crq62Z152xa Subject: [i2rs] Registration for I2RS Interim Meeting X-BeenThere: i2rs@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, 29 Mar 2013 20:53:20 -0000 --e89a8f642c14c098ce04d9167508 Content-Type: text/plain; charset=ISO-8859-1 Hey all; We've put up a registration page for the I2RS interim meeting at: http://i2rs-interim.eventbrite.com You must register in order to be able to attend. The cut off date for registration will be on 4/17. Cheers all, and hope to see you there ^_^ best, -Ed and Alia --e89a8f642c14c098ce04d9167508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey all;

We've put up a regis= tration page for the I2RS interim meeting at:

http://i= 2rs-interim.eventbrite.com

You must register in order to be able= to attend. =A0The cut off date for registration will be on 4/17.

Cheers all, and hope to see you there ^_^

best,
=A0 =A0-Ed and Alia
--e89a8f642c14c098ce04d9167508--