From jmh@joelhalpern.com Thu Nov 1 07:21:40 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C6421F8D9B; Thu, 1 Nov 2012 07:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRl-HTaPKb1W; Thu, 1 Nov 2012 07:21:40 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 20E7D21F8D99; Thu, 1 Nov 2012 07:21:40 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 83B0C558099; Thu, 1 Nov 2012 07:21:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 7FE491BD124B; Thu, 1 Nov 2012 07:21:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-6.clppva.btas.verizon.net [71.161.52.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id D29811BD1245; Thu, 1 Nov 2012 07:21:37 -0700 (PDT) Message-ID: <5092856B.6070502@joelhalpern.com> Date: Thu, 01 Nov 2012 10:21:31 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "karp@ietf.org" , "lisp@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Fwd: Re: [85all] NomCom: Office Hours in Atlanta X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:21:40 -0000 Correction to the deadline for feedback. Yours, Joel -------- Original Message -------- Subject: Re: [85all] NomCom: Office Hours in Atlanta Date: Thu, 1 Nov 2012 08:22:48 -0400 From: Matthew Lepinski To: 85all@ietf.org I apologize for a minor error in the message below. In order to ensure that your input is useful to the NomCom, please send us your feedback on or before Sunday, November 11. (i.e., NOT November 4 as incorrectly indicated in the email below) - Matt Lepinski nomcom-chair@ietf.org On Wed, Oct 31, 2012 at 11:09 PM, Matthew Lepinski wrote: > The IETF Nominations Committee (NomCom) continues to seek input from > the IETF Community. > > The final list of candidates (as per RFC 5680) that the NomCom is > considering for open positions can be found at: > https://www.ietf.org/group/nomcom/2012/input/ > > The NomCom will be holding office hours during IETF 85, Monday- > Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes > comments on specific individuals, as well as general feedback related to > any of the positions that NomCom is considering. > > Note: A list of leadership positions that the NomCom is considering can be > found at: https://www.ietf.org/group/nomcom/2012/ > > If the NomCom office hours are inconvenient for you or if you cannot > attend IETF 85, the NomCom is happy to take community input via email > to nomcom12@ietf.org. Additionally, the NomCom is happy to arrange a > meeting outside of office hours, just send us email and we can set > something up. > > Comments on specific candidates can also be provided to the NomCom > via the web feedback tool: > https://www.ietf.org/group/nomcom/2012/input/ > > In order to ensure that your input is received in time to be useful, please > provide your input on or before Sunday, November 4. > > Thank you for your help, > - Matt Lepinski > nomcom-chair@ietf.org _______________________________________________ 85all mailing list 85all@ietf.org https://www.ietf.org/mailman/listinfo/85all From cheng.li2@zte.com.cn Thu Nov 1 17:50:17 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0339321F987E for ; Thu, 1 Nov 2012 17:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 yZlAwWw52xfs for ; Thu, 1 Nov 2012 17:50:13 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id AD83D21F9871 for ; Thu, 1 Nov 2012 17:50:12 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id D7B971259346; Fri, 2 Nov 2012 08:51:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qA20o28d000639; Fri, 2 Nov 2012 08:50:02 +0800 (GMT-8) (envelope-from cheng.li2@zte.com.cn) To: jnc@mercury.lcs.mit.edu MIME-Version: 1.0 X-KeepSent: CB818DA0:A63A4D7B-48257AAA:0002FF0B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: cheng.li2@zte.com.cn Date: Fri, 2 Nov 2012 08:49:49 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-02 08:49:43, Serialize complete at 2012-11-02 08:49:43 Content-Type: multipart/alternative; boundary="=_alternative 0004A98D48257AAA_=" X-MAIL: mse01.zte.com.cn qA20o28d000639 Cc: lisp@ietf.org Subject: [lisp] LISP-NAT Deployment - draft-ietf-lisp-introduction-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 00:50:17 -0000 This is a multipart message in MIME format. --=_alternative 0004A98D48257AAA_= Content-Type: text/plain; charset="US-ASCII" Hi Noel, I have a question about LISP-NAT Deployment specified in " draft-ietf-lisp-introduction-00". In the third paragraph of Section 10.5.1, you mentioned "in addition, since LISP expects all incoming data traffic to be on a specific port, it was not possible to have multiple ETRs behind a single NAT (which normally would have only one global address to share, meaning port mapping would have to be used, except that... )" Is something missing here? Certainly there maybe scenarios such like two or more LISP MN connect behind the same NAT, i.e. two or more ETRs behind a single NAT. Best Regards Li Cheng-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 0004A98D48257AAA_= Content-Type: text/html; charset="US-ASCII"
Hi Noel,

  I have a question about LISP-NAT Deployment specified in "draft-ietf-lisp-introduction-00".

  In the third paragraph of Section 10.5.1, you mentioned

     "in addition, since LISP expects all incoming data
     traffic to be on a specific port, it was not possible to have
     multiple ETRs behind a single NAT (which normally would have only one
     global address to share, meaning port mapping would have to be used,
     except that... )"

  Is something missing here?

  Certainly there maybe scenarios such like two or more LISP MN connect behind the same NAT,
  i.e. two or more ETRs behind a single NAT.

Best Regards
Li Cheng 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 0004A98D48257AAA_=-- From jnc@mercury.lcs.mit.edu Thu Nov 1 19:22:34 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E8C21F987E for ; Thu, 1 Nov 2012 19:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcXKnduwLJ7q for ; Thu, 1 Nov 2012 19:22:34 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC3D21F9403 for ; Thu, 1 Nov 2012 19:22:33 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2C28318C0D0; Thu, 1 Nov 2012 22:22:32 -0400 (EDT) To: lisp@ietf.org Message-Id: <20121102022232.2C28318C0D0@mercury.lcs.mit.edu> Date: Thu, 1 Nov 2012 22:22:32 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP-NAT Deployment - draft-ietf-lisp-introduction-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 02:22:34 -0000 > From: cheng.li2@zte.com.cn > In the third paragraph of Section 10.5.1, you mentioned > "in addition, since LISP expects all incoming data traffic to be on a > specific port, it was not possible to have multiple ETRs behind a > single NAT (which normally would have only one global address to share, > meaning port mapping would have to be used, except that... )" > Is something missing here? > Certainly there maybe scenarios such like two or more LISP MN connect > behind the same NAT, i.e. two or more ETRs behind a single NAT. Maybe I am missing something, but if a NAT has two ETRs behind it, and if an inbound UDP packet to destination port 4341 arrives at the NAT, how does the NAT know which ETR to send the packet to? (Since the destination IP address in the packet is that of the NAT, and port 4341 would be used for packets to either ETR.) Even if you look at the sort host and port, that doesn't necessarily help, because some source ITR could be sending packets to both ETRs, so packets to either ETR could also have the identical source host/port. In short, there's no way for the NAT to know which ETR the packet is for. Note that there is a separate "NAT Traversal For LISP" document which provides mechanisms to bypass all these issues. Noel From cheng.li2@zte.com.cn Thu Nov 1 20:39:17 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4239D21F9534; Thu, 1 Nov 2012 20:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.074 X-Spam-Level: X-Spam-Status: No, score=-98.074 tagged_above=-999 required=5 tests=[AWL=-4.524, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] 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 KoLYGKm9ghqR; Thu, 1 Nov 2012 20:39:16 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1E15A21F9509; Thu, 1 Nov 2012 20:39:16 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id C851A125A8F2; Fri, 2 Nov 2012 11:40:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qA23d4F3001051; Fri, 2 Nov 2012 11:39:05 +0800 (GMT-8) (envelope-from cheng.li2@zte.com.cn) In-Reply-To: <20121102022232.2C28318C0D0@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) MIME-Version: 1.0 X-KeepSent: C009E34F:A5913A69-48257AAA:00127119; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: cheng.li2@zte.com.cn Date: Fri, 2 Nov 2012 11:38:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-02 11:38:47, Serialize complete at 2012-11-02 11:38:47 Content-Type: multipart/alternative; boundary="=_alternative 001423F648257AAA_=" X-MAIL: mse02.zte.com.cn qA23d4F3001051 Cc: lisp-bounces@ietf.org, jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: [lisp] =?gb2312?b?tPC4tDogUmU6ICBMSVNQLU5BVCBEZXBsb3ltZW50IC0g?= =?gb2312?b?ZHJhZnQtaWV0Zi1saXNwLWludHJvZHVjdGlvbi0wMA==?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 03:39:17 -0000 This is a multipart message in MIME format. --=_alternative 001423F648257AAA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTm9lbCwNCg0KICBNeSByZXNwb25zZSBpcyBpbmxpbmUuIFRoYW5rIHlvdS4NCg0KbGlzcC1i b3VuY2VzQGlldGYub3JnINC009ogMjAxMi0xMS0wMiAxMDoyMjozMjoNCg0KPiAgICAgPiBGcm9t OiBjaGVuZy5saTJAenRlLmNvbS5jbg0KPiANCj4gICAgID4gSW4gdGhlIHRoaXJkIHBhcmFncmFw aCBvZiBTZWN0aW9uIDEwLjUuMSwgeW91IG1lbnRpb25lZA0KPiANCj4gICAgID4gICJpbiBhZGRp dGlvbiwgc2luY2UgTElTUCBleHBlY3RzIGFsbCBpbmNvbWluZyBkYXRhIHRyYWZmaWMgdG8gYmUg DQpvbiBhDQo+ICAgICA+ICAgc3BlY2lmaWMgcG9ydCwgaXQgd2FzIG5vdCBwb3NzaWJsZSB0byBo YXZlIG11bHRpcGxlIEVUUnMgYmVoaW5kIA0KYQ0KPiAgICAgPiAgIHNpbmdsZSBOQVQgKHdoaWNo IG5vcm1hbGx5IHdvdWxkIGhhdmUgb25seSBvbmUgZ2xvYmFsIA0KPiBhZGRyZXNzIHRvIHNoYXJl LA0KPiAgICAgPiAgIG1lYW5pbmcgcG9ydCBtYXBwaW5nIHdvdWxkIGhhdmUgdG8gYmUgdXNlZCwg ZXhjZXB0IHRoYXQuLi4gKSINCj4gDQo+ICAgICA+IElzIHNvbWV0aGluZyBtaXNzaW5nIGhlcmU/ DQo+ICAgICA+IENlcnRhaW5seSB0aGVyZSBtYXliZSBzY2VuYXJpb3Mgc3VjaCBsaWtlIHR3byBv ciBtb3JlIExJU1AgTU4gDQpjb25uZWN0DQo+ICAgICA+IGJlaGluZCB0aGUgc2FtZSBOQVQsIGku ZS4gdHdvIG9yIG1vcmUgRVRScyBiZWhpbmQgYSBzaW5nbGUgTkFULg0KPiANCj4gTWF5YmUgSSBh bSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IGlmIGEgTkFUIGhhcyB0d28gRVRScyBiZWhpbmQgaXQs IGFuZCANCmlmIGFuDQo+IGluYm91bmQgVURQIHBhY2tldCB0byBkZXN0aW5hdGlvbiBwb3J0IDQz NDEgYXJyaXZlcyBhdCB0aGUgTkFULCBob3cgZG9lcyANCnRoZQ0KPiBOQVQga25vdyB3aGljaCBF VFIgdG8gc2VuZCB0aGUgcGFja2V0IHRvPw0KPiANCj4gKFNpbmNlIHRoZSBkZXN0aW5hdGlvbiBJ UCBhZGRyZXNzIGluIHRoZSBwYWNrZXQgaXMgdGhhdCBvZiB0aGUgTkFULCBhbmQgDQpwb3J0DQo+ IDQzNDEgd291bGQgYmUgdXNlZCBmb3IgcGFja2V0cyB0byBlaXRoZXIgRVRSLikNCg0KSSBkb24n dCB1bmRlcnN0YW5kIHZlcnkgY2xlYXJseS4NCg0KQ29uc2lkZXIgdGhlIHNjZW5hcmlvIHRoYXQg dHdvIEVUUnMgYmVoaW5kIGEgc2luZ2xlIE5BVC4NCg0KV2hlbiBOQVQgZXN0YWJsaXNoIHN0YXRl cyBmb3IgRVRScyB3aG8gYm90aCBzZW5kIHBhY2tldHMgb3V0Ym91bmQsIGl0IA0KY291bGQgYXNz aWduDQpkaWZmZXJlbnQgZ2xvYmFsIElQIGFkZHJlc3NlcyBmb3IgdGhlbS4NCg0KQXMgYSByZXN1 bHQsIHdoZW4gTkFUIHJlY2VpdmVzIHBhY2tldHMgaW5ib3VuZCwgZXZlbiB0aG91Z2ggcGFja2V0 cyBib3RoIA0KaGF2ZSBEZXN0aW5hdGlvbg0KcG9ydCA0MzQxLCB0aGVpciBkZXN0aW5hdGlvbiBh ZGRyZXNzZXMgYXJlIGFjY29yZGluZyB0byBkaWZmZXJlbnQgRVRScy4NCg0KV2FzIHRoZXJlIHNv bWV0aGluZyBJIG1pc3VuZGVyc3Rvb2Q/DQoNCkJlc3QgUmVnYXJkcw0KTGkgQ2hlbmcNCg0KPiAN Cj4gRXZlbiBpZiB5b3UgbG9vayBhdCB0aGUgc29ydCBob3N0IGFuZCBwb3J0LCB0aGF0IGRvZXNu J3QgbmVjZXNzYXJpbHkgDQpoZWxwLA0KPiBiZWNhdXNlIHNvbWUgc291cmNlIElUUiBjb3VsZCBi ZSBzZW5kaW5nIHBhY2tldHMgdG8gYm90aCBFVFJzLCBzbyANCnBhY2tldHMgdG8NCj4gZWl0aGVy IEVUUiBjb3VsZCBhbHNvIGhhdmUgdGhlIGlkZW50aWNhbCBzb3VyY2UgaG9zdC9wb3J0Lg0KPiAN Cj4gSW4gc2hvcnQsIHRoZXJlJ3Mgbm8gd2F5IGZvciB0aGUgTkFUIHRvIGtub3cgd2hpY2ggRVRS IHRoZSBwYWNrZXQgaXMgDQpmb3IuDQo+IA0KPiANCj4gTm90ZSB0aGF0IHRoZXJlIGlzIGEgc2Vw YXJhdGUgIk5BVCBUcmF2ZXJzYWwgRm9yIExJU1AiIGRvY3VtZW50IHdoaWNoDQo+IHByb3ZpZGVz IG1lY2hhbmlzbXMgdG8gYnlwYXNzIGFsbCB0aGVzZSBpc3N1ZXMuDQo+IA0KPiAgICBOb2VsDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGxpc3Ag bWFpbGluZyBsaXN0DQo+IGxpc3BAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9saXNwDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50 IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5k IGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAg SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVw cm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2Yg dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBu b3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo= --=_alternative 001423F648257AAA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE5vZWwsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgTXkgcmVzcG9uc2Ug aXMgaW5saW5lLiBUaGFuaw0KeW91LjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y Pmxpc3AtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTItMTEtMDIgMTA6MjI6MzI6PGJyPg0KPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZndDsgRnJvbTogY2hlbmcubGkyQHp0ZS5jb20uY248YnI+ DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IEluIHRoZSB0aGlyZCBwYXJhZ3Jh cGggb2YgU2VjdGlvbiAxMC41LjEsIHlvdSBtZW50aW9uZWQ8YnI+DQomZ3Q7IDxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyAmZ3Q7ICZuYnNwOyZxdW90O2luIGFkZGl0aW9uLCBzaW5jZSBMSVNQIGV4 cGVjdHMgYWxsDQppbmNvbWluZyBkYXRhIHRyYWZmaWMgdG8gYmUgb24gYTxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyAmZ3Q7ICZuYnNwOyBzcGVjaWZpYyBwb3J0LCBpdCB3YXMgbm90IHBvc3NpYmxl IHRvIGhhdmUNCm11bHRpcGxlIEVUUnMgYmVoaW5kIGE8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg Jmd0OyAmbmJzcDsgc2luZ2xlIE5BVCAod2hpY2ggbm9ybWFsbHkgd291bGQgaGF2ZSBvbmx5DQpv bmUgZ2xvYmFsIDxicj4NCiZndDsgYWRkcmVzcyB0byBzaGFyZSw8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJmd0OyAmbmJzcDsgbWVhbmluZyBwb3J0IG1hcHBpbmcgd291bGQgaGF2ZSB0byBiZSB1 c2VkLA0KZXhjZXB0IHRoYXQuLi4gKSZxdW90Ozxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZndDsgSXMgc29tZXRoaW5nIG1pc3NpbmcgaGVyZT88YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJmd0OyBDZXJ0YWlubHkgdGhlcmUgbWF5YmUgc2NlbmFyaW9zIHN1Y2ggbGlrZSB0d28g b3INCm1vcmUgTElTUCBNTiBjb25uZWN0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZndDsgYmVo aW5kIHRoZSBzYW1lIE5BVCwgaS5lLiB0d28gb3IgbW9yZSBFVFJzIGJlaGluZA0KYSBzaW5nbGUg TkFULjxicj4NCiZndDsgPGJyPg0KJmd0OyBNYXliZSBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBi dXQgaWYgYSBOQVQgaGFzIHR3byBFVFJzIGJlaGluZCBpdCwNCmFuZCBpZiBhbjxicj4NCiZndDsg aW5ib3VuZCBVRFAgcGFja2V0IHRvIGRlc3RpbmF0aW9uIHBvcnQgNDM0MSBhcnJpdmVzIGF0IHRo ZSBOQVQsIGhvdw0KZG9lcyB0aGU8YnI+DQomZ3Q7IE5BVCBrbm93IHdoaWNoIEVUUiB0byBzZW5k IHRoZSBwYWNrZXQgdG8/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IChTaW5jZSB0aGUgZGVzdGluYXRp b24gSVAgYWRkcmVzcyBpbiB0aGUgcGFja2V0IGlzIHRoYXQgb2YgdGhlIE5BVCwNCmFuZCBwb3J0 PGJyPg0KJmd0OyA0MzQxIHdvdWxkIGJlIHVzZWQgZm9yIHBhY2tldHMgdG8gZWl0aGVyIEVUUi4p PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIGRvbid0IHVuZGVyc3Rh bmQgdmVyeSBjbGVhcmx5LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Q29uc2lkZXIgdGhlIHNjZW5hcmlvIHRoYXQgdHdvIEVUUnMgYmVoaW5kIGEgc2luZ2xlDQpOQVQu PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5XaGVuIE5BVCBlc3RhYmxp c2ggc3RhdGVzIGZvciBFVFJzIHdobyBib3RoIHNlbmQgcGFja2V0cw0Kb3V0Ym91bmQsIGl0IGNv dWxkIGFzc2lnbjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ZGlmZmVyZW50IGds b2JhbCBJUCBhZGRyZXNzZXMgZm9yIHRoZW0uPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj5BcyBhIHJlc3VsdCwgd2hlbiBOQVQgcmVjZWl2ZXMgcGFja2V0cyBpbmJvdW5k LCBldmVuDQp0aG91Z2ggcGFja2V0cyBib3RoIGhhdmUgRGVzdGluYXRpb248L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPnBvcnQgNDM0MSwgdGhlaXIgZGVzdGluYXRpb24gYWRkcmVz c2VzIGFyZSBhY2NvcmRpbmcNCnRvIGRpZmZlcmVudCBFVFJzLjwvZm9udD48L3R0Pg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+V2FzIHRoZXJlIHNvbWV0aGluZyBJIG1pc3VuZGVyc3Rvb2Q/ PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5CZXN0IFJlZ2FyZHM8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkxpIENoZW5nPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IDxicj4NCiZndDsgRXZlbiBpZiB5b3UgbG9vayBh dCB0aGUgc29ydCBob3N0IGFuZCBwb3J0LCB0aGF0IGRvZXNuJ3QgbmVjZXNzYXJpbHkNCmhlbHAs PGJyPg0KJmd0OyBiZWNhdXNlIHNvbWUgc291cmNlIElUUiBjb3VsZCBiZSBzZW5kaW5nIHBhY2tl dHMgdG8gYm90aCBFVFJzLCBzbw0KcGFja2V0cyB0bzxicj4NCiZndDsgZWl0aGVyIEVUUiBjb3Vs ZCBhbHNvIGhhdmUgdGhlIGlkZW50aWNhbCBzb3VyY2UgaG9zdC9wb3J0Ljxicj4NCiZndDsgPGJy Pg0KJmd0OyBJbiBzaG9ydCwgdGhlcmUncyBubyB3YXkgZm9yIHRoZSBOQVQgdG8ga25vdyB3aGlj aCBFVFIgdGhlIHBhY2tldA0KaXMgZm9yLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IE5vdGUgdGhhdCB0aGVyZSBpcyBhIHNlcGFyYXRlICZxdW90O05BVCBUcmF2ZXJzYWwgRm9yIExJ U1AmcXVvdDsgZG9jdW1lbnQNCndoaWNoPGJyPg0KJmd0OyBwcm92aWRlcyBtZWNoYW5pc21zIHRv IGJ5cGFzcyBhbGwgdGhlc2UgaXNzdWVzLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7Tm9lbDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7IGxpc3AgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBsaXNwQGlldGYu b3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3A8 YnI+DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJ bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHBy aXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNp dmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCBy ZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBv dGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4g ZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9m b250PjwvcHJlPjxicj4NCg== --=_alternative 001423F648257AAA_=-- From jnc@mercury.lcs.mit.edu Thu Nov 1 20:52:49 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B0A21F992F for ; Thu, 1 Nov 2012 20:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpkU6LT1EfzE for ; Thu, 1 Nov 2012 20:52:49 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 23A6921F992A for ; Thu, 1 Nov 2012 20:52:48 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A31E818C0D2; Thu, 1 Nov 2012 23:52:47 -0400 (EDT) To: lisp@ietf.org Message-Id: <20121102035247.A31E818C0D2@mercury.lcs.mit.edu> Date: Thu, 1 Nov 2012 23:52:47 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP-NAT Deployment - draft-ietf-lisp-introduction-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 03:52:49 -0000 > From: cheng.li2@zte.com.cn > Consider the scenario that two ETRs behind a single NAT. > When NAT establish states for ETRs who both send packets outbound, it > could assign different global IP addresses for them. Most NAT devices (at least, IPv4 NAT devices) share a _single_ global IP address among multiple machines. So, the NAT _cannot_ "assign [a] different global IP address[] for" each ETR. Noel From cheng.li2@zte.com.cn Thu Nov 1 23:15:15 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C5221F9973 for ; Thu, 1 Nov 2012 23:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.812 X-Spam-Level: X-Spam-Status: No, score=-95.812 tagged_above=-999 required=5 tests=[AWL=-2.262, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] 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 W8DCXr3D28+w for ; Thu, 1 Nov 2012 23:15:14 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 94EE521F9808 for ; Thu, 1 Nov 2012 23:15:14 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 570AC125BCD5; Fri, 2 Nov 2012 14:16:18 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qA26F50p056566; Fri, 2 Nov 2012 14:15:05 +0800 (GMT-8) (envelope-from cheng.li2@zte.com.cn) In-Reply-To: <20121102035247.A31E818C0D2@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) MIME-Version: 1.0 X-KeepSent: 9A25D441:B9DC9037-48257AAA:0015EE2F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: cheng.li2@zte.com.cn Date: Fri, 2 Nov 2012 14:14:52 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-02 14:14:46, Serialize complete at 2012-11-02 14:14:46 Content-Type: multipart/alternative; boundary="=_alternative 00226C1648257AAA_=" X-MAIL: mse01.zte.com.cn qA26F50p056566 Cc: jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: [lisp] =?gb2312?b?tPC4tDogUmU6IExJU1AtTkFUIERlcGxveW1lbnQgLSBk?= =?gb2312?b?cmFmdC1pZXRmLWxpc3AtaW50cm9kdWN0aW9uLTAw?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 06:15:15 -0000 This is a multipart message in MIME format. --=_alternative 00226C1648257AAA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTm9lbCwNCiANCiAgVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXBseS4NCg0KICBZ ZXMsIEkgYWdyZWUuIElmICJOQVQgVHJhdmVyc2FsIiBpcyBub3QgYmFzZWQgb24gUlRSLCAiRGVz dGluYXRpb24gUG9ydCIgDQppcyBpbmRlZWQgYSBwcm9ibGVtLg0KDQoNCmpuY0BtZXJjdXJ5Lmxj cy5taXQuZWR1IChOb2VsIENoaWFwcGEpINC009ogMjAxMi0xMS0wMiAxMTo1Mjo0NzoNCg0KPiAg ICAgPiBGcm9tOiBjaGVuZy5saTJAenRlLmNvbS5jbg0KPiANCj4gICAgID4gQ29uc2lkZXIgdGhl IHNjZW5hcmlvIHRoYXQgdHdvIEVUUnMgYmVoaW5kIGEgc2luZ2xlIE5BVC4NCj4gDQo+ICAgICA+ IFdoZW4gTkFUIGVzdGFibGlzaCBzdGF0ZXMgZm9yIEVUUnMgd2hvIGJvdGggc2VuZCBwYWNrZXRz IG91dGJvdW5kLCANCml0DQo+ICAgICA+IGNvdWxkIGFzc2lnbiBkaWZmZXJlbnQgZ2xvYmFsIElQ IGFkZHJlc3NlcyBmb3IgdGhlbS4NCj4gDQo+IE1vc3QgTkFUIGRldmljZXMgKGF0IGxlYXN0LCBJ UHY0IE5BVCBkZXZpY2VzKSBzaGFyZSBhIF9zaW5nbGVfIGdsb2JhbCBJUA0KPiBhZGRyZXNzIGFt b25nIG11bHRpcGxlIG1hY2hpbmVzLiBTbywgdGhlIE5BVCBfY2Fubm90XyAiYXNzaWduIFthXSAN CmRpZmZlcmVudA0KPiBnbG9iYWwgSVAgYWRkcmVzc1tdIGZvciIgZWFjaCBFVFIuDQo+IA0KPiAg ICAgICAgTm9lbA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21p dHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBh cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlv biwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVz IGltbWVkaWF0ZWx5Lg0K --=_alternative 00226C1648257AAA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE5vZWwsPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgVGhhbmsgeW91IHZlcnkgbXVjaCBmb3Ig eW91cg0KcmVwbHkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgWWVzLCBJIGFncmVlLiBJZiAmcXVvdDtOQVQgVHJhdmVyc2FsJnF1b3Q7DQpp cyBub3QgYmFzZWQgb24gUlRSLCAmcXVvdDtEZXN0aW5hdGlvbiBQb3J0JnF1b3Q7IGlzIGluZGVl ZCBhIHByb2JsZW0uPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+am5j QG1lcmN1cnkubGNzLm1pdC5lZHUgKE5vZWwgQ2hpYXBwYSkg0LTT2iAyMDEyLTExLTAyDQoxMTo1 Mjo0Nzo8YnI+DQo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJmd0OyBGcm9tOiBjaGVuZy5saTJA enRlLmNvbS5jbjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZndDsgQ29uc2lk ZXIgdGhlIHNjZW5hcmlvIHRoYXQgdHdvIEVUUnMgYmVoaW5kIGEgc2luZ2xlDQpOQVQuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJmd0OyBXaGVuIE5BVCBlc3RhYmxpc2ggc3Rh dGVzIGZvciBFVFJzIHdobyBib3RoIHNlbmQNCnBhY2tldHMgb3V0Ym91bmQsIGl0PGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZndDsgY291bGQgYXNzaWduIGRpZmZlcmVudCBnbG9iYWwgSVAgYWRk cmVzc2VzIGZvcg0KdGhlbS48YnI+DQomZ3Q7IDxicj4NCiZndDsgTW9zdCBOQVQgZGV2aWNlcyAo YXQgbGVhc3QsIElQdjQgTkFUIGRldmljZXMpIHNoYXJlIGEgX3NpbmdsZV8gZ2xvYmFsDQpJUDxi cj4NCiZndDsgYWRkcmVzcyBhbW9uZyBtdWx0aXBsZSBtYWNoaW5lcy4gU28sIHRoZSBOQVQgX2Nh bm5vdF8gJnF1b3Q7YXNzaWduDQpbYV0gZGlmZmVyZW50PGJyPg0KJmd0OyBnbG9iYWwgSVAgYWRk cmVzc1tdIGZvciZxdW90OyBlYWNoIEVUUi48YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Tm9lbDxicj4NCjwvZm9udD48L3R0Pg0KDQo8YnI+PHByZT48Zm9u dCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFu c21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBp bnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlv dSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVj dGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5 IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K --=_alternative 00226C1648257AAA_=-- From arnatal@ac.upc.edu Fri Nov 2 11:30:42 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7957D1F0C6E for ; Fri, 2 Nov 2012 11:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 UpIz8jFAJelY for ; Fri, 2 Nov 2012 11:30:42 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 96C9C1F0C6A for ; Fri, 2 Nov 2012 11:30:40 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qA2IUdt6016867 for ; Fri, 2 Nov 2012 19:30:39 +0100 Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by gw.ac.upc.edu (Postfix) with ESMTP id 5626E6B006C for ; Fri, 2 Nov 2012 19:30:38 +0100 (CET) Received: by mail-vc0-f172.google.com with SMTP id fl11so4512595vcb.31 for ; Fri, 02 Nov 2012 11:30:37 -0700 (PDT) Received: by 10.52.92.97 with SMTP id cl1mr2306133vdb.65.1351881036972; Fri, 02 Nov 2012 11:30:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.69.116 with HTTP; Fri, 2 Nov 2012 11:30:16 -0700 (PDT) From: =?ISO-8859-1?Q?Alberto_Rodr=EDguez_Natal?= Date: Fri, 2 Nov 2012 19:30:16 +0100 Message-ID: To: lisp@ietf.org Content-Type: multipart/alternative; boundary=20cf3071d01cfcc0e904cd8754a8 Subject: [lisp] Comments on draft-ietf-lisp-introduction-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:30:42 -0000 --20cf3071d01cfcc0e904cd8754a8 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I like the document, I think it is a solid work. Just a few comments, mostly regarding format and typos. Content comments - About the future uses of LISP, I think that besides referring to the [Future] document, maybe it is worth to point out a few possible examples of these future uses. Just to illustrate the reader and to allow him/her to see the possibilities of LISP. - In section 11.3, I do agree that some brief comments about SMR and Proxy-Map-Reply should be included. Format/style comments - I agree with the idea, mentioned in previous reviews, that acronyms (specially LISP-related ones) should be followed by what they stand for the first time they appear. Slightly related to this, TTL acronym is used in 8 but defined in 9.2.3. - I think that sections at the beginning of the document, that introduce topics that will be discussed in detail later, should point to the sections where these topics are discussed. This is already done in some sections (section 3.3 points to section 9.5 and section 4.3 links to 5.2), but not in all. Some examples where this can be done: section 3.4 can point to 10.1, section 4.4 to 11.3 and 5.2.3 to 9.1 - I believe that LISP-related terms shouldn't be used prior to introduce them. As an example, Map-Request and Map-Reply concepts are used in 5.1, but they are not introduced until 5.2.2 Typos (I will try to omit those that have already appeared in other reviews in the mailing list) - Sec. 2.2: "whereever" possible - Sec. 4: It is very "imporant" to note - Sec. 4.2: and the "existince" of a binding layer - Sec. 4.3: distributed "computationa" - Sec 8.2: In most "exising" hardware - Sec. 10.2.1: precisely "to" to minimize the number - Sec. 11.4: LISP's mapping capability "isa" used - Sec 12.4: are _not_ "synonmous" Regards, Alberto --20cf3071d01cfcc0e904cd8754a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I like the document, I think it is a solid work. Just a few = comments, mostly regarding format and typos.


Content comments
- About the future uses of LISP, I think that besides referring to the= [Future] document, maybe it is worth to point out a few possible examples = of these future uses. Just to illustrate the reader and to allow him/her to= see the possibilities of LISP.

- In section 11.3, I do agree that some brief comments about SMR and Pr= oxy-Map-Reply should be included.


Format/style comments

-= I agree with the idea, mentioned in previous reviews, that acronyms (speci= ally LISP-related ones) should be followed by what they stand for the first= time they appear. Slightly related to this, TTL acronym is used in 8 but d= efined in 9.2.3.

- I think that sections at the beginning of the document, that introduc= e topics that will be discussed in detail later, should point to the sectio= ns where these topics are discussed. This is already done in some sections = (section 3.3 points to section 9.5 and section 4.3 links to 5.2), but not i= n all. Some examples where this can be done: section 3.4 can point to 10.1,= section 4.4 to 11.3 and 5.2.3 to 9.1

- I believe that LISP-related terms shouldn't be used prior to intr= oduce them. As an example, Map-Request and Map-Reply concepts are used in 5= .1, but they are not introduced until 5.2.2


Typos (I will try t= o omit those that have already appeared in other reviews in the mailing lis= t)

- Sec. 2.2: "whereever" possible
- Sec. 4: It is very &quo= t;imporant" to note
- Sec. 4.2: and the "existince" of a = binding layer
- Sec. 4.3: distributed "computationa"
- Sec = 8.2: In most "exising" hardware
- Sec. 10.2.1: precisely "to" to minimize the number
- Sec. 11= .4: LISP's mapping capability "isa" used
- Sec 12.4: are _= not_ "synonmous"


Regards,
Alberto
--20cf3071d01cfcc0e904cd8754a8-- From acabello@ac.upc.edu Sat Nov 3 06:02:04 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DE921F9C53 for ; Sat, 3 Nov 2012 06:02:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5d2S8v2EAxY for ; Sat, 3 Nov 2012 06:02:02 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9F321F9C3E for ; Sat, 3 Nov 2012 06:01:57 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qA3D1GVT015941; Sat, 3 Nov 2012 14:01:31 +0100 Received: from [10.0.0.7] (62.83.144.193.dyn.user.ono.com [62.83.144.193]) by gw.ac.upc.edu (Postfix) with ESMTP id 7D9346B0074; Sat, 3 Nov 2012 14:00:45 +0100 (CET) From: Albert Cabellos Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Nov 2012 14:00:34 +0100 Message-Id: To: Noel Chiappa Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: lisp@ietf.org Subject: [lisp] Comments on lisp-architecture X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 13:02:04 -0000 Hi all, Here are my comments to draft-lisp-architecture, Thanks! Albert > LISP Working Group J. N. = Chiappa > Internet-Draft Yorktown Museum of Asian = Art > Intended status: Informational July 16, = 2012 > Expires: January 17, 2013 >=20 >=20 > An Architectural Perspective on the LISP > Location-Identity Separation System > draft-chiappa-lisp-architecture-01 [snip] > 2.2. Deployment of New Namespaces >=20 > Once the mapping system is widely deployed and available, it should > make deployment of new namespaces (in the sense of new syntax, if = not > new semantics) easier. E.g. if someone wishes in the future to > devise a system which uses native MPLS [RFC3031] for a data = carriage > system joining together a large number of xTRs, it would easy = enough > to arrange to have the mappings for destinations attached to those > xTRs abe some sort of MPLS-specific name. Once-> I suggest removing this word given that the Mapping System is = already there. MPLS-> Although it is a good analogy, I don=B4t think that MPLS is a = good example given that with LISP we can=B4t stack labels. > More broadly, the existence of a binding layer, with support for > multiple namespace built into the interface on both sides (see > Section 5) is a tremendously powerful evolutionary tool; one can > introduce a new namespace (on one side) more easily, if it is = mapped > to something which is already deployed (on the other). Then, having > taken that step, one can invert the process, and deploy yet another > new namespace, but this time on the other. >=20 > 2.3. Future Development of LISP >=20 > Speculation about long-term future developments which are enabled = by > the deployment of LISP is not really proper for this document. > However, interested readers may wish to consult [Future] for one > person's thoughts on this topic. >=20 > 3. Architectual Perspectives >=20 > This section contains some high-level architectural perspectives > which have proven useful in a number of ways for thinking about = LISP. > For one, when trying to think of LISP as a complete system, they > provide a conceptual structure which can aid analysis of LISP. For > another, they can allow the application of past analysis of, and > experience with, similar designs. >=20 > 3.1. Another Packet-Switching Layer Weak suggestion, maybe it is worth to mention Van Jacobson=B4s view that = the Internet was an overlay of the Public Switched Telephone Network, in = this context LISP is an overlay of the Internet. > When considering the overall structure of the LISP system at a high > level, it has proven most useful to think of it as another packet- > switching layer, run on top of the original internet layer - much = as > the Internet first ran on top of the ARPANET. >=20 > All the functions that a normal packet switch has to undertake - = such > as ensuring that it can reach its neighbours, and they they are = still > up - the devices that make up the LISP overlay also have to do, = along > the 'tunnels' which connect them to other LISP devices. >=20 > There is, however, one big difference: the fanout of a typical LISP > ITR will be much larger than most classic physical packet switches. > (ITRs only need to be considered, as the LISP tunnels are all > effectively unidirectional, from ITR to ETR - an ETR needs to keep = no > per-tunnel state, etc.) >=20 > LISP is, fundamentally, a 'tunnel' based system. Tunnel system > designs do have their issues (e.g. the high inter-'switch' = fan-out), > but it's important to realize that they also can have advantages, > some of which are listed below. [snip] > 4.2. Need for a Mapping System >=20 > LISP does need to have a mapping system, which brings design, > implementation, configuration and operational costs. Surely all > these costs are a bad thing? However, having a mapping system have > advantages, especially when there is a mapping layer which has = global > visibility (i.e. other entities know that it is there, and have an > interface designed to be able to interact with it). This is unlike, > say, the mappings in NAT, which are 'invisible' to the rest of the > network. Typo? "Surely all these costs are a bad thing." Typo: However, having a mapping system *has*... > In fact, one could argue that the mapping layer is LISP's greatest > strength. Wheeler's Axiom* ('Any problem in computer science can be > solved with another level of indirection') indicates that the = binding > layer available with the LISP mapping system will be of great = value. > Again, it is not the job of this document to list them all - and in > any event, there is no way to forsee them all. >=20 > The author of this document has often opined that the hallmark of > great architecture is not how well it does the things it was = designed > to do, but how well it does things it was never expected to have to > handle. Providing such a powerful and generic binding layer is one > sure way to achieve the sort of lasting flexibility and power that > leads to that outcome. >=20 > [Footnote *: This Axiom is often mis-attributed to Butler Lampson, > but Lampson himself indicated that it came from David Wheeler.] >=20 > 4.3. Piggybacking of Control on User Data >=20 > LISP piggybacks control transactions on top of user data packets. > This is a technique that has a long history in data networking, = going > back to the early ARPANET. [McQuillan] It is now apparently = regarded > as a somewhat dubious technique, the feeling seemingly being that > control and user data should be strictly segregated. >=20 > It should be noted that _none_ of the piggybacking of control > functionality in LISP is _architecturally fundamental_ to LISP. All > of the functions in LISP which are performed with piggybacking = could > be performed almost equally well with separate control packets. >=20 > The "almost" is solely because it would cause more overhead (i.e. > control packets); neither the response time, robustness, etc would > necessarily be affected - although for some functions, to match the > response time observed using piggybacking on user data would need = as > much control traffic as user data traffic. >=20 > This technique is particularly important, however, because of the > issue identified at the start of this section - the very large = fanout > of the typical LISP switch. Unlike a typical router, which will = have > control interactions with only a few neighbours, a LISP switch = could > eventually have control interactions with hundreds, or perhaps even > thousands (for a large site) of neighbours. >=20 > Explicit control traffic, especially if good response times are > desired, could amount to a very great deal of overhead in such a > case. Maybe it=B4s worth mentioning a specific example of piggybacked control = on user data: Echo-nonce. [snip] > 5.3. Overlapping Uses of Existing Namespaces >=20 > It is in theory possible to have a block of IPvN namespace used as > both EIDs and RLOCs. In other words, EIDs from that block might map > to some other RLOCs, and that block might also appear in the DFZ as > the locators of some other ETRs. >=20 > This is obviously potentially confusing - when a 'bare' IPvN = address > from one of these blocks, is it the RLOC, or the EID? Sometimes it > it obvious from the context, but in general one could not simply = have > a (hypothetical) table which assigns all of the address space to > either 'EID' or 'RLOC'. >=20 > In addition, such usage will not allow interoperation of the sites > named by those EIDs with legacy sites, using the PITR mechanism > ([Introduction], Section "Proxy Devices"), since that mechanisms > depends on advertizing the EIDs into the DFZ, although the LISP-NAT > mechanism should still work ([Introduction], Section "LISP-NAT"). >=20 > Nevertheless, as the IPv4 namespace becomes increasingly used up, > this may be an increasingly attractive way of getting the 'absolute > last drop' out of that space. I think that there might be some potential issues of overlapping = namespaces and LISP-TE recursion mechanism. In this scenario the mapping = system is queried using RLOCs. If a given address has meaning both in = terms of EID and RLOC this might cause some issues. > 5.4. LCAFs >=20 > {{To be written.}} >=20 > --- Key-ID > --- Instance-IDs >=20 > 6. Scalability >=20 > As with robustness, any global communication system must be = scalable, > and scalable up to almost any size. As previously mentioned (xref > target=3D"Perspectives-Packet"/), the large fanouts to be seen with > LISP, due to its 'overlay' nature, present a special challenge. >=20 > One likely saving grace is that as the Internet grows, most sites > will likely only interact with a limited subset of the Internet; if > nothing else, the separation of the world into language blocks = means > that content in, say, Chinese, will not be of interest to most of = the > rest of the world. This tendency will help with a lot of things > which could be problematic if constant, full, N^2 connectivity were > likely on all nodes; for example the caching of mappings. I suggest removing the `Chinese=B4example for a more general sentence, = something like "the separation of the world into language blocks might = suggest that users speaking a given language do not typically access = content written in other languages". Besides this many measurements show = that because of port-scans networks reach the entire Internet, so this = might not be strictly true. =20 > 6.1. Demand Loading of Mappings >=20 > One question that many will have about LISP's design is 'why = demand- > load mappings - why not just load them all'? It is certainly true > that with the growth of memory sizes, the size of the complete > database is such that one could reasonably propose keeping the = entire > thing in each LISP device. (In fact, one proposed mapping system = for > LISP, named NERD, did just that. [NERD]) >=20 > A 'pull'-based system was chosen over 'push' for several reasons; = the > main one being that the issue is not just the pure _size_ of the > mapping database, but its _dynamicity_. Depending on how often > mappings change, the update rate of a complete database could be > relatively large. >=20 > It is especially important to realize that, depending on what > (probably unforseeable) uses eventually evolve for the > identity->location mapping capability LISP provides, the update = rate > could be very high indeed. E.g. if LISP is used for mobility, that > will greatly increase the update rate. Such a powerful and flexible > tool is likely be used in unforseen ways (Section 4.2), so it's > unwise to make a choice that would preclude any which raise the > update rate significantly. >=20 > Push as a mechanism is also fundamentally less desirable than pull, > since the control plane overhead consumed to load and maintain > information about unused destinations is entirely wasted. The only > potential downside to the pull option is the delay required for the > demand-loading of information. >=20 > (It's also probably worth noting that many issues that some people > have with the mapping approach of LISP, such as the total mapping > database size, etc are the same - if not worse - for push as they = are > for pull.) >=20 > Finally, for IPv4, as the address space becomes more highly used, = it > will become more fragmented - i.e. there will tend to be more, > smaller, entries. For a routing table, which every router has to > hold, this is problematic. For a demand-loaded mapping table, it is > not bad. Indeed, this was the original motivation for LISP > ([RFC4984]) - although many other useful and desirable uses for it > have since been enumerated (see [Introduction], Section > "Applications"). >=20 > For all of these reasons, as long as there is locality of reference > (i.e. most ITRs will use only a subset of the entire set), it makes > much more sense to use the a pull model, than the classic push one > heretofore seen widely at the internetwork layer (with a pull > approach thus being somewhat novel - and thus unsettling to many - = to > people who work at that layer). >=20 > It may well be that some sites (e.g. large content providers) may > need non-standard mechanisms - perhaps something more of a 'push' > model. This remains to be determined, but it is certainly feasible. >=20 > 6.2. Caching of Mappings >=20 > It should be noted that the caching spoken of here is likely not > classic caching, where there is a fixed/limited size cache, and > entries have to be discarded to make room for newly needed entries. > The economics of memory being what they are, there is no reason to > discard mappings once they have been loaded (although of course > implementations are free to chose to do so, if they wish to). I am unsure if I understood this last paragraph. AFAIK the map-cache = must be implemented -for high-speed routers- in TCAM memories which are = expensive and hence, have a fixed/limited cache size. > This leads to another point about the caching of mappings: the > algorithms for management of the cache are purely a local issue. = The > algorithm in any particular ITR can be changed at will, with no = need > for any coordination. A change might be for purposes of > experimentation, or for upgrade, or even because of environmental > variations - different environments might call for different cache > management strategies. >=20 > The local, unsynchronized replacability of the cache management > scheme is the architectural aspect of the design; the exact > algorithm, which is engineering, is not. Related paper: = http://ebookbrowse.com/an-analytical-model-for-the-lisp-cache-size-pdf-d36= 2171631 [snip] > 7.2. Design Guidance >=20 > In designing the security, there are a small number of key points > that will guide the design: >=20 > - Design lifetime > - Threat level >=20 > How long is the design intended to last? If LISP is successful, a > minimum of a 50-year lifetime is quite possible. (For comparison, > IPv4 is now 34 at the time of writing this, and will be around for = at > least several decades yet, if not longer; DNS is 28, and will > probably last indefinitely.) "will probably last indefinitely" is a strong statement, I suggest = removing it. > How serious are the threats it needs to meet? As mentioned above, > the Internet can bring the worst crackers from anywhere to any > location, in a flash. Their sophistication level is rising all the > time: as the easier holes are plugged, they go after others. This > will inevitably eventually require the most powerful security > mechanisms available to counteract their attacks. >=20 > Which is not to say that LISP needs to be that secure _right away_. > The threat will develop and grow over a long time period. However, > the basic design has to be capable of being _securable_ to the > expanded degree that will eventually be necessary. However, > _eventually_ it will need to be as securable as, say, DNS - i.e. it > _can_ be secured to the same level, although people may chose not = to > secure their LISP infrastructure as well as DNSSEC potentially = does. > [RFC4033] >=20 > In particular, it should be noted that historically many systems = have > been broken into, not through a weakness in the algorithms, etc, = but > because of poor operational mechanics. (The well-known 'Ultra' > breakins of the Allies were mostly due to failures in operational > procedure. [Welchman]) So operational capabilities intended to > reduce the chance of human operational failure are just as = important > as strong algorithms; making things operationally robust is a key > part of 'real' security. >=20 > 7.2.1. Security Mechanism Complexity >=20 > Complexity is bad for several reasons, and should always be reduced > to a minimum. There are three kinds of complexity cost: protocol > complexity, implementation complexity, and configuration = complexity. > We can further subdivide protocol complexity into packet format > complexity, and algorithm complexity. (There is some overlap of > algorithm complexity, and implementation complexity.) >=20 > We can, within some limits, trade off one kind of complexity for > others: e.g. we can provide configuration _options_ which are = simpler > for the users to operate, at the cost of making the protocol and > implementation complexity greater. And we can make initial (less > capable) implementations simpler if we make the protocols slightly > more complex (so that early implementations don't have to implement > all the features of the full-blown protocol). >=20 > It's more of a question of some operational convenience/etc issues = - > e.g. 'How easy will it be to recover from a cryptosystem > compromise'. If we have two ways to recover from a security > compromise, one which is mostly manual and a lot of work, and = another > which is more automated but makes the protocol more complicated, if > compromises really are very rare, maybe the smart call _is_ to go > with the manual thing - as long as we have looked carefully at both > options, and understood in some detail the costs and benefits of > each. >=20 > 7.3. Security Overview >=20 > First, there are two different classes of attack to be considered: > denial of service (DoS, i.e. the ability of an intruder to simply > cause traffic not to successfully flow) versus exploitation (i.e. = the > ability to cause traffic to be 'highjacked', i.e. traffic to be = sent > to the wrong location). >=20 > Second, one needs to look at all the places that may be attacked. > Again, LISP is a relatively simple system, so there are not that = many > parts to examine. The following are the things we need to secure: >=20 > - Lookups > - Indexing > - Mappings I suggest citing LISP-SEC. [snip] > 11.1.1. Missing Mapping Packet Queueing >=20 > Currently, some (all?) ITRs discard packets when they need a > mapping, but have not loaded one yet, thereby causing the = applicaton > to have to retransmit their opening packet. True, many ARP > implementations use the same strategy, but the average APR cache = will > only ever contain a few mappings, so it will not be so noticeable = as > with the mapping cache in an ITR, which will likely contain > thousands. >=20 > Obviously, they could queue the packets while waiting to load the > mapping, but this presents a number of subtle implementation = issues: > the ITR must make sure that it does not queue too many packets, = etc. >=20 > In particular, if such packets are queued, this presents a = potential > DoS attack vector, unless the code is carefully written with that > possibility in mind. A missing mapping packet can be also forwarded to a PETR avoiding = drop/buffering. > 11.1.2. Mapping Cache Management Algorithm >=20 > Relatively little work has been done on sophisticated mapping cache > management algorithms; in particular, the issue of which mapping(s) > to drop if the cache reaches some maximum allowed size. >=20 > This particular issue has also been identified as another potential > DoS attack vector. We have a technical report (not published yet, but public) discussing = and evaluating precisely this aspect. If needed we can share the = document. From acabello@ac.upc.edu Sat Nov 3 06:17:04 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C2C21F95DB for ; Sat, 3 Nov 2012 06:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, SARE_FWDLOOK=1.666] 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 3-av-L7wwipm for ; Sat, 3 Nov 2012 06:17:02 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8382021F95B8 for ; Sat, 3 Nov 2012 06:17:01 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qA3DGKo1016132; Sat, 3 Nov 2012 14:16:35 +0100 Received: from [10.0.0.7] (62.83.144.193.dyn.user.ono.com [62.83.144.193]) by gw.ac.upc.edu (Postfix) with ESMTP id 2E6966B0074; Sat, 3 Nov 2012 14:15:48 +0100 (CET) From: Albert Cabellos Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Nov 2012 14:15:34 +0100 Message-Id: <74BE17D6-1E2E-4E52-9907-0DDE1F012B06@ac.upc.edu> To: Noel Chiappa Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" Subject: [lisp] Comments on draft-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 13:17:04 -0000 Hi, Below are my comments on the introduction draft. Thanks! Albert [snip] > This likely resulted not just from lack of insight, but also the = fact > that extra mechanism is needed to support this separation (and in = the Typo, "that *an* extra mechanism" > early days there were no resources to spare), as well as the lack = of > need for it in the smaller networks of the time. (It is a truism = of > system design that small systems can get away with doing two things > with one mechanism, in a way that usually will not work when the > system gets much larger.) >=20 > The ISO protocol architecture took steps in this direction [NSAP], > but to the Internet community the necessity of a clear separation = was > definitively shown by Saltzer. [RFC1498] Later work expanded on > Saltzer's, and tied his separation concepts into the fate-sharing > concepts of Clark. [Clark], [Chiappa] >=20 > The separation of location and identity is a step which has = recently > been identified by the IRTF as a critically necessary evolutionary > architectural step for the Internet. However, it has taken some = time > for this requirement to be generally accepted by the Internet > engineering community at large, although it seems that this may > finally be happening. >=20 > The LISP system for separation of location and identity resulted = from > the discussions of this topic at the Amsterdam IAB Routing and > Addressing Workshop, which took place in October 2006. [RFC4984] >=20 > A small group of like-minded personnel from various scattered > locations within Cisco, spontaneously formed immediately after that > workshop, to work on an idea that came out of informal discussions = at > the workshop. The first Internet-Draft on LISP appeared in = January, > 2007, along with a LISP mailing list at the IETF. [LISP] >=20 > Trial implementations started at that time, with initial trial > deployments underway since June 2007; the results of early = experience > have been fed back into the design in a continuous, ongoing process > over several years. LISP at this point represents a moderately > mature system, having undergone a long organic series of changes = and > updates. >=20 > LISP transitioned from an IRTF activity to an IETF WG in March = 2009, > and after numerous revisions, the basic specifications moved to > becoming RFCs in 2012 (although work to expand and improve it > continues, and undoubtly will for a long time to come). >=20 > 2. Deployment Philosophy >=20 > It may seem odd to cover 'deployment philosophy' at this point in > such a document. However the deployment philosophy was a major > driver for much of the design (to some degree the architecture, and > to a very large measure, the engineering). So, as such an = important > motivator, it is very desirable for readers to have this material = in > hand as they examine the design, so that design choices that may = seem > questionable at first glance can be better understood. >=20 > Experience over the last several decades has shown that having a > viable 'deployment model' for a new design is absolutely key to the > success of that design. A new design may be fantastic - but if it > can not or will not be successfully deployed (for whatever = factors), > it is useless. This absolute primacy of a viable deployment model = is > what has lead to some painful compromises in the design. >=20 > The extreme focus on a viable deployment scheme is one of the > novelties of LISP. There is an in-depth discussion about deployment scenarios in: = http://tools.ietf.org/html/draft-ietf-lisp-deployment-05. I also suggest = citing this draft. > 2.1. Economics >=20 > The key factor in successful adoption, as shown by recent = experience > in the Internet - and little appreciated to begin with, some = decades > back - is economics: does the new design have benefits which = outweigh > its costs. Typo?: missing ? > More importantly, this balance needs to hold for early adopters - > because if they do not receive benefits to their adoption, the = sphere > of earliest adopters will not expand, and it will never get to > widespread deployment. One might have the world's best clean-slate > design, but if it does not have a deployment plan which is > economically feasible, it's just a mildly interesting piece of = paper. >=20 > This is particularly true of architectural enhancements, which are > far less likely to be an addition which one can 'bolt onto the = side' > of existing mechanisms, and often offer their greatest benefits = only > when widely (or ubiquitously) deployed. >=20 > Maximizing the cost-benefit ratio obviously has two aspects. = First, > on the cost side, by making the design as inexpensive as possible, > which means in part making the deployment as easy as possible. > Second, on the benefit side, by providing many new capabilities, > which is best done not by loading the design up with lots of = features > or options (which adds complexity), but by making the addition > powerful through deeper flexibility. We believe LISP has met both = of > these goals. Related paper: http://www.cs.princeton.edu/~jrex/papers/cacm10.pdf. I am = not suggesting citing it, but rather consider its main argument.=20 > 2.2. Maximize Re-use of Existing Mechanism >=20 > One key part of reducing the cost of a new design is to absolutely > minimize the amount of change _required_ to existing, deployed, > devices: the fewer devices need to be changed, and the smaller the > change to those that do, the lower the pain (and thus the greater = the > likelihood) of deployment. >=20 > Designs which absolutely require 'forklift upgrades' to large = amounts > of existing gear are far less likely to succeed - because they have > to have extremely large benefits to make their very substantial = costs > worthwhile. >=20 > It is for this reason that LISP, in most cases, initially requires = no > changes to devices in the Internet (both hosts and routers), and = also > initially reuses, whereever possible, existing protocols (IPv4 > [RFC791] and IPv6 [RFC2460]). The 'initially' must be stressed - > careful attention has also long been paid to the long-term future > (see [Future]), and larger changes become feasible as deployment > succeeds. I think that I am not understanding this section, LISP does requires = changes to some routers (a software update). > 2.3. Self-Deployment >=20 > LISP has deliberately employed a rather different deployment model, > which we might call 'self-deployment'; it does not require a huge > push to get it deployed, rather, it is hoped that once people see = it > and realize they can easily make good use of it _on their own_ = (i.e. > without requiring adoption by others), it will 'deploy itself' = (hence > the name of the approach). >=20 > One can liken the problem of deploying new systems in this way to > rolling a snowball down a hill: unless one starts with a big enough > initial snowball, and finds a hill of the right steepness (i.e. the > right path for it to travel, once it starts moving), one's snowball > is not going to go anywhere on its own. However, if one has picked > one's spot correctly, little additional work is needed - just stand > back and watch it go. The benefits of the above-mentioned "self-deployment" can be summarised = as the interoperability with existing infrastructure. As a result LISP = provides some benefits to early adopters while retaining full = compatibility with the legacy infrastructure.=20 > 3. LISP Overview >=20 > LISP is an incrementally deployable architectural upgrade to the > existing Internet infrastructure, one which provides separation of > location and identity. The separation is usually not perfect, for > reasons which are driven by the deployment philosophy (above), and > explored in a little more detail elsewhere (in [Architecture], > Section "Namespaces-EIDs-Residual"). >=20 > LISP separates the functions of location and identity, current > intermingled in IPvN addresses. (This document uses the meaning = for > 'address' proposed in [Atkinson], i.e. a name with mixed location = and > identity semantics.) >=20 > 3.1. Basic Approach >=20 > In LISP, nodes have both a 'locator' (a name which says _where_ in > the network's connectivity structure the node is), called an = 'RLOC', > and an 'identifier' (a name which serves only to provide a = persistent > handle for the node), called an 'EID'. A node may have more than = one > RLOC, or its RLOC may change over time (e.g. if the node is = mobile), > but it keeps the same EID. Suggested rewording: "RLOC, *and* its RLOC*(s) may change=85" > Technically, one should probably say that ideally, the EID names = the > node (or rather, its end-end communication stack, if one wants to = be > as forward-looking as possible), and the RLOC(s) name interface(s). > (At the moment, in reality, the situation is somewhat more complex, > as will be explained elsewhere (in [Architecture], Section > "Namespaces-EIDs-Residual"). >=20 > This second distinction, of _what_ is named by the two classes of > name, is necessary both to enable some of the capabilities that = LISP > provides (e.g the ability to seamlessly support multiple = interfaces, > to different networks), and is also a further enhancement to the > architecture. Faailing to clearly recognize both interfaces and > communication stacks as distinctly separate classes of things is > another failing of the existing Internet architecture (again, one > inherited from the previous generation of networking). Typo: Faailing > A novelty in LISP is that it uses existing IPvN addresses = (initially, > at least) for both of these kinds of names, thereby minimizing the > deployment cost, as well as providing the ability to easily = interact > with unmodified hosts and routers. >=20 > 3.2. Basic Functionality >=20 > The basic operation of LISP, as it currently stands, is that LISP > augmented packet switches near the source and destination of = packets > intercept traffic, and 'enhance' the packets. >=20 > The LISP device near the source looks up additional information = about > the destination, and then wraps the packet in an outer header, one > which contains some of that additional information. The LISP = device > near the destination removes that header, leaving the original, > unmodified, packet to be processed by the destination node. >=20 > The LISP device near the source (the Ingress Tunnel Router, or = 'ITR') > uses the information originally in the packet about the identity of > its ultimate destination, i.e. the destination address, which one = can > view as the EID of the ultimate destination. It uses the = destination > EID to look up the current location (the RLOC) of that EID. >=20 > The lookup is performed through a 'mapping system', which is the > heart of LISP: it is a distributed directory of bindings from EIDs = to > RLOCS. The destination RLOC will be (initially at least) the = address > of the LISP device near the destination (the Egress Tunnel Router, = or > 'ETR'). >=20 > The ITR then generates a new outer header for the original packet, > with that header containing the destination's RLOC as the wrapped > packet's destination, and the ITR's own address (i.e. the RLOC of = the > original source) as the wrapped packet's source, and sends it off. >=20 > When the packet gets to the ETR, that outer header is stripped off, > and the original packet is forwarded to the original ultimate > destination for normal processing. >=20 > Return traffic is handled similarly, often (depending on the > network's configuration) with the original ITR and ETR switching > roles. The ETR and ITR functionality is usually co-located in a > single device; these are normally denominated as 'xTRs'. In this section the Mapping System is defined as directory, in the = section below as a database. I suggest using a consistent notation. > 3.3. Mapping from EIDs to RLOCs >=20 > The mappings from EIDs to RLOCs are provided by a distributed (and > potentially replicated) database, the mapping database, which is = the > heart of LISP. >=20 > Mappings are requested on need, not (generally) pre-loaded; in = other > words, mapping are distributed via a 'pull' mechanism. Once = obtained > by an ITR, they are cached, to limit the amount of control traffic = to > a practicable level. (The mapping system will be discussed in more > detail below, in Section 5.2 and Section 9) >=20 > Extensive studies, including large-scale simulations driven by > lengthy recordings of actual traffic at several major sites, have > been performed to verify that this 'pull and cache' approach is > viable, in practical engineering terms. [Iannone] (This subject = will > be discussed in more detail in Section 9.5, below.) Related paper: = http://ebookbrowse.com/an-analytical-model-for-the-lisp-cache-size-pdf-d36= 2171631 This work presents an general analythical model that relates the = hit-rate, cache size vs. parameters describing the traffic and show the = feasability of lisp under some circumstances.=20 >=20 > 3.4. Interworking With Non-LISP-Capable Endpoints >=20 > The capability for 'easy' interoperation between nodes using LISP, > and existing non-LISP-using hosts or sites (often called 'legacy' > hosts), is clearly crucial. >=20 > To allow such interoperation, a number of mechanisms have been > designed. This multiplicity is in part because different = mechanisms > have different advantages and disadvantages (so that no single > mechanism is optimal for all cases), but also because with limited > field experience, it is not clear which (if any) approach will be > preferable. >=20 > One approach uses proxy LISP devices, called PITRs (proxy ITRs) and > PETRs (proxy ETRs), to provide LISP functionality during = interaction > with legacy sites. Another approach uses a device with combined = LISP > and NAT ([RFC1631]) functionality, named a LISP-NAT. I don=B4t see why LISP-NAT is mentioned here, LISP-NAT is not related = with interoperating with non-lisp capable endpoints. Could you please = clarify? [snip] > 4.3. Traffic Engineering >=20 > Traffic engineering (TE) [RFC3272], desirable though this = capability > is in a global network, is currently somewhat problematic to = provide > in the Internet. The problem, fundamentally, is that this = capability > was not visualized when the Internet was designed, so support for = it > is somewhat in the 'when the only tool you have is a hammer, > everything looks like nail' category. >=20 > TE is, fundamentally, a routing issue. However, the current = Internet > routing architecture, which is basically the Baran design of fifty > years ago [Baran] (a single large, distributed computationa), is = ill- > suited to provide TE. The Internet seems a long way from adopting = a > more-advanced routing architecture, although the basic concepts for > such have been known for some time. [RFC1992] >=20 > Although the identity-location binding layer is thus a poor place, > architecturally, to provide TE capabilities, it is still an > improvement over the current routing tools available for this = purpose > (e.g. injection of more-specific routes into the global routing > table). In addition, instead of the entire network incurring the > costs (through the routing system overhead), when using a binding > layer to provide TE, the overhead is limited to those who are > actually communicating with that particular destination. Why *poor*? Id/Loc binding is an efficient way to provide TE, and LISP = is a good example. Actually in section 9.4 it is defined as a "powerful" = way to provide such feature. > LISP includes a number of features in the mapping system to support > TE. (Described in Section 5.2 below.) > 4.4. Mobility >=20 > Mobility is yet another place where separation of location and > identity is obviously a key part of a clean, efficient and high- > functionality solution. Considerable experimentation has been > completed on doing mobility with LISP. >=20 > 4.5. IP Version Reciprocal Traversal >=20 > Note that LISP 'automagically' allows intermixing of various IP > versions for packet carriage; IPv4 packets might well be carried in > IPv6, or vice versa, depending on the network's configuration. = This > would allow an 'island' of operation of one type to be > 'automatically' tunneled over a stretch of infrastucture which only > supports the other type. >=20 > While the machinery of LISP may seem too heavyweight to be good for > such a mundane use, this is not intended as a 'sole use' case for > deployment of LISP. Rather, it is something which, if LISP is = being > deployed anyway (for its other advantages), is an added benefit = that > one gets 'for free'. >=20 > 4.6. Local Uses >=20 > LISP has a number of use cases which are within purely local > contexts, i.e. not in the larger Internet. These fall into two > categories: uses seen on the Internet (above), but here on a = private > (and usually small scale) setting; and applications which do not = have > a direct analog in the larger Internet, and which apply only to = local > deployments. >=20 > Among the former are multi-homing, IP version traversal, and = support > of VPN's for segmentation and multi-tenancy (i.e. a spatially > separated private VPN whose components are joined together using = the > public Internet as a backbone). >=20 > Among the latter class, non-Internet applications which have no > analog on the Internet, are the following example applications: > virtual machine mobility in data centers; other non-IP EID types = such > as local network MAC addresses, or application specific data. >=20 > 5. Major Functional Subsystems >=20 > LISP has only two major functional subsystems - the collection of > LISP packet switches (the xTRs), and the mapping system, which > manages the mapping database. The purpose and operation of each is > described at a high level below, and then, later on, in a fair = amount > of detail, in separate sections on each (Sections Section 8 and > Section 9, respectively). I suggest routers instead of switches given that xTRs operate at L3. [snip] > 8. xTRs >=20 > As mentioned above (in Section 5.1), xTRs are the basic = data-handling > devices in LISP. This section explores some advanced topics = related > to xTRs. >=20 > Careful rules have been specified for both TTL and ECN [RFC3168] to > ensure that passage through xTRs does not interfere with the > operation of these mechanisms. In addition, care has been taken to > ensure that 'traceroute' works when xTRs are involved. Could you provide arguments supporting such claim (last paragraph)? = AFAIK traceroute does not actually work in LISP given that it sees the = RLOC space as a single hop. > 8.1. When to Encapsulate >=20 > An ITR knows that a destination is running LISP, and thus that it > should perform LISP processing on a packet (including potential > encapsulation) if it has an entry in its local mapping cache that > covers the destination EID. >=20 > Conversely, if the cache contains a 'negative' entry (indicating = that > the ITR has previously attempted to find a mapping that covers this > EID, and it has been informed by the mapping system that no such > mapping exists), it knows the destination is not running LISP, and > the packet can be forwarded normally. >=20 > (The ITR cannot simply depend on the appearance, or non-appearance, > of the destination in the DFZ routing tables, as a way to tell if a > destination is a LISP site or not, because mechanisms to allow > interoperation of LISP sites and 'legacy' sites necessarily involve > advertising LISP sites' EIDs into the DFZ.) This scenario is defined as LISP+BGP in the lisp deployment draft. > 8.2. UDP Encapsulation Details >=20 > The UDP encapsulation used by LISP for carrying traffic from ITR to > ETR, and many of the details of how the it works, were all chosen = for > very practical reasons. >=20 > Use of UDP (instead of, say, a LISP-specific protocol number) was > driven by the fact that many devices filter out 'unknown' = protocols, > so adopting a non-UDP encapsulation would have made the initial > deployment of LISP harder - and our goal (see Section 2.1) was to > make the deployment as easy as possible. >=20 > The UDP source port in the encapsulated packet is a hash of the > original source and destination; this is because many ISPs use > multiple parallel paths (so-called 'Equal Cost Multi-Path'), and > load-share across them. Using such a hash in the source-port in = the > outer header both allows LISP traffic to be load-shared, and also > ensures that packets from individual connections are delivered in > order (since most ISPs try to ensure that packets for a particular > {source, source port, destination, destination port} tuple flow = along > a single path, and do not become disordered).. >=20 > The UDP checksum is zero because the inner packet usually already = has > a end-end checksum, and the outer checksum adds no value. = [Saltzer] > In most exising hardware, computing such a checksum (and checking = it > at the other end) would also present an intolerable load, for no > benefit. Typo? end-to-end? > 8.5. Mapping Gleaning in ETRs >=20 > As an optimization to the mapping acquisition process, ETRs are > allowed to 'glean' mappings from incoming user data packets, and = also > from incoming Map-Request control messages. This is not secure, = and > so any such mapping must be 'verified' by sending a Map-Request to > get an authoritative mapping. (See further discussion of the > security implications of this in [Architecture], Section "Security- > xTRs".) >=20 > The value of gleaning is that most communications are two-way, and = so > if host A is sending packets to host B (therefore needing B's > EID->RLOC mapping), very likely B will soon be sending packets back > to A (and thus needing A's EID->RLOC mapping). Without gleaning, > this would sometimes result in a delay, and the dropping of the = first > return packet; this is felt to be very undesirable. IMO gleaning is not secure, this is well accepted by the WG and should = be clearly discouraged. [snip] > 9.2.2. Map-Reply Maessages Typo: Messages [snip] > 10.1. Internetworking Mechanism >=20 > One aspect which has received a lot of attention are the mechanisms > previously referred to (in Section 3.4) to allow interoperation of > LISP sites with so-called 'legacy' sites which are not running LISP > (yet). (yet)->This is a very strong statement, I suggest removing it. > To briefly refresh what was said there, there are two main = approaches > to such interworking: proxy nodes (PITRs and PETRs), and an > alternative mechanism using device with combined NAT and LISP > functionality; these are described in more detail here. >=20 > 10.2. Proxy Devices >=20 > PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to > nodes using LISP. PETRs (proxy ETRs) serve as ETRs for LISP = traffic > _to_ legacy hosts (for cases where a LISP device cannot send = packets > directly to such sites, without encapsulation). >=20 > Note that return traffic _to_ a legacy site from a LISP-using node > does not necessarily have to pass through an ITR/PETR pair - the > original packets can usually just be sent directly to the > destination. However, for some kinds of LISP operation (e.g. = mobile > nodes), this is not possible; in these situations, the PETR is > needed. The main reason behind this is uPRF, I suggest mentioning it. > 10.2.1. PITRs >=20 > PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to > nodes using LISP. To do that, they have to advertise into the > existing legacy backbone Internet routing the availability of > whatever ranges of EIDs (i.e. of nodes using LISP) they are = proxying > for, so that legacy hosts will know where to send traffic to those > LISP nodes. >=20 > As mentioned previously (Section 8.1), an ITR at another LISP site > can avoid using a PITR (i.e. it can detect that a given destination > is not a legacy site, if a PITR is advertising it into the DFZ) by > checking to see if a LISP mapping exists for that destination. >=20 > This technique obviously has an impact on routing table in the DFZ, > but it is not clear yet exactly what that impact will be; it is = very > dependent on the collected details of many individual deployment > decisions. >=20 > A PITR may cover a group of EID blocks with a single EID > advertisement, in order to reduce the number of routing table = entries > added. (In fact, at the moment, aggressive aggregation of EID > announcements is performed, precisely to to minimize the number of > new announced routes added by this technique.) >=20 > At the same time, it a site does traffic engineering with LISP > instead of fine-grained BGP announcement, that will help keep table > sizes down (and this is true even in the early stages of LISP > deployment). The same is true for multi-homing. In the deployment draft we describe the Proxy-ITR Route Distribution = (PITR-RD), I think it makes sense to mention it here. >=20 > 10.2.2. PETRs >=20 > PETRs (proxy ETRs) serve as ETRs for LISP traffic _to_ legacy = hosts, > for cases where a LISP device cannot send packets to sites without > encapsulation. That typically happens for one of two reasons. >=20 > First, it will happen in places where some device is implementing > Unicast Reverse Path Forwarding (uRPF), to prevent a variety of > negative behaviour; originating packets with the source's EID in = the > source address field will result in them being filtered out and > discarded. >=20 > Second, it will happen when a LISP site wishes to send packets to a > non-LISP site, and the path in between does not support the > particular IP protocol version used by the source along its entir > length. Use of a PETR on the other side of the 'gap' will allow = the > LISP site's packet to 'hop over' the gap, by utilizing LISP's > built-in support for mixed protocol encapsulation. >=20 > PETRs are generally paired with specific ITRs, which have the > location of their PETRs configured into them. In other words, = unlike > normal ETRS, PETRs do not have to register themselves in the = mapping > database, on behalf of any legacy sites they serve. >=20 > Also, allowing an ITR to always send traffic leaving a site to a = PETR > does avoid having to chose whether or not to encapsulate packets; = it > can just always encapsulate packets, sending them to the PETR if it > has no specific mapping for the destination. However, this is not > advised: as mentioned, it is easy to tell if something is a legacy > destination. PETR can be used also to forward packets that miss in the map-cache, = this avoids drops/buffering and improves the overall performance. It is = also very easy to implement. > 10.3. LISP-NAT >=20 > A LISP-NAT device, as previously mentioned, combines LISP and NAT > functionality, in order to allow a LISP site which is internally > using addresses which cannot be globally routed to communicate with > non-LISP sites elsewhere in the Internet. (In other words, the > technique used by the PITR approach simply cannot be used in this > case.) >=20 > To do this, a LISP-NAT performs the usual NAT functionality, and > translates a host's source address(es) in packets passing through = it > from an 'inner' value to an 'outer' value, and storing that > translation in a table, which it can use to similarly process > subsequent packets (both outgoing and incoming). [Interworking] >=20 > There are two main cases where this might apply: > - Sites using non-routable global addresses > - Sites using private addresses [RFC1918] >=20 > 10.4. LISP and DFZ Routing >=20 > {{To be written.}} >=20 > 10.5. Use Through NAT Devices >=20 > Like them or not (and NAT devices have many egregious issues - some > inherent in the nature of the process of mapping addresses; others, > such as the brittleness due to non-replicated critical state, = caused > by the way NATs were introduced, as stand-alone 'invisible' boxes), > NATs are both ubiquitous, and here to stay for a long time to come. >=20 > Thus, in the actual Internet of today, having any new mechanisms > function well in the presence of NATs (i.e. with LISP xTRs behind a > NAT device) is absolutely necessary. LISP has produced a variety = of > mechanisms to do this. >=20 > 10.5.1. First-Phase NAT Support >=20 > The first mechanism used by LISP to operate through a NAT device = only > worked with some NATs, those which were configurable to allow = inbound > packet traffic to reach a configured host. >=20 > A pair of new LISP control messages, LISP Echo-Request and Echo- > Reply, allowed the ETR to discover its temporary global address; = the > Echo-Request was sent to the configured Map-Server, and it replied > with an Echo-Reply which included the source address from which the > Echo Request was received (i.e. the public global address assigned = to > the ETR by the NAT). The ETR could then insert that address in any > Map-Reply control messages which it sent to correspondent ITRs. >=20 > The fact that this mechanism did not support all NATs, and also > required manual configuration of the NAT, meant that this was not a > good solution; in addition, since LISP expects all incoming data > traffic to be on a specific port, it was not possible to have > multiple ETRs behind a single NAT (which normally would have only = one > global address to share, meaning port mapping would have to be = used, > except that... ) IMHO this provides too much details to the reader. This is the only LISP = feature that is presented along with its history.=20 [snip] > 11.2. Replacement of ALT with DDT >=20 > As mentioned in Section 9.2, an interface is provided to allow > replacement of the indexing subsystem. LISP initially used an > indexing system called ALT. [ALT] ALT was relatively easy to > construct from existing tools (GRE, BGP, etc), but it had a number = of > issues that made it unsuitable for large-scale use. ALT is now = being > superseded by DDT. >=20 > As indicated previously (Section 9.5), the basic structure and > operation of DDT is identical to that of TREE, so the extensive > simulation work done for TREE applies equally to DDT, as do the > conclusions drawn about TREE's superiority to ALT. [Jakab] >=20 > {{Briefly synopsize results}} If needed, I volunteer to write a short summary of the main results. >=20 > 11.2.1. Why Not Use DNS >=20 > One obvious question is 'Since DDT is so similar to DNS, why not > simply use DNS?' In particular, people are familiar with the DNS, > how to configure it, etc - would it not thus be preferable to use = it? > To completely answer this would take more space that available = here, > but, briefly, there were two main reasons, and one lesser one. >=20 > First, the syntax of DNS names did not lend itself to looking up > names in other syntaxes (e.g. bit fields). This is a problem which > has been previously encountered, e.g. in reverse address lookups. > [RFC5855] >=20 > Second, as an existing system, the interfaces between DNS (should = it > have been used as an indexing subsystem for LISP) would not be > 'tuneable' to be optimal for LISP. For instance, if it were = desired > to have the leaf node in an indexing lookup directly contact the = ETR > on behalf of the node doing the lookup (thereby avoiding a = round-trip > delay), that would not be easy without modifications to the DNS = code. > Obviously, with a 'custom' system, this issue does not arise. >=20 > Finally, DNS security, while robust, is fairly complex. Doing DDT > offered an opportunity to provide a more nuanced security model. > (See [Architecture], Section "Security" for more about this.) Last paragraph->This is a strong statement presented without the = appropriate arguments. I don=B4t see why DDT security (not discussed in = detail) is less complex that DNS-SEC.=20 From jnc@mercury.lcs.mit.edu Sat Nov 3 06:22:09 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E3721F98D7 for ; Sat, 3 Nov 2012 06:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] 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 E+fw2-v6-kug for ; Sat, 3 Nov 2012 06:22:08 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8403021F95DD for ; Sat, 3 Nov 2012 06:22:08 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9350318C0DD; Sat, 3 Nov 2012 09:22:07 -0400 (EDT) To: lisp@ietf.org Message-Id: <20121103132207.9350318C0DD@mercury.lcs.mit.edu> Date: Sat, 3 Nov 2012 09:22:07 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on lisp-architecture X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 13:22:09 -0000 > From: Albert Cabellos Hi, thanks for the comments; I'll reply in detail later, but one thing that caught my eye quickly: > MPLS-> Although it is a good analogy, I don't think that MPLS is a good > example given that with LISP we can't stack labels. ??? LISP does use 'stacked' encapsulations (e.g. for a mobile node moving to a LISP site)? And the mapping output could be an MPLS header with a 'pre-loaded' label stack (that's how you do source routing in a label-based system - I'm not sure if the existing MPLS stuff uses that capability, but eventually in Nimrod [which was the place that came up with the idea of label stacks, see RFC-1753] we realized that was how to minimize state setup, by 'pre-loading' the flow stack at the time the packet is created). So I'm not sure I understand this comment? In any case, I'm OK with using some other example - I just used MPLS because that's one that had been discussed, because there's a lot of MPLS-capable infrastructure already deployed. Did you have an alternative suggestion? I can't quickly come up with one that's as good as MPLS. Noel From fcoras@ac.upc.edu Sat Nov 3 13:22:25 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475EC21F9C91 for ; Sat, 3 Nov 2012 13:22:25 -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=[BAYES_50=0.001, SARE_FWDLOOK=1.666] 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 XZ-aboI6xg1q for ; Sat, 3 Nov 2012 13:22:20 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id B172121F9C94 for ; Sat, 3 Nov 2012 13:22:19 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qA3KLRua021010; Sat, 3 Nov 2012 21:21:32 +0100 Received: from [10.8.0.18] (unknown [10.8.0.18]) by gw.ac.upc.edu (Postfix) with ESMTP id A118E6B0074; Sat, 3 Nov 2012 21:20:55 +0100 (CET) Message-ID: <50957CA2.5090804@ac.upc.edu> Date: Sat, 03 Nov 2012 21:20:50 +0100 From: Florin Coras User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Noel Chiappa , lisp@ietf.org Content-Type: multipart/mixed; boundary="------------080208030008020904060804" Subject: [lisp] Comments on draft-ietf-lisp-introduction-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 20:22:25 -0000 This is a multi-part message in MIME format. --------------080208030008020904060804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Hereafter my comments on the introduction draft. Florin --------------080208030008020904060804 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-lisp-introduction-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-lisp-introduction-00.txt" LISP Working Group J. N. Chiappa Internet-Draft Yorktown Museum of Asian Art Intended status: Informational October 15, 2012 Expires: April 18, 2013 An Introduction to the LISP Location-Identity Separation System draft-ietf-lisp-introduction-00 Abstract LISP is an upgrade to the architecture of the IPvN internetworking system, one which separates location and identity (currently intermingled in IPvN addresses). This is a change which has been identified by the IRTF as a critically necessary evolutionary architectural step for the Internet. In LISP, nodes have both a 'locator' (a name which says _where_ in the network's connectivity structure the node is) and an 'identifier' (a name which serves only to provide a persistent handle for the node). A node may have more than one locator, or its locator may change over time (e.g. if the node is mobile), but it keeps the same identifier. One of the chief novelties of LISP, compared to other proposals for the separation of location and identity, is its approach to deploying this upgrade. (In general, it is comparatively easy to conceive of new network designs, but much harder to devise approaches which will actually get deployed throughout the global network.) LISP aims to achieve the near-ubiquitous deployment necessary for maximum exploitation of an architectural upgrade by i) minimizing the amount of change needed (existing hosts and routers can operate unmodified); and ii) by providing significant benefits to early adopters. This document is an introduction to the entire LISP system, for those who are unfamiliar with it. It is intended to be both easy to follow, and also give a fairly detailed understanding of the entire system. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 18, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Background 2. Deployment Philosophy 2.1. Economics 2.2. Maximize Re-use of Existing Mechanism 2.3. Self-Deployment 3. LISP Overview 3.1. Basic Approach 3.2. Basic Functionality 3.3. Mapping from EIDs to RLOCs 3.4. Interworking With Non-LISP-Capable Endpoints 4. Initial Applications 4.1. Provider Independence 4.2. Multi-Homing 4.3. Traffic Engineering 4.4. Mobility 4.5. IP Version Reciprocal Traversal 4.6. Local Uses 5. Major Functional Subsystems 5.1. xTRs 5.2. Mapping System 5.2.1. Mapping System Organization 5.2.2. Interface to the Mapping System 5.2.3. Indexing Subsystem 6. Examples of Operation 6.1. An Ordinary Packet's Processing 6.2. A Mapping Cache Miss 7. Design Approach 7.1. Quick Implement-Test Loop 7.1.1. No Desk Fixes 7.1.2. Code Before Documentation 7.2. Only Fix Real Problems 7.3. No Theoretical Perfection 7.3.1. No Ocean Boiling 7.4. Just Enough Security 8. xTRs 8.1. When to Encapsulate 8.2. UDP Encapsulation Details 8.3. Header Control Channel 8.3.1. Echo Nonces 8.3.2. Instances 8.4. Fragmentation 8.5. Mapping Gleaning in ETRs 9. The Mapping System 9.1. The Indexing Subsystem 9.2. The Mapping System Interface 9.2.1. Map-Request Messages 9.2.2. Map-Reply Maessages 9.2.3. Map-Register and Map-Notify Messages 9.2.4. Map-Referral Messages 9.3. Reliability via Replication 9.4. Extended Tools 9.5. Expected Performance 10. Deployment Mechanisms 10.1. Internetworking Mechanism 10.2. Proxy Devices 10.2.1. PITRs 10.2.2. PETRs 10.3. LISP-NAT 10.4. LISP and DFZ Routing 10.5. Use Through NAT Devices 10.5.1. First-Phase NAT Support 10.5.2. Second-Phase NAT Support 11. Current Improvements 11.1. Mapping Versioning 11.2. Replacement of ALT with DDT 11.2.1. Why Not Use DNS 11.3. Mobile Device Support 11.4. Multicast Support 11.5. {{Any others?}} 12. Fault Discovery/Handling 12.1. Handling Missing Mappings 12.2. Outdated Mappings 12.2.1. Outdated Mappings - Updated Mapping 12.2.2. Outdated Mappings - Wrong ETR 12.2.3. Outdated Mappings - No Longer an ETR 12.3. Erroneous mappings 12.4. Neighbour Liveness 12.5. Neighbour Reachability 13. Acknowledgments 14. IANA Considerations 15. Security Considerations 16. References 16.1. Normative References 16.2. Informative References Appendix A. Glossary/Definition of Terms Appendix B. Other Appendices 1. Background It has gradually been realized in the networking community that networks (especially large networks) should deal quite separately with the identity and location of a node (basically, 'who' a node is, and 'where' it is). At the moment, in both IPv4 and IPv6, addresses indicate both where the named device is, as well as identify it for purposes of end-end communication. The distinction was more than a little hazy at first: the early Internet [RFC791], like the ARPANET before it [Heart] [NIC8246], co- mingled the two, although there was recognition in the early Internet work that there were two different things going on. [IEN19] This likely resulted not just from lack of insight, but also the fact that extra mechanism is needed to support this separation (and in the early days there were no resources to spare), as well as the lack of need for it in the smaller networks of the time. (It is a truism of system design that small systems can get away with doing two things with one mechanism, in a way that usually will not work when the system gets much larger.) The ISO protocol architecture took steps in this direction [NSAP], but to the Internet community the necessity of a clear separation was definitively shown by Saltzer. [RFC1498] Later work expanded on Saltzer's, and tied his separation concepts into the fate-sharing concepts of Clark. [Clark], [Chiappa] The separation of location and identity is a step which has recently been identified by the IRTF as a critically necessary evolutionary architectural step for the Internet. However, it has taken some time for this requirement to be generally accepted by the Internet engineering community at large, although it seems that this may finally be happening. The LISP system for separation of location and identity resulted from the discussions of this topic at the Amsterdam IAB Routing and Addressing Workshop, which took place in October 2006. [RFC4984] A small group of like-minded personnel from various scattered locations within Cisco, spontaneously formed immediately after that workshop, to work on an idea that came out of informal discussions at the workshop. The first Internet-Draft on LISP appeared in January, 2007, along with a LISP mailing list at the IETF. [LISP] Trial implementations started at that time, with initial trial deployments underway since June 2007; the results of early experience have been fed back into the design in a continuous, ongoing process over several years. LISP at this point represents a moderately mature system, having undergone a long organic series of changes and updates. LISP transitioned from an IRTF activity to an IETF WG in March 2009, and after numerous revisions, the basic specifications moved to becoming RFCs in 2012 (although work to expand and improve it continues, and undoubtly will for a long time to come). 2. Deployment Philosophy It may seem odd to cover 'deployment philosophy' at this point in such a document. However the deployment philosophy was a major driver for much of the design (to some degree the architecture, and to a very large measure, the engineering). So, as such an important motivator, it is very desirable for readers to have this material in hand as they examine the design, so that design choices that may seem questionable at first glance can be better understood. Experience over the last several decades has shown that having a viable 'deployment model' for a new design is absolutely key to the success of that design. A new design may be fantastic - but if it can not or will not be successfully deployed (for whatever factors), it is useless. This absolute primacy of a viable deployment model is what has lead to some painful compromises in the design. The extreme focus on a viable deployment scheme is one of the novelties of LISP. 2.1. Economics The key factor in successful adoption, as shown by recent experience in the Internet - and little appreciated to begin with, some decades back - is economics: does the new design have benefits which outweigh its costs. More importantly, this balance needs to hold for early adopters - because if they do not receive benefits to their adoption, the sphere of earliest adopters will not expand, and it will never get to widespread deployment. One might have the world's best clean-slate design, but if it does not have a deployment plan which is economically feasible, it's just a mildly interesting piece of paper. This is particularly true of architectural enhancements, which are far less likely to be an addition which one can 'bolt onto the side' of existing mechanisms, and often offer their greatest benefits only when widely (or ubiquitously) deployed. Maximizing the cost-benefit ratio obviously has two aspects. First, on the cost side, by making the design as inexpensive as possible, which means in part making the deployment as easy as possible. Second, on the benefit side, by providing many new capabilities, which is best done not by loading the design up with lots of features or options (which adds complexity), but by making the addition powerful through deeper flexibility. We believe LISP has met both of these goals. 2.2. Maximize Re-use of Existing Mechanism One key part of reducing the cost of a new design is to absolutely minimize the amount of change _required_ to existing, deployed, devices: the fewer devices need to be changed, and the smaller the change to those that do, the lower the pain (and thus the greater the likelihood) of deployment. Designs which absolutely require 'forklift upgrades' to large amounts of existing gear are far less likely to succeed - because they have to have extremely large benefits to make their very substantial costs worthwhile. It is for this reason that LISP, in most cases, initially requires no changes to devices in the Internet (both hosts and routers), and also initially reuses, whereever possible, existing protocols (IPv4 [RFC791] and IPv6 [RFC2460]). The 'initially' must be stressed - careful attention has also long been paid to the long-term future (see [Future]), and larger changes become feasible as deployment succeeds. 2.3. Self-Deployment LISP has deliberately employed a rather different deployment model, which we might call 'self-deployment'; it does not require a huge push to get it deployed, rather, it is hoped that once people see it and realize they can easily make good use of it _on their own_ (i.e. without requiring adoption by others), it will 'deploy itself' (hence the name of the approach). One can liken the problem of deploying new systems in this way to rolling a snowball down a hill: unless one starts with a big enough initial snowball, and finds a hill of the right steepness (i.e. the right path for it to travel, once it starts moving), one's snowball is not going to go anywhere on its own. However, if one has picked one's spot correctly, little additional work is needed - just stand back and watch it go. 3. LISP Overview LISP is an incrementally deployable architectural upgrade to the existing Internet infrastructure, one which provides separation of location and identity. The separation is usually not perfect, for reasons which are driven by the deployment philosophy (above), and explored in a little more detail elsewhere (in [Architecture], Section "Namespaces-EIDs-Residual"). LISP separates the functions of location and identity, current intermingled in IPvN addresses. (This document uses the meaning for 'address' proposed in [Atkinson], i.e. a name with mixed location and identity semantics.) 3.1. Basic Approach In LISP, nodes have both a 'locator' (a name which says _where_ in the network's connectivity structure the node is), called an 'RLOC', and an 'identifier' (a name which serves only to provide a persistent handle for the node), called an 'EID'. A node may have more than one RLOC, or its RLOC may change over time (e.g. if the node is mobile), but it keeps the same EID. Technically, one should probably say that ideally, the EID names the node (or rather, its end-end communication stack, if one wants to be as forward-looking as possible), and the RLOC(s) name interface(s). (At the moment, in reality, the situation is somewhat more complex, as will be explained elsewhere (in [Architecture], Section "Namespaces-EIDs-Residual"). This second distinction, of _what_ is named by the two classes of name, is necessary both to enable some of the capabilities that LISP provides (e.g the ability to seamlessly support multiple interfaces, to different networks), and is also a further enhancement to the architecture. Faailing FC: typo "faaling" to clearly recognize both interfaces and communication stacks as distinctly separate classes of things is another failing of the existing Internet architecture (again, one inherited from the previous generation of networking). A novelty in LISP is that it uses existing IPvN addresses (initially, at least) for both of these kinds of names, thereby minimizing the deployment cost, as well as providing the ability to easily interact with unmodified hosts and routers. 3.2. Basic Functionality The basic operation of LISP, as it currently stands, is that LISP augmented packet switches FC: Although I understand the reasoning, shouldn't 'switches' be replaced by 'routers' for clarity? near the source and destination of packets intercept traffic, and 'enhance' the packets. The LISP device near the source looks up additional information about the destination, and then wraps the packet in an outer header, one which contains some of that additional information. The LISP device near the destination removes that header, leaving the original, unmodified, packet to be processed by the destination node. The LISP device near the source (the Ingress Tunnel Router, or 'ITR') uses the information originally in the packet about the identity of its ultimate destination, i.e. the destination address, which one can view as the EID of the ultimate destination. It uses the destination EID to look up the current location (the RLOC) of that EID. The lookup is performed through a 'mapping system', which is the heart of LISP: it is a distributed directory of bindings from EIDs to RLOCS. The destination RLOC will be (initially at least) the address of the LISP device near the destination (the Egress Tunnel Router, or 'ETR'). The ITR then generates a new outer header for the original packet, with that header containing the destination's RLOC as the wrapped packet's destination, and the ITR's own address (i.e. the RLOC of the original source) as the wrapped packet's source, and sends it off. When the packet gets to the ETR, that outer header is stripped off, and the original packet is forwarded to the original ultimate destination for normal processing. Return traffic is handled similarly, often (depending on the network's configuration) with the original ITR and ETR switching roles. The ETR and ITR functionality is usually co-located in a single device; these are normally denominated as 'xTRs'. 3.3. Mapping from EIDs to RLOCs The mappings from EIDs to RLOCs are provided by a distributed (and potentially replicated) database, the mapping database, which is the heart of LISP. Mappings are requested on need, not (generally) pre-loaded; in other words, mapping are distributed via a 'pull' mechanism. Once obtained by an ITR, they are cached, to limit the amount of control traffic to a practicable level. (The mapping system will be discussed in more detail below, in Section 5.2 and Section 9) Extensive studies, including large-scale simulations driven by lengthy recordings of actual traffic at several major sites, have been performed to verify that this 'pull and cache' approach is viable, in practical engineering terms. [Iannone] (This subject will be discussed in more detail in Section 9.5, below.) FC: I'm left thinking that this section should be part of the "Basic Approach" section. LISP is map-and-encap, i.e., splitting address semantics and binding them through a mapping system. Otherwise, maybe "Basic Approach" should be renamed to something along the lines of "Naming and Addressing". 3.4. Interworking With Non-LISP-Capable Endpoints The capability for 'easy' interoperation between nodes using LISP, and existing non-LISP-using hosts or sites (often called 'legacy' hosts), is clearly crucial. To allow such interoperation, a number of mechanisms have been designed. This multiplicity is in part because different mechanisms have different advantages and disadvantages (so that no single mechanism is optimal for all cases), but also because with limited field experience, it is not clear which (if any) approach will be preferable. One approach uses proxy LISP devices, called PITRs (proxy ITRs) and PETRs (proxy ETRs), to provide LISP functionality during interaction with legacy sites. Another approach uses a device with combined LISP and NAT ([RFC1631]) functionality, named a LISP-NAT. 4. Initial Applications As previously mentioned, it is felt that LISP will provide even the earliest adopters with some useful capabilities, and that these capabilities will drive early LISP deployment. It is very imporant to note that even when used only for interoperation with existing unmodified hosts, use of LISP can still provide benefits for communications with the site which has deployed it - and, perhaps even more importantly, can do so _to both sides_. This characteristic acts to further enhance the utility for early adopters of deploying LISP, thereby increasing the cost/benefit ratio needed to drive deployment, and increasing the 'self-deployment' aspect of LISP. Note also that this section only lists likely _early_ applications and benefits - if and once deployment becomes more widespread, other aspects will come into play (as described in [Architecture], in the "Goals of LISP" section). 4.1. Provider Independence Provider independence (i.e. the ability to easily change one's Internet Service Provider) was probably the first place where the Internet engineering community finally really felt the utility of separating location and identity. The problem is simple: for the global routing to scale, addresses need to be aggregated (i.e. things which are close in the overall network's connectivity need to have closely related addresses), the so-called "provider aggregated" addresses. [RFC4116] However, if this principle is followed, it means that when an entity switches providers (i.e. it moves to a different 'place' in the network), it has to renumber, a painful undertaking. [RFC5887] In theory, it ought to be possible to update the DNS entries, and have everyone switch to the new addresses, but in practise, FC: practice addresses are embedded in many places, such as firewall configurations at other sites. Having separate namespaces for location and identity greatly reduces the problems involved with renumbering; an organization which moves retains its EIDs (which are how most other parties refer to its nodes), but is allocated new RLOCs, and the mapping system can quickly provide the updated binding from the EIDs to the new RLOCs. 4.2. Multi-Homing Multi-homing is another place where the value of separation of location and identity became apparent. FC: since Provider Independence was defined above, should't this also? There are several different sub-flavours of the multi-homing problem - e.g. depending on whether one wants open connections to keep working, etc - and other axes as well (e.g. site multi-homing versus host multi-homing). In particular, for the 'keep open connections up' case, without separation of location and identity, the only currently feasible approach is to use provider-independent addressses - which moves the problem into the global routing system, with attendant costs. This approach is also not really feasible for host multi-homing. Multi-homing was once somewhat esoteric, but a number of trends are driving an increased desirability, e.g. the wish to have multiple ISP links to a site for robustness; the desire to have mobile handsets connect up to multiple wireless systems; etc. Again, separation of location and identity, and the existince of a binding layer which can be updated fairly quickly, as provided by LISP, is a very useful tool for all variants of this issue. 4.3. Traffic Engineering FC: same as for Multi-Homing Traffic engineering (TE) [RFC3272], desirable though this capability is in a global network, is currently somewhat problematic to provide in the Internet. The problem, fundamentally, is that this capability was not visualized when the Internet was designed, so support for it is somewhat in the 'when the only tool you have is a hammer, everything looks like nail' category. TE is, fundamentally, a routing issue. However, the current Internet routing architecture, which is basically the Baran design of fifty years ago [Baran] (a single large, distributed computationa), is ill- suited to provide TE. The Internet seems a long way from adopting a more-advanced routing architecture, although the basic concepts for such have been known for some time. [RFC1992] Although the identity-location binding layer is thus a poor place, architecturally, to provide TE capabilities, it is still an improvement over the current routing tools available for this purpose (e.g. injection of more-specific routes into the global routing table). In addition, instead of the entire network incurring the costs (through the routing system overhead), when using a binding layer to provide TE, the overhead is limited to those who are actually communicating with that particular destination. LISP includes a number of features in the mapping system to support TE. (Described in Section 5.2 below.) 4.4. Mobility Mobility is yet another place where separation of location and identity is obviously a key part of a clean, efficient and high- functionality solution. Considerable experimentation has been completed on doing mobility with LISP. FC: maybe it would be worth saying that both host and network mobility is achievable (like in the case of multihoming). 4.5. IP Version Reciprocal Traversal Note that LISP 'automagically' allows intermixing of various IP versions for packet carriage; IPv4 packets might well be carried in IPv6, or vice versa, depending on the network's configuration. This would allow an 'island' of operation of one type to be 'automatically' tunneled over a stretch of infrastucture which only supports the other type. While the machinery of LISP may seem too heavyweight to be good for such a mundane use, this is not intended as a 'sole use' case for deployment of LISP. Rather, it is something which, if LISP is being deployed anyway (for its other advantages), is an added benefit that one gets 'for free'. 4.6. Local Uses LISP has a number of use cases which are within purely local contexts, i.e. not in the larger Internet. These fall into two categories: uses seen on the Internet (above), but here on a private (and usually small scale) setting; and applications which do not have a direct analog in the larger Internet, and which apply only to local deployments. Among the former are multi-homing, IP version traversal, and support of VPN's for segmentation and multi-tenancy (i.e. a spatially separated private VPN whose components are joined together using the public Internet as a backbone). Among the latter class, non-Internet applications which have no analog on the Internet, are the following example applications: virtual machine mobility in data centers; other non-IP EID types such as local network MAC addresses, or application specific data. 5. Major Functional Subsystems LISP has only two major functional subsystems - the collection of LISP packet switches (the xTRs), and the mapping system, which manages the mapping database. The purpose and operation of each is described at a high level below, and then, later on, in a fair amount of detail, in separate sections on each (Sections Section 8 and Section 9, respectively). 5.1. xTRs xTRs are fairly normal packet switches, enhanced with a little extra functionality in both the data and control planes, to perform LISP data and control functionality. The data plane functions in ITRs include deciding which packets need to be given LISP processing (since packets to non-LISP sites may be sent 'vanilla'); looking up the mapping; encapsulating the packet; and sending it to the ETR. This encapsulation is done using UDP [RFC768] (for reasons to be explained below, in Section 8.2), along with an additional IPvN header (to hold the asource FC: source and destination RLOCs). To the extent that traffic engineering features are in use for a particular EID, the ITRs implement them as well. In the ETR, the data plane simply unwraps the packets, and forwards the 'vanilla' packets to the ultimate destination. Control plane functions in ITRs include: asking for {EID->RLOC} mappings via Map-Request control messages; handling the returning Map-Replies which contain the requested information; managing the local cache of mappings; checking for the reachability and liveness of their neighbour ETRs; and checking for outdated mappings and requesting updates. In the ETR, control plane functions include participating in the neighbour reachability and liveness function (see Section 12.4); interacting with the mapping indexing system (next section); and answering requests for mappings (ditto). 5.2. Mapping System The mapping database is a distributed, and potentially replicated, database which holds bindings between EIDs (identity) and RLOCs (location). To be exact, it contains bindings between EID blocks and RLOCs (the block size is given explicitly, as part of the syntax). Support for blocks is both for minimizing the administrative configuration overhead, as well as for operational efficiency; e.g. when a group of EIDs are behind a single xTR. However, the block may be (and often is) as small as a single EID. Since mappings are only loaded upon demand, if smaller blocks become predominant, then the increased size of the overall database is far less problematic than if the routing table came to be dominated by such small entries. A particular node may have more than one RLOC, or may change its RLOC(s), while keeping its singlar identity. The binding contains not just the RLOC(s), but also (for each RLOC for any given EID) priority and weight (to allow allocation of load between several RLOCs at a given priority); this allows a certain amount of traffic engineering to be accomplished with LISP. 5.2.1. Mapping System Organization The mapping system is actually split into two major functional sub- systems. The actual bindings themselves are held by the ETRs, and an ITR which needs a binding effectively gets it from the ETR. This co-location of the authoritative version of the mappings, and the forwarding functionality which it describes, is an instance of fate-sharing. [Clark] To find the appropriate ETR(s) to query for the mapping, the second subsystem, an 'indexing system', itself also a distributed, potentally replicated database, provides information on which ETR(s) are authoritative sources of information about the bindings which are available. 5.2.2. Interface to the Mapping System The client interface to the mapping system from an ITR's point of view is not with the indexing system directly; rather, it is through devices called Map Resolvers (MRs). ITRs send request control messages (Map-Request packets) to an MR. (This interface is probably the most important standardized interface in LISP - it is the key to the entire system.) The MR uses the indexing system to eventually forward the Map-Request to the appropriate ETR. The ETR formulates reply control messages (Map- Reply packets), which is conveyed to the ITR. The details of the indexing system, etc, are thus hidden from the 'ordinary' ITRs. Similarly, the client interface to the indexing system from an ETR's point of view is through devices called Map Servers (MSs - admittedly a poorly chosen term, but it's too late to change it now). ETRs send registration control messages (Map-Register packets) to an MS, which makes the information about the mappings which the ETR indicates it is authoritative for available to the indexing system. The MS formulates a reply control message (the Map-Notify packet), which confirms the registration, and is returned to the ETR. The details of the indexing system are thus likewise hidden from the 'ordinary' ETRs. 5.2.3. Indexing Subsystem The current indexing system is called the Delegated Database Tree (DDT), which is very similar in operation to DNS. [DDT], [RFC1034] However, unlike DNS, the actual mappings are not handled by DDT; DDT merely identifies the ETRs which hold the mappings. Again, extensive large-scale simulations driven by lengthy recordings of actual traffic at several major sites, have been performed to verify the effectiveness of this particular indexing system. [Jakab] 6. Examples of Operation To aid in comprehension, a few examples are given of user packets traversing the LISP system. The first shows the processing of a typical user packet, i.e. what the vast majority of user packets will see. The second shows what happens when the first packet to a previously-unseen destination (at a particular ITR) is to be processed by LISP. 6.1. An Ordinary Packet's Processing This case follows the processing of a typical user packet (for instance, a normal TCP data or acknowledgment packet associated with an open HTTP connection) as it makes its way from the source host to the destination. {{Rest to be written.}} 6.2. A Mapping Cache Miss If a host sends a packet, and it gets to the ITR, and the ITR both i) determines that it needs to perform LISP processing on the user data packet, but ii) does not yet have a mapping cache entry which covers that destination EID, then more complex processing ensues. {{Rest to be written.}} 7. Design Approach Before describing LISP's components in more detail below, it may be worth saying a few words about the design philosophy used in creating them - this may make clearer the reasons for some engineering choices in the mechanisms given there. 7.1. Quick Implement-Test Loop LISP uses a philosophy similar to that used in the early days of the Internet, which is to just build it, then try it and see what happens, and move forward from there based on what actually happens. The concept has been to get something up and running, and then modify it based on testing and experience. 7.1.1. No Desk Fixes Don't try and forsee all issues from desk analysis. (Which is not to say that one should not spend _some_ time on trying to forsee problems, but be aware that it is a 'diminishing returns' process.) The performance of very large, complex, physically distributed systems is hard to predict, so rather than try (which would necessarily be an incomplete exercise anyway, testing would inevitably be required eventually), at a certain point it's better just to get on with it - and you will learn a host of other lessons in the process, too. 7.1.2. Code Before Documentation This is often a corollary to the kind of style described above. While it probably would not have been possible in a large, inhomogenous group, the small, close nature of the LISP implementation group did allow this approach. 7.2. Only Fix Real Problems Don't worry about anything unless experience show it's a real problem. For instance, in the early stages, much was made out of the problem of 'what does an ITR do if it gets a packet, but does not (yet) have a mapping for the destination?' In practise, simply dropping such packets has just not proved to be a problem; the higher level protocol will retransmit them after a timeout, and the mapping is usually in place by then. So spending a lot of time (and its companion, energy) and mechanism (and _its_ extremely undesirable companion, complexity) on solving this 'problem' would not have been the most efficient approach, overall. 7.3. No Theoretical Perfection Attack hard problems with a number of cheap and simple mechanisms that co-operate and overlap. Trying to find a single mechanism that is all of: - Robust - Efficient - Fast is often (usually?) a fool's errand. (The analogy to the aphorism 'Fast, Cheap, Good - Pick Any Two' should be obvious.) However, a collection of simple and cheap mechanisms may effectively be able to meet all of these goals (see, for example, ETR Liveness/Reachability, Section 12.4). Yes, this results in a system which is not provably correct in all circumstances. The world, however, is full of such systems - and in the real world, effective robustness is more likely to result from having multiple, overlapping mechanisms than one single high-powered (and inevitably complex) one. In the world of civil engineering, redundancy is now accepted as a key design principle; the same should be true of information systems. [Salvadori] 7.3.1. No Ocean Boiling Don't boil the ocean to kill a single fish. This is a combination of 7.2 (Only Fix Real Problems) and 7.3 (No Theoretical Perfection); it just means that spending a lot of complexity and/or overhead to deal with a problem that's not really a problem is not good engineering. 7.4. Just Enough Security How much security to have is a complex issue. It's relatively easy for designers to add good security, but much harder to get the users to jump over all the hoops necessary to use it. LISP has therefore adopted a position where we add 'just enough' security. The overall approach to security in LISP is fairly subtle, though, and is covered in more detail elsewhere (in [Architecture], Section "Security"). 8. xTRs As mentioned above (in Section 5.1), xTRs are the basic data-handling devices in LISP. This section explores some advanced topics related to xTRs. Careful rules have been specified for both TTL and ECN [RFC3168] to ensure that passage through xTRs does not interfere with the operation of these mechanisms. In addition, care has been taken to ensure that 'traceroute' works when xTRs are involved. 8.1. When to Encapsulate An ITR knows that a destination is running LISP, and thus that it should perform LISP processing on a packet (including potential encapsulation) if it has an entry in its local mapping cache that covers the destination EID. Conversely, if the cache contains a 'negative' entry (indicating that the ITR has previously attempted to find a mapping that covers this EID, and it has been informed by the mapping system that no such mapping exists), it knows the destination is not running LISP, and the packet can be forwarded normally. (The ITR cannot simply depend on the appearance, or non-appearance, of the destination in the DFZ routing tables, as a way to tell if a destination is a LISP site or not, because mechanisms to allow interoperation of LISP sites and 'legacy' sites necessarily involve advertising LISP sites' EIDs into the DFZ.) 8.2. UDP Encapsulation Details The UDP encapsulation used by LISP for carrying traffic from ITR to ETR, and many of the details of how the it works, were all chosen for very practical reasons. Use of UDP (instead of, say, a LISP-specific protocol number) was driven by the fact that many devices filter out 'unknown' protocols, so adopting a non-UDP encapsulation would have made the initial deployment of LISP harder - and our goal (see Section 2.1) was to make the deployment as easy as possible. The UDP source port in the encapsulated packet is a hash of the original source and destination; this is because many ISPs use multiple parallel paths (so-called 'Equal Cost Multi-Path'), and load-share across them. Using such a hash in the source-port in the outer header both allows LISP traffic to be load-shared, and also ensures that packets from individual connections are delivered in order (since most ISPs try to ensure that packets for a particular {source, source port, destination, destination port} tuple flow along a single path, and do not become disordered).. The UDP checksum is zero because the inner packet usually already has a end-end checksum, and the outer checksum adds no value. [Saltzer] In most exising hardware, computing such a checksum (and checking it at the other end) would also present an intolerable load, for no benefit. 8.3. Header Control Channel LISP provides a multiplexed channel in the encapsulation header. It is mostly (but not entirely) used for control purposes. (See [Architecture], Section "Architecture-Piggyback" for a longer discussion of the architectural implications of this.) The general concept is that the header starts with an 8-bit 'flags' field, and it also includes two data fields (one 24 bits, one 32), the contents and meaning of which vary, depending on which flags are set. This allows these fields to be 'multiplexed' among a number of different low-duty-cycle functions, while minimizing the space overhead of the LISP encapsulation header. 8.3.1. Echo Nonces One important use is for a mechanism known as the Nonce Echo, which is used as an efficient method for ITRs to check the reachability of correspondent ETRs. Basically, an ITR which wishes to ensure that an ETR is up, and reachable, sends a nonce to that ETR, carried in the encapsulation header; when that ETR (acting as an ITR) sends some other user data packet back to the ITR (acting in turn as an ETR), that nonce is carried in the header of that packet, allowing the original ITR to confirm that its packets are reaching that ETR. Note that lack of a response is not necessarily _proof_ that something has gone wrong - but it stronly suggests that something has, so other actions (e.g. a switch to an alternative ETR, if one is listed; a direct probe; etc) are advised. (See Section 12.5 for more about Echo Nonces.) 8.3.2. Instances Another use of these header fields is for 'Instances' - basically, support for VPN's across backbones. [RFC4026] Since there is only one destination UDP port used for carriage of user data packets, and the source port is used for multiplexing (above), there is no other way to differentiate among different destination address namespaces (which are often overlapped in VPNs). 8.4. Fragmentation Several mechanisms have been proposed for dealing with packets which are too large to transit the path from a particular ITR to a given ETR. One, called the 'stateful' approach, keeps a per-ETR record of the maximum size allowed, and sends an ICMP Too Big message to the original source host when a packet which is too large is seen. In the other, referred to as the 'stateless' approach, for IPv4 packets without the 'DF' bit set, too-large packets are fragmented, and then the fragments are forwarded; all other packets are discarded, and an ICMP Too Big message returned. It is not clear at this point which approach is preferable. 8.5. Mapping Gleaning in ETRs As an optimization to the mapping acquisition process, ETRs are allowed to 'glean' mappings from incoming user data packets, and also from incoming Map-Request control messages. This is not secure, and so any such mapping must be 'verified' by sending a Map-Request to get an authoritative mapping. (See further discussion of the security implications of this in [Architecture], Section "Security- xTRs".) The value of gleaning is that most communications are two-way, and so if host A is sending packets to host B (therefore needing B's EID->RLOC mapping), very likely B will soon be sending packets back to A (and thus needing A's EID->RLOC mapping). Without gleaning, this would sometimes result in a delay, and the dropping of the first return packet; this is felt to be very undesirable. 9. The Mapping System RFC 1034 ("DNS Concepts and Facilities") has this to say about the DNS name to IP address mapping system: "The sheer size of the database and frequency of updates suggest that it must be maintained in a distributed manner, with local caching to improve performance. Approaches that attempt to collect a consistent copy of the entire database will become more and more expensive and difficult, and hence should be avoided." and this observation applies equally to the LISP mapping system. As previously mentioned, the mapping system is split into an indexing subsystem, which keeps track of where all the mappings are kept, and the mappings themsleves, the authoritative copies of which are always held by ETRs. 9.1. The Indexing Subsystem The indexing system in LISP is currently implemented by the DDT system. LISP initially used (for ease of getting something operational without having to write a lot of code) an indexing system called ALT, which used BGP running over virtual tunnels. [ALT] This proved to have a number of issues, and has now been superseded by DDT. In DDT, the EID namespace(s) are instantiated as a tree of DDT nodes. Starting with the root node(s), which have 'reponsibility' for the entire namespace, portions of the namespace are delegated to child nodes, in a recursive process extending through as many levels as are needed. Eventually, leaf nodes in the DDT tree delegate namespace blocks to ETRs. MRs obtain information about delegations by interrogating DDT nodes, and caching the results. aThis FC: This allows them, when passed a request for a mapping by an ITR, to forward the mapping request to the appropriate ETR (perhaps after loading some missing delegation entries into their delegation cache). 9.2. The Mapping System Interface As mentioned in Section 5.2.2, both of the inferfaces to the mapping system (from ITRs, and ETRs) are standardized, so that the more numerous xTRs do not have to be modified when the mapping indexing system is changed. This precaution has already allowed the mapping system to be upgraded during LISP's evolution, when ALT was replaced by DDT. This section describes the interfaces in a little more detail. 9.2.1. Map-Request Messages The Map-Request message contains a number of fields, the two most important of which are the requested EID block identifier (remember that individual mappings may cover a block of EIDs, not just a single EID), and the Address Family Identifier (AFI) for that EID block. [AFI] The inclusion of the AFI allows the mapping system interface (as embodied in these control packets) a great deal of flexibility. (See [Architecture], Section "Namespaces" for more on this.) Other important fields are the source EID (and its AFI), and one or more RLOCs for the source EID, along with their AFIs. Multiple RLOCs are included to ensure that at least one is in a form which will allow the reply to be returned to the requesting ITR, and the source EID is used for a variety of functions, including 'gleaning' (see Section 8.5). Finally, the message includes a long nonce, for simple, efficient protection against offpath attackers (see [Architecture], Section "Security-xTRs" for more), and a variety of other fields and control flag bits. 9.2.2. Map-Reply Maessages The Map-Reply message looks similar, except it includes the mapping entry for the requested EID(s), which contains one or more RLOCs and their associated data. (Note that the reply may cover a larger block of the EID namespace than the request; most requests will be for a single EID, the one which prompted the query.) For each RLOC in the entry, there is the RLOC, its AFI (of course), priority and weight fields (see Section 5.2), and multicast priority and weight fields. 9.2.3. Map-Register and Map-Notify Messages The Map-Register message contains authentication information, and a number of mapping records, each with an individual Time-To-Live (TTL). Each of the records contains an EID (potentially, a block of EIDs) and its AFI, a version number for this mapping (see Section 11.1), and a number of RLOCs and their AFIs. Each RLOC entry also includes the same data as in the Map-Replies (i.e. priority and weight); this is because in some circumstances it is advantageous to allow the MS to proxy reply on the ETR's behalf to Map-Request messages. [Mobility] Map-Notify messages have the exact same contents as Map-Register messages; they are purely acknowledgements. 9.2.4. Map-Referral Messages Map-Referral messages look almost identical to Map-Reply messages (which is felt to be an advantage by some people, although having a more generic record-based format would probably be better in the long run, as ample experience with DNS has shown), except that the RLOCs potentially name either i) other DDT nodes (children in the delegation tree), or ii) terminal MSs. There are also optional authentication fields; see [Architecture], Section "Security-Mappings" for more. 9.3. Reliability via Replication Everywhere throughout the mapping system, robustness to operational failures is obtained by replicating data in multiple instances of any particular node (of whatever type). Map-Resolvers, Map-Servers, DDT nodes, ETRs - all of them can be replicated, and the protocol supports this replication. There are generally no mechanisms specified yet to ensure coherence between multiple copies of any particular data item, etc - this is currently a manual responsibility. If and when LISP protocol adoption proceeds, an automated layer to perform this functionality can 'easily' be layered on top of the existing mechanisms. 9.4. Extended Tools In addition to the priority and weight data items in mappings, LISP offers other tools to enhance functionality, particularly in the traffic engineering area. One are 'source-specific mappings', i.e. the ETR may return different mappings to the enquiring ITR, depending on the identity of the ITR. This allows very fine-tuned traffic engineering, far more powerful than routing-based TE. 9.5. Expected Performance {{To be written.}} 10. Deployment Mechanisms This section discusses several deployment issues in more detail. With LISP's heavy emphasis on practicality, much work has gone into making sure it works well in the real-world environments most people have to deal with. 10.1. Internetworking Mechanism One aspect which has received a lot of attention are the mechanisms previously referred to (in Section 3.4) to allow interoperation of LISP sites with so-called 'legacy' sites which are not running LISP (yet). To briefly refresh what was said there, there are two main approaches to such interworking: proxy nodes (PITRs and PETRs), and an alternative mechanism using device with combined NAT and LISP functionality; these are described in more detail here. 10.2. Proxy Devices PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to nodes using LISP. PETRs (proxy ETRs) serve as ETRs for LISP traffic _to_ legacy hosts (for cases where a LISP device cannot send packets directly to such sites, without encapsulation). Note that return traffic _to_ a legacy site from a LISP-using node does not necessarily have to pass through an ITR/PETR pair - the original packets can usually just be sent directly to the destination. However, for some kinds of LISP operation (e.g. mobile nodes), this is not possible; in these situations, the PETR is needed. 10.2.1. PITRs PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to nodes using LISP. To do that, they have to advertise into the existing legacy backbone Internet routing the availability of whatever ranges of EIDs (i.e. of nodes using LISP) they are proxying for, so that legacy hosts will know where to send traffic to those LISP nodes. As mentioned previously (Section 8.1), an ITR at another LISP site can avoid using a PITR (i.e. it can detect that a given destination is not a legacy site, if a PITR is advertising it into the DFZ) by checking to see if a LISP mapping exists for that destination. This technique obviously has an impact on routing table in the DFZ, but it is not clear yet exactly what that impact will be; it is very dependent on the collected details of many individual deployment decisions. A PITR may cover a group of EID blocks with a single EID advertisement, in order to reduce the number of routing table entries added. (In fact, at the moment, aggressive aggregation of EID announcements is performed, precisely to to minimize the number of new announced routes added by this technique.) At the same time, it FC: if a site does traffic engineering with LISP instead of fine-grained BGP announcement, that will help keep table sizes down (and this is true even in the early stages of LISP deployment). The same is true for multi-homing. 10.2.2. PETRs PETRs (proxy ETRs) serve as ETRs for LISP traffic _to_ legacy hosts, for cases where a LISP device cannot send packets to sites without encapsulation. That typically happens for one of two reasons. First, it will happen in places where some device is implementing Unicast Reverse Path Forwarding (uRPF), to prevent a variety of negative behaviour; originating packets with the source's EID in the source address field will result in them being filtered out and discarded. Second, it will happen when a LISP site wishes to send packets to a non-LISP site, and the path in between does not support the particular IP protocol version used by the source along its entir FC: entire length. Use of a PETR on the other side of the 'gap' will allow the LISP site's packet to 'hop over' the gap, by utilizing LISP's built-in support for mixed protocol encapsulation. PETRs are generally paired with specific ITRs, which have the location of their PETRs configured into them. In other words, unlike normal ETRS, PETRs do not have to register themselves in the mapping database, on behalf of any legacy sites they serve. Also, allowing an ITR to always send traffic leaving a site to a PETR does avoid having to chose whether or not to encapsulate packets; it can just always encapsulate packets, sending them to the PETR if it has no specific mapping for the destination. However, this is not advised: as mentioned, it is easy to tell if something is a legacy destination. 10.3. LISP-NAT A LISP-NAT device, as previously mentioned, combines LISP and NAT functionality, in order to allow a LISP site which is internally using addresses which cannot be globally routed to communicate with non-LISP sites elsewhere in the Internet. (In other words, the technique used by the PITR approach simply cannot be used in this case.) To do this, a LISP-NAT performs the usual NAT functionality, and translates a host's source address(es) in packets passing through it from an 'inner' value to an 'outer' value, and storing that translation in a table, which it can use to similarly process subsequent packets (both outgoing and incoming). [Interworking] There are two main cases where this might apply: - Sites using non-routable global addresses - Sites using private addresses [RFC1918] 10.4. LISP and DFZ Routing {{To be written.}} 10.5. Use Through NAT Devices Like them or not (and NAT devices have many egregious issues - some inherent in the nature of the process of mapping addresses; others, such as the brittleness due to non-replicated critical state, caused by the way NATs were introduced, as stand-alone 'invisible' boxes), NATs are both ubiquitous, and here to stay for a long time to come. Thus, in the actual Internet of today, having any new mechanisms function well in the presence of NATs (i.e. with LISP xTRs behind a NAT device) is absolutely necessary. LISP has produced a variety of mechanisms to do this. 10.5.1. First-Phase NAT Support The first mechanism used by LISP to operate through a NAT device only worked with some NATs, those which were configurable to allow inbound packet traffic to reach a configured host. A pair of new LISP control messages, LISP Echo-Request and Echo- Reply, allowed the ETR to discover its temporary global address; the Echo-Request was sent to the configured Map-Server, and it replied with an Echo-Reply which included the source address from which the Echo Request was received (i.e. the public global address assigned to the ETR by the NAT). The ETR could then insert that address in any Map-Reply control messages which it sent to correspondent ITRs. The fact that this mechanism did not support all NATs, and also required manual configuration of the NAT, meant that this was not a good solution; in addition, since LISP expects all incoming data traffic to be on a specific port, it was not possible to have multiple ETRs behind a single NAT (which normally would have only one global address to share, meaning port mapping would have to be used, except that... ) 10.5.2. Second-Phase NAT Support For a more comprehensive approach to support of LISP xTR deployment behind NAT devices, a fairly extensive supplement to LISP, LISP NAT Traversal, has been designed. [NAT] A new class of LISP device, the LISP Re-encapsulating Tunnel Router (RTR), passes traffic through the NAT, both to and from the xTR. (Inbound traffic has to go through the RTR as well, since otherwise multiple xTRs could not operate behind a single NAT, for the 'specified port' reason in the section above.) (Had the Map-Reply included a port number, this could have been avoided - although of course it would be possible to define a new RLOC type which included protocol and port, to allow other encapsulation techniques.) Two new LISP control messages (Info-Request and Info-Reply) allow an xTR to detect if it is behind a NAT device, and also discover the global IP address and UDP port assigned by the NAT to the xTR. A modification to LISP Map-Register control messages allows the xTR to initialize mapping state in the NAT, in order to use the RTR. This mechanism addresses cases where the xTR is behind a NAT, but the xTR's associated MS is on the public side of the NAT; this limitation, that MS's must be in the 'public' part of the Internet, seems reasonable. 11. Current Improvements In line with the philosophies laid out in Section 7, LISP is something of a moving target. This section discusses some of the contemporaneous improvements being made to LISP. 11.1. Mapping Versioning As mentioned, LISP has been under development for a considerable time. One early addition to LISP (it is already part of the base specification) is mapping versioning; i.e. the application of identifying sequence numbers to different versions of a mappping. [Versioning] This allows an ITR to easily discover when a cached mapping has been updated by a more recent variant. Version numbers are available in control messages (Map-Replies), but the initial concept is that to limit control message overhead, the versioning mechanism should primarily use the multiplex user data header control channel (see Section 8.3). Versioning can operate in both directions: an ITR can advise an ETR what version of a mapping it is currently using (so the ETR can notify it if there is a more recent version), and ETRs can let ITRs know what the current mapping version is (so the ITRs can request an update, if their copy is outdated). At the moment version numbers are manually assigned, and ordered. Some felt that this was non-optimal, and that a better approach would have been to have 'fingerprints' which were computed from the current mapping data (i.e. a hash). It is not clear that the ordering buys much (if anything), and the potential for mishaps with manually configured version numbers is self-evident. 11.2. Replacement of ALT with DDT As mentioned in Section 9.2, an interface is provided to allow replacement of the indexing subsystem. LISP initially used an indexing system called ALT. [ALT] ALT was relatively easy to construct from existing tools (GRE, BGP, etc), but it had a number of issues that made it unsuitable for large-scale use. ALT is now being superseded by DDT. As indicated previously (Section 9.5), the basic structure and operation of DDT is identical to that of TREE, so the extensive simulation work done for TREE applies equally to DDT, as do the conclusions drawn about TREE's superiority to ALT. [Jakab] {{Briefly synopsize results}} 11.2.1. Why Not Use DNS One obvious question is 'Since DDT is so similar to DNS, why not simply use DNS?' In particular, people are familiar with the DNS, how to configure it, etc - would it not thus be preferable to use it? To completely answer this would take more space that available here, but, briefly, there were two main reasons, and one lesser one. First, the syntax of DNS names did not lend itself to looking up names in other syntaxes (e.g. bit fields). This is a problem which has been previously encountered, e.g. in reverse address lookups. [RFC5855] Second, as an existing system, the interfaces between DNS (should it have been used as an indexing subsystem for LISP) would not be 'tuneable' to be optimal for LISP. For instance, if it were desired to have the leaf node in an indexing lookup directly contact the ETR on behalf of the node doing the lookup (thereby avoiding a round-trip delay), that would not be easy without modifications to the DNS code. Obviously, with a 'custom' system, this issue does not arise. Finally, DNS security, while robust, is fairly complex. Doing DDT offered an opportunity to provide a more nuanced security model. (See [Architecture], Section "Security" for more about this.) 11.3. Mobile Device Support Mobility is an obvious capability to provide with LISP. Doing so is relatively simple, if the mobile host is prepared to act as its own ETR. It obtains a local 'temporary use' address, and registers that address as its RLOC. Packets to the mobile host are sent to its temporary address, whereever that may be, and the mobile host first unwraps them (acting as an ETR), and the processes them normally (acting as a host). (Doing mobility without having the mobile host act as its ETR is difficult, even if ETRs are quite common. The reason is that if the ETR and mobile host are not integrated, during the step from the ETR to the mobile host, the packets must contain the mobile host's EID, and this may not be workable. If there is a local router between the ETR and mobile host, for instance, it is unlikely to know how to get the packets to the mobile host.) If the mobile host migrates to a site which is itself a LISP site, things get a little more complicated. The 'temporary address' it gets is itself an EID, requiring mapping, and wrapping for transit across the rest of the Internet. A 'double encapsulation' is thus required at the other end; the packets are first encapsulated with the mobile node's temporary address as their RLOC, and then this has to be looked up in a second lookup cycle (see Section 8.1), and then wrapped again, with the site's RLOC as their destination. This results in slight loss in maximum packet size, due to the duplicated headers, but on the whole it is considerably simpler than the alternative, which would be to re-wrap the packet at the site's ETR, when it is discovered that the destination's EID was not 'native' to the site. This would require that the mobile node's EID effectively have two different mappings, depending on whether the lookup was being performed outside the LISP site, or inside. {{Also probably need to mention briefly how the other end is notified when mappings are updated, and about proxy-Map-Replies.}} [Mobility] 11.4. Multicast Support Multicast may seem an odd thing to support with LISP, since LISP is all about separating identity from location, but although a multicast group in some sense has an identity, it certainly does not have _a_ location. However, multicast is important to some users of the network, for a number of reasons: doing multiple unicast streams is inefficient; it is easy to use up all the upstream bandwidth, and without multicast a server can also be saturated fairly easily in doing the unicast replication. So it is important for LISP to 'play nicely' with multicast; work on multicast support in LISP is fairly advanced, although not far-ranging. Briefly, destination group addresses are not mapped; only the source address (when the source is inside a LISP site) needs to be mapped, both during distribution tree setup, as well as actual traffic delivery. In other words, LISP's mapping capability isa FC: is used: it is just applied to the source, not the destination (as with most LISP activity); the inner source is the EID, and the outer source is the EID's RLOC. Note that this does mean that if the group is using separate source- specific trees for distribution, there isn't a separate distribution tree outside the LISP site for each different source of traffic to the group from inside the LISP site; they are all lumped together under a single source, the RLOC. The approach currently used by LISP requires no packet format changes to existing multicast protocols. See [Multicast] for more; additional LISP multicast issues are discussed in [LISP], Section 12. 11.5. {{Any others?}} 12. Fault Discovery/Handling LISP is, in terms of its functionality, a fairly simple system: the list of failure modes is thus not extensive. 12.1. Handling Missing Mappings Handling of missing mappings is fairly simple: the ITR calls for the mapping, and in the meantime can either discard traffic to the destination (as many ARP implementations do) [RFC826], or, if dropping the traffic is deemed undesirable, it can forward them via a 'default PITR'. A number of PITRs advertise all EID blocks into the backbone routing, so that any ITRs which are temporarily missing a mapping can forward the traffic to these default PITRs via normal transmission methods, where they are encapsulated and passed on. 12.2. Outdated Mappings If a mapping changes once an ITR has retrieved it, that may result in traffic to the EIDs covered by that mapping failing. There are three cases to consider: - When the ETR traffic is being sent to is still a valid ETR for that EID, but the mapping has been updated (e.g. to change the priority of various ETRs) - When the ETR traffic is being sent to is still an ETR, but no longer a valid ETR for that EID - When the ETR traffic is being sent to is no longer an ETR 12.2.1. Outdated Mappings - Updated Mapping A 'mapping versioning' system, whereby mappings have version numbers, and ITRs are notified when their mapping is out of date, has been added to detect this, and the ITR responds by refreshing the mapping. [Versioning] 12.2.2. Outdated Mappings - Wrong ETR {{To be written.}} 12.2.3. Outdated Mappings - No Longer an ETR If the destination of traffic from an ITR is no longer an ETR, one might get an ICMP Destination Unreachable error message. However, one cannot depend on that. The following mechanism will work, though. Since the destination is not an ETR, the echoing reachability detection mechanism (see Section 8.3.1) will detect a problem. At that point, the backstop mechanism, Probing, will kick in. Since the destination is still not an ETR, that will fail, too. At that point, traffic will be switched to a different ETR, or, if none are available, a re-map may be requested. 12.3. Erroneous mappings {{To be written.}} 12.4. Neighbour Liveness The ITR, like all packet switches, needs to detect, and react, when its next-hop neighbour ceases operation. As LISP traffic is effectively always unidirectional (from ITR to ETR), this could be somewhat problematic. Solving a related problem, neighbour reachability (below) subsumes handling this fault mode, however. Note that the two terms (liveness and reachability) are _not_ synonmous (although a lot of LISP documentation confuses them). Liveness is a property of a node - it is either up and functioning, or it is not. Reachability is only a property of a particular _pair_ of nodes. If packets sent from a first node to a second are successfully received at the second, it is 'reachable' from the first. However, the second node may at the very same time _not_ be reachable from some other node. Reachability is _always_ a ordered pairwise property, and of a specified ordered pair. 12.5. Neighbour Reachability A more significant issue than whether a particular ETR E is up or not is, as mentioned above, that although ETR E may be up, attached to the network, etc, an issue in the network between a source ITR I and E may prevent traffic from I from getting to E. (Perhaps a routing problem, or perhaps some sort of access control setting.) The one-way nature of LISP traffic makes this situation hard to detect in a way which is economic, robust and fast. Two out of the three are usually not to hard, but all three at the same time - as is highly desirable for this particular issue - are harder. In line with the LISP design philosophy (Section 7.3), this problem is attacked not with a single mechanism (which would have a hard time meeting all those three goals simultaneously), but with a collection of simpler, cheaper mechanisms, which collectively will usually meet all three. They are reliance on the underlying routing system (which can of course only reliably provide a negative reachabilty indication, not a positive one), the echo nonce (which depends on some return traffic from the destination xTR back to the source), and finally direct 'pinging', in the case where no positive echo is returned. (The last is not the first choice, as due to the large fan-out expected of LISP devices, reliance on it as a sole mechanism would produce a fair amount of overhead.) 13. Acknowledgments The author would like thank all the members of the core LISP group for their willingness to allow him to add himself to their effort, and for their enthusiasm for whatever assistance he has been able to provide. He would also like to thank (in alphabetical order) Vina Ermagan, Vince Fuller, and especially Joel Halpern for their careful review of, and helpful suggestions for, this document. Grateful thanks also to Darrel Lewis for his help with material on non- Internet uses of LISP, and to Vince Fuller for help with XML. A final thanks is due to John Wrocklawski for the author's organizational affiliation. This memo was created using the xml2rfc tool 14. IANA Considerations This document makes no request of the IANA. 15. Security Considerations This memo does not define any protocol and therefore creates no new security issues. 16. References 16.1. Normative References [RFC768] J. Postel, "User Datagram Protocol", RFC 768, August 1980. [RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981. [RFC1498] J. H. Saltzer, "On the Naming and Binding of Network Destinations", RFC 1498, (Originally published in: "Local Computer Networks", edited by P. Ravasio et al., North-Holland Publishing Company, Amsterdam, 1982, pp. 311-317.), August 1993. [RFC2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [Architecture] J. N. Chiappa, "An Architectural Perspective on the LISP Location-Identity Separation System", draft-ietf-lisp-architecture-00 (work in progress), October 2012. [DDT] V. Fuller, D. Lewis, and D. Farinacci, "LISP Delegated Database Tree", draft-fuller-lisp-ddt-01 (work in progress), March 2012. [Future] J. N. Chiappa, "Potential Long-Term Developments With the LISP System", draft-chiappa-lisp-evolution-00 (work in progress), July 2012. [Interworking] D. Lewis, D. Meyer, D. Farinacci, and V. Fuller, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-06 (work in progress), March 2012. [LISP] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-23 (work in progress), May 2012. [Mobility] D. Farinacci, V. Fuller, D. Lewis, and D. Meyer, "LISP Mobility Architecture", draft-meyer-lisp-mn-07 (work in progress), April 2012. [Multicast] D. Farinacci, D. Meyer, J. Zwiebel, and S. Venaas, "LISP for Multicast Environments", draft-ietf-lisp-multicast-14 (work in progress), February 2012. [NAT] V. Ermagan, D. Farinacci, D. Lewis, J. Skriver, F. Maino, and C. White, "NAT traversal for LISP", draft-ermagan-lisp-nat-traversal-01 (work in progress), March 2012. [Versioning] L. Iannone, D. Saucez, and O. Bonaventure, "LISP Mapping Versioning", draft-ietf-lisp-map-versioning-09 (work in progress), March 2012. [AFI] IANA, "Address Family Indicators (AFIs)", Address Family Numbers, January 2011, . 16.2. Informative References [NIC8246] A. McKenzie and J. Postel, "Host-to-Host Protocol for the ARPANET", NIC 8246, Network Information Center, SRI International, Menlo Park, CA, October 1977. [IEN19] J. F. Shoch, "Inter-Network Naming, Addressing, and Routing", IEN (Internet Experiment Note) 19, January 1978. [RFC826] D. Plummer, "Ethernet Address Resolution Protocol", RFC 826, November 1982. [RFC1034] P. V. Mockapetris, "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [RFC1631] K. Egevang and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994. [RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [RFC1992] I. Castineyra, J. N. Chiappa, and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996. [RFC3168] K. Ramakrishnan, S. Floyd, and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3272] D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002. [RFC4026] L. Andersson and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [RFC4116] J. Abley, K. Lindqvist, E. Davies, B. Black, and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005. [RFC4984] D. Meyer, L. Zhang, and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [RFC5855] J. Abley and T. Manderson, "Nameservers for IPv4 and IPv6 Reverse Zones", RFC 5855, May 2010. [RFC5887] B. Carpenter, R. Atkinson, and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010. [ALT] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-10 (work in progress), December 2011. [NSAP] International Organization for Standardization, "Information Processing Systems - Open Systems Interconnection - Basic Reference Model", ISO Standard 7489.1984, 1984. [Atkinson] R. Atkinson, "Revised draft proposed definitions", RRG list message, Message-Id: 808E6500-97B4-4107- 8A2F-36BC913BE196@extremenetworks.com, 11 June 2007, . [Baran] P. Baran, "On Distributed Communications Networks", IEEE Transactions on Communications Systems Vol. CS-12 No. 1, pp. 1-9, March 1964. [Chiappa] J. N. Chiappa, "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", Personal draft (work in progress), 1999, . [Clark] D. D. Clark, "The Design Philosophy of the DARPA Internet Protocols", in 'Proceedings of the Symposium on Communications Architectures and Protocols SIGCOMM '88', pp. 106-114, 1988. [Heart] F. E. Heart, R. E. Kahn, S. M. Ornstein, W. R. Crowther, and D. C. Walden, "The Interface Message Processor for the ARPA Computer Network", Proceedings AFIPS 1970 SJCC, Vol. 36, pp. 551-567. [Jakab] L. Jakab, A. Cabellos-Aparicio, F. Coras, D. Saucez, and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System", in 'IEEE Journal on Selected Areas in Communications', Vol. 28, No. 8, pp. 1332-1343, October 2010. [Iannone] L. Iannone and O. Bonaventure, "On the Cost of Caching Locator/ID Mappings", in 'Proceedings of the 3rd International Conference on emerging Networking EXperiments and Technologies (CoNEXT'07)', ACM, pp. 1-12, December 2007. [Saltzer] J. H. Saltzer, D. P. Reed, and D. D. Clark, "End-To- End Arguments in System Design", ACM TOCS, Vol 2, No. 4, pp 277-288, November 1984. [Salvadori] M. Salvadori and M. Levy, "Why Buildings Fall Down", W. W. Norton, New York, pg. 81, 1992. Appendix A. Glossary/Definition of Terms - Address - Locator - EID - RLOC - ITR - ETR - xTR - PITR - PETR - MR - MS - DFZ Appendix B. Other Appendices Possible appendices: -- Location/Identity Separation Brief History -- LISP History -- Old models (LISP 1, LISP 1.5, etc) Author's Address J. Noel Chiappa Yorktown Museum of Asian Art Yorktown, Virginia USA EMail: jnc@mit.edu --------------080208030008020904060804-- From terry.manderson@icann.org Sun Nov 4 07:47:12 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C327221F8712 for ; Sun, 4 Nov 2012 07:47:11 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD6m9wHYKYkp for ; Sun, 4 Nov 2012 07:47:08 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9D10621F8707 for ; Sun, 4 Nov 2012 07:47:08 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Sun, 4 Nov 2012 07:47:08 -0800 From: Terry Manderson To: LISP mailing list list Date: Sun, 4 Nov 2012 07:47:09 -0800 Thread-Topic: Agenda for Tuesday Thread-Index: Ac26o6XvY047h930gkmlA+k+vCG+2Q== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3434924829_25207643" MIME-Version: 1.0 Subject: [lisp] Agenda for Tuesday X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 15:47:12 -0000 --B_3434924829_25207643 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit WG, The current agenda for our WG meeting on Tuesday is here: http://tools.ietf.org/wg/lisp/agenda I am more than comfortable for presenters to use their own laptops so that graphics (etc) render appropriately, however I will still need your slide-set by 5pm Monday for the benefit of any folk following the meeting remotely. Participants, it would be appreciated that you review the drafts being discussed. It should also be noted that the last item: =-=-=-=-=-=-=- - Intro and Architecture, 30 mins Open mic discussion, come prepared. http://tools.ietf.org/wg/lisp/draft-ietf-lisp-introduction/ and http://tools.ietf.org/wg/lisp/draft-ietf-lisp-architecture/ =-=-=-=-=-=-=- is an effort to have an open discussion on these documents, I will facilitate this discussion, however it would be of most benefit if all folks who come to the meeting have READ these two drafts beforehand!! It should be clear to WG now that these two documents are a gate on further WG items. Cheers, Terry --B_3434924829_25207643 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUJHdsZG5tRul38uB2rkO/YKDtc84wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTA0MTU0NzA5WjANBgkqhkiG 9w0BAQEFAASCAQAlDnWAiyalwu3973htDtNVhzYfthMNzJNImz5Lq4+Y6aNlrEyPsHOq6XLn KhGMbeS+XivFONM3SXbb9i+LzO+JUuv7uz6DHqdr7dDepkECu8L9AjnoLIaBuUWeDI14Z+HR WyEZzm6qs1n+zt6wndrQi23i0qCxoMnIzs1jUcRP/MK0FrI2qtX8f/sOHblPRga8K4+l9aFW loiCdX2yOuN5ftwdvctvyw1G6VncRR2p+o0ub3EpPze8pK+qI3ac+jh80FVyMFGJr36FigFr PUC3Sp8XlbAS7FAIIZ+IVB21B9seVqmf//ZTFsjUacVLj0xG4ayFHEuii8uILH6nv57d --B_3434924829_25207643-- From fcoras@ac.upc.edu Sun Nov 4 13:23:35 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8859F21F8698 for ; Sun, 4 Nov 2012 13:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=2.133, 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 GB2gpNUJNCa3 for ; Sun, 4 Nov 2012 13:23:34 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0660621F84F3 for ; Sun, 4 Nov 2012 13:23:33 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qA4LMg3R005396; Sun, 4 Nov 2012 22:22:47 +0100 Received: from [10.8.0.14] (unknown [10.8.0.14]) by gw.ac.upc.edu (Postfix) with ESMTP id D93A16B0094; Sun, 4 Nov 2012 22:22:10 +0100 (CET) Message-ID: <5096DC7C.4090806@ac.upc.edu> Date: Sun, 04 Nov 2012 22:22:04 +0100 From: Florin Coras User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Noel Chiappa , lisp@ietf.org Content-Type: multipart/mixed; boundary="------------070204090507090809020709" Subject: [lisp] Comments on draft-ietf-lisp-architecture-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 21:23:35 -0000 This is a multi-part message in MIME format. --------------070204090507090809020709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Hereafter my comments on the architecture draft. Florin --------------070204090507090809020709 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-lisp-architecture-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-lisp-architecture-00.txt" LISP Working Group J. N. Chiappa Internet-Draft Yorktown Museum of Asian Art Intended status: Informational October 15, 2012 Expires: April 18, 2013 An Architectural Perspective on the LISP Location-Identity Separation System draft-ietf-lisp-architecture-00 [snip] 3.1. Another Packet-Switching Layer When considering the overall structure of the LISP system at a high level, it has proven most useful to think of it as another packet- switching layer, run on top of the original internet layer - much as the Internet first ran on top of the ARPANET. All the functions that a normal packet switch has to undertake - such as ensuring that it can reach its neighbours, and they FC: that they are still up - the devices that make up the LISP overlay also have to do, along the 'tunnels' which connect them to other LISP devices. [snip] 4.2. Need for a Mapping System LISP does need to have a mapping system, which brings design, implementation, configuration and operational costs. Surely all these costs are a bad thing? However, having a mapping system have FC: has/brings advantages, especially when there is a mapping layer which has global visibility (i.e. other entities know that it is there, and have an interface designed to be able to interact with it). This is unlike, say, the mappings in NAT, which are 'invisible' to the rest of the network. [snip] 5. Namespaces One of the key elements in any architecture, or architectural analysis, are the namespaces involved: what are their semantics and syntax, what are the kinds of things they name, etc. LISP has two key namespace, EIDs and RLOCs, but it must be emphasized that on an architectural level, neither the syntax, or, to a lesser degree, the semantics, of either are absolutely fixed. There are certain core semantics which are generaly unchanging (such as the notion that EIDs provide only identity, whereas RLOCs provide location), but as we will see, there is a certain amount of flexibility available for the long-term. In particular, all of LISP's key interfaces always include an Address Family Identifier (AFI) [AFI] for all names, so that new forms can be introduced at any time the need is felt. Of course, in practise such an introduction would not be a trivial exercise - but neither is is FC: remove one is impossibly painful, as is the case with IPv4's 32-bit addresses, which are effectively impossible to upgrade. [snip] 5.1.1. Residual Location Functionality in EIDs LISP retains, especially in the early stages of the deployment, in many cases some residual location-naming functionality in EIDs, FC: full stop This is to allow the packet to be correctly routed/forwarded to the destination node, once it has been unwrapped by the ETR - and this is a direct result of LISP's deployment philosophy (see [Introduction], Section "Deployment"). [snip] 5.3. Overlapping Uses of Existing Namespaces It is in theory possible to have a block of IPvN namespace used as both EIDs and RLOCs. In other words, EIDs from that block might map to some other RLOCs, and that block might also appear in the DFZ as the locators of some other ETRs. This is obviously potentially confusing - when a 'bare' IPvN address from one of these blocks, is it the RLOC, or the EID? Sometimes it FC: drop one it it obvious from the context, but in general one could not simply have a (hypothetical) table which assigns all of the address space to either 'EID' or 'RLOC'. [snip] 6. Scalability As with robustness, any global communication system must be scalable, and scalable up to almost any size. As previously mentioned (xref target="Perspectives-Packet"/), the large fanouts to be seen with LISP, due to its 'overlay' nature, present a special challenge. One likely saving grace is that as the Internet grows, most sites will likely only interact with a limited subset of the Internet; if nothing else, the separation of the world into language blocks means that content in, say, Chinese, will not be of interest to most of the rest of the world. This tendency will help with a lot of things which could be problematic if constant, full, N^2 connectivity were likely on all nodes; for example the caching of mappings. FC: I would say that generally content tends to 'cluster' in a limited number of servers/networks. Thus, the fanout is already limited. Moreover, I'm not convinced content will be segregated based on social/cultural considerations but on economical ones. Unfortunately, I'm right now lacking a good reference to support the claim. But, [1] gives an idea about how 'popular' websites are generally hosted by 'large' hosting providers. [1] http://www.pcworld.com/article/2012852/amazon-web-services-outage-takes-out-popular-websites-again.html [snip] The most important result of this change is that it avoids a concentration of resolution request traffic at the root of the indexing tree, a problem which by itself made ALT unsuitable for a global-scale system. The problem of root concentration (and thus overload) is almost unavoidable in ALT (even if masses of 'bypass' links are created). ALT's scalability also depends on enforcing an intelligent organization that aincreases FC: increases aggregation. Unfortunately, the current backbone routing BGP system shows that there is a risk of an organic growth of ALT, one which does not achieve aggregation. DDT does not display this weakness, since its organization is inherently hierarchical (and thus inherently aggregable). [snip] 11.2.1. Mapping Database Provider Lock-in This refers to the fact that if one does not like the entity which is providing the indexing for the part of the address space which one's EIDs are allocated out of, there isn't probably isn't FC: drop an "isn't" any way to switch to an alternative provider. It is not clear that this is a real probem, though - the fact that all DNS top-level zones only have a single registry has not been a problem, nor has the fact that if one doesn't like the service the registry offers, one can't take one's DNS name to another registry. [snip] --------------070204090507090809020709-- From arnatal@ac.upc.edu Sun Nov 4 15:12:59 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7FD21F87E6 for ; Sun, 4 Nov 2012 15:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] 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 WJLfLFbm83co for ; Sun, 4 Nov 2012 15:12:59 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id B773921F87D4 for ; Sun, 4 Nov 2012 15:12:58 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qA4NCROu007198 for ; Mon, 5 Nov 2012 00:12:42 +0100 Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by gw.ac.upc.edu (Postfix) with ESMTP id 0DCDF6B0255 for ; Mon, 5 Nov 2012 00:11:56 +0100 (CET) Received: by mail-vc0-f172.google.com with SMTP id fl11so5896651vcb.31 for ; Sun, 04 Nov 2012 15:11:45 -0800 (PST) Received: by 10.58.155.99 with SMTP id vv3mr7948012veb.50.1352070705625; Sun, 04 Nov 2012 15:11:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.69.116 with HTTP; Sun, 4 Nov 2012 15:11:25 -0800 (PST) From: =?ISO-8859-1?Q?Alberto_Rodr=EDguez_Natal?= Date: Mon, 5 Nov 2012 00:11:25 +0100 Message-ID: To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [lisp] Comments on draft-ietf-lisp-architecture-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 23:12:59 -0000 Hi all, No major comments, just a few typos. I think these haven't appeared yet in any previous review on the list. Sec. 5.1: they "contain contain" no information Sec. 5..1.1: between the ETR and the "desination" node Sec. 6: Broken reference? -> As previously mentioned (xref target="Perspectives-Packet"/) Sec. 11.1.1: thereby causing the "applicaton" Sec. 11.2.1: It is not clear that this is a real "probem" Regards, Alberto From pvinci@VinciConsulting.com Sun Nov 4 16:36:00 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3875021F880F for ; Sun, 4 Nov 2012 16:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 zWtRhLNIqXaA for ; Sun, 4 Nov 2012 16:35:59 -0800 (PST) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0E321F880B for ; Sun, 4 Nov 2012 16:35:59 -0800 (PST) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 19:35:58 -0500 From: Paul Vinciguerra To: Terry Manderson , LISP mailing list list Thread-Topic: Agenda for Tuesday Thread-Index: Ac26o6XvY047h930gkmlA+k+vCG+2QASY3rw Date: Mon, 5 Nov 2012 00:35:57 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C94A65432@NYDC-EXCH01.vinci-consulting-corp.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.232.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] Agenda for Tuesday X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 00:36:00 -0000 Will this available online for viewing/listening remotely? Paul -----Original Message----- From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of Ter= ry Manderson Sent: Sunday, November 04, 2012 10:47 AM To: LISP mailing list list Subject: [lisp] Agenda for Tuesday WG, The current agenda for our WG meeting on Tuesday is here: http://tools.ietf.org/wg/lisp/agenda I am more than comfortable for presenters to use their own laptops so that = graphics (etc) render appropriately, however I will still need your slide-s= et by 5pm Monday for the benefit of any folk following the meeting remotely= . Participants, it would be appreciated that you review the drafts being disc= ussed. It should also be noted that the last item: =3D-=3D-=3D-=3D-=3D-=3D-=3D- - Intro and Architecture, 30 mins Open mic discussion, come prepared. http://tools.ietf.org/wg/lisp/draft-ietf-lisp-introduction/ and http://tools.ietf.org/wg/lisp/draft-ietf-lisp-architecture/ =3D-=3D-=3D-=3D-=3D-=3D-=3D- is an effort to have an open discussion on these documents, I will facilita= te this discussion, however it would be of most benefit if all folks who co= me to the meeting have READ these two drafts beforehand!! It should be clear to WG now that these two documents are a gate on further= WG items. Cheers, Terry From fcoras@ac.upc.edu Mon Nov 5 00:13:40 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015C321F862D for ; Mon, 5 Nov 2012 00:13: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=[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 YRx3pk5PDRsq for ; Mon, 5 Nov 2012 00:13:39 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id E4AAA21F85C2 for ; Mon, 5 Nov 2012 00:13:38 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qA58CkEf014227; Mon, 5 Nov 2012 09:12:51 +0100 Received: from [192.168.1.11] (198.pool85-58-11.dynamic.orange.es [85.58.11.198]) by gw.ac.upc.edu (Postfix) with ESMTP id CFB2F6B024B; Mon, 5 Nov 2012 09:12:15 +0100 (CET) Message-ID: <509774D5.20504@ac.upc.edu> Date: Mon, 05 Nov 2012 09:12:05 +0100 From: Florin Coras User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Vinciguerra References: <6E5736BD68F770449C74FBAD975F807C94A65432@NYDC-EXCH01.vinci-consulting-corp.local> In-Reply-To: <6E5736BD68F770449C74FBAD975F807C94A65432@NYDC-EXCH01.vinci-consulting-corp.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: LISP mailing list list Subject: Re: [lisp] Agenda for Tuesday X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 08:13:40 -0000 Hi, On 11/05/2012 01:35 AM, Paul Vinciguerra wrote: > Will this available online for viewing/listening remotely? The meeting is Tuesday, November 6 from 13:00-15:00 Atlanta time. You can find the associated meeting materials here [1]. If the room (Salon B) doesn't change the audio will be available from [1] and the link to the jabber (xmpp) room is lisp@jabber.ietf.org [1] http://tools.ietf.org/agenda/85/ [2] http://ietf85streaming.dnsalias.net/ietf/ietf855.m3u Florin > > Paul > > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of Terry Manderson > Sent: Sunday, November 04, 2012 10:47 AM > To: LISP mailing list list > Subject: [lisp] Agenda for Tuesday > > WG, > > The current agenda for our WG meeting on Tuesday is here: > > http://tools.ietf.org/wg/lisp/agenda > > I am more than comfortable for presenters to use their own laptops so that graphics (etc) render appropriately, however I will still need your slide-set by 5pm Monday for the benefit of any folk following the meeting remotely. > > Participants, it would be appreciated that you review the drafts being discussed. > > It should also be noted that the last item: > > =-=-=-=-=-=-=- > - Intro and Architecture, 30 mins > Open mic discussion, come prepared. > http://tools.ietf.org/wg/lisp/draft-ietf-lisp-introduction/ > and > http://tools.ietf.org/wg/lisp/draft-ietf-lisp-architecture/ > =-=-=-=-=-=-=- > > is an effort to have an open discussion on these documents, I will facilitate this discussion, however it would be of most benefit if all folks who come to the meeting have READ these two drafts beforehand!! > > It should be clear to WG now that these two documents are a gate on further WG items. > > Cheers, > Terry > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From lear@cisco.com Mon Nov 5 02:43:49 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCBB21F844C for ; Mon, 5 Nov 2012 02:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.589 X-Spam-Level: X-Spam-Status: No, score=-110.589 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Smerp6TsRoLR for ; Mon, 5 Nov 2012 02:43:49 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7C43321F844B for ; Mon, 5 Nov 2012 02:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2800; q=dns/txt; s=iport; t=1352112228; x=1353321828; h=message-id:date:from:mime-version:to:subject; bh=2kaLb2djYHiScWOeKLcIVFhD8HCtgdqsWjtf80H/8Og=; b=MsNIU9fNNMpqrR9h4U09fNgLOq2i2VGGY7EjXlQPwXgmsWr5RmXZ7QJ/ mN5SDB4V0KB9iCFqhWcc6CXa/OU1FtQ8oXIhN93ZjOppHEAyW4HCh+Eox qoHFZKCS0ut2LQR1eNVdJm6jJIaud1jfy6YZ5aTYkvCYymHHReItmR3ln g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAFAJ+Xl1CQ/khR/2dsb2JhbABEhheFX7dMgQiCNwEQVSABDQ8WCwILAwIBAgE3FA0IAQEXB4domQiBK40okhuRKoETA5V7jlmBa4Jw X-IronPort-AV: E=Sophos;i="4.80,714,1344211200"; d="scan'208,217";a="9337779" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 05 Nov 2012 10:43:45 +0000 Received: from dhcp-10-55-88-197.cisco.com (dhcp-10-55-88-197.cisco.com [10.55.88.197]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA5AhjgL003578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Nov 2012 10:43:45 GMT Message-ID: <50979861.8060002@cisco.com> Date: Mon, 05 Nov 2012 11:43:45 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "lisp@ietf.org" X-Enigmail-Version: 1.4.5 Content-Type: multipart/alternative; boundary="------------060704060607050602070802" Subject: [lisp] comments on architecture/intro drafts X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 10:43:50 -0000 This is a multi-part message in MIME format. --------------060704060607050602070802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, I will not be in Atlanta this time round, but will try to listen in and comment via Jabber if there is a reason to. My comments, unsurprisingly, relate to the mapping systems in these drafts. In the architecture draft, Noel rightly points out NERD's characteristics, but states that a particular mapping system has been "chosen". One solution is better than two, quite frankly, from an interoperability standpoint, and that work goes on with LISP-ALT, I would suggest that the architecture properly delineate the mapping function from packet format and processing. There are different ways to play the "State Game". And this should also be clear in the intro, where Noel talks about fate sharing. One of the problems with NERD is that it doesn't do fate sharing, but rather expects that reachibility** testing is done between ETR & ITR through locator status bits. My point here isn't so much to rehash NERD as it is to make clear in the architecture the right layers so that The Next Mapping System that Yakov writes can plug in easily ;-) Eliot --------------060704060607050602070802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi,

I will not be in Atlanta this time round, but will try to listen in and comment via Jabber if there is a reason to.

My comments, unsurprisingly, relate to the mapping systems in these drafts.   In the architecture draft, Noel rightly points out NERD's characteristics, but states that a particular mapping system has been "chosen".  One solution is better than two, quite frankly, from an interoperability standpoint, and that work goes on with LISP-ALT, I would suggest that the architecture properly delineate the mapping function from packet format and processing.  There are different ways to play the "State Game".  And this should also be clear in the intro, where Noel talks about fate sharing.  One of the problems with NERD is that it doesn't do fate sharing, but rather expects that reachibility testing is done between ETR & ITR through locator status bits.

My point here isn't so much to rehash NERD as it is to make clear in the architecture the right layers so that The Next Mapping System that Yakov writes can plug in easily ;-)

Eliot
--------------060704060607050602070802-- From terry.manderson@icann.org Mon Nov 5 14:55:59 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A1B11E80A2 for ; Mon, 5 Nov 2012 14:55:59 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 460ZmGioM++Z for ; Mon, 5 Nov 2012 14:55:59 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id ED0AF11E8097 for ; Mon, 5 Nov 2012 14:55:58 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 5 Nov 2012 14:55:58 -0800 From: Terry Manderson To: Paul Vinciguerra , LISP mailing list list Date: Mon, 5 Nov 2012 14:55:56 -0800 Thread-Topic: Agenda for Tuesday Thread-Index: Ac26o6XvY047h930gkmlA+k+vCG+2QASY3rwAC7gv7Q= Message-ID: In-Reply-To: <6E5736BD68F770449C74FBAD975F807C94A65432@NYDC-EXCH01.vinci-consulting-corp.local> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3435036956_26518937" MIME-Version: 1.0 Subject: Re: [lisp] Agenda for Tuesday X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 22:55:59 -0000 --B_3435036956_26518937 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Paul, The meeting will indeed (as always in fact) be remote friendly. You can find details of the audio feed and jabber room details here: http://tools.ietf.org/agenda/85/ Cheers Terry On 5/11/12 10:35 AM, "Paul Vinciguerra" wrote: > Will this available online for viewing/listening remotely? > > Paul > > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of Terry > Manderson > Sent: Sunday, November 04, 2012 10:47 AM > To: LISP mailing list list > Subject: [lisp] Agenda for Tuesday > > WG, > > The current agenda for our WG meeting on Tuesday is here: > > http://tools.ietf.org/wg/lisp/agenda > > I am more than comfortable for presenters to use their own laptops so that > graphics (etc) render appropriately, however I will still need your slide-set > by 5pm Monday for the benefit of any folk following the meeting remotely. > > Participants, it would be appreciated that you review the drafts being > discussed. > > It should also be noted that the last item: > > =-=-=-=-=-=-=- > - Intro and Architecture, 30 mins > Open mic discussion, come prepared. > http://tools.ietf.org/wg/lisp/draft-ietf-lisp-introduction/ > and > http://tools.ietf.org/wg/lisp/draft-ietf-lisp-architecture/ > =-=-=-=-=-=-=- > > is an effort to have an open discussion on these documents, I will facilitate > this discussion, however it would be of most benefit if all folks who come to > the meeting have READ these two drafts beforehand!! > > It should be clear to WG now that these two documents are a gate on further WG > items. > > Cheers, > Terry --B_3435036956_26518937 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQULjl12ClbYa4CV2CuQf8a64pWWXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTA1MjI1NTU2WjANBgkqhkiG 9w0BAQEFAASCAQA75Rv0l8eWpObHLp9HY4h1S4c2mEmQAgpYyywvL+WhG4K6UNz9DHryWXJh aKCZgiR0SchruKZy8NrXR8nv1yBIU/7vwneWGHN24Q4dnMi+IxOGof48vakkJu5CwILvJy5X U+OOrzrYl5aFcDSiOL0k6du6oeNgiDW0LfxF1COCiaT6pKkgPLXSixef9gAb4b3jGFylIOSp LsumE9Crf01wFF2vTxGim3xCqe0urFqdC4yEyxCCiMfOq99kA7jPdBOhsSbRMGrvn3QKjdJY zTAVDUwt5Q+ED9LryE3/pslmLcZm/WMjzPVcvgZ1gIMbBFWNO9GMoYnBYqr9WQM0S4Un --B_3435036956_26518937-- From acabello@ac.upc.edu Tue Nov 6 13:38:31 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B34921F847B for ; Tue, 6 Nov 2012 13:38:31 -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 7Wu30vlR1Ssv for ; Tue, 6 Nov 2012 13:38:27 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 50CC221F8471 for ; Tue, 6 Nov 2012 13:38:26 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qA6LcOYV026355; Tue, 6 Nov 2012 22:38:24 +0100 Received: from [10.8.0.18] (unknown [10.8.0.18]) by gw.ac.upc.edu (Postfix) with ESMTP id D62FB6B006C; Tue, 6 Nov 2012 22:38:22 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Albert Cabellos In-Reply-To: <20121103132207.9350318C0DD@mercury.lcs.mit.edu> Date: Tue, 6 Nov 2012 16:38:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121103132207.9350318C0DD@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1499) Cc: lisp@ietf.org Subject: Re: [lisp] Comments on lisp-architecture X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 21:38:31 -0000 Hi Noel, Thanks! Actually after reading your email and realizing that ELPs can = also be EIDs I agree with the MPLS example, I feel that it is a good = example of what LISP can be, Albert On Nov 3, 2012, at 9:22 AM, Noel Chiappa = wrote: >> From: Albert Cabellos >=20 > Hi, thanks for the comments; I'll reply in detail later, but one thing = that > caught my eye quickly: >=20 >> MPLS-> Although it is a good analogy, I don't think that MPLS is a = good >> example given that with LISP we can't stack labels. >=20 > ??? LISP does use 'stacked' encapsulations (e.g. for a mobile node = moving to > a LISP site)? >=20 > And the mapping output could be an MPLS header with a 'pre-loaded' = label > stack (that's how you do source routing in a label-based system - I'm = not > sure if the existing MPLS stuff uses that capability, but eventually = in > Nimrod [which was the place that came up with the idea of label = stacks, see > RFC-1753] we realized that was how to minimize state setup, by = 'pre-loading' > the flow stack at the time the packet is created). >=20 > So I'm not sure I understand this comment? >=20 >=20 > In any case, I'm OK with using some other example - I just used MPLS = because > that's one that had been discussed, because there's a lot of = MPLS-capable > infrastructure already deployed. Did you have an alternative = suggestion? I > can't quickly come up with one that's as good as MPLS. >=20 > Noel From pvinci@VinciConsulting.com Tue Nov 6 17:26:36 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A9221F8B9B for ; Tue, 6 Nov 2012 17:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Y6hyUdVlGH14 for ; Tue, 6 Nov 2012 17:26:35 -0800 (PST) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id CFADB21F8B19 for ; Tue, 6 Nov 2012 17:26:34 -0800 (PST) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 20:26:33 -0500 From: Paul Vinciguerra To: "lisp@ietf.org" Thread-Topic: Comments on LISP intro and architecture from today's slides. Thread-Index: Ac28hMZdooY7GIapRrymIyDkA9BEAA== Date: Wed, 7 Nov 2012 01:26:33 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C94A70247@NYDC-EXCH01.vinci-consulting-corp.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.232.102] Content-Type: multipart/alternative; boundary="_000_6E5736BD68F770449C74FBAD975F807C94A70247NYDCEXCH01vinci_" MIME-Version: 1.0 Subject: [lisp] Comments on LISP intro and architecture from today's slides. X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 01:26:36 -0000 --_000_6E5736BD68F770449C74FBAD975F807C94A70247NYDCEXCH01vinci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I reviewed today's slides and the Jabber logs and have a few comments: Does the introduction document try to do too much? Would simpler be better in this case? My thought is that as an introduction, it should address: * The background problem/proposed solution. * "what's in it for me" - the use cases that this architectural change brin= gs to the table. * The life of the packet to introduce all the elements in context demonstra= ting their use. Many of the other sections, for example, 7, 11, and 12 all seem to be more = applicable and relate more to the architecture than the intro document. Paul --_000_6E5736BD68F770449C74FBAD975F807C94A70247NYDCEXCH01vinci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I reviewed today’s slides and the Jabber logs = and have a few comments:

 

Does the introduction document try to do too much?

 

Would simpler be better in this case?

 

My thought is that as an introduction, it should add= ress:

* The background problem/proposed solution.

* “what’s in it for me” – th= e use cases that this architectural change brings to the table.<= /p>

* The life of the packet to introduce all the elemen= ts in context demonstrating their use.

 

Many of the other sections, for example, 7, 11, and = 12 all seem to be more applicable and relate more to the architecture than = the intro document.

 

Paul

--_000_6E5736BD68F770449C74FBAD975F807C94A70247NYDCEXCH01vinci_-- From jnc@mercury.lcs.mit.edu Tue Nov 6 18:09:47 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6027321F8B54 for ; Tue, 6 Nov 2012 18:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HIhUGCjelBca for ; Tue, 6 Nov 2012 18:09:47 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id DD36B21F8B4E for ; Tue, 6 Nov 2012 18:09:46 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0EA7718C0CB; Tue, 6 Nov 2012 21:09:46 -0500 (EST) To: lisp@ietf.org Message-Id: <20121107020946.0EA7718C0CB@mercury.lcs.mit.edu> Date: Tue, 6 Nov 2012 21:09:46 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on LISP intro and architecture from today's slides. X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 02:09:48 -0000 > From: Paul Vinciguerra > Does the introduction document try to do too much? > ... > My thought is that as an introduction, it should address: > * The background problem/proposed solution. > * "what's in it for me" - the use cases that this architectural change > brings to the table. > * The life of the packet to introduce all the elements in context > demonstrating their use. This sounds like a 'LISP user' document, and that's probably a very useful document to have, but it's not an 'introduction to LISP for engineers who want to know a fair amount about how it works internally', which is what the existing 'Introduction' document is. (Although to be honest, for a 'user' document, I'm not sure I see the value of the third topic.) > relate more to the architecture than the intro document. The other document is _not_ 'the architecture document' (and I'm about to rename it, as soon as the ID block comes off, to emphasize that). An architecture document covers, to start with, _the architecture_ (duhh), which starts with talking about i) what the major pieces of the system are, and ii) how those pieces interact. None of that is in the second document. The pair of documents _together_ form an 'architecture' document, as it would normally be thought of. What really happened was that there used to be only one 'architecture' document, and it got too long, so it was split up into two documents. In deciding what to put where, I decided that making the first document be an 'engineers introduction to LISP' would provide a relatively coherent document, one which would stand, and be useful, on its own. Anyway, if someone (you?) would like to volunteer to write a 'users introduction to LISP', that would be fine with me, but I'd like to keep the 'engineers' introduction to LISP' more or less as it is - and if you and the WG think it would be better titled 'An Engineering Introduction to LISP", to more accurately portray what it is, that would be fine with me. Noel From pvinci@VinciConsulting.com Tue Nov 6 18:20:03 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F9321F8997 for ; Tue, 6 Nov 2012 18:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 IYL+qaMY6IhI for ; Tue, 6 Nov 2012 18:20:02 -0800 (PST) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id 67FA521F889D for ; Tue, 6 Nov 2012 18:20:01 -0800 (PST) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 21:20:00 -0500 From: Paul Vinciguerra To: "lisp@ietf.org" Thread-Topic: lisp deployment document Thread-Index: Ac28i0KgzlJXe8KrR8e8ShvYzf50gw== Date: Wed, 7 Nov 2012 02:19:59 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.232.102] Content-Type: multipart/alternative; boundary="_000_6E5736BD68F770449C74FBAD975F807C94A703ACNYDCEXCH01vinci_" MIME-Version: 1.0 Subject: [lisp] lisp deployment document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 02:20:03 -0000 --_000_6E5736BD68F770449C74FBAD975F807C94A703ACNYDCEXCH01vinci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jakab, et al. Expires April 23, 2013 [Page 21] Internet-Draft LISP Deployment October 2012 * To verify LISP connectivity, ping LISP connected sites. See http://www.lisp4.net/ and/or http://www.lisp6.net/ for potential candidates. This section seems overly simple. There are three deployment options that I am aware of: * Deployment in the Beta network * Deployment in a separate LISP Island connected via DDT * Deployment in a separate LISP Island not connected via DDT With PxTR's in the mix, pinging LISP sites doesn't assure end-end LISP conn= ectivity. It is our experience that PxTR's just magically make things work= , and because of that, it doesn't always flow the way you think it does. There probably needs to be some prefix that doesn't have a coarse aggregate= announced into the DFZ for testing end-end LISP connectivity for the first= two deployment options listed above. If you're the last deployment case, = you're on your own to verify end-end LISP connectivity. Paul --_000_6E5736BD68F770449C74FBAD975F807C94A703ACNYDCEXCH01vinci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jakab, et al.      &nb= sp;     Expires April 23, 2013    &= nbsp;           [Page 21]=

Internet-Draft      &n= bsp;        LISP Deployment  &= nbsp;           &nbs= p; October 2012

 

 

       *  To veri= fy LISP connectivity, ping LISP connected sites.  See

        &nbs= p; http://www.lisp4.net/ and/or http://www.lisp6.net/ for

        &nbs= p; potential candidates.

 

This section seems overly simple.

 

There are three deployment options that I am aware o= f:

·         Deployment in the Beta network

·         Deployment in a separate LISP Island connect= ed via DDT

·         Deployment in a separate LISP Island not con= nected via DDT

 

With PxTR’s in the mix, pinging LISP sites doe= sn’t assure end-end LISP connectivity.  It is our experience tha= t PxTR’s just magically make things work, and because of that, it doe= sn’t always flow the way you think it does.

 

There probably needs to be some prefix that doesn= 217;t have a coarse aggregate announced into the DFZ for testing end-end LI= SP connectivity for the first two deployment options listed above.  If= you’re the last deployment case, you’re on your own to verify end-end LISP connectivity.

 

Paul

--_000_6E5736BD68F770449C74FBAD975F807C94A703ACNYDCEXCH01vinci_-- From heinerhummel@aol.com Wed Nov 7 04:55:16 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FEB21F8ACD for ; Wed, 7 Nov 2012 04:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6] 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 7vrNqxNuiwQB for ; Wed, 7 Nov 2012 04:55:15 -0800 (PST) Received: from imr-da06.mx.aol.com (imr-da06.mx.aol.com [205.188.169.203]) by ietfa.amsl.com (Postfix) with ESMTP id 70A9E21F8A8F for ; Wed, 7 Nov 2012 04:55:15 -0800 (PST) Received: from mtaomg-ma06.r1000.mx.aol.com (mtaomg-ma06.r1000.mx.aol.com [172.29.41.13]) by imr-da06.mx.aol.com (8.14.1/8.14.1) with ESMTP id qA7Ct17u030227 for ; Wed, 7 Nov 2012 07:55:01 -0500 Received: from core-dqe005a.r1000.mail.aol.com (core-dqe005.r1000.mail.aol.com [172.29.162.81]) by mtaomg-ma06.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id AE1C9E000082 for ; Wed, 7 Nov 2012 07:55:01 -0500 (EST) References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> To: lisp@ietf.org In-Reply-To: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CF8AFE3BE3AC45_340_7C603_webmail-m021.sysops.aol.com" X-Mailer: Webmail 37130-STANDARD Received: from 178.27.21.1 by webmail-m021.sysops.aol.com (64.12.183.102) with HTTP (WebMailUI); Wed, 07 Nov 2012 07:55:01 -0500 Message-Id: <8CF8AFE3BD3029E-340-22317@webmail-m021.sysops.aol.com> X-Originating-IP: [178.27.21.1] Date: Wed, 7 Nov 2012 07:55:01 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1352292901; bh=GY4YI49SI4eVQIn7VQVMvRW2/HHqonBxSPp1LCeUu4I=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=mZ3ryIx93M2OP/ANRxaAfBGk6u6eDqt4ZoDu+GLIvcusmxOzgWI9aKfgP3LZ5myTW JAQfrROECIkm5bTESt+kPO+kyHH+e7B8LovnKv3jhHqZ3TgPqKVeF0pUI+gcrL4sXw 76Pns6yW1Sg0GNwt/kiWbKbzxR/3ITL1SeHMVjHM= X-AOL-SCOLL-SCORE: 0:2:380781184:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d290d509a5a252215 Subject: [lisp] draft-ietf-lisp-lcaf-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 12:55:16 -0000 This is a multi-part message in MIME format. ----------MB_8CF8AFE3BE3AC45_340_7C603_webmail-m021.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" As there is AFI=3D16387 Type 5, I would like to suggest an additional Type = by which the geographical coordinates wrt longitude and latitude are biject= ively mapped to {square degree#,square minute#, second row#, second column#= } such that the meridian (east/west) and equator ( north/south) dominated = scheme is transformed into a fast addressable (offsetting) scheme which sta= rts at the south pole and which only knows the directions to-east and to no= rth as by the following:=20 (1) Unicast: Square degree#: The globe may be conceived as 180 rings of sphericaltriangles/rectangles, s= tarting at the South pole with a ring of 360 sphericaltriangles, each of wh= ich is limited by two longitudes and latitude 89=C2=B0 Southfrom the Equato= r. Towards North there follow 178 rings of 360 sphericalrectangles, each of= which is limited by two consecutive longitudes andlatitudes. Finally there= is a last ring of 360 spherical triangles around theNorth pole. =20 Each spherical triangles/rectangles is assigned a square degree number from= 1 to 64800, startingat the South Pole with that triangle which is limited = by the twolongitude degrees 0 and 1 East, the South Pole and latitude 89 So= uth, windingfrom there in eastbound direction, while forming a full circle = such that number360 is assigned to that triangle, which is limited by the t= wo longitudedegrees 1 West and 0,while number 361 is assigned to that spher= ical rectangle,which is limited by the longitude degrees 0 and 1 East and t= he latitudes 89South and 88 South. While winding in eastbound direction and= while windingtowards the North Pole, the last number 64800 is assigned to = thatspherical triangle which is limited by the longitudes 1 West and 0, the= latitude89 North and the North Pole. =20 Square minute# derived from given longitude minute x and latitude minute y. if South of the Equator then minute row# =3D 60 =E2=80=93y else minute ro= w# =3D y+1 if West of Greenwich then minute column# =3D 60- x else minute column# =3D = x+1. square minute# =3D (minute row# -1) times 60 + minute column#Square minute#= derived from given longitude minute x and latitude minute y. second row# and second column# derived from given longitude second x and la= titude second y. if South of the Equator then second row# =3D 60 =E2=80=93y else second ro= w# =3D y+1 if West of Greenwich then second column# =3D 60- x else second column# =3D = x+1. (no second square# needs to be calculated) The proposed enhancement would enable a next-hop determination by either on= e or three table offsets in case of unicast forwarding (2) Multicast Multicast-Locator {square degree#; "multicast address"-number which is uni= que per indicated square degree} Well-known Multicast-Locator {square degree# =3D64801; standardized "Multic= ast address" number for that well-known service} =20 The Multicast-Locator enables the retrieving of the proper entry from a new= Multicast-FIB entry (inside a participating node only) which enables multi= ple concurrent next-hops eventually. (3) Anycast Anycast-Locator {square degree#; "anycast address"-number which is unique = per indicated square degree} Well-known Anycast-Locator {square degree# =3D64802; standardized "Anycast = address" number for that well-known service} The Anycast-Locator enables the retrieving of an entry of a new Anycast-FIB= (inside a participating node only) which enables just one next hop. While (2) and (3) specify which one out of multipe Multicast/Anycast-servic= es, at a more general place of the LISP header there should be some flags which indicate the fundamental forwarding type 0=3Dunicast,1=3Dm= ulticast, 2=3D anycast, 3=3D.broadcast, 4=3Dmp2p,.....) H.H. =20 =20 =20 =20 ----------MB_8CF8AFE3BE3AC45_340_7C603_webmail-m021.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

As there is AFI=3D16387 Typ= e 5, I would like to suggest an additional Type by which the geographical c= oordinates wrt longitude and latitude are bijectively mapped to {square deg= ree#,square minute#, second row#, second column#} such that the  meridian (east/west)= and equator ( north/south) dominated scheme is transformed into a fast addressable (= offsetting) scheme which starts at the south pole and which only knows the = directions to-east and to north as by the following: 

(1) Unicast:
Square degree#:
The globe may be conceived as 180 rings of spherical triangles/rectangles, starting at the South pole with a ring of 360 spheric= al triangles, each of which is limited by two longitudes and latitude 89=C2=B0= South from the Equator. Towards North there follow 178 rings of 360 spherical rectangles, each of which is limited by two consecutive longitudes and latitudes. Finally there is a last ring of 360 spherical triangles around t= he North pole.  
Each spherical triangles/rectangles is assigned a square d= egree number from 1 to 64800, starting at the South Pole with that triangle which is limited by the two longitude degrees 0 and 1 East, the South Pole and latitude 89 South, windi= ng from there in eastbound direction, while forming a full circle such that nu= mber 360 is assigned to that triangle, which is limited by the two longitude degrees 1 West and 0,while number 361 is assigned to that spherical rectang= le, which is limited by the longitude degrees 0 and 1 East and the latitudes 89 South and 88 South. While winding in eastbound direction and while winding towards the North Pole, the last number 64800 is assigned to that spherical triangle which is limited by the longitudes 1 West and 0, the lat= itude 89 North and the North Pole.  
Square mi= nute# derived from given longitude minute x and latitude minute y.
if &= nbsp;South of the Equator  then minute row# =3D 60 =E2=80=93y els= e minute row# =3D y+1
if West o= f Greenwich then minute column# =3D 60- x else minute column# =3D x+1.=
square minute= # =3D (minute row# -1) times 60 + minute column#Square minute# derived from given longitude minute x and lati= tude minute y.

second row# a= nd second column# derived from given longitude second x and latitude second= y.
if &= nbsp;South of the Equator  then second row# =3D 60 =E2=80=93y els= e second row# =3D y+1
if West o= f Greenwich then second column# =3D 60- x else second column# =3D x+1.=
(no second square# needs to be= calculated)

The proposed enhancement would= enable a next-hop determination by either one or three table offsets in ca= se of unicast forwarding

(2) Multicast
Multicast-Locator {square degree#;  = "multicast address"-number which is unique per indicated square degree}
Well-known Multicast-Locator {squa= re degree# =3D64801; standardized "Multicast address" number for that well-= known service}
 =
The Multicast-Locator enables = the retrieving of the proper entry from a new Multicast-FIB entry (inside a= participating node only) which enables multiple concurrent next-hops event= ually.

(3) Anycast
Anycast-Locator {square degree#;  "a= nycast address"-number which is unique per indicated square degree}
Well-known Anycast-Locator {square= degree# =3D64802; standardized "Anycast address" number for that well-know= n service}

The Anycast-Locator enables the retrieving of an entry of a= new Anycast-FIB  (inside a participating node only) which enables jus= t one next hop.

While (2) and (3) specify whic= h one out of multipe Multicast/Anycast-services, at a more general place of= the LISP header there should be
some flags which indicate the = fundamental forwarding type 0=3Dunicast,1=3Dmulticast, 2=3D anycast, 3=3D.b= roadcast, 4=3Dmp2p,.....)

H.H.
   =   
 

 
 
----------MB_8CF8AFE3BE3AC45_340_7C603_webmail-m021.sysops.aol.com-- From ljakab@ac.upc.edu Wed Nov 7 06:00:23 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA8221F8B67 for ; Wed, 7 Nov 2012 06:00:23 -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 kYALl1Dkyh7n for ; Wed, 7 Nov 2012 06:00:22 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9761421F8B62 for ; Wed, 7 Nov 2012 06:00:22 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qA7E0KO1022560; Wed, 7 Nov 2012 15:00:20 +0100 Received: from [192.168.1.5] (unknown [89.123.113.21]) by gw.ac.upc.edu (Postfix) with ESMTP id 880E16B0074; Wed, 7 Nov 2012 15:00:19 +0100 (CET) Message-ID: <509A6972.5070807@ac.upc.edu> Date: Wed, 07 Nov 2012 16:00:18 +0200 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: Paul Vinciguerra References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> In-Reply-To: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "lisp@ietf.org" Subject: Re: [lisp] lisp deployment document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:00:23 -0000 Hi Paul, Thank you for the feedback on the document, it's great having the operational community participate. Indeed, the existance of PxTR's are making the ping check less meaningful. How about combining the ping check with a traceroute? Even if the routers carrying the LISP encapsulated packets won't show up on a traceroute, you can see if the encapsulation/decapsulation happens at the expected locations (xTRs instead of PxTRs) or not. The LISP-only EID prefix you propose is definitely a good option too. But if I understand it correctly, it depends on a third party running a known good LISP test site. At the time of writing we didn't know of any such service, so it was not included as an possibility. Regading deployment options, why do you consider the first and second one separately? According to the ddt-root.org web site, the Beta network is a DDT connected LISP island as well. Sure, it runs deeper in the tree, delegating the 153.16/16 further down, but I wouldn't look at it as a separate deployment option. -Lori On 11/07/12 04:19, Paul Vinciguerra wrote: > > Jakab, et al. Expires April 23, 2013 [Page 21] > > Internet-Draft LISP Deployment October 2012 > > * To verify LISP connectivity, ping LISP connected sites. See > > http://www.lisp4.net/ and/or http://www.lisp6.net/ for > > potential candidates. > > This section seems overly simple. > > There are three deployment options that I am aware of: > > ·Deployment in the Beta network > > ·Deployment in a separate LISP Island connected via DDT > > ·Deployment in a separate LISP Island not connected via DDT > > With PxTR’s in the mix, pinging LISP sites doesn’t assure end-end LISP > connectivity. It is our experience that PxTR’s just magically make > things work, and because of that, it doesn’t always flow the way you > think it does. > > There probably needs to be some prefix that doesn’t have a coarse > aggregate announced into the DFZ for testing end-end LISP connectivity > for the first two deployment options listed above. If you’re the last > deployment case, you’re on your own to verify end-end LISP connectivity. > > Paul > From farinacci@gmail.com Wed Nov 7 06:06:24 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427E221F875C for ; Wed, 7 Nov 2012 06:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 qLxbBOygYL1Y for ; Wed, 7 Nov 2012 06:06:20 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BECE421F8794 for ; Wed, 7 Nov 2012 06:06:18 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1291621pbb.31 for ; Wed, 07 Nov 2012 06:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dFW0U8V6RjWFlQogXihklCNgkJf1L4+2dpaHUmfS6ok=; b=DuypYadV73OTGpHfEWoUuIzpnAAtR7SrIXkuAO92gC81Fc0nNxjaCvlL4ei2WF53Dk lfJyfkTYLDmpsWR79Ej5voOkfnnRONMlue0zdG/FVAS9eBfrkLc4T47AjJ0MFQD5R9sO V1mY5cI/xenj39V7tqbvv/twS538B1hFDTr24ohIueZ2C9TZlPSxf7sN8IK9pcRfFyDG 6kxUBjNWYksqlzyt5fUM1cbnHlyPuZkaUXW/1w84ph32lNov7mwmRwQbeS9p+QWuWmlD pkbk3BopOEYm9JEG4uVPXQGYwx1CdKizk7egi2C1Swwg5UBVoro7SPrI3UAMdHwp+YFG 6Acw== Received: by 10.68.196.170 with SMTP id in10mr14266760pbc.0.1352297178518; Wed, 07 Nov 2012 06:06:18 -0800 (PST) Received: from sjc-vpn5-326.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id ve6sm14179656pbc.58.2012.11.07.06.06.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 06:06:17 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <8CF8AFE3BD3029E-340-22317@webmail-m021.sysops.aol.com> Date: Wed, 7 Nov 2012 06:06:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <997B2419-BD23-4813-BEA9-277CADF38449@gmail.com> References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> <8CF8AFE3BD3029E-340-22317@webmail-m021.sysops.aol.com> To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.1499) Cc: lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp-lcaf-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:06:24 -0000 > As there is AFI=3D16387 Type 5, I would like to suggest an additional = Type by which the geographical coordinates wrt longitude and latitude = are bijectively mapped to {square degree#,square minute#, second row#, = second column#} such that the meridian (east/west) and equator ( = north/south) dominated scheme is transformed into a fast addressable = (offsetting) scheme which starts at the south pole and which only knows = the directions to-east and to north as by the following:=20 Why? Can you give us a specific use-case. > (1) Unicast: > Square degree#: > The globe may be conceived as 180 rings of spherical = triangles/rectangles, starting at the South pole with a ring of 360 = spherical triangles, each of which is limited by two longitudes and = latitude 89=B0 South from the Equator. Towards North there follow 178 = rings of 360 spherical rectangles, each of which is limited by two = consecutive longitudes and latitudes. Finally there is a last ring of = 360 spherical triangles around the North pole. =20 > Each spherical triangles/rectangles is assigned a square degree number = from 1 to 64800, starting at the South Pole with that triangle which is = limited by the two longitude degrees 0 and 1 East, the South Pole and = latitude 89 South, winding from there in eastbound direction, while = forming a full circle such that number 360 is assigned to that triangle, = which is limited by the two longitude degrees 1 West and 0,while number = 361 is assigned to that spherical rectangle, which is limited by the = longitude degrees 0 and 1 East and the latitudes 89 South and 88 South. = While winding in eastbound direction and while winding towards the North = Pole, the last number 64800 is assigned to that spherical triangle which = is limited by the longitudes 1 West and 0, the latitude 89 North and the = North Pole. =20 >=20 > Square minute# derived from given longitude minute x and latitude = minute y. > if South of the Equator then minute row# =3D 60 =96y else minute = row# =3D y+1 > if West of Greenwich then minute column# =3D 60- x else minute column# = =3D x+1. > square minute# =3D (minute row# -1) times 60 + minute column#Square = minute# derived from given longitude minute x and latitude minute y. >=20 > second row# and second column# derived from given longitude second x = and latitude second y. > if South of the Equator then second row# =3D 60 =96y else second = row# =3D y+1 > if West of Greenwich then second column# =3D 60- x else second column# = =3D x+1. > (no second square# needs to be calculated) >=20 > The proposed enhancement would enable a next-hop determination by = either one or three table offsets in case of unicast forwarding >=20 > (2) Multicast > Multicast-Locator {square degree#; "multicast address"-number which = is unique per indicated square degree} > Well-known Multicast-Locator {square degree# =3D64801; standardized = "Multicast address" number for that well-known service} > =20 > The Multicast-Locator enables the retrieving of the proper entry from = a new Multicast-FIB entry (inside a participating node only) which = enables multiple concurrent next-hops eventually. But a multicast entry will describe a set of receivers spread across the = planet. So the concept of a multicast group have a physical presents is = in conflict to its traditional and fundamental meaning. > (3) Anycast > Anycast-Locator {square degree#; "anycast address"-number which is = unique per indicated square degree} > Well-known Anycast-Locator {square degree# =3D64802; standardized = "Anycast address" number for that well-known service} >=20 > The Anycast-Locator enables the retrieving of an entry of a new = Anycast-FIB (inside a participating node only) which enables just one = next hop. >=20 > While (2) and (3) specify which one out of multipe = Multicast/Anycast-services, at a more general place of the LISP header = there should be > some flags which indicate the fundamental forwarding type = 0=3Dunicast,1=3Dmulticast, 2=3D anycast, 3=3D.broadcast, 4=3Dmp2p,.....) This is going to be a problem as well. An anycast address is multiple = unicast address residing in physically different places. One would have = a semantic issue knowing if an address is in multiple physical places = (same as the multicast point I brought up above) or an address has moved = from one physical location to another. Dino >=20 > H.H. > =20 > =20 >=20 > =20 > =20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Wed Nov 7 06:16:42 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117B221F88B2 for ; Wed, 7 Nov 2012 06:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 MZMreLK6eqjE for ; Wed, 7 Nov 2012 06:16:41 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD90F21F880A for ; Wed, 7 Nov 2012 06:16:40 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1298412pbb.31 for ; Wed, 07 Nov 2012 06:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kngpNzzOoYmaicRCqpTRhSP4kfJov3PqcX5q+RZ3dqY=; b=NOTcILR5O5EgVK3yz0MYA2QN8n4lR0jD8zlF0aNPd31nkQFpWYllSi0w1u4PhHLuK+ YAIWpUqPMsf3SZj2F1j8qowxuMTzjRfa0KOrvQwKnjHGdiUvLGYhqypE2D1w42wjKtjc 0xa6EAU3gSXIi28ffFk8lKitBUOODgEQEAlZxxFQuyZKHNaOtMfN9GorDNg7JrcxXHXq lPbHtfgOatN3ZOpJe+11K+eRioJAck/TP0skeK/ZLM6IfEh1NHMsF9eZuFdAWRwEu+4M YggRyF0WQjVZHWYEvWEadhrYIQVwkYIizP7yiyOqJiqOJ06Bx0/l9LRCWrlyNxNbgI0L i6bA== Received: by 10.68.191.1 with SMTP id gu1mr14059980pbc.150.1352297793668; Wed, 07 Nov 2012 06:16:33 -0800 (PST) Received: from sjc-vpn5-326.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id j8sm14346082paz.30.2012.11.07.06.16.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 06:16:32 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <509A6972.5070807@ac.upc.edu> Date: Wed, 7 Nov 2012 06:16:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9736C3B9-C91F-402B-8FC1-324B94478A47@gmail.com> References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> <509A6972.5070807@ac.upc.edu> To: Lori Jakab X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" Subject: Re: [lisp] lisp deployment document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:16:42 -0000 The LISP-only EID-prefix is one use of the draft-ietf-lisp-eid-block = draft. Dino On Nov 7, 2012, at 6:00 AM, Lori Jakab wrote: > Hi Paul, >=20 > Thank you for the feedback on the document, it's great having the > operational community participate. Indeed, the existance of PxTR's are > making the ping check less meaningful. How about combining the ping > check with a traceroute? Even if the routers carrying the LISP > encapsulated packets won't show up on a traceroute, you can see if the > encapsulation/decapsulation happens at the expected locations (xTRs > instead of PxTRs) or not. >=20 > The LISP-only EID prefix you propose is definitely a good option too. > But if I understand it correctly, it depends on a third party running = a > known good LISP test site. At the time of writing we didn't know of = any > such service, so it was not included as an possibility. >=20 > Regading deployment options, why do you consider the first and second > one separately? According to the ddt-root.org web site, the Beta = network > is a DDT connected LISP island as well. Sure, it runs deeper in the > tree, delegating the 153.16/16 further down, but I wouldn't look at it > as a separate deployment option. >=20 > -Lori >=20 > On 11/07/12 04:19, Paul Vinciguerra wrote: >>=20 >> Jakab, et al. Expires April 23, 2013 [Page 21] >>=20 >> Internet-Draft LISP Deployment October 2012 >>=20 >> * To verify LISP connectivity, ping LISP connected sites. See >>=20 >> http://www.lisp4.net/ and/or http://www.lisp6.net/ for >>=20 >> potential candidates. >>=20 >> This section seems overly simple. >>=20 >> There are three deployment options that I am aware of: >>=20 >> =B7Deployment in the Beta network >>=20 >> =B7Deployment in a separate LISP Island connected via DDT >>=20 >> =B7Deployment in a separate LISP Island not connected via DDT >>=20 >> With PxTR=92s in the mix, pinging LISP sites doesn=92t assure end-end = LISP >> connectivity. It is our experience that PxTR=92s just magically make >> things work, and because of that, it doesn=92t always flow the way = you >> think it does. >>=20 >> There probably needs to be some prefix that doesn=92t have a coarse >> aggregate announced into the DFZ for testing end-end LISP = connectivity >> for the first two deployment options listed above. If you=92re the = last >> deployment case, you=92re on your own to verify end-end LISP = connectivity. >>=20 >> Paul >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From pvinci@VinciConsulting.com Wed Nov 7 06:44:14 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5813721F88FA for ; Wed, 7 Nov 2012 06:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 vBhFjEl6S2cQ for ; Wed, 7 Nov 2012 06:44:13 -0800 (PST) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id 01EC221F875C for ; Wed, 7 Nov 2012 06:44:12 -0800 (PST) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 09:44:11 -0500 From: Paul Vinciguerra To: Lori Jakab Thread-Topic: [lisp] lisp deployment document Thread-Index: Ac28i0KgzlJXe8KrR8e8ShvYzf50gwAjt4gAAAoSATA= Date: Wed, 7 Nov 2012 14:44:10 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C94A7164D@NYDC-EXCH01.vinci-consulting-corp.local> References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> <509A6972.5070807@ac.upc.edu> In-Reply-To: <509A6972.5070807@ac.upc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.232.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] lisp deployment document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:44:14 -0000 > Hi Paul, >=20 > Thank you for the feedback on the document, it's great having the > operational community participate. Indeed, the existance of PxTR's are > making the ping check less meaningful. How about combining the ping check > with a traceroute? Even if the routers carrying the LISP encapsulated pac= kets > won't show up on a traceroute, you can see if the > encapsulation/decapsulation happens at the expected locations (xTRs > instead of PxTRs) or not. [PV] When we started doing more complex configurations that included LISP w= ith NAT and crypto, we could not rely on pings and traceroutes. We had to = rely on debugs and packet captures. It is great that LISP decodes are avai= lable in wireshark. >=20 > The LISP-only EID prefix you propose is definitely a good option too. > But if I understand it correctly, it depends on a third party running a k= nown > good LISP test site. At the time of writing we didn't know of any such se= rvice, > so it was not included as an possibility. >=20 [PV] I would expect that we should be able to request a small prefix from A= RIN for this as a Sect. 4.4 Micro allocation while waiting on the draft-iet= f-lisp-eid-block. > Regading deployment options, why do you consider the first and second one > separately? According to the ddt-root.org web site, the Beta network is a > DDT connected LISP island as well. Sure, it runs deeper in the tree, dele= gating > the 153.16/16 further down, but I wouldn't look at it as a separate > deployment option. >=20 [PV] If you deploy onto the beta network, the DDT component is already done= and is working. If you are connecting a new island to DDT, you may have a= dditional DDT related troubleshooting to perform. (for example,=20 The correctness of the authoritative map server DDT config) We were never = part of the beta network, we started out as my third case and evolved into = my second listed case.=20 > -Lori >=20 > On 11/07/12 04:19, Paul Vinciguerra wrote: > > > > Jakab, et al. Expires April 23, 2013 [Page 21] > > > > Internet-Draft LISP Deployment October 2012 > > > > * To verify LISP connectivity, ping LISP connected sites. See > > > > http://www.lisp4.net/ and/or http://www.lisp6.net/ for > > > > potential candidates. > > > > This section seems overly simple. > > > > There are three deployment options that I am aware of: > > > > *Deployment in the Beta network > > > > *Deployment in a separate LISP Island connected via DDT > > > > *Deployment in a separate LISP Island not connected via DDT > > > > With PxTR's in the mix, pinging LISP sites doesn't assure end-end LISP > > connectivity. It is our experience that PxTR's just magically make > > things work, and because of that, it doesn't always flow the way you > > think it does. > > > > There probably needs to be some prefix that doesn't have a coarse > > aggregate announced into the DFZ for testing end-end LISP connectivity > > for the first two deployment options listed above. If you're the last > > deployment case, you're on your own to verify end-end LISP connectivity= . > > > > Paul > > From ljakab@ac.upc.edu Wed Nov 7 07:27:15 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FFD21F8BFE for ; Wed, 7 Nov 2012 07:27:15 -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 0HsQJwgXkV4Z for ; Wed, 7 Nov 2012 07:27:14 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5095C21F8BF0 for ; Wed, 7 Nov 2012 07:27:14 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qA7FRBVN025629; Wed, 7 Nov 2012 16:27:11 +0100 Received: from [192.168.1.5] (unknown [89.123.113.21]) by gw.ac.upc.edu (Postfix) with ESMTP id C497E6B0074; Wed, 7 Nov 2012 16:27:10 +0100 (CET) Message-ID: <509A7DCE.8010008@ac.upc.edu> Date: Wed, 07 Nov 2012 17:27:10 +0200 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: Dino Farinacci References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> <509A6972.5070807@ac.upc.edu> <9736C3B9-C91F-402B-8FC1-324B94478A47@gmail.com> In-Reply-To: <9736C3B9-C91F-402B-8FC1-324B94478A47@gmail.com> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "lisp@ietf.org" Subject: Re: [lisp] lisp deployment document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:27:15 -0000 On 11/07/12 16:16, Dino Farinacci wrote: > The LISP-only EID-prefix is one use of the draft-ietf-lisp-eid-block draft. Sure, but that's IPv6-only. -Lori > > Dino > > On Nov 7, 2012, at 6:00 AM, Lori Jakab wrote: > >> Hi Paul, >> >> Thank you for the feedback on the document, it's great having the >> operational community participate. Indeed, the existance of PxTR's are >> making the ping check less meaningful. How about combining the ping >> check with a traceroute? Even if the routers carrying the LISP >> encapsulated packets won't show up on a traceroute, you can see if the >> encapsulation/decapsulation happens at the expected locations (xTRs >> instead of PxTRs) or not. >> >> The LISP-only EID prefix you propose is definitely a good option too. >> But if I understand it correctly, it depends on a third party running a >> known good LISP test site. At the time of writing we didn't know of any >> such service, so it was not included as an possibility. >> >> Regading deployment options, why do you consider the first and second >> one separately? According to the ddt-root.org web site, the Beta network >> is a DDT connected LISP island as well. Sure, it runs deeper in the >> tree, delegating the 153.16/16 further down, but I wouldn't look at it >> as a separate deployment option. >> >> -Lori >> >> On 11/07/12 04:19, Paul Vinciguerra wrote: >>> Jakab, et al. Expires April 23, 2013 [Page 21] >>> >>> Internet-Draft LISP Deployment October 2012 >>> >>> * To verify LISP connectivity, ping LISP connected sites. See >>> >>> http://www.lisp4.net/ and/or http://www.lisp6.net/ for >>> >>> potential candidates. >>> >>> This section seems overly simple. >>> >>> There are three deployment options that I am aware of: >>> >>> ·Deployment in the Beta network >>> >>> ·Deployment in a separate LISP Island connected via DDT >>> >>> ·Deployment in a separate LISP Island not connected via DDT >>> >>> With PxTR’s in the mix, pinging LISP sites doesn’t assure end-end LISP >>> connectivity. It is our experience that PxTR’s just magically make >>> things work, and because of that, it doesn’t always flow the way you >>> think it does. >>> >>> There probably needs to be some prefix that doesn’t have a coarse >>> aggregate announced into the DFZ for testing end-end LISP connectivity >>> for the first two deployment options listed above. If you’re the last >>> deployment case, you’re on your own to verify end-end LISP connectivity. >>> >>> Paul >>> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Wed Nov 7 07:32:27 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8278F21F8708 for ; Wed, 7 Nov 2012 07:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 2+fLricL15CS for ; Wed, 7 Nov 2012 07:32:26 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B74021F8679 for ; Wed, 7 Nov 2012 07:32:26 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1295286pad.31 for ; Wed, 07 Nov 2012 07:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rE/Yt1UDKw98kLgTMfXyeEaYw1kcIxOyiJnUMxAR+tA=; b=aS4y9Bvd9q8RUE4cq/9Jdk4zm32RABjrnPxnrL9V4eqxKk2AOF8hyYWNLI9qrkv4ur hiXHwTxXOmX1q0I5oSjsoybJ3SCQ/yvJR4MxwPY12FWej7MTLtmGnW938WBITLHUgmJx prNaUZU7NvE7DbZ8qJxqvxN6CymDL6lE/tN6sCzocbUzRhMnfKjQNUgbZ23psQNd5oDc f7B0W16AzEDtP4jQwwtjvvfhAuidMH1Za4XHJVv1w11/oZxJffgLcaRxPZ0riHFKZvnm inbuvGbtcpYf1bxhIM7bCkS/jg9yexLk/8DFr/EpZA6d6Qgk/r7RuBBHhwLotCdZ8TeV 7cpw== Received: by 10.68.136.9 with SMTP id pw9mr8155857pbb.155.1352302346160; Wed, 07 Nov 2012 07:32:26 -0800 (PST) Received: from sjc-vpn5-326.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id qj6sm14278718pbb.69.2012.11.07.07.32.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 07:32:24 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <509A7DCE.8010008@ac.upc.edu> Date: Wed, 7 Nov 2012 07:32:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4138AC45-D829-481D-A875-ECDE23D10E3F@gmail.com> References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> <509A6972.5070807@ac.upc.edu> <9736C3B9-C91F-402B-8FC1-324B94478A47@gmail.com> <509A7DCE.8010008@ac.upc.edu> To: Lori Jakab X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" Subject: Re: [lisp] lisp deployment document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:32:27 -0000 We could request a block of Class B IPv4 prefixes but the working group = didn't want to do that. Dino On Nov 7, 2012, at 7:27 AM, Lori Jakab wrote: > On 11/07/12 16:16, Dino Farinacci wrote: >> The LISP-only EID-prefix is one use of the draft-ietf-lisp-eid-block = draft. >=20 > Sure, but that's IPv6-only. >=20 > -Lori >=20 >>=20 >> Dino >>=20 >> On Nov 7, 2012, at 6:00 AM, Lori Jakab wrote: >>=20 >>> Hi Paul, >>>=20 >>> Thank you for the feedback on the document, it's great having the >>> operational community participate. Indeed, the existance of PxTR's = are >>> making the ping check less meaningful. How about combining the ping >>> check with a traceroute? Even if the routers carrying the LISP >>> encapsulated packets won't show up on a traceroute, you can see if = the >>> encapsulation/decapsulation happens at the expected locations (xTRs >>> instead of PxTRs) or not. >>>=20 >>> The LISP-only EID prefix you propose is definitely a good option = too. >>> But if I understand it correctly, it depends on a third party = running a >>> known good LISP test site. At the time of writing we didn't know of = any >>> such service, so it was not included as an possibility. >>>=20 >>> Regading deployment options, why do you consider the first and = second >>> one separately? According to the ddt-root.org web site, the Beta = network >>> is a DDT connected LISP island as well. Sure, it runs deeper in the >>> tree, delegating the 153.16/16 further down, but I wouldn't look at = it >>> as a separate deployment option. >>>=20 >>> -Lori >>>=20 >>> On 11/07/12 04:19, Paul Vinciguerra wrote: >>>> Jakab, et al. Expires April 23, 2013 [Page 21] >>>>=20 >>>> Internet-Draft LISP Deployment October 2012 >>>>=20 >>>> * To verify LISP connectivity, ping LISP connected sites. See >>>>=20 >>>> http://www.lisp4.net/ and/or http://www.lisp6.net/ for >>>>=20 >>>> potential candidates. >>>>=20 >>>> This section seems overly simple. >>>>=20 >>>> There are three deployment options that I am aware of: >>>>=20 >>>> =B7Deployment in the Beta network >>>>=20 >>>> =B7Deployment in a separate LISP Island connected via DDT >>>>=20 >>>> =B7Deployment in a separate LISP Island not connected via DDT >>>>=20 >>>> With PxTR=92s in the mix, pinging LISP sites doesn=92t assure = end-end LISP >>>> connectivity. It is our experience that PxTR=92s just magically = make >>>> things work, and because of that, it doesn=92t always flow the way = you >>>> think it does. >>>>=20 >>>> There probably needs to be some prefix that doesn=92t have a coarse >>>> aggregate announced into the DFZ for testing end-end LISP = connectivity >>>> for the first two deployment options listed above. If you=92re the = last >>>> deployment case, you=92re on your own to verify end-end LISP = connectivity. >>>>=20 >>>> Paul >>>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >=20 From pvinci@VinciConsulting.com Wed Nov 7 07:39:33 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C8F21F8B67 for ; Wed, 7 Nov 2012 07:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 eO+NgnA7BN27 for ; Wed, 7 Nov 2012 07:39:32 -0800 (PST) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2132321F8B18 for ; Wed, 7 Nov 2012 07:39:32 -0800 (PST) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 10:39:31 -0500 From: Paul Vinciguerra To: Dino Farinacci , Lori Jakab Thread-Topic: [lisp] lisp deployment document Thread-Index: Ac28i0KgzlJXe8KrR8e8ShvYzf50gwAjt4gAAACQ1wAAAnfPAAAALqSAAApXa+A= Date: Wed, 7 Nov 2012 15:39:30 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C94A7189B@NYDC-EXCH01.vinci-consulting-corp.local> References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> <509A6972.5070807@ac.upc.edu> <9736C3B9-C91F-402B-8FC1-324B94478A47@gmail.com> <509A7DCE.8010008@ac.upc.edu> <4138AC45-D829-481D-A875-ECDE23D10E3F@gmail.com> In-Reply-To: <4138AC45-D829-481D-A875-ECDE23D10E3F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.232.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] lisp deployment document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:39:33 -0000 Isn't 153.16.0.0/16 already the de facto ipv4 draft-ietf-lisp-eid-block? > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Wednesday, November 07, 2012 10:32 AM > To: Lori Jakab > Cc: Paul Vinciguerra; lisp@ietf.org > Subject: Re: [lisp] lisp deployment document >=20 > We could request a block of Class B IPv4 prefixes but the working group > didn't want to do that. >=20 > Dino >=20 > On Nov 7, 2012, at 7:27 AM, Lori Jakab wrote: >=20 > > On 11/07/12 16:16, Dino Farinacci wrote: > >> The LISP-only EID-prefix is one use of the draft-ietf-lisp-eid-block d= raft. > > > > Sure, but that's IPv6-only. > > > > -Lori > > > >> > >> Dino > >> > >> On Nov 7, 2012, at 6:00 AM, Lori Jakab wrote: > >> > >>> Hi Paul, > >>> > >>> Thank you for the feedback on the document, it's great having the > >>> operational community participate. Indeed, the existance of PxTR's > >>> are making the ping check less meaningful. How about combining the > >>> ping check with a traceroute? Even if the routers carrying the LISP > >>> encapsulated packets won't show up on a traceroute, you can see if > >>> the encapsulation/decapsulation happens at the expected locations > >>> (xTRs instead of PxTRs) or not. > >>> > >>> The LISP-only EID prefix you propose is definitely a good option too. > >>> But if I understand it correctly, it depends on a third party > >>> running a known good LISP test site. At the time of writing we > >>> didn't know of any such service, so it was not included as an possibi= lity. > >>> > >>> Regading deployment options, why do you consider the first and > >>> second one separately? According to the ddt-root.org web site, the > >>> Beta network is a DDT connected LISP island as well. Sure, it runs > >>> deeper in the tree, delegating the 153.16/16 further down, but I > >>> wouldn't look at it as a separate deployment option. > >>> > >>> -Lori > >>> > >>> On 11/07/12 04:19, Paul Vinciguerra wrote: > >>>> Jakab, et al. Expires April 23, 2013 [Page 21] > >>>> > >>>> Internet-Draft LISP Deployment October 2012 > >>>> > >>>> * To verify LISP connectivity, ping LISP connected sites. See > >>>> > >>>> http://www.lisp4.net/ and/or http://www.lisp6.net/ for > >>>> > >>>> potential candidates. > >>>> > >>>> This section seems overly simple. > >>>> > >>>> There are three deployment options that I am aware of: > >>>> > >>>> *Deployment in the Beta network > >>>> > >>>> *Deployment in a separate LISP Island connected via DDT > >>>> > >>>> *Deployment in a separate LISP Island not connected via DDT > >>>> > >>>> With PxTR's in the mix, pinging LISP sites doesn't assure end-end > >>>> LISP connectivity. It is our experience that PxTR's just magically > >>>> make things work, and because of that, it doesn't always flow the > >>>> way you think it does. > >>>> > >>>> There probably needs to be some prefix that doesn't have a coarse > >>>> aggregate announced into the DFZ for testing end-end LISP > >>>> connectivity for the first two deployment options listed above. If > >>>> you're the last deployment case, you're on your own to verify end-en= d > LISP connectivity. > >>>> > >>>> Paul > >>>> > >>> _______________________________________________ > >>> lisp mailing list > >>> lisp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lisp > > From farinacci@gmail.com Wed Nov 7 07:42:38 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4844321F8C29 for ; Wed, 7 Nov 2012 07:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 SOb8kf6Z8RaO for ; Wed, 7 Nov 2012 07:42:36 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id E6D0C21F8BE9 for ; Wed, 7 Nov 2012 07:42:27 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1301984pad.31 for ; Wed, 07 Nov 2012 07:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=OqJe4tYmmmhrg4cSQr6dTp7ZZi2+y6h4M+pTEERrTIc=; b=TzpI5z/JceojwkZiOnU3Zr2hIhfZu6wm2wD4C1jsrYGwwq7avFInFVComvKGFjzoMH 2GTh0O3J8o+5V+d3fmPgBVZVf5EJ++XqBuKs6LlXAlSj/JXSQRKHu9oZ1JABPWMSbCoy 9zoMyeBHaG7NsJILDN4oTiDFRsfWs5Le/4XYapreYJbtrlpsgJlkLysJJXcDkTD5Xwjf IoaBn2fr7o8/j3ljLZrbh4wfRGI4jCayTBvUnqxEuwtSdWA1aqUH7sBh3M99lh1RVlG5 /WOFLg1FJDHIASsmR8dGbERkAn/zzjl3TudV7HvmVewAym1gVJHKZhL9Gv3M9q9q0JmY +RdQ== Received: by 10.66.86.102 with SMTP id o6mr7300860paz.11.1352302947746; Wed, 07 Nov 2012 07:42:27 -0800 (PST) Received: from sjc-vpn5-326.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id rg9sm13464068pbc.46.2012.11.07.07.42.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 07:42:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <6E5736BD68F770449C74FBAD975F807C94A7189B@NYDC-EXCH01.vinci-consulting-corp.local> Date: Wed, 7 Nov 2012 07:42:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <119B8135-569F-48A9-B8FE-BFE654B25371@gmail.com> References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> <509A6972.5070807@ac.upc.edu> <9736C3B9-C91F-402B-8FC1-324B94478A47@gmail.com> <509A7DCE.8010008@ac.upc.edu> <4138AC45-D829-481D-A875-ECDE23D10E3F@gmail.com> <6E5736BD68F770449C74FBAD975F807C94A7189B@NYDC-EXCH01.vinci-consulting-corp.local> To: Paul Vinciguerra X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" Subject: Re: [lisp] lisp deployment document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:42:38 -0000 > Isn't 153.16.0.0/16 already the de facto ipv4 = draft-ietf-lisp-eid-block? Defacto, but an individual owns it and has been gracious to lend it out. = I'm not sure he would agree on global general use. Plus it is only a = single /16. Dino >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Wednesday, November 07, 2012 10:32 AM >> To: Lori Jakab >> Cc: Paul Vinciguerra; lisp@ietf.org >> Subject: Re: [lisp] lisp deployment document >>=20 >> We could request a block of Class B IPv4 prefixes but the working = group >> didn't want to do that. >>=20 >> Dino >>=20 >> On Nov 7, 2012, at 7:27 AM, Lori Jakab wrote: >>=20 >>> On 11/07/12 16:16, Dino Farinacci wrote: >>>> The LISP-only EID-prefix is one use of the = draft-ietf-lisp-eid-block draft. >>>=20 >>> Sure, but that's IPv6-only. >>>=20 >>> -Lori >>>=20 >>>>=20 >>>> Dino >>>>=20 >>>> On Nov 7, 2012, at 6:00 AM, Lori Jakab wrote: >>>>=20 >>>>> Hi Paul, >>>>>=20 >>>>> Thank you for the feedback on the document, it's great having the >>>>> operational community participate. Indeed, the existance of PxTR's >>>>> are making the ping check less meaningful. How about combining the >>>>> ping check with a traceroute? Even if the routers carrying the = LISP >>>>> encapsulated packets won't show up on a traceroute, you can see if >>>>> the encapsulation/decapsulation happens at the expected locations >>>>> (xTRs instead of PxTRs) or not. >>>>>=20 >>>>> The LISP-only EID prefix you propose is definitely a good option = too. >>>>> But if I understand it correctly, it depends on a third party >>>>> running a known good LISP test site. At the time of writing we >>>>> didn't know of any such service, so it was not included as an = possibility. >>>>>=20 >>>>> Regading deployment options, why do you consider the first and >>>>> second one separately? According to the ddt-root.org web site, the >>>>> Beta network is a DDT connected LISP island as well. Sure, it runs >>>>> deeper in the tree, delegating the 153.16/16 further down, but I >>>>> wouldn't look at it as a separate deployment option. >>>>>=20 >>>>> -Lori >>>>>=20 >>>>> On 11/07/12 04:19, Paul Vinciguerra wrote: >>>>>> Jakab, et al. Expires April 23, 2013 [Page 21] >>>>>>=20 >>>>>> Internet-Draft LISP Deployment October 2012 >>>>>>=20 >>>>>> * To verify LISP connectivity, ping LISP connected sites. See >>>>>>=20 >>>>>> http://www.lisp4.net/ and/or http://www.lisp6.net/ for >>>>>>=20 >>>>>> potential candidates. >>>>>>=20 >>>>>> This section seems overly simple. >>>>>>=20 >>>>>> There are three deployment options that I am aware of: >>>>>>=20 >>>>>> *Deployment in the Beta network >>>>>>=20 >>>>>> *Deployment in a separate LISP Island connected via DDT >>>>>>=20 >>>>>> *Deployment in a separate LISP Island not connected via DDT >>>>>>=20 >>>>>> With PxTR's in the mix, pinging LISP sites doesn't assure end-end >>>>>> LISP connectivity. It is our experience that PxTR's just = magically >>>>>> make things work, and because of that, it doesn't always flow the >>>>>> way you think it does. >>>>>>=20 >>>>>> There probably needs to be some prefix that doesn't have a coarse >>>>>> aggregate announced into the DFZ for testing end-end LISP >>>>>> connectivity for the first two deployment options listed above. = If >>>>>> you're the last deployment case, you're on your own to verify = end-end >> LISP connectivity. >>>>>>=20 >>>>>> Paul >>>>>>=20 >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >=20 From ljakab@ac.upc.edu Wed Nov 7 07:49:05 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C6021F8B74 for ; Wed, 7 Nov 2012 07:49:05 -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 GBmeBPfYeJkg for ; Wed, 7 Nov 2012 07:49:03 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id AEB9521F8B54 for ; Wed, 7 Nov 2012 07:48:59 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qA7FmvGv026379; Wed, 7 Nov 2012 16:48:57 +0100 Received: from [192.168.1.5] (unknown [89.123.113.21]) by gw.ac.upc.edu (Postfix) with ESMTP id 1B7896B0074; Wed, 7 Nov 2012 16:48:55 +0100 (CET) Message-ID: <509A82E7.6000502@ac.upc.edu> Date: Wed, 07 Nov 2012 17:48:55 +0200 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: Dino Farinacci References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> <509A6972.5070807@ac.upc.edu> <9736C3B9-C91F-402B-8FC1-324B94478A47@gmail.com> <509A7DCE.8010008@ac.upc.edu> <4138AC45-D829-481D-A875-ECDE23D10E3F@gmail.com> <6E5736BD68F770449C74FBAD975F807C94A7189B@NYDC-EXCH01.vinci-consulting-corp.local> <119B8135-569F-48A9-B8FE-BFE654B25371@gmail.com> In-Reply-To: <119B8135-569F-48A9-B8FE-BFE654B25371@gmail.com> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] lisp deployment document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:49:05 -0000 On 11/07/12 17:42, Dino Farinacci wrote: >> Isn't 153.16.0.0/16 already the de facto ipv4 draft-ietf-lisp-eid-block? > Defacto, but an individual owns it and has been gracious to lend it out. I'm not sure he would agree on global general use. Plus it is only a single /16. ...and is advertized in BGP, so it's not EID-only and the PxTR problem is still there, unless it is broken up into smaller prefixes (which is probably not what we want). -Lori > > Dino > >>> -----Original Message----- >>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>> Sent: Wednesday, November 07, 2012 10:32 AM >>> To: Lori Jakab >>> Cc: Paul Vinciguerra; lisp@ietf.org >>> Subject: Re: [lisp] lisp deployment document >>> >>> We could request a block of Class B IPv4 prefixes but the working group >>> didn't want to do that. >>> >>> Dino >>> >>> On Nov 7, 2012, at 7:27 AM, Lori Jakab wrote: >>> >>>> On 11/07/12 16:16, Dino Farinacci wrote: >>>>> The LISP-only EID-prefix is one use of the draft-ietf-lisp-eid-block draft. >>>> Sure, but that's IPv6-only. >>>> >>>> -Lori >>>> >>>>> Dino >>>>> >>>>> On Nov 7, 2012, at 6:00 AM, Lori Jakab wrote: >>>>> >>>>>> Hi Paul, >>>>>> >>>>>> Thank you for the feedback on the document, it's great having the >>>>>> operational community participate. Indeed, the existance of PxTR's >>>>>> are making the ping check less meaningful. How about combining the >>>>>> ping check with a traceroute? Even if the routers carrying the LISP >>>>>> encapsulated packets won't show up on a traceroute, you can see if >>>>>> the encapsulation/decapsulation happens at the expected locations >>>>>> (xTRs instead of PxTRs) or not. >>>>>> >>>>>> The LISP-only EID prefix you propose is definitely a good option too. >>>>>> But if I understand it correctly, it depends on a third party >>>>>> running a known good LISP test site. At the time of writing we >>>>>> didn't know of any such service, so it was not included as an possibility. >>>>>> >>>>>> Regading deployment options, why do you consider the first and >>>>>> second one separately? According to the ddt-root.org web site, the >>>>>> Beta network is a DDT connected LISP island as well. Sure, it runs >>>>>> deeper in the tree, delegating the 153.16/16 further down, but I >>>>>> wouldn't look at it as a separate deployment option. >>>>>> >>>>>> -Lori >>>>>> >>>>>> On 11/07/12 04:19, Paul Vinciguerra wrote: >>>>>>> Jakab, et al. Expires April 23, 2013 [Page 21] >>>>>>> >>>>>>> Internet-Draft LISP Deployment October 2012 >>>>>>> >>>>>>> * To verify LISP connectivity, ping LISP connected sites. See >>>>>>> >>>>>>> http://www.lisp4.net/ and/or http://www.lisp6.net/ for >>>>>>> >>>>>>> potential candidates. >>>>>>> >>>>>>> This section seems overly simple. >>>>>>> >>>>>>> There are three deployment options that I am aware of: >>>>>>> >>>>>>> *Deployment in the Beta network >>>>>>> >>>>>>> *Deployment in a separate LISP Island connected via DDT >>>>>>> >>>>>>> *Deployment in a separate LISP Island not connected via DDT >>>>>>> >>>>>>> With PxTR's in the mix, pinging LISP sites doesn't assure end-end >>>>>>> LISP connectivity. It is our experience that PxTR's just magically >>>>>>> make things work, and because of that, it doesn't always flow the >>>>>>> way you think it does. >>>>>>> >>>>>>> There probably needs to be some prefix that doesn't have a coarse >>>>>>> aggregate announced into the DFZ for testing end-end LISP >>>>>>> connectivity for the first two deployment options listed above. If >>>>>>> you're the last deployment case, you're on your own to verify end-end >>> LISP connectivity. >>>>>>> Paul >>>>>>> >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Wed Nov 7 07:52:37 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DD621F8C42 for ; Wed, 7 Nov 2012 07:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 OWNBYgERMGz1 for ; Wed, 7 Nov 2012 07:52:36 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD99E21F8B8E for ; Wed, 7 Nov 2012 07:52:36 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1308284pad.31 for ; Wed, 07 Nov 2012 07:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jGp2wEdUDkk5iza81AAxzBrqDI9yBwlr0tELpFq6r0Y=; b=ETCO/A000q0pholSzFmcCHJ89JcZuQ3HbC95ezC+It7V15iuQatbCJ6nucX1hX7/qF 0WsA11ShY5BJ/qfi1XMRrAiaXMls7KSufJJhlhIj3NsdzaCNyXc7Rwer8Xg2adLrc4Kh jOcIlqD1pxCEd7N+0BXpbGqLDes6eL9Anex3PQ+EWRk0QXsISOYiX/O6FOojiWvU5Bvu sCQItuuBuya5snsk7nIv9jad/OcNx66A0ASWxEBPyWoJjwU+SQDOl+FdEd+wuxW5jiUq CBbktXKo3mSFxUV/EJBT5Hnbyp1pVvhmajEvLAaWlHkP/H9S0UTb7NN2140rsLhdyxFz TaLg== Received: by 10.68.245.167 with SMTP id xp7mr15138760pbc.75.1352303556493; Wed, 07 Nov 2012 07:52:36 -0800 (PST) Received: from sjc-vpn5-326.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id uh10sm9573241pbc.35.2012.11.07.07.52.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 07:52:35 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <509A82E7.6000502@ac.upc.edu> Date: Wed, 7 Nov 2012 07:52:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9A4AA1D7-CD92-4F72-A153-6009EDB0C0FD@gmail.com> References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> <509A6972.5070807@ac.upc.edu> <9736C3B9-C91F-402B-8FC1-324B94478A47@gmail.com> <509A7DCE.8010008@ac.upc.edu> <4138AC45-D829-481D-A875-ECDE23D10E3F@gmail.com> <6E5736BD68F770449C74FBAD975F807C94A7189B@NYDC-EXCH01.vinci-consulting-corp.local> <119B8135-569F-48A9-B8FE-BFE654B25371@gmail.com> <509A82E7.6000502@ac.upc.edu> To: Lori Jakab X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" Subject: Re: [lisp] lisp deployment document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:52:37 -0000 > On 11/07/12 17:42, Dino Farinacci wrote: >>> Isn't 153.16.0.0/16 already the de facto ipv4 = draft-ietf-lisp-eid-block? >> Defacto, but an individual owns it and has been gracious to lend it = out. I'm not sure he would agree on global general use. Plus it is only = a single /16. >=20 > ...and is advertized in BGP, so it's not EID-only and the PxTR problem > is still there, unless it is broken up into smaller prefixes (which is > probably not what we want). But it will always be injected in underlying BGP because you need = non-LISP sites to talk to this destination prefix. The point is that = this prefix is not used as a locator (i.e. it is not the outer address = of any LISP encapsulated packet). Dino >=20 > -Lori >=20 >>=20 >> Dino >>=20 >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>> Sent: Wednesday, November 07, 2012 10:32 AM >>>> To: Lori Jakab >>>> Cc: Paul Vinciguerra; lisp@ietf.org >>>> Subject: Re: [lisp] lisp deployment document >>>>=20 >>>> We could request a block of Class B IPv4 prefixes but the working = group >>>> didn't want to do that. >>>>=20 >>>> Dino >>>>=20 >>>> On Nov 7, 2012, at 7:27 AM, Lori Jakab wrote: >>>>=20 >>>>> On 11/07/12 16:16, Dino Farinacci wrote: >>>>>> The LISP-only EID-prefix is one use of the = draft-ietf-lisp-eid-block draft. >>>>> Sure, but that's IPv6-only. >>>>>=20 >>>>> -Lori >>>>>=20 >>>>>> Dino >>>>>>=20 >>>>>> On Nov 7, 2012, at 6:00 AM, Lori Jakab wrote: >>>>>>=20 >>>>>>> Hi Paul, >>>>>>>=20 >>>>>>> Thank you for the feedback on the document, it's great having = the >>>>>>> operational community participate. Indeed, the existance of = PxTR's >>>>>>> are making the ping check less meaningful. How about combining = the >>>>>>> ping check with a traceroute? Even if the routers carrying the = LISP >>>>>>> encapsulated packets won't show up on a traceroute, you can see = if >>>>>>> the encapsulation/decapsulation happens at the expected = locations >>>>>>> (xTRs instead of PxTRs) or not. >>>>>>>=20 >>>>>>> The LISP-only EID prefix you propose is definitely a good option = too. >>>>>>> But if I understand it correctly, it depends on a third party >>>>>>> running a known good LISP test site. At the time of writing we >>>>>>> didn't know of any such service, so it was not included as an = possibility. >>>>>>>=20 >>>>>>> Regading deployment options, why do you consider the first and >>>>>>> second one separately? According to the ddt-root.org web site, = the >>>>>>> Beta network is a DDT connected LISP island as well. Sure, it = runs >>>>>>> deeper in the tree, delegating the 153.16/16 further down, but I >>>>>>> wouldn't look at it as a separate deployment option. >>>>>>>=20 >>>>>>> -Lori >>>>>>>=20 >>>>>>> On 11/07/12 04:19, Paul Vinciguerra wrote: >>>>>>>> Jakab, et al. Expires April 23, 2013 [Page 21] >>>>>>>>=20 >>>>>>>> Internet-Draft LISP Deployment October 2012 >>>>>>>>=20 >>>>>>>> * To verify LISP connectivity, ping LISP connected sites. See >>>>>>>>=20 >>>>>>>> http://www.lisp4.net/ and/or http://www.lisp6.net/ for >>>>>>>>=20 >>>>>>>> potential candidates. >>>>>>>>=20 >>>>>>>> This section seems overly simple. >>>>>>>>=20 >>>>>>>> There are three deployment options that I am aware of: >>>>>>>>=20 >>>>>>>> *Deployment in the Beta network >>>>>>>>=20 >>>>>>>> *Deployment in a separate LISP Island connected via DDT >>>>>>>>=20 >>>>>>>> *Deployment in a separate LISP Island not connected via DDT >>>>>>>>=20 >>>>>>>> With PxTR's in the mix, pinging LISP sites doesn't assure = end-end >>>>>>>> LISP connectivity. It is our experience that PxTR's just = magically >>>>>>>> make things work, and because of that, it doesn't always flow = the >>>>>>>> way you think it does. >>>>>>>>=20 >>>>>>>> There probably needs to be some prefix that doesn't have a = coarse >>>>>>>> aggregate announced into the DFZ for testing end-end LISP >>>>>>>> connectivity for the first two deployment options listed above. = If >>>>>>>> you're the last deployment case, you're on your own to verify = end-end >>>> LISP connectivity. >>>>>>>> Paul >>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> lisp mailing list >>>>>>> lisp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lisp >=20 From ljakab@ac.upc.edu Wed Nov 7 08:02:12 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3B521F8C12 for ; Wed, 7 Nov 2012 08:02:12 -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 vi2EyIOUfMOw for ; Wed, 7 Nov 2012 08:02:11 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 23DE621F8C04 for ; Wed, 7 Nov 2012 08:02:10 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id qA7G29nY026791; Wed, 7 Nov 2012 17:02:09 +0100 Received: from [192.168.1.5] (unknown [89.123.113.21]) by gw.ac.upc.edu (Postfix) with ESMTP id 13C746B0074; Wed, 7 Nov 2012 17:02:07 +0100 (CET) Message-ID: <509A85FF.3070109@ac.upc.edu> Date: Wed, 07 Nov 2012 18:02:07 +0200 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: Dino Farinacci References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> <509A6972.5070807@ac.upc.edu> <9736C3B9-C91F-402B-8FC1-324B94478A47@gmail.com> <509A7DCE.8010008@ac.upc.edu> <4138AC45-D829-481D-A875-ECDE23D10E3F@gmail.com> <6E5736BD68F770449C74FBAD975F807C94A7189B@NYDC-EXCH01.vinci-consulting-corp.local> <119B8135-569F-48A9-B8FE-BFE654B25371@gmail.com> <509A82E7.6000502@ac.upc.edu> <9A4AA1D7-CD92-4F72-A153-6009EDB0C0FD@gmail.com> In-Reply-To: <9A4AA1D7-CD92-4F72-A153-6009EDB0C0FD@gmail.com> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "lisp@ietf.org" Subject: Re: [lisp] lisp deployment document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:02:12 -0000 On 11/07/12 17:52, Dino Farinacci wrote: >> On 11/07/12 17:42, Dino Farinacci wrote: >>>> Isn't 153.16.0.0/16 already the de facto ipv4 draft-ietf-lisp-eid-block? >>> Defacto, but an individual owns it and has been gracious to lend it out. I'm not sure he would agree on global general use. Plus it is only a single /16. >> ...and is advertized in BGP, so it's not EID-only and the PxTR problem >> is still there, unless it is broken up into smaller prefixes (which is >> probably not what we want). > But it will always be injected in underlying BGP because you need non-LISP sites to talk to this destination prefix. The point is that this prefix is not used as a locator (i.e. it is not the outer address of any LISP encapsulated packet). Right, but if I understood it correctly (and Paul, please correct me if I got it wrong), Paul was advocating for the existance of a small block that is a "hole" in the DFZ, as a reliable way to determine LISP connectivity. Do we want to ask for a block specifically for that purpose? -Lori On 11/07/12 04:19, Paul Vinciguerra wrote: [...] > There probably needs to be some prefix that doesn’t have a coarse aggregate announced into the DFZ for testing end-end LISP connectivity for the first two deployment options listed above. From pvinci@VinciConsulting.com Wed Nov 7 08:12:18 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E089E21F8C8B for ; Wed, 7 Nov 2012 08:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 vfjBp3YOudqY for ; Wed, 7 Nov 2012 08:12:18 -0800 (PST) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2591221F8C80 for ; Wed, 7 Nov 2012 08:12:18 -0800 (PST) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 11:12:17 -0500 From: Paul Vinciguerra To: Lori Jakab , Dino Farinacci Thread-Topic: [lisp] lisp deployment document Thread-Index: Ac28i0KgzlJXe8KrR8e8ShvYzf50gwAjt4gAAACQ1wAAAnfPAAAALqSAAApXa+D//7ARAIAAAdKAgAABBQCAAAKrgIAAUyjA Date: Wed, 7 Nov 2012 16:12:16 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C94A71AC5@NYDC-EXCH01.vinci-consulting-corp.local> References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> <509A6972.5070807@ac.upc.edu> <9736C3B9-C91F-402B-8FC1-324B94478A47@gmail.com> <509A7DCE.8010008@ac.upc.edu> <4138AC45-D829-481D-A875-ECDE23D10E3F@gmail.com> <6E5736BD68F770449C74FBAD975F807C94A7189B@NYDC-EXCH01.vinci-consulting-corp.local> <119B8135-569F-48A9-B8FE-BFE654B25371@gmail.com> <509A82E7.6000502@ac.upc.edu> <9A4AA1D7-CD92-4F72-A153-6009EDB0C0FD@gmail.com> <509A85FF.3070109@ac.upc.edu> In-Reply-To: <509A85FF.3070109@ac.upc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.232.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] lisp deployment document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:12:19 -0000 >=20 > Right, but if I understood it correctly (and Paul, please correct me if I= got it > wrong), Paul was advocating for the existance of a small block that is a = "hole" > in the DFZ, as a reliable way to determine LISP connectivity. Do we want = to > ask for a block specifically for that purpose? [PV] Yes. I was asking about a single "tree in the forest" for exactly th= at purpose and I think Dino is pointing out that there are other reasons fo= r this besides mine and we need to address the much broader need "the fores= t". For this one purpose, a single /24 goes a long way under LISP.=20 From internet-drafts@ietf.org Wed Nov 7 08:24:42 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0178421F8C32; Wed, 7 Nov 2012 08:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 U4cKwHyDooHf; Wed, 7 Nov 2012 08:24:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1DE21F8BF2; Wed, 7 Nov 2012 08:24:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121107162441.30678.25200.idtracker@ietfa.amsl.com> Date: Wed, 07 Nov 2012 08:24:41 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:24:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : LISP EID Block Author(s) : Luigi Iannone Darrel Lewis David Meyer Vince Fuller Filename : draft-ietf-lisp-eid-block-03.txt Pages : 11 Date : 2012-11-07 Abstract: This is a direction to IANA to allocate a /16 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-eid-block-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-eid-block-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From heinerhummel@aol.com Wed Nov 7 08:37:59 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B631F21F8C83 for ; Wed, 7 Nov 2012 08:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, J_CHICKENPOX_66=0.6] 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 OmKANdVsk9zF for ; Wed, 7 Nov 2012 08:37:58 -0800 (PST) Received: from imr-ma01.mx.aol.com (imr-ma01.mx.aol.com [64.12.206.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5858121F8C81 for ; Wed, 7 Nov 2012 08:37:58 -0800 (PST) Received: from mtaomg-mb03.r1000.mx.aol.com (mtaomg-mb03.r1000.mx.aol.com [172.29.41.74]) by imr-ma01.mx.aol.com (Outbound Mail Relay) with ESMTP id CD9B4380000D9; Wed, 7 Nov 2012 11:37:57 -0500 (EST) Received: from core-dqe005a.r1000.mail.aol.com (core-dqe005.r1000.mail.aol.com [172.29.162.81]) by mtaomg-mb03.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id 791D2E00008D; Wed, 7 Nov 2012 11:37:57 -0500 (EST) References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> <8CF8AFE3BD3029E-340-22317@webmail-m021.sysops.aol.com> <997B2419-BD23-4813-BEA9-277CADF38449@gmail.com> To: farinacci@gmail.com In-Reply-To: <997B2419-BD23-4813-BEA9-277CADF38449@gmail.com> X-MB-Message-Source: WebUI Received: from 178.27.21.1 by webmail-m021.sysops.aol.com (64.12.183.102) with HTTP (WebMailUI); Wed, 07 Nov 2012 11:37:57 -0500 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CF8B1D606BBF95_340_82170_webmail-m021.sysops.aol.com" X-Mailer: Webmail 37130-STANDARD Message-Id: <8CF8B1D606BBF95-340-23C7C@webmail-m021.sysops.aol.com> X-Originating-IP: [178.27.21.1] Date: Wed, 7 Nov 2012 11:37:57 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1352306277; bh=IAaEbznEY9fTTJwj2jFfzaC4jMAbAoilwhsQDS+FbXk=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=xR+BfDjU82SFv3PcXc6aB40Nix0W0F0N6SefmHh1aTdORx6rlTSfyU6b0JRL+Q2eb 71D0jNVNySFi/SQ9G0O19Rwu8kV+rn6Rke2vjAnmpVAlwrXORtfcQ75A8D4/3o/UM9 XvUKIpKDah+t18etkkul1A6y+1JA1xrXQHY2+UAY= X-AOL-SCOLL-SCORE: 0:2:465803808:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d294a509a8e652483 Cc: lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp-lcaf-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:37:59 -0000 This is a multi-part message in MIME format. ----------MB_8CF8B1D606BBF95_340_82170_webmail-m021.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Dino, thank you for your response. I haven't followed up LISP for a long time and indeed read draft-...-lcaf-0= 0 today for the first time. Hereby I saw that particular address family and as one of several choices t= he indication of longitude/latidude degree/minute/second which was and whic= h still is the basis for what I described by draft-hummel-tara-00. For sure, the geographical coordination information can be 1:1 mapped from = type 5 to my proposed "TARA"-form and vice versus. The advantage of receiving the unicast-locator in the TARA-form is that you= can use it like an incoming MPLS-label, here to offset either 1 or 3 table= s for retrieving the next hop info. This is much faster than running 19 bin= ary search cycles applied to a FIB with more than 2^18 entries and the conv= ersion from type 5 to TARA-type wouldn't have to be done at each next hop e= ither (and, see above,if one needs the info in type 5 form that can easily = be derived from TARA-form too). Multicast, Anycast: In the past I also believed that there can't be a thing like a Multicast-Lo= cator. But then I developed a Multicast-model which only needs finite-state= -machines at the senderTR, at the receiverTRs, and yes at entry-border nodes of geopa= tches. Any other participating node does only have a single multicast-FIB e= ntry wrt to a particular multicast instance. I call that state-less multica= st. What is new, i.e. what breaks up with traditional IETF-view: a) I differentiate between a unicast-FIB, a multicast-FIB, a anycast-FIB (i= nstead of having a (one) FIB per se) b) Only the (already) participating nodes (wrt a particular multicast insta= nce) do have such a multicast-FIB entry which comprises just the particular= multicast-locator, one uplink, and evtl. multiple downlinks to neighboring= nodes - nothing else. In summary they form the delivery tree which is also= used for exchanging messages like QUIT, PRUNE, and especially for new mess= ages which are needed as to enable that all participating parties (the send= er as well as the receivers) can roam i.e can be mobile. =20 Anycast: So far no one has ever developed an Anycast-model with JOINs and Q= UITs analogously to Multicast. Don't think that I do not know the traditional understanding of anycast. An= d there are certainly services whereby EVERY node should "participate" in t= he anycast service without extra-joining, i.e. just by learning about the p= otential anycast-destinations. I think there are enough application of either brand ( I always think of we= ll-scoped anycast when I have to drive around in Munich looking for a parki= ng lot:-) Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Dino Farinacci An: HeinerHummel Cc: lisp Verschickt: Mi, 7 Nov 2012 3:06 pm Betreff: Re: [lisp] draft-ietf-lisp-lcaf-00 > As there is AFI=3D16387 Type 5, I would like to suggest an additional Typ= e by=20 which the geographical coordinates wrt longitude and latitude are bijective= ly=20 mapped to {square degree#,square minute#, second row#, second column#} such= that=20 the meridian (east/west) and equator ( north/south) dominated scheme is=20 transformed into a fast addressable (offsetting) scheme which starts at the= =20 south pole and which only knows the directions to-east and to north as by t= he=20 following:=20 Why? Can you give us a specific use-case. > (1) Unicast: > Square degree#: > The globe may be conceived as 180 rings of spherical triangles/rectangles= ,=20 starting at the South pole with a ring of 360 spherical triangles, each of = which=20 is limited by two longitudes and latitude 89=C2=B0 South from the Equator. = Towards=20 North there follow 178 rings of 360 spherical rectangles, each of which is= =20 limited by two consecutive longitudes and latitudes. Finally there is a las= t=20 ring of 360 spherical triangles around the North pole. =20 > Each spherical triangles/rectangles is assigned a square degree number fr= om 1=20 to 64800, starting at the South Pole with that triangle which is limited by= the=20 two longitude degrees 0 and 1 East, the South Pole and latitude 89 South,= =20 winding from there in eastbound direction, while forming a full circle such= that=20 number 360 is assigned to that triangle, which is limited by the two longit= ude=20 degrees 1 West and 0,while number 361 is assigned to that spherical rectang= le,=20 which is limited by the longitude degrees 0 and 1 East and the latitudes 89= =20 South and 88 South. While winding in eastbound direction and while winding= =20 towards the North Pole, the last number 64800 is assigned to that spherical= =20 triangle which is limited by the longitudes 1 West and 0, the latitude 89 N= orth=20 and the North Pole. =20 >=20 > Square minute# derived from given longitude minute x and latitude minute = y. > if South of the Equator then minute row# =3D 60 =E2=80=93y else minute = row# =3D y+1 > if West of Greenwich then minute column# =3D 60- x else minute column# = =3D x+1. > square minute# =3D (minute row# -1) times 60 + minute column#Square minut= e#=20 derived from given longitude minute x and latitude minute y. >=20 > second row# and second column# derived from given longitude second x and= =20 latitude second y. > if South of the Equator then second row# =3D 60 =E2=80=93y else second = row# =3D y+1 > if West of Greenwich then second column# =3D 60- x else second column# = =3D x+1. > (no second square# needs to be calculated) >=20 > The proposed enhancement would enable a next-hop determination by either = one=20 or three table offsets in case of unicast forwarding >=20 > (2) Multicast > Multicast-Locator {square degree#; "multicast address"-number which is u= nique=20 per indicated square degree} > Well-known Multicast-Locator {square degree# =3D64801; standardized "Mult= icast=20 address" number for that well-known service} > =20 > The Multicast-Locator enables the retrieving of the proper entry from a n= ew=20 Multicast-FIB entry (inside a participating node only) which enables multip= le=20 concurrent next-hops eventually. But a multicast entry will describe a set of receivers spread across the pl= anet.=20 So the concept of a multicast group have a physical presents is in conflict= to=20 its traditional and fundamental meaning. > (3) Anycast > Anycast-Locator {square degree#; "anycast address"-number which is uniqu= e per=20 indicated square degree} > Well-known Anycast-Locator {square degree# =3D64802; standardized "Anycas= t=20 address" number for that well-known service} >=20 > The Anycast-Locator enables the retrieving of an entry of a new Anycast-F= IB =20 (inside a participating node only) which enables just one next hop. >=20 > While (2) and (3) specify which one out of multipe Multicast/Anycast-serv= ices,=20 at a more general place of the LISP header there should be > some flags which indicate the fundamental forwarding type 0=3Dunicast,1= =3Dmulticast,=20 2=3D anycast, 3=3D.broadcast, 4=3Dmp2p,.....) This is going to be a problem as well. An anycast address is multiple unica= st=20 address residing in physically different places. One would have a semantic = issue=20 knowing if an address is in multiple physical places (same as the multicast= =20 point I brought up above) or an address has moved from one physical locatio= n to=20 another. Dino >=20 > H.H. > =20 > =20 >=20 > =20 > =20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp =20 ----------MB_8CF8B1D606BBF95_340_82170_webmail-m021.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Dino, thank you for your re= sponse.

I haven't followed up LISP for a long time and indeed read draft-...-l= caf-00 today for the first time.
Hereby I saw that particular address family and as one of several choi= ces the indication of longitude/latidude degree/minute/second which was and= which still is the basis for what I described by draft-hummel-tara-00.

For sure, the geographical coordination information can be 1:1 mapped = from type 5 to my proposed "TARA"-form and vice versus.
The advantage of receiving the unicast-locator in the TARA-form is tha= t you can use it like an incoming MPLS-label, here to offset either 1 or 3 = tables for retrieving the next hop info. This is much faster than running 19 binary search cycles applied to a F= IB with more than 2^18 entries and the conversion from type 5 to TARA-type = wouldn't have to be done at each next hop either (and, see above,if one nee= ds the info in type 5 form that can easily be derived from TARA-form too).<= /span>

Multicast, Anycast:
In the past I also believed that there can't be a thing like a Multica= st-Locator. But then I developed a Multicast-model which only needs finite-= state-machines
at the senderTR, at the receiverTRs, and yes at entry-border nodes of = geopatches. Any other participating node does only have a single multicast-= FIB entry wrt to a particular multicast instance. I call that state-less mu= lticast.

What is new, i.e. what breaks up with traditional IETF-view:
a) I differentiate between a unicast-FIB, a multicast-FIB, a anycast-F= IB (instead of having a (one) FIB per se)
b) Only the (already) participating nodes (wrt a particular multicast = instance) do have such a multicast-FIB entry which comprises just the parti= cular multicast-locator, one uplink, and evtl. multiple downlinks to neighb= oring nodes - nothing else. In summary they form the delivery tree which is= also used for exchanging messages like QUIT, PRUNE, and especially for new= messages which are needed as to enable that all participating parties (the= sender as well as the receivers) can roam i.e can be mobile.
 
Anycast: So far no one has ever developed an Anycast-model with JOINs = and QUITs analogously to Multicast.
Don't think that I do not know the traditional understanding of anycas= t. And there are certainly services whereby EVERY node should "participate"= in the anycast service without extra-joining, i.e. just by learning about = the potential anycast-destinations.
I think there are enough application of either brand ( I always think = of well-scoped anycast when I have to drive around in Munich looking for a = parking lot:-)

Heiner




-----= Urspr=C3=BCngliche Mitteilung-----
Von: Dino Farinacci <farinacci@gmail.com>
An: HeinerHummel <HeinerHummel@aol.com>
Cc: lisp <lisp@ietf.org>
Verschickt: Mi, 7 Nov 2012 3:06 pm
Betreff: Re: [lisp] draft-ietf-lisp-lcaf-00

> As there is AFI=3D16387 Type 5, I w=
ould like to suggest an additional Type by=20
which the geographical coordinates wrt longitude and latitude are bijective=
ly=20
mapped to {square degree#,square minute#, second row#, second column#} such=
 that=20
the  meridian (east/west) and equator ( north/south) dominated scheme is=20
transformed into a fast addressable (offsetting) scheme which starts at the=
=20
south pole and which only knows the directions to-east and to north as by t=
he=20
following:=20

Why? Can you give us a specific use-case.

> (1) Unicast:
> Square degree#:
> The globe may be conceived as 180 rings of spherical triangles/rectang=
les,=20
starting at the South pole with a ring of 360 spherical triangles, each of =
which=20
is limited by two longitudes and latitude 89=C2=B0 South from the Equator. =
Towards=20
North there follow 178 rings of 360 spherical rectangles, each of which is=
=20
limited by two consecutive longitudes and latitudes. Finally there is a las=
t=20
ring of 360 spherical triangles around the North pole. =20
> Each spherical triangles/rectangles is assigned a square degree number=
 from 1=20
to 64800, starting at the South Pole with that triangle which is limited by=
 the=20
two longitude degrees 0 and 1 East, the South Pole and latitude 89 South,=
=20
winding from there in eastbound direction, while forming a full circle such=
 that=20
number 360 is assigned to that triangle, which is limited by the two longit=
ude=20
degrees 1 West and 0,while number 361 is assigned to that spherical rectang=
le,=20
which is limited by the longitude degrees 0 and 1 East and the latitudes 89=
=20
South and 88 South. While winding in eastbound direction and while winding=
=20
towards the North Pole, the last number 64800 is assigned to that spherical=
=20
triangle which is limited by the longitudes 1 West and 0, the latitude 89 N=
orth=20
and the North Pole. =20
>=20
> Square minute# derived from given longitude minute x and latitude minu=
te y.
> if  South of the Equator  then minute row# =3D 60 =E2=80=93y else minu=
te row# =3D y+1
> if West of Greenwich then minute column# =3D 60- x else minute column#=
 =3D x+1.
> square minute# =3D (minute row# -1) times 60 + minute column#Square mi=
nute#=20
derived from given longitude minute x and latitude minute y.
>=20
> second row# and second column# derived from given longitude second x a=
nd=20
latitude second y.
> if  South of the Equator  then second row# =3D 60 =E2=80=93y else seco=
nd row# =3D y+1
> if West of Greenwich then second column# =3D 60- x else second column#=
 =3D x+1.
> (no second square# needs to be calculated)
>=20
> The proposed enhancement would enable a next-hop determination by eith=
er one=20
or three table offsets in case of unicast forwarding
>=20
> (2) Multicast
> Multicast-Locator {square degree#;  "multicast address"-number which i=
s unique=20
per indicated square degree}
> Well-known Multicast-Locator {square degree# =3D64801; standardized "M=
ulticast=20
address" number for that well-known service}
> =20
> The Multicast-Locator enables the retrieving of the proper entry from =
a new=20
Multicast-FIB entry (inside a participating node only) which enables multip=
le=20
concurrent next-hops eventually.

But a multicast entry will describe a set of receivers spread across the pl=
anet.=20
So the concept of a multicast group have a physical presents is in conflict=
 to=20
its traditional and fundamental meaning.

> (3) Anycast
> Anycast-Locator {square degree#;  "anycast address"-number which is un=
ique per=20
indicated square degree}
> Well-known Anycast-Locator {square degree# =3D64802; standardized "Any=
cast=20
address" number for that well-known service}
>=20
> The Anycast-Locator enables the retrieving of an entry of a new Anycas=
t-FIB =20
(inside a participating node only) which enables just one next hop.
>=20
> While (2) and (3) specify which one out of multipe Multicast/Anycast-s=
ervices,=20
at a more general place of the LISP header there should be
> some flags which indicate the fundamental forwarding type 0=3Dunicast,=
1=3Dmulticast,=20
2=3D anycast, 3=3D.broadcast, 4=3Dmp2p,.....)

This is going to be a problem as well. An anycast address is multiple unica=
st=20
address residing in physically different places. One would have a semantic =
issue=20
knowing if an address is in multiple physical places (same as the multicast=
=20
point I brought up above) or an address has moved from one physical locatio=
n to=20
another.

Dino

>=20
> H.H.
>     =20
> =20
>=20
> =20
> =20
> _______________________________________________
> lisp mailing list
> lisp@ietf.o=
rg
> https://www.ietf.org/mailman/listinfo/lisp
----------MB_8CF8B1D606BBF95_340_82170_webmail-m021.sysops.aol.com-- From farinacci@gmail.com Wed Nov 7 14:52:43 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BA121F86E4 for ; Wed, 7 Nov 2012 14:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, J_CHICKENPOX_66=0.6, 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 ATwIfiy5D4SE for ; Wed, 7 Nov 2012 14:52:31 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 44D2221F8738 for ; Wed, 7 Nov 2012 14:52:30 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1622969pbb.31 for ; Wed, 07 Nov 2012 14:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nmycohJPBOb8ALYy68D6VmPHXYUouVXNj/FQ5V/20HU=; b=MXZkUDSSCNqNRmwWEXmoqIKCwp9SfpIu6PXx5sa1S/E/fQUzfDN2oNO1Jr+DJSSXHv 4QtOL6T1HuPfs4zRGd94dxUyLzyhrscgR3SgbGlMzsk7IhyS0M/JgdA3nyrGwOWY7dD7 tedUHlU7r43EXSmVQJ7rSfFwqGkbF86vJeoKoadMLcb76Vst1Ys3HWGq+gyvg8MXORUi vntNn/DBerxNTX3XfcU38KJDJofKPtUMgGk1SCOyXqynayKUq/erGBV3ogaW0y16CsCe zk8jVnVseitCMYskFvOB5mzjMj1wdlNcapRc9LOmhxjupVCWFhxvxrkWij/n96lqX0SE SwLw== Received: by 10.66.72.36 with SMTP id a4mr10413630pav.16.1352328749967; Wed, 07 Nov 2012 14:52:29 -0800 (PST) Received: from sjc-vpn5-1097.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id j9sm14950134pav.15.2012.11.07.14.52.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 14:52:29 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <8CF8B1D606BBF95-340-23C7C@webmail-m021.sysops.aol.com> Date: Wed, 7 Nov 2012 14:52:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E5736BD68F770449C74FBAD975F807C94A703AC@NYDC-EXCH01.vinci-consulting-corp.local> <8CF8AFE3BD3029E-340-22317@webmail-m021.sysops.aol.com> <997B2419-BD23-4813-BEA9-277CADF38449@gmail.com> <8CF8B1D606BBF95-340-23C7C@webmail-m021.sysops.aol.com> To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.1499) Cc: lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp-lcaf-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 22:52:43 -0000 > Dino, thank you for your response. >=20 > I haven't followed up LISP for a long time and indeed read = draft-...-lcaf-00 today for the first time. > Hereby I saw that particular address family and as one of several = choices the indication of longitude/latidude degree/minute/second which = was and which still is the basis for what I described by = draft-hummel-tara-00. >=20 > For sure, the geographical coordination information can be 1:1 mapped = from type 5 to my proposed "TARA"-form and vice versus. > The advantage of receiving the unicast-locator in the TARA-form is = that you can use it like an incoming MPLS-label, here to offset either 1 = or 3 tables for retrieving the next hop info. This is much faster than = running 19 binary search cycles applied to a FIB with more than 2^18 = entries and the conversion from type 5 to TARA-type wouldn't have to be = done at each next hop either (and, see above,if one needs the info in = type 5 form that can easily be derived from TARA-form too). >=20 > Multicast, Anycast: > In the past I also believed that there can't be a thing like a = Multicast-Locator. But then I developed a Multicast-model which only = needs finite-state-machines > at the senderTR, at the receiverTRs, and yes at entry-border nodes of = geopatches. Any other participating node does only have a single = multicast-FIB entry wrt to a particular multicast instance. I call that = state-less multicast. Since April 2008, ala draft-ietf-lisp-multicast, there has been a = multicast locator. It turns out to be a delivery group that (S,G) = packets are encapsulated in and delivered by the multicast-capable core. > What is new, i.e. what breaks up with traditional IETF-view: > a) I differentiate between a unicast-FIB, a multicast-FIB, a = anycast-FIB (instead of having a (one) FIB per se) > b) Only the (already) participating nodes (wrt a particular multicast = instance) do have such a multicast-FIB entry which comprises just the = particular multicast-locator, one uplink, and evtl. multiple downlinks = to neighboring nodes - nothing else. In summary they form the delivery = tree which is also used for exchanging messages like QUIT, PRUNE, and = especially for new messages which are needed as to enable that all = participating parties (the sender as well as the receivers) can roam i.e = can be mobile. > =20 > Anycast: So far no one has ever developed an Anycast-model with JOINs = and QUITs analogously to Multicast. This is not how "anycast" has been defined before. So this is a new = capability/use-case and you should probably call it with a different = name. Dino > Don't think that I do not know the traditional understanding of = anycast. And there are certainly services whereby EVERY node should = "participate" in the anycast service without extra-joining, i.e. just by = learning about the potential anycast-destinations. > I think there are enough application of either brand ( I always think = of well-scoped anycast when I have to drive around in Munich looking for = a parking lot:-) >=20 > Heiner >=20 >=20 >=20 >=20 > -----Urspr=FCngliche Mitteilung-----=20 > Von: Dino Farinacci > An: HeinerHummel > Cc: lisp > Verschickt: Mi, 7 Nov 2012 3:06 pm > Betreff: Re: [lisp] draft-ietf-lisp-lcaf-00 >=20 > > As there is AFI=3D16387 Type 5, I would like to suggest an = additional Type by=20 > which the geographical coordinates wrt longitude and latitude are = bijectively=20 > mapped to {square degree#,square minute#, second row#, second column#} = such that=20 > the meridian (east/west) and equator ( north/south) dominated scheme = is=20 > transformed into a fast addressable (offsetting) scheme which starts = at the=20 > south pole and which only knows the directions to-east and to north as = by the=20 > following:=20 >=20 > Why? Can you give us a specific use-case. >=20 > > (1) Unicast: > > Square degree#: > > The globe may be conceived as 180 rings of spherical = triangles/rectangles,=20 > starting at the South pole with a ring of 360 spherical triangles, = each of which=20 > is limited by two longitudes and latitude 89=B0 South from the = Equator. Towards=20 > North there follow 178 rings of 360 spherical rectangles, each of = which is=20 > limited by two consecutive longitudes and latitudes. Finally there is = a last=20 > ring of 360 spherical triangles around the North pole. =20 > > Each spherical triangles/rectangles is assigned a square degree = number from 1=20 > to 64800, starting at the South Pole with that triangle which is = limited by the=20 > two longitude degrees 0 and 1 East, the South Pole and latitude 89 = South,=20 > winding from there in eastbound direction, while forming a full circle = such that=20 > number 360 is assigned to that triangle, which is limited by the two = longitude=20 > degrees 1 West and 0,while number 361 is assigned to that spherical = rectangle,=20 > which is limited by the longitude degrees 0 and 1 East and the = latitudes 89=20 > South and 88 South. While winding in eastbound direction and while = winding=20 > towards the North Pole, the last number 64800 is assigned to that = spherical=20 > triangle which is limited by the longitudes 1 West and 0, the latitude = 89 North=20 > and the North Pole. =20 > >=20 > > Square minute# derived from given longitude minute x and latitude = minute y. > > if South of the Equator then minute row# =3D 60 =96y else minute = row# =3D y+1 > > if West of Greenwich then minute column# =3D 60- x else minute = column# =3D x+1. > > square minute# =3D (minute row# -1) times 60 + minute column#Square = minute#=20 > derived from given longitude minute x and latitude minute y. > >=20 > > second row# and second column# derived from given longitude second x = and=20 > latitude second y. > > if South of the Equator then second row# =3D 60 =96y else second = row# =3D y+1 > > if West of Greenwich then second column# =3D 60- x else second = column# =3D x+1. > > (no second square# needs to be calculated) > >=20 > > The proposed enhancement would enable a next-hop determination by = either one=20 > or three table offsets in case of unicast forwarding > >=20 > > (2) Multicast > > Multicast-Locator {square degree#; "multicast address"-number which = is unique=20 > per indicated square degree} > > Well-known Multicast-Locator {square degree# =3D64801; standardized = "Multicast=20 > address" number for that well-known service} > > =20 > > The Multicast-Locator enables the retrieving of the proper entry = from a new=20 > Multicast-FIB entry (inside a participating node only) which enables = multiple=20 > concurrent next-hops eventually. >=20 > But a multicast entry will describe a set of receivers spread across = the planet.=20 > So the concept of a multicast group have a physical presents is in = conflict to=20 > its traditional and fundamental meaning. >=20 > > (3) Anycast > > Anycast-Locator {square degree#; "anycast address"-number which is = unique per=20 > indicated square degree} > > Well-known Anycast-Locator {square degree# =3D64802; standardized = "Anycast=20 > address" number for that well-known service} > >=20 > > The Anycast-Locator enables the retrieving of an entry of a new = Anycast-FIB =20 > (inside a participating node only) which enables just one next hop. > >=20 > > While (2) and (3) specify which one out of multipe = Multicast/Anycast-services,=20 > at a more general place of the LISP header there should be > > some flags which indicate the fundamental forwarding type = 0=3Dunicast,1=3Dmulticast,=20 > 2=3D anycast, 3=3D.broadcast, 4=3Dmp2p,.....) >=20 > This is going to be a problem as well. An anycast address is multiple = unicast=20 > address residing in physically different places. One would have a = semantic issue=20 > knowing if an address is in multiple physical places (same as the = multicast=20 > point I brought up above) or an address has moved from one physical = location to=20 > another. >=20 > Dino >=20 > >=20 > > H.H. > > =20 > > =20 > >=20 > > =20 > > =20 > > _______________________________________________ > > lisp mailing list > >=20 > lisp@ietf.org >=20 > >=20 > https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 >=20 From heinerhummel@aol.com Thu Nov 8 13:28:45 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCDF21F841B for ; Thu, 8 Nov 2012 13:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 DKmAl8R7hyQk for ; Thu, 8 Nov 2012 13:28:44 -0800 (PST) Received: from imr-da02.mx.aol.com (imr-da02.mx.aol.com [205.188.105.144]) by ietfa.amsl.com (Postfix) with ESMTP id 93A1621F8419 for ; Thu, 8 Nov 2012 13:28:44 -0800 (PST) Received: from mtaomg-ma02.r1000.mx.aol.com (mtaomg-ma02.r1000.mx.aol.com [172.29.41.9]) by imr-da02.mx.aol.com (Outbound Mail Relay) with ESMTP id DD2591C00016C for ; Thu, 8 Nov 2012 16:28:43 -0500 (EST) Received: from core-dqb002c.r1000.mail.aol.com (core-dqb002.r1000.mail.aol.com [172.29.212.197]) by mtaomg-ma02.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id B062CE000094 for ; Thu, 8 Nov 2012 16:28:43 -0500 (EST) To: lisp@ietf.org X-MB-Message-Source: WebUI X-MB-Message-Type: User MIME-Version: 1.0 From: heinerhummel@aol.com Content-Type: multipart/alternative; boundary="--------MB_8CF8C0F29966C6E_B58_9D614_webmail-m131.sysops.aol.com" X-Mailer: Webmail 37130-STANDARD Received: from 178.27.21.1 by webmail-m131.sysops.aol.com (149.174.9.18) with HTTP (WebMailUI); Thu, 08 Nov 2012 16:28:43 -0500 Message-Id: <8CF8C0F298CE712-B58-2AC74@webmail-m131.sysops.aol.com> X-Originating-IP: [178.27.21.1] Date: Thu, 8 Nov 2012 16:28:43 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1352410123; bh=6LinUHYTxSIaAaG1TC+hUlbBQQCp4sXTg3U1w5JmdCA=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=YL9/+Q7hfudJRFESopwszpKAByKbjWOKwtgqQl3EDKsr7xSJ+1WpxKQhEOcQT8OBk yzAfK8OOJun070OoPQMVqDBoi8jDWmRw2B/RXZhR1H+6p6lIrprbhjOhHGij2fSa6I oOsaweSTQBh0lzktvadzS+FcKiMsvQNLsY0Xt9AY= X-AOL-SCOLL-SCORE: 0:2:481412576:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d2909509c240b68db Subject: [lisp] Comments and questions to draft-ietf-lisp-introduction-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:28:45 -0000 This is a multi-part message in MIME format. ----------MB_8CF8C0F29966C6E_B58_9D614_webmail-m131.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" 11.2.1 Why not use DNS: imho DDT has been developed to blow up the LISP work. Right ? The given ex= planations do not convince me. 11.3 Mobile Device Support It doesn't even describe the task to be tackled 11.4 Multicast Support Again, it doesn't even describe the task to be tackled Also: I do not see any note how to cope with the ipv4 address depletion issue and= I also do not see any introduction how LISP sees itself in comparison with ILNP. I recommend to a= dd appropriate sections. Also, because I would be interested in the explanations, can anyone point t= o the right LISP-document where these topics are explained ? Thanks. Heiner ----------MB_8CF8C0F29966C6E_B58_9D614_webmail-m131.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" 11.2.1 Why not use DNS:

imho DDT has been developed  to blow up the LISP work. Right ? Th= e given explanations do not convince me.

11.3 Mobile Device Support
It doesn't even describe the task to be tackled

11.4 Multicast Support
Again, it doesn't even describe = the task to be tackled

Also:
I do not see any note how to cope wit= h the ipv4 address depletion issue and I also do not see any
introduction how LISP sees itself in = comparison with ILNP. I recommend to add appropriate sections.
Also, because I would be interested i= n the explanations, can anyone point to the right LISP-document where these= topics are
explained ? Thanks.

Heiner







 ----------MB_8CF8C0F29966C6E_B58_9D614_webmail-m131.sysops.aol.com-- From jnc@mercury.lcs.mit.edu Mon Nov 12 10:27:05 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1413121F86EC for ; Mon, 12 Nov 2012 10:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.604 X-Spam-Level: X-Spam-Status: No, score=-6.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hvUyNy404H5B for ; Mon, 12 Nov 2012 10:27:04 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5611B21F86E5 for ; Mon, 12 Nov 2012 10:27:04 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 93A7218C088; Mon, 12 Nov 2012 13:27:03 -0500 (EST) To: lisp@ietf.org Message-Id: <20121112182703.93A7218C088@mercury.lcs.mit.edu> Date: Mon, 12 Nov 2012 13:27:03 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments and questions to draft-ietf-lisp-introduction-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:27:05 -0000 > From: heinerhummel@aol.com Hi, thanks for those comments - most of them seem desirable, although I may have some comments later. One thing that caught my eye quickly: > 11.2.1 Why not use DNS: > imho DDT has been developed to blow up the LISP work. Right? This makes no sense, either organizationally, or technically. First, on the non-technical front, the people who proposed DDT are the same people who did LISP origially. Why would they want to blow up their own system? Second, I cannot see how the selection of DDT is a crippling blow, technically. Replacement of the ALT with 'something better' was necessary; the reasons aren't given in detail in the draft (which is intended for a future audience, not today/yesterday, which is why the details were left out). It turned out that what I saw as the worst problem with ALT (traffic hot-spots at the root) turned out to not be a problem yet (although in the long run, it would have been a major problem). Rather, the problem that was starting to appear with the ALT (I gather, from a brief conversation) was simply the configuration management - one had to configure all the tunnels, etc, etc. > The given explanations do not convince me. As to why DDT was preferred to a DNS-based system (the people at Cisco actually prototyped one, to see how it would do, compared to DDT), I can assure you that the reasons given in the document are a reasonable short summary of an extended discussion that went on over a couple of days. Needless to say, everyone who participated in that discussion will have their own views as to the strengths and weaknesses of each, and some people may have a different take on the benefits of DDT (and indeed, there were some people who actually preferred the DNS-based approach), but I tried to summarize the reasoning as best I could in the short amount of space I felt I could devote to the question. (Perhaps a longer, more detailed discussion of why DDT is better than a DNS-based alternative would be in order in the DDT spec, but I don't think it's proper in an introduction to the entire system.) I think in general the overall cost/benefit was felt to favour DDT - the cost being the necessity to write code and specs, and the benefit being that we didn't have to kludge anything, to adopt a system that was designed for a different use; we could do a system that was exactly what was best for LISP. You may disagree with that, and agree with those who preferred the DNS-based system. But that's your judgement - the judgement of me, and a number of others, goes the other way. Noel From damien.saucez@gmail.com Mon Nov 12 11:25:11 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7261E21F852D for ; Mon, 12 Nov 2012 11:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+FnLrtaVSbF for ; Mon, 12 Nov 2012 11:25:10 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0770321F8512 for ; Mon, 12 Nov 2012 11:25:09 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id u46so3277711wey.31 for ; Mon, 12 Nov 2012 11:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=H6dzV2GK8NefAetyGHtQJ6DGAvqod7F7aGm3/AoGnA0=; b=l1fESnvTfdOsQ6AA/UFxxZH5InPKV1N/1x7o0wG8zPYj1iP/PfD5nP+4X/DRexIyEz D0cCAsqDF+NF8QSJ4vFZ5SOZZkALRjw2IKtH4ffiwdPN8xaGqUcOUmZdMFAxnQUrYmDz +oqXeOubiwc6+HjSPs229isSX4C6sXM3Rr0d0Rw0Ob4BN9OO1TkALZeQ8Md+ksPlUJXH 3vigfcBqQDFu9RPrW3yOvM/dAmI5fXR95H96/SmWqVukzEMY86gO1Pq7zY/e9H6DS9Xa B98ikO3bOzhJ3/0z/hhaB9hSv9O/B3J7SEQOP5P43BvmYRC8baafWsCKSQyqGcNLvw/Y cyNA== Received: by 10.216.212.66 with SMTP id x44mr7828811weo.123.1352748308830; Mon, 12 Nov 2012 11:25:08 -0800 (PST) Received: from [172.16.139.253] (7.82.69.86.rev.sfr.net. [86.69.82.7]) by mx.google.com with ESMTPS id dm3sm13045581wib.3.2012.11.12.11.25.06 (version=SSLv3 cipher=OTHER); Mon, 12 Nov 2012 11:25:07 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Damien Saucez In-Reply-To: <20121112182703.93A7218C088@mercury.lcs.mit.edu> Date: Mon, 12 Nov 2012 20:25:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <51867C76-81F5-4EC4-8646-3E64ADA0CA00@gmail.com> References: <20121112182703.93A7218C088@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.1499) Cc: lisp@ietf.org Subject: Re: [lisp] Comments and questions to draft-ietf-lisp-introduction-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:25:11 -0000 Actually, LISP-DDT is the son of LISP-Tree that we=20 proposed in a peer-review journal and that was the result of years of research.=20 When we proposed it, Olivier and I started the discussion around a hierarchical mapping system, we wanted to have something: 1. Scalable=20 2. Fault tolerant and troubleshootable 3. Securable 4. Insensitive to configuration error we saw that a hierarchical system "a-la" DNS was something that was really answering these points. Then, based on the hard evaluation work of our collaborators (Lorand, Florin, and Albert), we have been able to prove how good such a system could be and the gain w.r.t. the other solutions proposed at that time. I have to admit that at that time, I was convinced that using DNS could make it. However, after implementation and experimentations, we have seen that it was not possible to keep DNS as-is and that thus the DNS protocol would have to be extended. As changing DNS is not an easy task, and has using DNS protocol was suboptimal in term of performance (encoding, parsing=85), we finally agreed with the fact that it was better to=20 have a new protocol that mimics DNS without being DNS and having its limitations in our case. The authors of DDT are very aware of all this and=20 DDT is a good tradeoff between our research expectations and their operational needs discovered deploying LISP in lisp4.net. For more details, check Lor=E1nd Jakab, Albert Cabellos-Aparicio, Florin Coras, Damien Saucez, = and Olivier Bonaventure. 2010. LISP-TREE: a DNS hierarchy to support the = lisp mapping system. IEEE J.Sel. A. Commun.28, 8 (October 2010), = 1332-1343. DOI=3D10.1109/JSAC.2010.101011 = http://dx.doi.org/10.1109/JSAC.2010.101011 Damien Saucez On 12 Nov 2012, at 19:27, jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote: >> From: heinerhummel@aol.com >=20 > Hi, thanks for those comments - most of them seem desirable, although = I may > have some comments later. One thing that caught my eye quickly: >=20 >=20 >> 11.2.1 Why not use DNS: >=20 >> imho DDT has been developed to blow up the LISP work. Right? >=20 > This makes no sense, either organizationally, or technically. First, = on the > non-technical front, the people who proposed DDT are the same people = who did > LISP origially. Why would they want to blow up their own system? = Second, I > cannot see how the selection of DDT is a crippling blow, technically. >=20 > Replacement of the ALT with 'something better' was necessary; the = reasons > aren't given in detail in the draft (which is intended for a future = audience, > not today/yesterday, which is why the details were left out). It = turned out > that what I saw as the worst problem with ALT (traffic hot-spots at = the root) > turned out to not be a problem yet (although in the long run, it would = have > been a major problem). Rather, the problem that was starting to appear = with > the ALT (I gather, from a brief conversation) was simply the = configuration > management - one had to configure all the tunnels, etc, etc. >=20 >> The given explanations do not convince me. >=20 > As to why DDT was preferred to a DNS-based system (the people at Cisco > actually prototyped one, to see how it would do, compared to DDT), I = can > assure you that the reasons given in the document are a reasonable = short > summary of an extended discussion that went on over a couple of days. >=20 > Needless to say, everyone who participated in that discussion will = have their > own views as to the strengths and weaknesses of each, and some people = may > have a different take on the benefits of DDT (and indeed, there were = some > people who actually preferred the DNS-based approach), but I tried to > summarize the reasoning as best I could in the short amount of space I = felt I > could devote to the question. >=20 > (Perhaps a longer, more detailed discussion of why DDT is better than = a > DNS-based alternative would be in order in the DDT spec, but I don't = think > it's proper in an introduction to the entire system.) >=20 > I think in general the overall cost/benefit was felt to favour DDT - = the cost > being the necessity to write code and specs, and the benefit being = that we > didn't have to kludge anything, to adopt a system that was designed = for a > different use; we could do a system that was exactly what was best for = LISP. >=20 > You may disagree with that, and agree with those who preferred the = DNS-based > system. But that's your judgement - the judgement of me, and a number = of > others, goes the other way. >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From iesg-secretary@ietf.org Tue Nov 13 06:45:47 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761FE21F86CC; Tue, 13 Nov 2012 06:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 6f4VX7QnyjBo; Tue, 13 Nov 2012 06:45:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0708121F854F; Tue, 13 Nov 2012 06:45:45 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> Date: Tue, 13 Nov 2012 06:45:45 -0800 Cc: lisp@ietf.org Subject: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 14:45:47 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP EID Block' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This is a direction to IANA to allocate a /16 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Tue Nov 13 08:27:12 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C4E21F8703; Tue, 13 Nov 2012 08:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXmv6EomMl3c; Tue, 13 Nov 2012 08:27:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C30B21F841F; Tue, 13 Nov 2012 08:27:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121113162711.25579.52645.idtracker@ietfa.amsl.com> Date: Tue, 13 Nov 2012 08:27:11 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-24.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 16:27:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : Locator/ID Separation Protocol (LISP) Author(s) : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-24.txt Pages : 97 Date : 2012-11-13 Abstract: This draft describes a network layer based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-24 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-24 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rogerj@gmail.com Wed Nov 14 01:42:28 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629FE21F8554; Wed, 14 Nov 2012 01:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 abR7extTdTP9; Wed, 14 Nov 2012 01:42:27 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 11EA621F84FF; Wed, 14 Nov 2012 01:42:26 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id fm10so2616212wgb.1 for ; Wed, 14 Nov 2012 01:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Hjd7fBAD8r0/3Y65Not/tjUjKYawmWTD66GmpS9fAk=; b=EBk4eSG9Qgci4SEtFYFy5x8hBq0FWg7JW1prAUs8LyG+OX6lcZOhKWHdRA25jxySP7 X17/tER4iiXajyqqmTf5T4hEXX/Jczc1ddaSxOFCLpZjP68zN8jbzNNQl6goyRmHR2L1 Xutrz5DIhZcQn6fbWYj5drYrOhiiGadoLeDoPtPg5Z/wp2EruYEN9eRc0CdLxnpHT1vX iOY4DyXtF0xn8PqZ91O306VkMI5N5oOx2QFisUmfXq8VyrdH/i34PS2byVuf8Cl029HH aaZ+dBy0wrn/AslxqkYgbzV10htN+HO9CgffIS7bfxjsjkUt1GJiHhH97m+ccmp458Z+ FP5w== MIME-Version: 1.0 Received: by 10.180.14.73 with SMTP id n9mr24833864wic.15.1352886146158; Wed, 14 Nov 2012 01:42:26 -0800 (PST) Received: by 10.217.83.4 with HTTP; Wed, 14 Nov 2012 01:42:26 -0800 (PST) In-Reply-To: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> Date: Wed, 14 Nov 2012 10:42:26 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: ietf@ietf.org, lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: rogerj@gmail.com Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:42:28 -0000 On Tue, Nov 13, 2012 at 3:45 PM, The IESG wrote: > > The IESG has received a request from the Locator/ID Separation Protocol > WG (lisp) to consider the following document: > - 'LISP EID Block' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This is a direction to IANA to allocate a /16 IPv6 prefix for use > with the Locator/ID Separation Protocol (LISP). The prefix will be > used for local intra-domain routing and global endpoint > identification, by sites deploying LISP as EID (Endpoint IDentifier) > addressing space. I have to ask, who can request an netblock from this address space and from where? I might be blind but I couldn't find it mentioned anywhere. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From luigi.iannone@telecom-paristech.fr Wed Nov 14 02:10:12 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E2821F8499 for ; Wed, 14 Nov 2012 02:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.116 X-Spam-Level: X-Spam-Status: No, score=-0.116 tagged_above=-999 required=5 tests=[AWL=2.133, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 LXtxVeRSJIgd for ; Wed, 14 Nov 2012 02:10:11 -0800 (PST) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.52.33]) by ietfa.amsl.com (Postfix) with ESMTP id F417A21F847B for ; Wed, 14 Nov 2012 02:10:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id 95A5022CFE; Wed, 14 Nov 2012 11:10:07 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGuL5ZWgPpOd; Wed, 14 Nov 2012 11:10:07 +0100 (CET) Received: from dhcp164-04.enst.fr (dhcp164-04.enst.fr [137.194.165.4]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 336FB22CF4; Wed, 14 Nov 2012 11:10:07 +0100 (CET) From: Luigi Iannone Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Nov 2012 11:15:17 +0100 Message-Id: <74F2D872-EE52-4DC1-9027-5C3E7591F998@telecom-paristech.fr> To: "lisp@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: Stefano Secci Subject: [lisp] LISP Control Plane X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 10:10:12 -0000 Hi All, as mentioned during the WG meeting, there is another LISP control-plane = implementation, based on the OpenLISP data-plane. The page of the Stefano Secci's group developing the code is:=20 http://www.lisp.ipv6.lip6.fr/a/Home/Home.html =20 and the code can be downloaded at: https://github.com/lip6-lisp/control-plane Ciao Luigi= From sander@steffann.nl Thu Nov 15 01:43:36 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2549621F8585; Thu, 15 Nov 2012 01:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.126 X-Spam-Level: * X-Spam-Status: No, score=1.126 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 H5e10viNfNFL; Thu, 15 Nov 2012 01:43:35 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 293D921F85C8; Thu, 15 Nov 2012 01:43:34 -0800 (PST) Received: from [172.20.10.3] (unknown [62.140.132.44]) by mail.sintact.nl (Postfix) with ESMTP id CD1722008; Thu, 15 Nov 2012 10:43:30 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: Date: Thu, 15 Nov 2012 10:43:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> To: =?iso-8859-1?Q?Roger_J=F8rgensen?= X-Mailer: Apple Mail (2.1499) Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 09:43:36 -0000 Hi, > I have to ask, who can request an netblock from this address space and > from where? > I might be blind but I couldn't find it mentioned anywhere. Good question. Will there be a central registry, or will parts of the = space be delegated to i.e. LISP based ISPs? - Sander From ggx@gigix.net Thu Nov 15 05:17:41 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A52121F88D6 for ; Thu, 15 Nov 2012 05:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 XZa75PwNz6cX for ; Thu, 15 Nov 2012 05:17:40 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB73921F88D5 for ; Thu, 15 Nov 2012 05:17:39 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id hj6so1067699wib.13 for ; Thu, 15 Nov 2012 05:17:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=U0QL3FjV/3rQ6Mf8arz/s2c4QMfNgPHpeMIaQOHq+Hs=; b=aOjLJGJ6ycniLnzeR1S36L7Hya51gDZNA2inZ0ve9+O8abQfYVSNP7IjmaqKA9d2RR 9OTvOYvqZV1CY7AzfLbH0azRMzCjt3MrsRl33/w9EG2Aa/mpv9+ZHYWgND/H06HCfxBM DXSsMKRSfOZihkDkxParP3euRFbtyoZmPI0KslNjE3RMfgRNPUmYx8RVbfKeLhMK8bzU saJfBOnostQHF1AXftex2IMrFFnU8/7nkEZp6k0XhHPFwLIkUG+zmomP/z/2RSvZrft9 otDsbOVsLHepaDahsRKrN2Ck9hP3NQCcdvLoMouFAhqfX/K9ZIoD/+7Qi2vLKJ0F4di1 5YHA== Received: by 10.180.96.226 with SMTP id dv2mr2240936wib.1.1352985458573; Thu, 15 Nov 2012 05:17:38 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:6c55:486d:3ba1:398a? ([2001:660:330f:a4:6c55:486d:3ba1:398a]) by mx.google.com with ESMTPS id eq2sm7324793wib.1.2012.11.15.05.17.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 05:17:37 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: Date: Thu, 15 Nov 2012 14:22:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8B4C4FF9-0967-42EC-80E6-89EC87D28B04@gigix.net> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> To: =?iso-8859-1?Q?Roger_J=F8rgensen?= X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQm8tyYTxrVRVQQfzSwQyRH4Zy9qXX5Q9e9y0RFEY26ftQGagnjDxtCZfkUJ/pOMrEo9vTPJ Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 13:17:41 -0000 Hi Roger, On 14 Nov. 2012, at 10:42 , Roger J=F8rgensen wrote: > On Tue, Nov 13, 2012 at 3:45 PM, The IESG = wrote: >>=20 >> The IESG has received a request from the Locator/ID Separation = Protocol >> WG (lisp) to consider the following document: >> - 'LISP EID Block' >> as Informational RFC >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments = may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >>=20 >> This is a direction to IANA to allocate a /16 IPv6 prefix for use >> with the Locator/ID Separation Protocol (LISP). The prefix will be >> used for local intra-domain routing and global endpoint >> identification, by sites deploying LISP as EID (Endpoint = IDentifier) >> addressing space. >=20 > I have to ask, who can request an netblock from this address space and > from where? Who: whoever is willing to deploy LISP. Where: your RIR?=20 > I might be blind but I couldn't find it mentioned anywhere. >=20 The purpose of the document is not to create a new way to distribute = prefixes with its own policies, rather to use the existing "process" but = just creating a code point specific for LISP. Luigi >=20 >=20 > --=20 >=20 > Roger Jorgensen | ROJO9-RIPE > rogerj@gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger@jorgensen.no From ggx@gigix.net Thu Nov 15 06:26:56 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528AB21F8847 for ; Thu, 15 Nov 2012 06:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=0.858, 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 ZhBAbJspv0RQ for ; Thu, 15 Nov 2012 06:26:55 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE9821F8809 for ; Thu, 15 Nov 2012 06:26:55 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so633199wgb.13 for ; Thu, 15 Nov 2012 06:26:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=nMR/BP85cTHquyCLHqVKg/OpBqSeZB8fV8TQtqpc770=; b=Ka+t9D2jxd+6j9TSSc9TU8yWceGAW/DNKHIazIIOFJWOyTRd1/SFRcnhiAvCprpww8 4oU08cdkF9cj5BmiDlm6E8wWllYos25UtuuvjW6nv7gt6O+JUJuwtpufnXkSzbcMromR JPPVITLLxKps3kp2BcAwfKM1y9yu9efo6nL+9I5YFIGpxSxvkued67/7AqKYLR3Ps9EC hsZWst/jW8CAuFPm5T0opaxr9h4Ut7yf9/YqodfgYLaJ4b03VDOygLG91Np1OTsNvanZ OmSlxri58ELP535kG3ghCNppvDaAqQdhSRYd4pha5sPSch2CNt4q+4FKoTNcHYVm/ejr mjqg== Received: by 10.181.11.233 with SMTP id el9mr109180wid.3.1352989614495; Thu, 15 Nov 2012 06:26:54 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:6c55:486d:3ba1:398a? ([2001:660:330f:a4:6c55:486d:3ba1:398a]) by mx.google.com with ESMTPS id az2sm27878726wib.7.2012.11.15.06.26.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 06:26:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: <6.2.5.6.2.20121114030352.0da0e888@resistor.net> Date: Thu, 15 Nov 2012 15:32:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <63359CE6-0009-45D1-B2AE-3F2B4384D5D4@gigix.net> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <6.2.5.6.2.20121114030352.0da0e888@resistor.net> To: SM X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkVR9Uo5xw7+MTQMUm1OmMzLLLE2SjyB6bd1Bh6m9bP5Q1jNdJ0r3H4mig5wdo7i8ONyJol Cc: ietf@ietf.org, "lisp@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 14:26:56 -0000 Hi, thanks for the comments. Few answers inline. On 14 Nov. 2012, at 12:19 , SM wrote: > At 06:45 13-11-2012, The IESG wrote: >> The IESG has received a request from the Locator/ID Separation = Protocol >> WG (lisp) to consider the following document: >> - 'LISP EID Block' >> as Informational RFC >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments = may be >=20 > The document does not clearly define how the address space will be = managed. This might end up being problematic in future. >=20 > In Section 4: >=20 > "Too guarantee reachability from the Legacy Internet the prefix could" >=20 > There is a typo for "Too". thanks, will fix. >=20 > In Section 6: >=20 > "It is suggested to IANA to temporarily avoid allocating any > other address block the same /12 prefix the EID /16 prefix > belongs to. This is to accommodate future requests of EID > space without fragmenting the EID addressing space." >=20 > Shouldn't that be under IANA Considerations? Well, if we go along that road we should put the whole document in a = single "IANA Considerations" Section. ;-) Actually the current IANA Considerations section states the same request = but does not specify "/12". You are right that it should be clearly stated, to make the document = coherent. Will fix. thanks >=20 > "If in the future there will be need for a larger EID Block the > address space adjacent the EID Block could be allocate by IANA > according to the current policies." >=20 > Which policies does the above refer to? >=20 It refers to the IANA allocation policies. May be it could be changed in = the following way: If in the future there will be need for a larger EID Block the address space adjacent the EID Block could be allocate by IANA according to its current allocation policies." Would that work? > In Section 10: >=20 > "This document instructs the IANA to assign a /16 IPv6 prefix for use > as the global LISP EID space using a hierarchical allocation as > outlined in [RFC5226]." >=20 > Who will be the delegated managers? I agree that this point has been not discussed thoroughly, the idea is = not to create any new "manager", rather to make ISPs (or whoever = interested in deploying LISP) to request an EID address sub-block as = they do with usual prefixes.=20 >=20 > "Following the policies outlined in [RFC5226], such space > will be assigned only upon IETF Review." >=20 Well, this is standard, to have a reserved space we have to go through = the (now called) "IETF Review", which is what we are doing ;-) ciao Luigi > The previous sentence mentions hierarchical allocation and the above = sentence mentions IETF Review. It is not clear how assignments from = this space will be made. >=20 > Regards, > -sm=20 From ggx@gigix.net Thu Nov 15 06:28:27 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BFB21F888C for ; Thu, 15 Nov 2012 06:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 YuEkLH+qAQZN for ; Thu, 15 Nov 2012 06:28:27 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3243421F8772 for ; Thu, 15 Nov 2012 06:28:27 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hm14so892531wib.13 for ; Thu, 15 Nov 2012 06:28:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=3G3DwCh93Uf/dcC1FZvmYm5osHvS+Lx7kYO/hwp0E1U=; b=U9jtSWlhIv2nsU+/nP0ORMTToX1SWDlpLBSM0SssipyoN/Fkewa6WzkKKqM5bwmNhJ 8zRfWKmmvrA1an8Shdq4MIsPFu9oYdXgRvn/UKZNrfvWq7Mz/qBVv8gPgt9Pk8GPzjxY 8+39YSe0TiZ0Yz+ec6aNlb8hVKggnJTEPjhyV7Rt8YM2VDaLzL7BvGXGQSlMweeedHXH Bur8UjAWnXi5tNv+J5dPBvUkB2ybCQov64NIx+Mr3pZuNrSmtxudEVpeWx/5PUtnFe30 HF6FFdX2AybXeCkSc5t+gQX624gK3itsu/qyEbvnDxNgFYBQ68tRUUy7IvYY2DtSwR6J bLjQ== Received: by 10.180.77.38 with SMTP id p6mr128180wiw.1.1352989705309; Thu, 15 Nov 2012 06:28:25 -0800 (PST) Received: from dhcp164-04.enst.fr (dhcp164-04.enst.fr. [137.194.165.4]) by mx.google.com with ESMTPS id hv4sm27883239wib.0.2012.11.15.06.28.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 06:28:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> Date: Thu, 15 Nov 2012 15:33:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnS3qes65kgTkYpslAoQHGKBxzHvykjFEjrgmnqyg8yHWZY3fIQ3ZXkkFVoG1bxTRTVhPAM Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= , ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 14:28:27 -0000 On 15 Nov. 2012, at 10:43 , Sander Steffann wrote: > Hi, >=20 >> I have to ask, who can request an netblock from this address space = and >> from where? >> I might be blind but I couldn't find it mentioned anywhere. >=20 > Good question. Will there be a central registry, or will parts of the = space be delegated to i.e. LISP based ISPs? >=20 Hi Sander, no central registry has been ever discussed, was more about delegated = the space to LISP ISPs. Luigi > - Sander >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ggx@gigix.net Thu Nov 15 06:33:44 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0442321F8891 for ; Thu, 15 Nov 2012 06:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 bcZwHKhL0uBx for ; Thu, 15 Nov 2012 06:33:43 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 58EF721F88D1 for ; Thu, 15 Nov 2012 06:33:43 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hm14so896915wib.13 for ; Thu, 15 Nov 2012 06:33:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ebMAfPyVqptKTc8EBTiMiK15f4za92RTQLdg4IDPUFY=; b=G6HWwEMjFnxqsBjZtZyuI4IzYt9cHDyNh5HOOmAofG7QELzSi+kTh3GHtSRmzaYldr x4WKvQ3lqxrQYw5VjfF5MK4GkpIFDSpKC96JGlQQLJYQumJMIosG8kuCiBKHjOxUBeMw ZqTgnVboo0Bhf0R43785rwVfe8ybO4kVUfX65XLFKRrR2lRqQM+Tq9/10nei9McQU4Do 3+/vJYYIh5wp8memGd0UAINmco2gn/7hG+PREmpCMSQfqBisiY3dviR8XKhQ+HpW/mBM BwpEEg4XuYAtvt/cdo6VHWnf0DyEfg2Sh9yLwucOmDucxlx/ec4xgQUApVaCEBJQfy6q bpSQ== Received: by 10.180.7.197 with SMTP id l5mr83383wia.13.1352990022350; Thu, 15 Nov 2012 06:33:42 -0800 (PST) Received: from dhcp164-04.enst.fr (dhcp164-04.enst.fr. [137.194.165.4]) by mx.google.com with ESMTPS id fa9sm7625419wib.5.2012.11.15.06.33.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 06:33:41 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: <1C49DB9E-6BD3-4A8A-8B19-2D5A8F4DAC94@apnic.net> Date: Thu, 15 Nov 2012 15:38:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7617A74B-6E11-4C9B-A1B8-73C3E332983C@gigix.net> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <1C49DB9E-6BD3-4A8A-8B19-2D5A8F4DAC94@apnic.net> To: George Michaelson X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmYoDBGwx7ZmlQaUW3KoooDzRmNhZunyZmm5+8kkFeUBUyk3n5eq+IOjfn4qv9rC99TMWnX Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 14:33:44 -0000 Hi George, On 15 Nov. 2012, at 11:50 , George Michaelson = wrote: > I think this document isn't ready for IETF last call. We are open to any suggestion to make the document ready for it. ;-) >=20 > I think the context of an experimental assignment which heads to > distributing IPv6 addresses to end-entities, even if the experiment > is not intended to be globally routable, poses questions about how > the address management function is going to work. Can the working > group be asked to discuss how this is meant to be interpreted in > the light of RFC2050 based processes? It might avoid future pain > if its clear how the IAB and the RIR understand these addresses and > their management. >=20 > The experiment has all the attributes of a general, wide-ranging > address distribution and management activity. I haven't seen any > substantive discussion of this in the WG mailing lists, and I'm > worried this hasn't been documented, or understood. Well, clearly I am missing something. WOuld you mind be a bit more = specific? Are you asking to have rough consensus on specific points? = Which points? thanks Luigi >=20 > cheers >=20 > -George From ggx@gigix.net Thu Nov 15 06:41:46 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDE621F88DE for ; Thu, 15 Nov 2012 06:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.109 X-Spam-Level: X-Spam-Status: No, score=-3.109 tagged_above=-999 required=5 tests=[AWL=0.490, 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 xyyAU+gRv5cU for ; Thu, 15 Nov 2012 06:41:45 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAB521F88FA for ; Thu, 15 Nov 2012 06:41:41 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id fm10so3187691wgb.1 for ; Thu, 15 Nov 2012 06:41:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=VhXy1oSQIKK6CkBWBYF+i1OSWgelFshFVhxWzrjnCyM=; b=I3oiK16MEVy+rxIa3uiu+JDxGJLT77pVdzbJgHVFwKNEqDxPr5ApDQy9q5fdSpyK0J Vjn5GY5QrV1UPZ+R2Cu1SfBuzQr/TfZu1o8r8IdY4ZtK0B5ynLmLrhGLowY8tgSpgLwl tB8nWmNOZ3vmAcT9aFT18NDDJFAkLVixjz6amf6au2Gfr5ayX7hSKEJCtks3bujzQI7G 2ldu62Ggo0vF1K6m0+OtQzMbMno5fRGZkrygRIbi9rySDEGKT2lyjvsczbzWyMCm2ryr 0XuuN0ZCbWD2hOOjzTctbvF1tO4VImNfsGqaeKa68pRaW53KPzuVL1MBxpZt5ien4S5a bLhQ== Received: by 10.180.100.97 with SMTP id ex1mr101310wib.17.1352990501144; Thu, 15 Nov 2012 06:41:41 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:6c55:486d:3ba1:398a? ([2001:660:330f:a4:6c55:486d:3ba1:398a]) by mx.google.com with ESMTPS id q10sm7662739wie.2.2012.11.15.06.41.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 06:41:40 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: <50A4CA14.9010909@bwijnen.net> Date: Thu, 15 Nov 2012 15:46:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <79AB8650-BB45-4F56-B7C2-B1D36DF5ADDD@gigix.net> References: <50A4CA14.9010909@bwijnen.net> To: Bert Wijnen (IETF) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlbvxv+4F96FEOBEm7SaZlwMMLo00aKj5s0rNOApAYtP9ZXEdZYp/pN503YmpgI0t8gkhle Cc: lisp@ietf.org, "ietf@ietf.org" , "iesg@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 14:41:46 -0000 Hi Bert, On 15 Nov. 2012, at 11:55 , Bert Wijnen (IETF) = wrote: [snip] >=20 > So it is not asking just a /16 but also asking for reservation of a = /12. >=20 > Pretty big space. >=20 > And in the list of reasons, I mainly read that it is "sufficiently = large", > but not much about why it needs to be this big. Why would a smaller > allocation not be sufficient? >=20 Well, to keep it short, the WG felt that /16 is the "right size", and = that if the growth of LISP would be so important as to need a bigger = space would be nice to have it contiguous (so implementations can just = change the prefix length).=20 Luigi > Bert From sander@steffann.nl Thu Nov 15 06:45:35 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1012121F8451; Thu, 15 Nov 2012 06:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.189 X-Spam-Level: * X-Spam-Status: No, score=1.189 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 L2THYOFBopQN; Thu, 15 Nov 2012 06:45:34 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 21D2321F846E; Thu, 15 Nov 2012 06:45:34 -0800 (PST) Received: from [10.13.121.140] (unknown [62.140.132.44]) by mail.sintact.nl (Postfix) with ESMTP id 4EC5C200C; Thu, 15 Nov 2012 15:45:33 +0100 (CET) References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> Mime-Version: 1.0 (1.0) In-Reply-To: <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <471ADB67-9BAB-44FC-BA9E-9D75DA011503@steffann.nl> X-Mailer: iPhone Mail (10A523) From: Sander Steffann Date: Thu, 15 Nov 2012 15:45:30 +0100 To: Luigi Iannone Cc: =?utf-8?Q?Roger_J=C3=B8rgensen?= , "ietf@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 14:45:35 -0000 Hi, > no central registry has been ever discussed, was more about delegated the s= pace to LISP ISPs. Glad to hear that! Sander From pvinci@VinciConsulting.com Thu Nov 15 07:10:00 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D9721F893A; Thu, 15 Nov 2012 07:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 OjgDRFxlyIFt; Thu, 15 Nov 2012 07:10:00 -0800 (PST) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id C461821F8932; Thu, 15 Nov 2012 07:09:59 -0800 (PST) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 10:09:58 -0500 From: Paul Vinciguerra To: Luigi Iannone , Sander Steffann Thread-Topic: [lisp] Last Call: (LISP EID Block) to Informational RFC Thread-Index: Ac3DQXxYSz//3jgbSSusYJBGpYtnCg== Date: Thu, 15 Nov 2012 15:09:57 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C94AA2C60@NYDC-EXCH01.vinci-consulting-corp.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.14] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "ietf@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 15:10:00 -0000 > On 15 Nov. 2012, at 10:43 , Sander Steffann wrote: >=20 > > Hi, > > > >> I have to ask, who can request an netblock from this address space > >> and from where? > >> I might be blind but I couldn't find it mentioned anywhere. > > > > Good question. Will there be a central registry, or will parts of the s= pace be > delegated to i.e. LISP based ISPs? > > >=20 > Hi Sander, >=20 > no central registry has been ever discussed, was more about delegated the > space to LISP ISPs. So there will be a pool of addresses that the RIR's can allocate out of for= EIDs? If that's the case, what is the additional value to an ISP who woul= d conceivably have to pay the RIR for another block of V6 addresses specifi= cally for use as EIDs, when most likely they are already paying for a block= that can be used for either purpose?=20 =20 Paul From ggm+ietf@apnic.net Thu Nov 15 02:50:11 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC85621F8577; Thu, 15 Nov 2012 02:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 J2S1K9qEaXEf; Thu, 15 Nov 2012 02:50:11 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 423EA21F8508; Thu, 15 Nov 2012 02:50:10 -0800 (PST) Received: from [IPv6:2001:67c:2e8:13:3966:7593:b81e:73fc] (unknown [IPv6:2001:67c:2e8:13:3966:7593:b81e:73fc]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 9D24EB68D4; Thu, 15 Nov 2012 20:50:07 +1000 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: George Michaelson In-Reply-To: Date: Thu, 15 Nov 2012 11:50:03 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1C49DB9E-6BD3-4A8A-8B19-2D5A8F4DAC94@apnic.net> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Thu, 15 Nov 2012 09:22:17 -0800 Cc: lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 10:50:12 -0000 I think this document isn't ready for IETF last call. I think the context of an experimental assignment which heads to distributing IPv6 addresses to end-entities, even if the experiment is not intended to be globally routable, poses questions about how the address management function is going to work. Can the working group be asked to discuss how this is meant to be interpreted in the light of RFC2050 based processes? It might avoid future pain if its clear how the IAB and the RIR understand these addresses and their management. The experiment has all the attributes of a general, wide-ranging address distribution and management activity. I haven't seen any substantive discussion of this in the WG mailing lists, and I'm worried this hasn't been documented, or understood. cheers -George From bertietf@bwijnen.net Thu Nov 15 02:55:20 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2217C21F84C5; Thu, 15 Nov 2012 02:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 uDZWYWFuRGPf; Thu, 15 Nov 2012 02:55:19 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 10FF921F849A; Thu, 15 Nov 2012 02:55:19 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TYx6L-0008Pm-2S; Thu, 15 Nov 2012 11:55:18 +0100 Received: from cat.ripe.net ([193.0.1.249] helo=guest165.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TYx6K-0004Ed-Um; Thu, 15 Nov 2012 11:55:17 +0100 Message-ID: <50A4CA14.9010909@bwijnen.net> Date: Thu, 15 Nov 2012 11:55:16 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "ietf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121115 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e2ba3b8c90244e04af6f0a2d86ef9a00 X-Mailman-Approved-At: Thu, 15 Nov 2012 09:22:17 -0800 Cc: "iesg@ietf.org" , lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 10:55:20 -0000 On Tue, Nov 13, 2012 at 3:45 PM, The IESG wrote: > > The IESG has received a request from the Locator/ID Separation Protocol > WG (lisp) to consider the following document: > - 'LISP EID Block' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf at ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be > sent to iesg at ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This is a direction to IANA to allocate a /16 IPv6 prefix for use > with the Locator/ID Separation Protocol (LISP). The prefix will be > used for local intra-domain routing and global endpoint > identification, by sites deploying LISP as EID (Endpoint IDentifier) > addressing space. Mmm... In section 5 it states: The working group reached consensus on an initial allocation of a /16 prefix out of a /12 block which is asked to remain reserved for future use as EID space. The reason of such consensus is manifold: So it is not asking just a /16 but also asking for reservation of a /12. Pretty big space. And in the list of reasons, I mainly read that it is "sufficiently large", but not much about why it needs to be this big. Why would a smaller allocation not be sufficient? Bert From bertietf@bwijnen.net Thu Nov 15 06:46:57 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA98321F88B7; Thu, 15 Nov 2012 06:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 q0-FHuNo6W21; Thu, 15 Nov 2012 06:46:57 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 2241B21F8928; Thu, 15 Nov 2012 06:46:57 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TZ0iT-00018J-Op; Thu, 15 Nov 2012 15:46:54 +0100 Received: from cat.ripe.net ([193.0.1.249] helo=guest165.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TZ0iT-0004Ec-EU; Thu, 15 Nov 2012 15:46:53 +0100 Message-ID: <50A5005D.2080704@bwijnen.net> Date: Thu, 15 Nov 2012 15:46:53 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Luigi Iannone References: <50A4CA14.9010909@bwijnen.net> <79AB8650-BB45-4F56-B7C2-B1D36DF5ADDD@gigix.net> In-Reply-To: <79AB8650-BB45-4F56-B7C2-B1D36DF5ADDD@gigix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121115 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd49c4d59811551b7ded1ee84cc640e623a X-Mailman-Approved-At: Thu, 15 Nov 2012 09:22:17 -0800 Cc: lisp@ietf.org, "ietf@ietf.org" , "iesg@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 14:46:58 -0000 Nice to try and keep it short. But I was hoping for some more detail and explanation. I have not followed the discussions (if any) in the WG so I may be missing the reasons why you need this much space. I would hope that the WG (if they have consensus (which may be something different than "the WG felt")) could elaborate or summarize the discussions that lead to the conclusion that this amount of space is needed and makes sense. Pointers to the WG mlist discussions where the pros and cons of various prefixes sizes are discussed or summarize would also be welcome. Bert On 11/15/12 3:46 PM, Luigi Iannone wrote: > Hi Bert, > > On 15 Nov. 2012, at 11:55 , Bert Wijnen (IETF) wrote: > > [snip] >> >> So it is not asking just a /16 but also asking for reservation of a /12. >> >> Pretty big space. >> >> And in the list of reasons, I mainly read that it is "sufficiently large", >> but not much about why it needs to be this big. Why would a smaller >> allocation not be sufficient? >> > > Well, to keep it short, the WG felt that /16 is the "right size", and that if the growth of LISP would be so important as to need a bigger space would be nice to have it contiguous (so implementations can just change the prefix length). > > Luigi > >> Bert > > From gih@apnic.net Thu Nov 15 09:59:04 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFE821F8959; Thu, 15 Nov 2012 09:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 hzV+4wsCHDg0; Thu, 15 Nov 2012 09:59:03 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC2F21F896E; Thu, 15 Nov 2012 09:58:54 -0800 (PST) Received: from [192.168.48.32] (unknown [87.213.29.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 67B2EB68BC; Fri, 16 Nov 2012 03:58:49 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Geoff Huston In-Reply-To: <63359CE6-0009-45D1-B2AE-3F2B4384D5D4@gigix.net> Date: Fri, 16 Nov 2012 04:58:44 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <6.2.5.6.2.20121114030352.0da0e888@resistor.net> <63359CE6-0009-45D1-B2AE-3F2B4384D5D4@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.1499) Cc: "ietf@ietf.org Mailing List" , lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:59:04 -0000 >> In Section 6: >>=20 >> "It is suggested to IANA to temporarily avoid allocating any >> other address block the same /12 prefix the EID /16 prefix >> belongs to. This is to accommodate future requests of EID >> space without fragmenting the EID addressing space." >>=20 >> Shouldn't that be under IANA Considerations? >=20 > Well, if we go along that road we should put the whole document in a = single "IANA Considerations" Section. ;-) >=20 > Actually the current IANA Considerations section states the same = request but does not specify "/12". > You are right that it should be clearly stated, to make the document = coherent. Will fix. thanks >=20 it would be very helpful for the document to clearly show the basis for = the calculation of a /12. Why a /12 and not any other size? What are the = underlying estimates here? Why do they lead to the conclusion of a /12? I am uncomfortable with the rather vague nature of the justification = being shown here, and I don't think that this document as it stands is = ready for publication.=20 Geoff From sander@steffann.nl Thu Nov 15 09:59:57 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D037221F88A9; Thu, 15 Nov 2012 09:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.072 X-Spam-Level: * X-Spam-Status: No, score=1.072 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 nuJjMLj5-Ykx; Thu, 15 Nov 2012 09:59:56 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id B802C21F8991; Thu, 15 Nov 2012 09:59:51 -0800 (PST) Received: from [172.20.10.3] (unknown [62.140.132.44]) by mail.sintact.nl (Postfix) with ESMTP id 1B451200C; Thu, 15 Nov 2012 18:59:45 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <6E5736BD68F770449C74FBAD975F807C94AA2C60@NYDC-EXCH01.vinci-consulting-corp.local> Date: Thu, 15 Nov 2012 18:59:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85D1FE26-4299-454C-AE81-684B08934232@steffann.nl> References: <6E5736BD68F770449C74FBAD975F807C94AA2C60@NYDC-EXCH01.vinci-consulting-corp.local> To: Paul Vinciguerra X-Mailer: Apple Mail (2.1499) Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "ietf@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:59:57 -0000 Hi, > So there will be a pool of addresses that the RIR's can allocate out = of for EIDs? If that's the case, what is the additional value to an ISP = who would conceivably have to pay the RIR for another block of V6 = addresses specifically for use as EIDs, when most likely they are = already paying for a block that can be used for either purpose?=20 Good point. I am currently using my whole /32 allocation from RIPE NCC as EID space. = I run multiple PxTRs in an BGP based anycast setup to route to/from the = non-LISP internet. What would be the use of requesting another prefix? I = would have to put it in the global routing table to route traffic for it = (unless other people start running PITRs for the whole /12, but then we = get the 3rd party relay dependencies we know so well from 6to4...) (PS: my PxTRs do map-requests for anything in ::/0 using DDT, so = everything in DDT is already sent to a locator if possible, and they = forward traffic natively otherwise) Met vriendelijke groet, Sander Steffann From aservin@lacnic.net Thu Nov 15 10:14:07 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C0921F88A9; Thu, 15 Nov 2012 10:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 WY-r4PdfO3ql; Thu, 15 Nov 2012 10:14:06 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 6E63821F888E; Thu, 15 Nov 2012 10:14:06 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:39f7:daf:f8fc:e39d]) by mail.lacnic.net.uy (Postfix) with ESMTP id 26C5530841C; Thu, 15 Nov 2012 16:14:01 -0200 (UYST) Message-ID: <50A530E7.8@lacnic.net> Date: Thu, 15 Nov 2012 16:13:59 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: lisp@ietf.org References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> In-Reply-To: <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: ietf@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:14:07 -0000 Luigi, On 15/11/2012 12:33, Luigi Iannone wrote: > > On 15 Nov. 2012, at 10:43 , Sander Steffann wrote: > >> Hi, >> >>> I have to ask, who can request an netblock from this address space and >>> from where? >>> I might be blind but I couldn't find it mentioned anywhere. >> >> Good question. Will there be a central registry, or will parts of the space be delegated to i.e. LISP based ISPs? >> > > Hi Sander, > > no central registry has been ever discussed, was more about delegated the space to LISP ISPs. How are you going to allocate space to ISPs? Who is going to track the allocations made to ISPs, how are they going to be published, what are the requirements to ask for space, what data needs to be registered, where I can see allocations data? You asked George why the document is not ready to be published. Well, the undocumented rules on how the space is going to be managed is one important reason IMHO. Regards, as > > Luigi > > >> - Sander >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From farinacci@gmail.com Thu Nov 15 10:26:06 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A3421F8467; Thu, 15 Nov 2012 10:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 A01A0wl7kCYF; Thu, 15 Nov 2012 10:26:04 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9A721F8428; Thu, 15 Nov 2012 10:26:04 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1278033pad.31 for ; Thu, 15 Nov 2012 10:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rf0IPjmMHLRM/S6zNnDAfmV7Ac+E30fN0kMcL0M4x5Q=; b=OWnr3Q2V7EdpVXUmtmM/7OmssLBUdqLOFPYpPaLvOzdoJusvN9fB6VJ/9keyjNomCU FNlzbLb4GL02afObRaVnSgooNH/X0z4P6xuTNbU19KyMO+t50wAtd2cyFJXHpA2NzpbD jTTGOrKNFHPIzp6jcHKB6WxaltgwrnkXHsB5mgRZQ1JobI4WoGKDY0pY5ViYa2ursCWI +JMoe+/GduNyGoFaZC8nUMQq1WTHZQN8AoN1A/oeRsGP/j4YNV0uGwaA1Lrh6+bOGCy4 i1gwn+I/yXqPymc21iPvQDzCbBocxC7Z5R9I+DgtXjDyfp9cxvw42Lm/Le+XG7/ji6OO /TQg== Received: by 10.66.73.102 with SMTP id k6mr5610000pav.22.1353003959927; Thu, 15 Nov 2012 10:25:59 -0800 (PST) Received: from sjc-vpn5-1054.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id g10sm10091212pav.9.2012.11.15.10.25.56 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 10:25:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <50A530E7.8@lacnic.net> Date: Thu, 15 Nov 2012 10:25:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1499) Cc: lisp@ietf.org, ietf@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:26:06 -0000 > Luigi, >=20 > On 15/11/2012 12:33, Luigi Iannone wrote: >>=20 >> On 15 Nov. 2012, at 10:43 , Sander Steffann = wrote: >>=20 >>> Hi, >>>=20 >>>> I have to ask, who can request an netblock from this address space = and >>>> from where? >>>> I might be blind but I couldn't find it mentioned anywhere. >>>=20 >>> Good question. Will there be a central registry, or will parts of = the space be delegated to i.e. LISP based ISPs? >>>=20 >>=20 >> Hi Sander, >>=20 >> no central registry has been ever discussed, was more about delegated = the space to LISP ISPs. >=20 >=20 > How are you going to allocate space to ISPs? This is PI space. The registries will take portions of this space to = allocate to end devices. This is endpoint ID space. ISPs will continue = to allocate addresses for LISP RLOCs. And they will have to allocate = orders of magnitude less address space now. > Who is going to track the allocations made to ISPs, how are they = going > to be published, what are the requirements to ask for space, what data > needs to be registered, where I can see allocations data? Registries will track allocations to end sites. > You asked George why the document is not ready to be published. = Well, > the undocumented rules on how the space is going to be managed is one > important reason IMHO. This draft is purely a draft to REQUEST space. There will need to be a = deployment guide on how to allocate EIDs, in general. Dino >=20 > Regards, > as > =09 >=20 >>=20 >> Luigi >>=20 >>=20 >>> - Sander >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From aservin@lacnic.net Thu Nov 15 10:47:23 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7019521F871F; Thu, 15 Nov 2012 10:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 XdVmrGmnGxzI; Thu, 15 Nov 2012 10:47:23 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 76A0F21F869B; Thu, 15 Nov 2012 10:47:22 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:39f7:daf:f8fc:e39d]) by mail.lacnic.net.uy (Postfix) with ESMTP id 50EAB308436; Thu, 15 Nov 2012 16:47:22 -0200 (UYST) Message-ID: <50A538B8.7080709@lacnic.net> Date: Thu, 15 Nov 2012 16:47:20 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dino Farinacci References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: lisp@ietf.org, ietf@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:47:23 -0000 Dino, But who are the registries? The RIRs? Large ISPs? IANA? I think you should specify clearly either: what a registry is or that is not defined yet. Point taken on "This draft is purely a draft to REQUEST space. There will need to be a deployment guide on how to allocate EIDs, in general." But then it should be written somewhere in the document. Although it could be enough only to clearly say that a deployment guide would define allocation guides in the future; for the sake of clarity and usefulness (now, after the space is allocated by IANA it will be there left unused because there is not a clearly indication how is going to be used) I would recommend to discuss how the space is going to be allocated. Regards as On 15/11/2012 16:25, Dino Farinacci wrote: >> Luigi, >> >> On 15/11/2012 12:33, Luigi Iannone wrote: >>> >>> On 15 Nov. 2012, at 10:43 , Sander Steffann wrote: >>> >>>> Hi, >>>> >>>>> I have to ask, who can request an netblock from this address space and >>>>> from where? >>>>> I might be blind but I couldn't find it mentioned anywhere. >>>> >>>> Good question. Will there be a central registry, or will parts of the space be delegated to i.e. LISP based ISPs? >>>> >>> >>> Hi Sander, >>> >>> no central registry has been ever discussed, was more about delegated the space to LISP ISPs. >> >> >> How are you going to allocate space to ISPs? > > This is PI space. The registries will take portions of this space to allocate to end devices. This is endpoint ID space. ISPs will continue to allocate addresses for LISP RLOCs. And they will have to allocate orders of magnitude less address space now. > >> Who is going to track the allocations made to ISPs, how are they going >> to be published, what are the requirements to ask for space, what data >> needs to be registered, where I can see allocations data? > > Registries will track allocations to end sites. > >> You asked George why the document is not ready to be published. Well, >> the undocumented rules on how the space is going to be managed is one >> important reason IMHO. > > This draft is purely a draft to REQUEST space. There will need to be a deployment guide on how to allocate EIDs, in general. > > Dino > >> >> Regards, >> as >> >> >>> >>> Luigi >>> >>> >>>> - Sander >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Thu Nov 15 11:27:24 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B0C21F892B; Thu, 15 Nov 2012 11:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5RmVd2Cn-xh; Thu, 15 Nov 2012 11:27:24 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3A721F8487; Thu, 15 Nov 2012 11:27:24 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1316534pad.31 for ; Thu, 15 Nov 2012 11:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=f7gX3VV3hpum0JQntxgjbd/BUjqCnR1htVY0RGxJxgo=; b=HGzbpjWsIQ+NHgNap/EhH5PpMhokdVs2j5ti9ov6/n+aPFDz4bCMLKiZnXaIpaXr3d 1NB/dsGMtz0rfTwL1GVclMDZA1gqr+l3RuB+5G17co6Hog1Kbk8jzsAqXv0RdRX5KX4b ZYkx4B0hAnL0/0+Dl4eZ4aARNUDNLNN4njteuXxwJf6R3SC5x6Uot3U44GfkoV+rsXpp /rsAhiqTrlKGZLc2CGmY59rKY7MmMQ7yqwCrEQwYC9gNNWh5kbL/xlBp5/5jwYlkrpI8 7kBJFbC7duxIrD5z69dKfwpc+Q2ZKg8v40tBy4xpz398xtT5BNe9qJxTQX2x1YrzVpp6 v4Vw== Received: by 10.66.88.133 with SMTP id bg5mr5830092pab.80.1353007643819; Thu, 15 Nov 2012 11:27:23 -0800 (PST) Received: from [192.168.1.4] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPS id ph7sm9937211pbb.9.2012.11.15.11.27.21 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 11:27:23 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <50A538B8.7080709@lacnic.net> Date: Thu, 15 Nov 2012 11:27:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <50A538B8.7080709@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1499) Cc: lisp@ietf.org, ietf@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:27:24 -0000 > Dino, >=20 > But who are the registries? The RIRs? Large ISPs? IANA? I think = you > should specify clearly either: what a registry is or that is not = defined > yet. Yes, nothing has to change in terms of who and how PI addresses are = allocated. > Point taken on "This draft is purely a draft to REQUEST space. = There > will need to be a deployment guide on how to allocate EIDs, in = general." > But then it should be written somewhere in the document. I agree the wording in the abstract and introduction should be a bit = stronger and/or more direct. > Although it could be enough only to clearly say that a = deployment guide > would define allocation guides in the future; for the sake of clarity > and usefulness (now, after the space is allocated by IANA it will be > there left unused because there is not a clearly indication how is = going > to be used) I would recommend to discuss how the space is going to be > allocated. Sure, good comment. Dino >=20 > Regards > as >=20 > =09 > On 15/11/2012 16:25, Dino Farinacci wrote: >>> Luigi, >>>=20 >>> On 15/11/2012 12:33, Luigi Iannone wrote: >>>>=20 >>>> On 15 Nov. 2012, at 10:43 , Sander Steffann = wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>>> I have to ask, who can request an netblock from this address = space and >>>>>> from where? >>>>>> I might be blind but I couldn't find it mentioned anywhere. >>>>>=20 >>>>> Good question. Will there be a central registry, or will parts of = the space be delegated to i.e. LISP based ISPs? >>>>>=20 >>>>=20 >>>> Hi Sander, >>>>=20 >>>> no central registry has been ever discussed, was more about = delegated the space to LISP ISPs. >>>=20 >>>=20 >>> How are you going to allocate space to ISPs? >>=20 >> This is PI space. The registries will take portions of this space to = allocate to end devices. This is endpoint ID space. ISPs will continue = to allocate addresses for LISP RLOCs. And they will have to allocate = orders of magnitude less address space now. >>=20 >>> Who is going to track the allocations made to ISPs, how are they = going >>> to be published, what are the requirements to ask for space, what = data >>> needs to be registered, where I can see allocations data? >>=20 >> Registries will track allocations to end sites. >>=20 >>> You asked George why the document is not ready to be published. = Well, >>> the undocumented rules on how the space is going to be managed is = one >>> important reason IMHO. >>=20 >> This draft is purely a draft to REQUEST space. There will need to be = a deployment guide on how to allocate EIDs, in general. >>=20 >> Dino >>=20 >>>=20 >>> Regards, >>> as >>> =09 >>>=20 >>>>=20 >>>> Luigi >>>>=20 >>>>=20 >>>>> - Sander >>>>>=20 >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp From sander@steffann.nl Thu Nov 15 11:51:35 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF7C21F846C; Thu, 15 Nov 2012 11:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 glExuFD0TICg; Thu, 15 Nov 2012 11:51:34 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id A81B221F8417; Thu, 15 Nov 2012 11:51:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id B80F02012; Thu, 15 Nov 2012 20:51:31 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7OLOxWt2GNc; Thu, 15 Nov 2012 20:51:31 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 0717D200C; Thu, 15 Nov 2012 20:51:30 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: Date: Thu, 15 Nov 2012 20:51:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:51:35 -0000 Hi, >> How are you going to allocate space to ISPs? >=20 > This is PI space. The registries will take portions of this space to = allocate to end devices. Are you thinking about the existing RIRs here? If so: it might be a good = idea to notify them that this is coming. > This draft is purely a draft to REQUEST space. There will need to be a = deployment guide on how to allocate EIDs, in general. And if the RIR system is used every RIR will develop its own policy for = allocating EIDs independently (hopefully based on the recommendations in = such a deployment guide). It will have to be very clear whose = responsibility it is to allocate from this space, and when assigning = responsibility it might be a good idea to make sure they accept that = responsibility too. Note that I am not opposing the idea. I'm just trying to make sure this = address space doesn't disappear into a black hole because nobody takes = the responsibility to manage it. One thing we have to be very careful with here is that EIDs are not = directly allocated/assigned to end sites from this block. That will = cause everyone to independently find (different) PITRs for their space, = which will make a mess of the global IPv6 routing table... Thanks, Sander From sander@steffann.nl Thu Nov 15 12:04:01 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC3921F842B; Thu, 15 Nov 2012 12:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 2LXJ3PfSGdmd; Thu, 15 Nov 2012 12:04:01 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4B21F841D; Thu, 15 Nov 2012 12:04:01 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 70EA42012; Thu, 15 Nov 2012 21:04:00 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgHVGRECm+CO; Thu, 15 Nov 2012 21:03:59 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id A603B200C; Thu, 15 Nov 2012 21:03:59 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: Date: Thu, 15 Nov 2012 21:03:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <50A538B8.7080709@lacnic.net> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:04:01 -0000 Hi Dino, >> But who are the registries? The RIRs? Large ISPs? IANA? I think = you >> should specify clearly either: what a registry is or that is not = defined >> yet. >=20 > Yes, nothing has to change in terms of who and how PI addresses are = allocated. Sorry, but if the RIRs are going to allocate from this space then that = is not the IETFs decision to make. That responsibility lies with the = policy-making community in the RIR's region. And in the RIPE region = there is ongoing work to write a policy that removes the distinction = between PA and PI for IPv6. So don't make any assumptions here. Also: if they are handed out as PI addresses there is still the question = of who is going to run the PxTRs for that space. No operator will route = the whole /12 or /16 for free. Besides the cost, that would put us back = to the 6to4 mess: being dependent on (possibly unknown) 3rd-party relays = that you have no business relationship with. Assigning the addresses as = PI would mean that every block has to be routed separately, which will = fill up the routing table. PA would make aggregation possible but tie = the end-user to one LISP-ISP, and that ISP might then just use their = existing PA block anyway (without using up an extra BGP routing table = slot). I think it should be clear who is going to manage the address space = before requesting it. Sander From pvinci@VinciConsulting.com Thu Nov 15 12:22:04 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAD321F8604; Thu, 15 Nov 2012 12:22:01 -0800 (PST) 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] 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 tF8zbv894Qz8; Thu, 15 Nov 2012 12:22:00 -0800 (PST) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id AAA8321F85FA; Thu, 15 Nov 2012 12:21:59 -0800 (PST) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 15:21:58 -0500 From: Paul Vinciguerra To: Sander Steffann , Dino Farinacci Thread-Topic: [lisp] Last Call: (LISP EID Block) to Informational RFC Thread-Index: AQHNw16z6nPAFQBGGECg4Vbwr2D40pfrokoA//+tu1A= Date: Thu, 15 Nov 2012 20:21:56 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C94AA4F0C@NYDC-EXCH01.vinci-consulting-corp.local> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> In-Reply-To: <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:22:04 -0000 > One thing we have to be very careful with here is that EIDs are not direc= tly > allocated/assigned to end sites from this block. That will cause everyone= to > independently find (different) PITRs for their space, which will make a m= ess > of the global IPv6 routing table... >=20 > Thanks, > Sander =20 I don't think that (by definition) there is any way to cleanly aggregate PI= space. Legacy advertisements are going to be done by their LISP provider = and will have to match the endpoint's PI allocations. From farinacci@gmail.com Thu Nov 15 13:24:20 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B526121F84C4; Thu, 15 Nov 2012 13:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 vOedzSx6UjkA; Thu, 15 Nov 2012 13:24:20 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF9121F84BA; Thu, 15 Nov 2012 13:24:20 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1381767pad.31 for ; Thu, 15 Nov 2012 13:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kYmcTdpLPsEfAPHYGzr2ANvg1WHU/HT6u+8U4+Pxtzs=; b=uJOqAE475ibKzFyh4LEH+KGy/5ORC7Y+PqythaUmN+ljwjzUhe9NDhsloC/4K7QTlQ uEzGTyZT3NkIpO9j36N/pZTCkPWpN/wwD3IaEGAvp1pv1/0RWVQgmxF9QLEgts3uFaTp mlh5xfQVOdopug3eWRHiO+4qbZsx3VeBn8r2PpfRh1sB6Bn2lmR9XLHm8NyZfSrIZs7/ 1zrRsdoOmD1V3/20x5Iq/sgN2IfWwCXFbRX4kLe2WC0teNMTpb+fqyCrrSwf7Botm8Pn sqbRwzZT+X4NT/FfVgTtSTmkyvLzC3qAGYfnhbHk13oWvc8DTWJKsmkRXc0bht5N3Gxz DyKQ== Received: by 10.68.248.1 with SMTP id yi1mr2869788pbc.93.1353014659904; Thu, 15 Nov 2012 13:24:19 -0800 (PST) Received: from dhcp-10-155-59-220.cisco.com (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPS id is6sm10054834pbc.55.2012.11.15.13.24.18 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 13:24:19 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> Date: Thu, 15 Nov 2012 13:24:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1499) Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:24:20 -0000 > Hi, >=20 >>> How are you going to allocate space to ISPs? >>=20 >> This is PI space. The registries will take portions of this space to = allocate to end devices. >=20 > Are you thinking about the existing RIRs here? If so: it might be a = good idea to notify them that this is coming. Nothing is coming. Nothing really needs to change. But if there is anything written up to define allocation procedures, the = RIRs can review such a document. The main motivation for this prefix is to optimize ITRs so they know = that a destination is in a LISP site. This COULD eliminate a mapping = database lookup for a destination not in this range. Meaning, if a = packet is destined to a non-EID, you may know this by inspecting the = address rather than asking the mapping system. >> This draft is purely a draft to REQUEST space. There will need to be = a deployment guide on how to allocate EIDs, in general. >=20 > And if the RIR system is used every RIR will develop its own policy = for allocating EIDs independently (hopefully based on the = recommendations in such a deployment guide). It will have to be very = clear whose responsibility it is to allocate from this space, and when = assigning responsibility it might be a good idea to make sure they = accept that responsibility too. Right. > Note that I am not opposing the idea. I'm just trying to make sure = this address space doesn't disappear into a black hole because nobody = takes the responsibility to manage it. >=20 > One thing we have to be very careful with here is that EIDs are not = directly allocated/assigned to end sites from this block. That will = cause everyone to independently find (different) PITRs for their space, Why not? > which will make a mess of the global IPv6 routing table... And why do you think you need to assign PITRs per sub-block? Dino >=20 > Thanks, > Sander >=20 From farinacci@gmail.com Thu Nov 15 13:25:40 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F283E21F896C; Thu, 15 Nov 2012 13:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 zLwXTv5ZKvVj; Thu, 15 Nov 2012 13:25:39 -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 812EB21F8947; Thu, 15 Nov 2012 13:25:39 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so849384dan.31 for ; Thu, 15 Nov 2012 13:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=oBFS7tz/G6QqiQoKH7YZ6EBcKZXZlYCChCgmv7AcgCg=; b=vbDKVXSYuku3KOSEyoQU/mkwzSS7IMtFDy8tTjQIfgQb3OnEEHbZNxlGRWUmaYceYI sZrxJW9kBZ1RCHYmHEt5OnyRZV5SF6zPHJhJWprp83EnJYnyR0ie9E4CnMPwYdUgVgoj 1YYAVSmiR/4hNN5Vgb69SJhP9pXD43GfFY9qujwSGUZnxKcn2DS5UtpV1o7fBeRNAo6l XHflhTuIjMVz3Pnc8hj9+3Yy3l3toEZVHAvrfMyYovLYV9vLIwOkE4FQkBu9xnprLXXg JLb1r2Y7rVQ2BU2Kb/+ma+0vxP0NBOEzCTcFU37kW/S2ZJTrxOyQb51H0GiJPTwXXUXS +Dlg== Received: by 10.66.74.40 with SMTP id q8mr6877478pav.29.1353014738896; Thu, 15 Nov 2012 13:25:38 -0800 (PST) Received: from dhcp-10-155-59-220.cisco.com (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPS id pv8sm10062749pbc.26.2012.11.15.13.25.36 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 13:25:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <6E5736BD68F770449C74FBAD975F807C94AA4F0C@NYDC-EXCH01.vinci-consulting-corp.local> Date: Thu, 15 Nov 2012 13:25:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5958FE99-2975-490A-9F51-E56CFD9D384B@gmail.com> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <6E5736BD68F770449C74FBAD975F807C94AA4F0C@NYDC-EXCH01.vinci-consulting-corp.local> To: Paul Vinciguerra X-Mailer: Apple Mail (2.1499) Cc: "ietf@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:25:40 -0000 And you do not want to tie addresses to topological entities. Or you = will lose the mobility capabilities that Locator/ID separation can = bring. Dino On Nov 15, 2012, at 12:21 PM, Paul Vinciguerra = wrote: >> One thing we have to be very careful with here is that EIDs are not = directly >> allocated/assigned to end sites from this block. That will cause = everyone to >> independently find (different) PITRs for their space, which will make = a mess >> of the global IPv6 routing table... >>=20 >> Thanks, >> Sander >=20 > I don't think that (by definition) there is any way to cleanly = aggregate PI space. Legacy advertisements are going to be done by their = LISP provider and will have to match the endpoint's PI allocations. From sander@steffann.nl Thu Nov 15 13:27:01 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4580E21F89AA; Thu, 15 Nov 2012 13:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 Q3V12zv+fFhr; Thu, 15 Nov 2012 13:27:00 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id B6CDA21F871F; Thu, 15 Nov 2012 13:27:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 291202012; Thu, 15 Nov 2012 22:27:00 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INREHQvYeA3s; Thu, 15 Nov 2012 22:26:55 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 5377D200C; Thu, 15 Nov 2012 22:26:52 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <6E5736BD68F770449C74FBAD975F807C94AA4F0C@NYDC-EXCH01.vinci-consulting-corp.local> Date: Thu, 15 Nov 2012 22:26:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <6E5736BD68F770449C74FBAD975F807C94AA4F0C@NYDC-EXCH01.vinci-consulting-corp.local> To: Paul Vinciguerra X-Mailer: Apple Mail (2.1499) Cc: "ietf@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:27:01 -0000 Hi, >> One thing we have to be very careful with here is that EIDs are not = directly >> allocated/assigned to end sites from this block. That will cause = everyone to >> independently find (different) PITRs for their space, which will make = a mess >> of the global IPv6 routing table... >>=20 >> Thanks, >> Sander >=20 > I don't think that (by definition) there is any way to cleanly = aggregate PI space. Legacy advertisements are going to be done by their = LISP provider and will have to match the endpoint's PI allocations. Yeah, so RIR policy-making communities might want to allow for LISP-PA = space for example. I don't think we can make assumptions about that = here. The other side of this is then: why not use 'normal' address = space? If it is going to be announced in the legacy global BGP table = anyway by some LISP provider I can't see why an end-site would choose = for the LISP block instead of the more flexible regular block (which can = then also be used as EID space)... Thanks, Sander From sander@steffann.nl Thu Nov 15 13:32:02 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF90A21F89B0; Thu, 15 Nov 2012 13:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 kg0ATs1jelyB; Thu, 15 Nov 2012 13:32:01 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 361EC21F89AC; Thu, 15 Nov 2012 13:32:01 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 89ECA2012; Thu, 15 Nov 2012 22:32:00 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikWVaMxgEMks; Thu, 15 Nov 2012 22:31:59 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id BE23B200C; Thu, 15 Nov 2012 22:31:59 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: Date: Thu, 15 Nov 2012 22:31:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:32:02 -0000 Hi Dino, > Nothing is coming. Nothing really needs to change. >=20 > But if there is anything written up to define allocation procedures, = the RIRs can review such a document. >=20 > The main motivation for this prefix is to optimize ITRs so they know = that a destination is in a LISP site. This COULD eliminate a mapping = database lookup for a destination not in this range. Meaning, if a = packet is destined to a non-EID, you may know this by inspecting the = address rather than asking the mapping system. I don't agree. For example: I'm using regular space for LISP EIDs now, = so you can't assume that if it's not in this block that it's not in the = mapping system... >>> This draft is purely a draft to REQUEST space. There will need to be = a deployment guide on how to allocate EIDs, in general. >>=20 >> And if the RIR system is used every RIR will develop its own policy = for allocating EIDs independently (hopefully based on the = recommendations in such a deployment guide). It will have to be very = clear whose responsibility it is to allocate from this space, and when = assigning responsibility it might be a good idea to make sure they = accept that responsibility too. >=20 > Right. >=20 >> Note that I am not opposing the idea. I'm just trying to make sure = this address space doesn't disappear into a black hole because nobody = takes the responsibility to manage it. >>=20 >> One thing we have to be very careful with here is that EIDs are not = directly allocated/assigned to end sites from this block. That will = cause everyone to independently find (different) PITRs for their space, >=20 > Why not? Because the RIR communities will probably just refuse to allocate from = this space if it means that all those routes end up in the BGP table... = They are already plenty of people that don't like regular PI policies... >> which will make a mess of the global IPv6 routing table... >=20 > And why do you think you need to assign PITRs per sub-block? I hope that is not necessary, but if addresses are assigned to end-sites = directly in a PI-like way then who is going to provide PITR services for = the users? Someone has to pay the bandwidth cost for operating a PITR... = And the users of that space want reliability, so they are not going to = rely on the goodwill of some unknown 3rd parties. There is too much bad = experience with 2002::/16 for that. If you see another way that I am missing please let me know! I want this = to work, I just don't see how... - Sander From sander@steffann.nl Thu Nov 15 13:34:36 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB8F21F89B0; Thu, 15 Nov 2012 13:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 lG6RX4GLeHsB; Thu, 15 Nov 2012 13:34:36 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1262421F89AA; Thu, 15 Nov 2012 13:34:36 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 6C4B52012; Thu, 15 Nov 2012 22:34:35 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHXh5z9TzBoe; Thu, 15 Nov 2012 22:34:35 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id DCE77200C; Thu, 15 Nov 2012 22:34:34 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <5958FE99-2975-490A-9F51-E56CFD9D384B@gmail.com> Date: Thu, 15 Nov 2012 22:34:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <78C68165-E984-4974-B2D4-12A9A008A25E@steffann.nl> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <6E5736BD68F770449C74FBAD975F807C94AA4F0C@NYDC-EXCH01.vinci-consulting-corp.local> <5958FE99-2975-490A-9F51-E56CFD9D384B@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" , "ietf@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:34:36 -0000 Hi, > And you do not want to tie addresses to topological entities. Or you = will lose the mobility capabilities that Locator/ID separation can = bring. Well, it is a business model. I am providing exactly such a service to a = few test users now. I now hand out EID space from my PA block. If = someone wants to be provider independent I'll route their PI space for = them as well. I'm just hoping that we can avoid any BGP routing table = mess... Sander From farinacci@gmail.com Thu Nov 15 13:36:44 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968D621F89C7; Thu, 15 Nov 2012 13:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 G1QevkXJL9Me; Thu, 15 Nov 2012 13:36:43 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CAA4421F89AC; Thu, 15 Nov 2012 13:36:43 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1461375pbc.31 for ; Thu, 15 Nov 2012 13:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kt8KG1sCA0zCl0XqVj8kuWUC/8V/bxmBKXC4N31GIpM=; b=wSb7FY6WQdOBzx0d40kVDCsHzpD3ebvZMEnb/OydWWgxlKQBX5YocxfBjZ/Tgusqvo KAsIIP4nx8sOl4TEZHUGyBahnKJZhE15/KWKxRKdGDfuLnOU8xXohdlKuF7xUvYq79XP Y3fj811poW3hPSTlde4rOtOdp65VIkuIPVFAFCAduHqEi71uK1nE7gNJtK8uvZDKRUQi KfojqFg/pMMdaJbDjeSMyUOxoQ4DhlSDpYWpQ7ooBNjb/D4XMaK7cEhaz4gKSBUW54UM On2rAS/Dp3MFxFD3f/sdX7zPMhPpCp+M1vqW7tfkqpAdqTLH9WT+Tzu1mE9Wy1VfpooL 08/A== Received: by 10.66.87.34 with SMTP id u2mr6686117paz.82.1353015400161; Thu, 15 Nov 2012 13:36:40 -0800 (PST) Received: from dhcp-10-155-59-220.cisco.com (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPS id m7sm10307372paz.3.2012.11.15.13.36.39 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 13:36:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> Date: Thu, 15 Nov 2012 13:36:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1499) Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:36:44 -0000 > Hi Dino, >=20 >> Nothing is coming. Nothing really needs to change. >>=20 >> But if there is anything written up to define allocation procedures, = the RIRs can review such a document. >>=20 >> The main motivation for this prefix is to optimize ITRs so they know = that a destination is in a LISP site. This COULD eliminate a mapping = database lookup for a destination not in this range. Meaning, if a = packet is destined to a non-EID, you may know this by inspecting the = address rather than asking the mapping system. >=20 > I don't agree. For example: I'm using regular space for LISP EIDs now, = so you can't assume that if it's not in this block that it's not in the = mapping system... That is why I capitalized "COULD". >>>> This draft is purely a draft to REQUEST space. There will need to = be a deployment guide on how to allocate EIDs, in general. >>>=20 >>> And if the RIR system is used every RIR will develop its own policy = for allocating EIDs independently (hopefully based on the = recommendations in such a deployment guide). It will have to be very = clear whose responsibility it is to allocate from this space, and when = assigning responsibility it might be a good idea to make sure they = accept that responsibility too. >>=20 >> Right. >>=20 >>> Note that I am not opposing the idea. I'm just trying to make sure = this address space doesn't disappear into a black hole because nobody = takes the responsibility to manage it. >>>=20 >>> One thing we have to be very careful with here is that EIDs are not = directly allocated/assigned to end sites from this block. That will = cause everyone to independently find (different) PITRs for their space, >>=20 >> Why not? >=20 > Because the RIR communities will probably just refuse to allocate from = this space if it means that all those routes end up in the BGP table... = They are already plenty of people that don't like regular PI policies... You have all the PITRs in the world advertise only the one /12 into = underlying routing. >>> which will make a mess of the global IPv6 routing table... >>=20 >> And why do you think you need to assign PITRs per sub-block? >=20 > I hope that is not necessary, but if addresses are assigned to = end-sites directly in a PI-like way then who is going to provide PITR = services for the users? Someone has to pay the bandwidth cost for = operating=20 PITR services are provide for non-LISP sources to send to these sites. = If you have a well-known defined /12 that all PITRs advertise, then when = you allocate sub-blocks, you don't have to change, reconfigure, or touch = the 1000s of PITRs deployed. > a PITR... And the users of that space want reliability, so they are = not going to rely on the goodwill of some unknown 3rd parties. There is = too much bad experience with 2002::/16 for that. We do that all the time on the Internet unless you sent this email on a = source-route to me. ;-) > If you see another way that I am missing please let me know! I want = this to work, I just don't see how... > - Sander Dino From sander@steffann.nl Thu Nov 15 13:48:51 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C4A21F8A40; Thu, 15 Nov 2012 13:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 oRNAywDRicEE; Thu, 15 Nov 2012 13:48:51 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id E620321F8A3E; Thu, 15 Nov 2012 13:48:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 479FB2012; Thu, 15 Nov 2012 22:48:50 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Vuyvuo7-wcr; Thu, 15 Nov 2012 22:48:45 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 53248200C; Thu, 15 Nov 2012 22:48:43 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> Date: Thu, 15 Nov 2012 22:48:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:48:51 -0000 Hi, >>> The main motivation for this prefix is to optimize ITRs so they know = that a destination is in a LISP site. This COULD eliminate a mapping = database lookup for a destination not in this range. Meaning, if a = packet is destined to a non-EID, you may know this by inspecting the = address rather than asking the mapping system. >>=20 >> I don't agree. For example: I'm using regular space for LISP EIDs = now, so you can't assume that if it's not in this block that it's not in = the mapping system... >=20 > That is why I capitalized "COULD". Ok :-) But I think it comes down to COULD ignore that certain EIDs are in the mapping system and always = route them legacy-style I wouldn't agree with COULD know if certain addresses are EIDs or not by looking at the = prefix because any address space can be used as EIDs now. Or are you proposing = to deprecate the use of all other address space as EIDs? >> Because the RIR communities will probably just refuse to allocate = from this space if it means that all those routes end up in the BGP = table... They are already plenty of people that don't like regular PI = policies... >=20 > You have all the PITRs in the world advertise only the one /12 into = underlying routing. ROFL. No sorry, that's not going to work a) they would have to pay all the bandwidth cost for users of that EID = space that they have no business relation with b) as a user of that EID space I would be at the mercy of PITR operators = that I don't even know c) See all the arguments about why 6to4 is unreliable. They'll apply = here too >>>> which will make a mess of the global IPv6 routing table... >>>=20 >>> And why do you think you need to assign PITRs per sub-block? >>=20 >> I hope that is not necessary, but if addresses are assigned to = end-sites directly in a PI-like way then who is going to provide PITR = services for the users? Someone has to pay the bandwidth cost for = operating=20 >=20 > PITR services are provide for non-LISP sources to send to these sites. = If you have a well-known defined /12 that all PITRs advertise, then when = you allocate sub-blocks, you don't have to change, reconfigure, or touch = the 1000s of PITRs deployed. What makes you think that all those PITRs will pay the cost for routing = all that traffic? >> a PITR... And the users of that space want reliability, so they are = not going to rely on the goodwill of some unknown 3rd parties. There is = too much bad experience with 2002::/16 for that. >=20 > We do that all the time on the Internet unless you sent this email on = a source-route to me. ;-) No, sorry. I now pay my ISP to make sure my connectivity works. In your = example I'm going to rely on some unknown PETR for outbound traffic and = on whatever PITR is closest to the other side for my inbound traffic. I = might be able to control the PETR, but not the PITR because that depends = on the routing from the other side. We have been here before with = 2002::/16. Don't repeat that huge mistake! - Sander From farinacci@gmail.com Thu Nov 15 14:04:26 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2AF21F8A01; Thu, 15 Nov 2012 14:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 CnrDYFXGqkxz; Thu, 15 Nov 2012 14:04:25 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B97521F8A00; Thu, 15 Nov 2012 14:04:24 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1403017pad.31 for ; Thu, 15 Nov 2012 14:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=g7EI6xNgiJc2oLUr3sPpaj4LLvny9ThftO7XV0utpcY=; b=KjwpzrOIWBs4wy1Ag+l+o1IEqzZNc91e6NaLS/62FjP+QWHW9858nF6VewUBlLXoOj iiZpHUGnrgd4noj3bRFmMUKZ7BNlw5XeYsxMzOtq8cTyyz31OvT1x4tec9QDhI56u1Ux JCZIKwqQXd5znv4AJV8Fo/i5ROMPuE1Fme9xt8ZFU+bU6MLYe5vR92ck4I8mYUSwW6II ckVNsWgBm3pGlN3r1GONSM/e+F5ass0rsF2sUb6ke7ZqiVmj3U5ZzerrR04L0UR1UBue XCEzlJWJcL1UcCt+8SNKOTzaDlGmFZ3xJecUxRcCL9PArsuahQzDexkMNDcNtguufTTg +kaA== Received: by 10.68.200.10 with SMTP id jo10mr9005881pbc.45.1353017064305; Thu, 15 Nov 2012 14:04:24 -0800 (PST) Received: from dhcp-10-155-59-220.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id b6sm10325433pav.33.2012.11.15.14.04.22 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 14:04:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: Date: Thu, 15 Nov 2012 14:04:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> To: Sander Steffann X-Mailer: Apple Mail (2.1499) Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:04:26 -0000 > Hi, >=20 >>>> The main motivation for this prefix is to optimize ITRs so they = know that a destination is in a LISP site. This COULD eliminate a = mapping database lookup for a destination not in this range. Meaning, if = a packet is destined to a non-EID, you may know this by inspecting the = address rather than asking the mapping system. >>>=20 >>> I don't agree. For example: I'm using regular space for LISP EIDs = now, so you can't assume that if it's not in this block that it's not in = the mapping system... >>=20 >> That is why I capitalized "COULD". >=20 > Ok :-) >=20 > But I think it comes down to > COULD ignore that certain EIDs are in the mapping system and always = route them legacy-style No, I don't think so. You just avoided doing LISP to the destination = site that wants multi-homing. > I wouldn't agree with > COULD know if certain addresses are EIDs or not by looking at the = prefix > because any address space can be used as EIDs now. Or are you = proposing to deprecate the use of all other address space as EIDs? You can configure a device to be more restrictive. And this would be the = case in the non-capital I internet. >>> Because the RIR communities will probably just refuse to allocate = from this space if it means that all those routes end up in the BGP = table... They are already plenty of people that don't like regular PI = policies... >>=20 >> You have all the PITRs in the world advertise only the one /12 into = underlying routing. >=20 > ROFL. No sorry, that's not going to work I'm sorry, it can work and people will WANT to do this. Infrastructure = providers do want to attract traffic. > a) they would have to pay all the bandwidth cost for users of that EID = space that they have no business relation with If you have enough PITRs spread around the Internet, it works no = differently than a set of boxes at a public inter-connect that = advertises the same prefix (to say google). > b) as a user of that EID space I would be at the mercy of PITR = operators that I don't even know You are at the mercy of a lot of infrastructure components today. This = is no different. You are at the mercy of your DNS server, are you not? = It is the same thing. So let's not make things more complicated. > c) See all the arguments about why 6to4 is unreliable. They'll apply = here too Then you deploy an ITR at your site. You will want to for other reasons, = so you kill the problem you think you have. >>>>> which will make a mess of the global IPv6 routing table... >>>>=20 >>>> And why do you think you need to assign PITRs per sub-block? >>>=20 >>> I hope that is not necessary, but if addresses are assigned to = end-sites directly in a PI-like way then who is going to provide PITR = services for the users? Someone has to pay the bandwidth cost for = operating=20 >>=20 >> PITR services are provide for non-LISP sources to send to these = sites. If you have a well-known defined /12 that all PITRs advertise, = then when you allocate sub-blocks, you don't have to change, = reconfigure, or touch the 1000s of PITRs deployed. >=20 > What makes you think that all those PITRs will pay the cost for = routing all that traffic? Pay the cost? The cost is the bandwidth that is already provision to = come into those boxes. And infrastructure providers do want to attract = traffic. >>> a PITR... And the users of that space want reliability, so they are = not going to rely on the goodwill of some unknown 3rd parties. There is = too much bad experience with 2002::/16 for that. >>=20 >> We do that all the time on the Internet unless you sent this email on = a source-route to me. ;-) >=20 > No, sorry. I now pay my ISP to make sure my connectivity works. In = your example I'm going to rely on some unknown PETR for outbound traffic = and on whatever PITR is closest to the other side for my inbound Don't change the context of this discussion. We are talking PITRs. PETRs = are something completely different. > traffic. I might be able to control the PETR, but not the PITR because = that depends on the routing from the other side. We have been here = before with 2002::/16. Don't repeat that huge mistake! >=20 > - Sander This is now off topic. The draft has nothing to do with PITR deployment. Dino From ggm+ietf@apnic.net Thu Nov 15 14:25:04 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47FB21F8A3A; Thu, 15 Nov 2012 14:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 cP8B5a3K1KCx; Thu, 15 Nov 2012 14:25:04 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 3132D21F8A38; Thu, 15 Nov 2012 14:25:04 -0800 (PST) Received: from [192.168.55.108] (unknown [87.213.29.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id DC87BB684D; Fri, 16 Nov 2012 08:25:01 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: George Michaelson In-Reply-To: <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> Date: Thu, 15 Nov 2012 23:24:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <551B2C05-2E30-4B6F-8D35-8CA0482A8D82@apnic.net> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) Cc: "ietf@ietf.org list" , lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:25:04 -0000 Dino, to come back on topic. I understand the drafts purpose is to = request a block of IPv6 address be delegated for this specific purpose, = from IANA. The request is to the IAB. So, its a request for = architectural aspects of addressing, facing an experiment. a /12 is a very large amount of space. This demands rigour in the = process to apply, even a reservation requires a sense of why, and = justification. "we think its about right" isn't appropriate and the = document needs more work to specify why a 16, and why a /12, and what = the implications are of eg a smaller allocation under a /16 reservation, = or some other size (a /32 even, for which there are both precedents, in = experimental allocations, and an existing process inside the RIR address = management framework). Secondly, you appear to assume these allocations to EID can simply use = current RIR practices. The problem is that you need to understand what = needs-based and justification means in process terms: Hostmasters in the = RIR system try very hard not to be placed in a position of making = arbitrary subjective decisions: they have processes which are designed = to ask for objective justifications to specify why an allocation should = take place, and at what scale. Those objective criteria face addresses = as addresses. not EID. For an example: IPv6 address allocation process currently is implemented = using sparse allocation (binary chop with some modifications) in the = APNIC region. This maximises space around allocations to equalise the = distribution of free blocks such that the commons, the unallocated = space, remains as usefully large as possible and when the next binary = stride is entered, there is some understanding its going to be applied = in common to all occupants of that region of space (in terms of the size = of hole around them, which is not a reservation per se, but provides for = risk-management of future growth to the largest extent). We're really quite proud of sparse: its extended the life of the /12 we = occupy quite markedly. What impact will EID have on this? Is sparse an = appropriate allocation engine to use for EID? What if eg you have = expectations of almost-geographic aspects of address management in EID. = Doesn't that require documentation as a process? And, you may be = specifying a cost on the RIR system, to engineer support for the new = allocation logic. If it doesn't logically fit in sparse allocation, we = need to know. And we need to know why. EID are not going to be used like 'normal' addresses. So, the normal = justifications don't look entirely appropriate to me from 10,000ft. The = document needs to say "maybe we need to understand the allocation = processes that the RIR should objectively apply" or maybe you need to = step outside of draft space and engage inside the RIR policy process and = seek a global policy which can document the process. To ask for an IANA allocation without having undertaken this process = looks wrong to me. So, I stand by my concern the document isn't ready = for IETF last call: it hasn't addressed substantive issues around the = process and expectations of address/registry function, to manage the = /16, and it hasn't documented the basis of asking for a /16 in the first = place, or a /12 reservation. cheers -George= From jmh@joelhalpern.com Thu Nov 15 14:39:51 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1664721F89F6; Thu, 15 Nov 2012 14:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50uYF8zC9quK; Thu, 15 Nov 2012 14:39:50 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2487C21F896C; Thu, 15 Nov 2012 14:39:45 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 0706D5593C0; Thu, 15 Nov 2012 14:39:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 43BFD1BDB2E6; Thu, 15 Nov 2012 14:39:42 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-174.clppva.btas.verizon.net [71.161.50.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 527D71BDAD44; Thu, 15 Nov 2012 14:39:39 -0800 (PST) Message-ID: <50A56F23.7020903@joelhalpern.com> Date: Thu, 15 Nov 2012 17:39:31 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: George Michaelson References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> <551B2C05-2E30-4B6F-8D35-8CA0482A8D82@apnic.net> In-Reply-To: <551B2C05-2E30-4B6F-8D35-8CA0482A8D82@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ietf@ietf.org list" , lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:39:51 -0000 Whatever else is going on, LISP EIDs do not have geographic significance. They do not have IP Routing topological significance. The are not aggregateable. They are intended to beused by a site as a single prefix. Hence, the desired behavior (within the /16) is exactly the same as that needed to respond to a PI request. Yours, Joel On 11/15/2012 5:24 PM, George Michaelson wrote: > > Dino, to come back on topic. I understand the drafts purpose is to request a block of IPv6 address be delegated for this specific purpose, from IANA. The request is to the IAB. So, its a request for architectural aspects of addressing, facing an experiment. > > a /12 is a very large amount of space. This demands rigour in the process to apply, even a reservation requires a sense of why, and justification. "we think its about right" isn't appropriate and the document needs more work to specify why a 16, and why a /12, and what the implications are of eg a smaller allocation under a /16 reservation, or some other size (a /32 even, for which there are both precedents, in experimental allocations, and an existing process inside the RIR address management framework). > > Secondly, you appear to assume these allocations to EID can simply use current RIR practices. The problem is that you need to understand what needs-based and justification means in process terms: Hostmasters in the RIR system try very hard not to be placed in a position of making arbitrary subjective decisions: they have processes which are designed to ask for objective justifications to specify why an allocation should take place, and at what scale. Those objective criteria face addresses as addresses. not EID. > > For an example: IPv6 address allocation process currently is implemented using sparse allocation (binary chop with some modifications) in the APNIC region. This maximises space around allocations to equalise the distribution of free blocks such that the commons, the unallocated space, remains as usefully large as possible and when the next binary stride is entered, there is some understanding its going to be applied in common to all occupants of that region of space (in terms of the size of hole around them, which is not a reservation per se, but provides for risk-management of future growth to the largest extent). > > We're really quite proud of sparse: its extended the life of the /12 we occupy quite markedly. What impact will EID have on this? Is sparse an appropriate allocation engine to use for EID? What if eg you have expectations of almost-geographic aspects of address management in EID. Doesn't that require documentation as a process? And, you may be specifying a cost on the RIR system, to engineer support for the new allocation logic. If it doesn't logically fit in sparse allocation, we need to know. And we need to know why. > > EID are not going to be used like 'normal' addresses. So, the normal justifications don't look entirely appropriate to me from 10,000ft. The document needs to say "maybe we need to understand the allocation processes that the RIR should objectively apply" or maybe you need to step outside of draft space and engage inside the RIR policy process and seek a global policy which can document the process. > > To ask for an IANA allocation without having undertaken this process looks wrong to me. So, I stand by my concern the document isn't ready for IETF last call: it hasn't addressed substantive issues around the process and expectations of address/registry function, to manage the /16, and it hasn't documented the basis of asking for a /16 in the first place, or a /12 reservation. > > cheers > > -George > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From sander@steffann.nl Thu Nov 15 14:41:50 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5578321F8A72; Thu, 15 Nov 2012 14:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 MZSe2S4K8fjK; Thu, 15 Nov 2012 14:41:49 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 556CA21F852D; Thu, 15 Nov 2012 14:41:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 089302012; Thu, 15 Nov 2012 23:41:48 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftoPN+nb53pn; Thu, 15 Nov 2012 23:41:45 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 7DEC7200C; Thu, 15 Nov 2012 23:41:45 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> Date: Thu, 15 Nov 2012 23:41:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <22AD9545-DDC9-4FE9-A984-1D0E3987D02D@steffann.nl> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:41:50 -0000 Hi, >> But I think it comes down to >> COULD ignore that certain EIDs are in the mapping system and always = route them legacy-style >=20 > No, I don't think so. You just avoided doing LISP to the destination = site that wants multi-homing. That's what I said (or at least meant :) ) >> I wouldn't agree with >> COULD know if certain addresses are EIDs or not by looking at the = prefix >> because any address space can be used as EIDs now. Or are you = proposing to deprecate the use of all other address space as EIDs? >=20 > You can configure a device to be more restrictive. And this would be = the case in the non-capital I internet. Ok >>>> Because the RIR communities will probably just refuse to allocate = from this space if it means that all those routes end up in the BGP = table... They are already plenty of people that don't like regular PI = policies... >>>=20 >>> You have all the PITRs in the world advertise only the one /12 into = underlying routing. >>=20 >> ROFL. No sorry, that's not going to work >=20 > I'm sorry, it can work and people will WANT to do this. Infrastructure = providers do want to attract traffic. >=20 >> a) they would have to pay all the bandwidth cost for users of that = EID space that they have no business relation with >=20 > If you have enough PITRs spread around the Internet, it works no = differently than a set of boxes at a public inter-connect that = advertises the same prefix (to say google). Yes, but there is a big financial incentive for Google to maintain that. >> b) as a user of that EID space I would be at the mercy of PITR = operators that I don't even know >=20 > You are at the mercy of a lot of infrastructure components today. This = is no different. Yes it is. *please*please*please* study what happened to 6to4 and the = 2002::/16 prefix before continuing this discussion. > You are at the mercy of your DNS server, are you not? It is the same = thing. So let's not make things more complicated. >=20 >> c) See all the arguments about why 6to4 is unreliable. They'll apply = here too >=20 > Then you deploy an ITR at your site. You will want to for other = reasons, so you kill the problem you think you have. >=20 >>>>>> which will make a mess of the global IPv6 routing table... >>>>>=20 >>>>> And why do you think you need to assign PITRs per sub-block? >>>>=20 >>>> I hope that is not necessary, but if addresses are assigned to = end-sites directly in a PI-like way then who is going to provide PITR = services for the users? Someone has to pay the bandwidth cost for = operating=20 >>>=20 >>> PITR services are provide for non-LISP sources to send to these = sites. If you have a well-known defined /12 that all PITRs advertise, = then when you allocate sub-blocks, you don't have to change, = reconfigure, or touch the 1000s of PITRs deployed. >>=20 >> What makes you think that all those PITRs will pay the cost for = routing all that traffic? >=20 > Pay the cost? The cost is the bandwidth that is already provision to = come into those boxes. And infrastructure providers do want to attract = traffic. That assumes that *everybody* runs such a PITR... Otherwise the company = running the PITR will attract traffic from other's and pay for the = bandwidth. >>>> a PITR... And the users of that space want reliability, so they are = not going to rely on the goodwill of some unknown 3rd parties. There is = too much bad experience with 2002::/16 for that. >>>=20 >>> We do that all the time on the Internet unless you sent this email = on a source-route to me. ;-) >>=20 >> No, sorry. I now pay my ISP to make sure my connectivity works. In = your example I'm going to rely on some unknown PETR for outbound traffic = and on whatever PITR is closest to the other side for my inbound >=20 > Don't change the context of this discussion. We are talking PITRs. = PETRs are something completely different. Yes, and I explicitly mention below that you *can* control those. >> traffic. I might be able to control the PETR, but not the PITR = because that depends on the routing from the other side. We have been = here before with 2002::/16. Don't repeat that huge mistake! >>=20 >> - Sander >=20 > This is now off topic. The draft has nothing to do with PITR = deployment. *you* are the one suggesting that PITRs will be deployed that handle the = /12 or /16 that is being proposed in this draft. Getting this EID = address accessible from non-LISP sites needs PITRs, so it is very much = on topic. Please read up on the mess that RFC 3056 caused. There is a good reason = that RFC 6724 depreferenced 2002::/16. It explicitly says (although it = contains an error, it says 2002::/32 when 2002::/16 is meant): = "Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4 = connectivity is less reliable today (and is expected to be phased out = over time, rather than becoming more reliable)." The EID prefix has the = same problems as the 6to4 prefix. Before requesting address space for EIDs I think we need to know how = it's going to be distributed (RIRs, separate registry (actually doesn't = have to be a bad idea!)) and how it's going to be routed (like PI space = is today with every end-site a separate entry in the global BGP table, = like, PA space where a LISP-ISP provides aggregation, like 6to4 is with = the whole prefix anycast by open relays, ...) Please understand that I am u huge fan of LISP (my home network and lab = networks are all using LISP). I am just not very sure if we really need = this EID prefix. I am afraid it will do a lot of harm if defined, = distributed and routed badly. - Sander From aservin@lacnic.net Thu Nov 15 14:49:15 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4EC21F8AA4; Thu, 15 Nov 2012 14:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 ers2UDZi0LZX; Thu, 15 Nov 2012 14:49:14 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 07C1B21F8A92; Thu, 15 Nov 2012 14:49:04 -0800 (PST) Received: from [IPv6:2800:af:ba30:fa64:4d61:e232:817c:d402] (unknown [IPv6:2800:af:ba30:fa64:4d61:e232:817c:d402]) by mail.lacnic.net.uy (Postfix) with ESMTP id 2715A308454; Thu, 15 Nov 2012 20:48:54 -0200 (UYST) Message-ID: <50A57153.70000@lacnic.net> Date: Thu, 15 Nov 2012 20:48:51 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Joel M. Halpern" References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> <551B2C05-2E30-4B6F-8D35-8CA0482A8D82@apnic.net> <50A56F23.7020903@joelhalpern.com> In-Reply-To: <50A56F23.7020903@joelhalpern.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: George Michaelson , "ietf@ietf.org list" , lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:49:16 -0000 Joel, I think that George raised a very valid concern and he explained very well the RIR machinery to perform address allocation. Saying that "it is just PI" simple does not help. As an example of our concerns (or at least mine), the policy to allocate PI in lacnic is: " 4.5.4.1. Direct assignment of portable IPv6 addresses to End Sites having portable IPv4 addresses previously assigned by LACNIC LACNIC will assign portable IPv6 address blocks directly to end sites if they hold portable IPv4 addresses previously assigned by LACNIC. In case of announcing the assignment on the Internet inter-domain routing system, the receiving organization shall announce the block maintaining de-aggregation to a minimum in accordance with the announcing organization's needs. Assignments will be made in blocks smaller than or equal to a /32 but always greater than or equal to a /48. Where possible, subsequent allocations will be made from an adjacent address block, but only if duly documented and justified. 4.5.4.2. Direct assignment of portable IPv6 addresses to End sites not having portable IPv4 addresses previously assigned by LACNIC LACNIC will assign portable IPv6 address blocks directly to end sites that satisfy the following requirements: Not be an LIR or ISP. In case of announcing the assignment on the Internet inter-domain routing system, the receiving organization shall announce the block maintaining de-aggregation to a minimum in accordance with the announcing organization's needs. Provide detailed information showing how the requested block will be used within the following three, six and twelve months. Submit addressing plans for at least a year, and host numbers on each subnet. Submit a detailed description of the network topology. Prepare a detailed description of the network routing plans, including the routing protocols to be used as well as any existing limitations. Assignments will be made in blocks smaller than or equal to a /32 but always greater than or equal to a /48. Where possible, subsequent allocations will be made from an adjacent address block, but only if duly documented and justified. " So, are you expecting these to be the rules over the /16 that you are requesting? As I said to Dino, you are free to leave the rules for later definition, but that IMHO would demerit the request making the space basically useless. Regards, as On 15/11/2012 20:39, Joel M. Halpern wrote: > Whatever else is going on, LISP EIDs do not have geographic > significance. They do not have IP Routing topological significance. The > are not aggregateable. > > They are intended to beused by a site as a single prefix. Hence, the > desired behavior (within the /16) is exactly the same as that needed to > respond to a PI request. > > Yours, > Joel > > On 11/15/2012 5:24 PM, George Michaelson wrote: >> >> Dino, to come back on topic. I understand the drafts purpose is to >> request a block of IPv6 address be delegated for this specific >> purpose, from IANA. The request is to the IAB. So, its a request for >> architectural aspects of addressing, facing an experiment. >> >> a /12 is a very large amount of space. This demands rigour in the >> process to apply, even a reservation requires a sense of why, and >> justification. "we think its about right" isn't appropriate and the >> document needs more work to specify why a 16, and why a /12, and what >> the implications are of eg a smaller allocation under a /16 >> reservation, or some other size (a /32 even, for which there are both >> precedents, in experimental allocations, and an existing process >> inside the RIR address management framework). >> >> Secondly, you appear to assume these allocations to EID can simply use >> current RIR practices. The problem is that you need to understand what >> needs-based and justification means in process terms: Hostmasters in >> the RIR system try very hard not to be placed in a position of making >> arbitrary subjective decisions: they have processes which are designed >> to ask for objective justifications to specify why an allocation >> should take place, and at what scale. Those objective criteria face >> addresses as addresses. not EID. >> >> For an example: IPv6 address allocation process currently is >> implemented using sparse allocation (binary chop with some >> modifications) in the APNIC region. This maximises space around >> allocations to equalise the distribution of free blocks such that the >> commons, the unallocated space, remains as usefully large as possible >> and when the next binary stride is entered, there is some >> understanding its going to be applied in common to all occupants of >> that region of space (in terms of the size of hole around them, which >> is not a reservation per se, but provides for risk-management of >> future growth to the largest extent). >> >> We're really quite proud of sparse: its extended the life of the /12 >> we occupy quite markedly. What impact will EID have on this? Is sparse >> an appropriate allocation engine to use for EID? What if eg you have >> expectations of almost-geographic aspects of address management in >> EID. Doesn't that require documentation as a process? And, you may be >> specifying a cost on the RIR system, to engineer support for the new >> allocation logic. If it doesn't logically fit in sparse allocation, we >> need to know. And we need to know why. >> >> EID are not going to be used like 'normal' addresses. So, the normal >> justifications don't look entirely appropriate to me from 10,000ft. >> The document needs to say "maybe we need to understand the allocation >> processes that the RIR should objectively apply" or maybe you need to >> step outside of draft space and engage inside the RIR policy process >> and seek a global policy which can document the process. >> >> To ask for an IANA allocation without having undertaken this process >> looks wrong to me. So, I stand by my concern the document isn't ready >> for IETF last call: it hasn't addressed substantive issues around the >> process and expectations of address/registry function, to manage the >> /16, and it hasn't documented the basis of asking for a /16 in the >> first place, or a /12 reservation. >> >> cheers >> >> -George >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Thu Nov 15 22:24:13 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6984421F84DD; Thu, 15 Nov 2012 22:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 F3OnXuaejydj; Thu, 15 Nov 2012 22:24:12 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5C821F8522; Thu, 15 Nov 2012 22:24:12 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1724833pbc.31 for ; Thu, 15 Nov 2012 22:24:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Cf0mDqTfJxuYXvRwAsKszpjDa7N75lUwPrtiRResaI8=; b=NDuFq07PW3jhOq473zCMWXcrNPmYR5dRLTgUSuiJE+Kk7VB7F9Va+QiDWFBgrrJXyA zt33SWf2Cs12HJdRGa02PN8+yQ3OaiWzhAdobMoNqTnTF2qaB3YEe7JYmlZthAJShyyx BPNDkq1eRj6gaQba/ycme588iq82Jhrwjk4EHxJstivG+AYWbL/EbjbLw7GXuiXuDVmy O2yeA8HkSw6RpcON5/0v87vvRrz3PrKWpI4NoBLRceyLAaYYpg0pMBH5GIZ4RF9GR/Nv 4ZxmfkVWYmZj5Yg0joww0sfFumK1bios40cEpSc3EGY85Dl20gWe0Lw6NKrczLhUULyj D2Ng== Received: by 10.66.85.134 with SMTP id h6mr10052689paz.36.1353047051916; Thu, 15 Nov 2012 22:24:11 -0800 (PST) Received: from sjc-vpn5-144.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id c1sm545245pav.23.2012.11.15.22.24.08 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 22:24:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <37436188-2E53-40DC-839F-AC52E5CA8188@apnic.net> Date: Thu, 15 Nov 2012 22:24:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <766205F6-48FB-4962-9F43-EDCACC73D1DA@gmail.com> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> <37436188-2E53-40DC-839F-AC52E5CA8188@apnic.net> To: George Michaelson X-Mailer: Apple Mail (2.1499) Cc: "ietf@ietf.org list" , lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 06:24:13 -0000 > Dino, to come back on topic. I understand the drafts purpose is to = request a block of IPv6 address be delegated for this specific purpose, = from IANA. The request is to the IAB. So, its a request for = architectural aspects of addressing, facing an experiment. Sure. > a /12 is a very large amount of space. This demands rigour in the = process to apply, even a reservation requires a sense of why, and = justification. "we think its about right" isn't appropriate and the = document needs more work to specify why a 16, and why a /12, and what = the implications are of eg a smaller allocation under a /16 reservation, = or some other size (a /32 even, for which there are both precedents, in = experimental allocations, and an existing process inside the RIR address = management framework). Okay. > Secondly, you appear to assume these allocations to EID can simply use = current RIR practices. The problem is that you need to understand what = needs-based and justification means in process terms: Hostmasters in the = RIR system try very hard not to be placed in a position of making = arbitrary subjective decisions: they have processes which are designed = to ask for objective justifications to specify why an allocation should = take place, and at what scale. Those objective criteria face addresses = as addresses. not EID. No, I am not making any assumptions either way. How allocation gets done = is subject to more work. > For an example: IPv6 address allocation process currently is = implemented using sparse allocation (binary chop with some = modifications) in the APNIC region. This maximises space around = allocations to equalise the distribution of free blocks such that the = commons, the unallocated space, remains as usefully large as possible = and when the next binary stride is entered, there is some understanding = its going to be applied in common to all occupants of that region of = space (in terms of the size of hole around them, which is not a = reservation per se, but provides for risk-management of future growth to = the largest extent). There is no special semantics of EIDs that require you to change this. = EIDs are just addresses that do not get injected into the underlying = routing system. Other than that, they are just like any other address an = RIR allocates. > We're really quite proud of sparse: its extended the life of the /12 = we occupy quite markedly. What impact will EID have on this? Is sparse = an appropriate allocation engine to use for EID? What if eg you have = expectations of almost-geographic aspects of address management in EID. = Doesn't that require documentation as a process? And, you may be = specifying a cost on the RIR system, to engineer support for the new = allocation logic. If it doesn't logically fit in sparse allocation, we = need to know. And we need to know why. What Joel said. > EID are not going to be used like 'normal' addresses. So, the normal = justifications don't look entirely Define how a 'normal address" is used. > appropriate to me from 10,000ft. The document needs to say "maybe we = need to understand the allocation processes that the RIR should = objectively apply" or maybe you need to step outside of draft space and = engage inside the RIR policy process and seek a global policy which can = document the process. The working decided that this draft is solely for request purposes. We = could use help from RIRs to write a document on how to allocate EIDs. = But I am pretty sure it would look like documents that already exist. I don't understand why you think they look different or need to be = treated differently. So you have to do the explaining. ;-) > To ask for an IANA allocation without having undertaken this process = looks wrong to me. So, I stand by my concern the document isn't ready = for IETF last call: it hasn't addressed substantive issues around the = process and expectations of address/registry function, to manage the = /16, and it hasn't documented the basis of asking for a /16 in the first = place, or a /12 reservation. Here is a real world example we have been using on the LISP beta = network. It is so simple that it really needs no more explanation than = what I am going to explain below: (1) We have 2610:00d0::/32 allocated for EIDs. (2) Each site on the LISP beta network gets a /48 out of that. (3) Each site xTRs register their /48 with the mapping system using = RLOCs that are PA addresses they use to attach to the Internet. That is it. So I am not getting why there are so many issues. Can't we = keep this simple and experiment please? Dino >=20 > cheers >=20 > -George From ggm+ietf@apnic.net Fri Nov 16 00:38:24 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B084321F86D2; Fri, 16 Nov 2012 00:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 268bKqoqKP3A; Fri, 16 Nov 2012 00:38:23 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1AB21F8668; Fri, 16 Nov 2012 00:38:21 -0800 (PST) Received: from [IPv6:2001:67c:2e8:13:3490:ce58:7e8b:5eb0] (unknown [IPv6:2001:67c:2e8:13:3490:ce58:7e8b:5eb0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 65F57B68D2; Fri, 16 Nov 2012 18:38:18 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: George Michaelson In-Reply-To: <766205F6-48FB-4962-9F43-EDCACC73D1DA@gmail.com> Date: Fri, 16 Nov 2012 09:38:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <149720A8-FC8D-4BD0-9A7A-0EB42E8CCE75@apnic.net> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> <37436188-2E53-40DC-839F-AC52E5CA8188@apnic.net> <766205F6-48FB-4962-9F43-EDCACC73D1DA@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) Cc: "ietf@ietf.org list" , lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 08:38:24 -0000 On 16/11/2012, at 7:24 AM, Dino Farinacci wrote: >=20 >> Secondly, you appear to assume these allocations to EID can simply = use current RIR practices. The problem is that you need to understand = what needs-based and justification means in process terms: Hostmasters = in the RIR system try very hard not to be placed in a position of making = arbitrary subjective decisions: they have processes which are designed = to ask for objective justifications to specify why an allocation should = take place, and at what scale. Those objective criteria face addresses = as addresses. not EID. >=20 > No, I am not making any assumptions either way. How allocation gets = done is subject to more work. Maybe this is something you could come to an RIR meeting and present on = or discuss? We've got an APNIC/APRICOT coming up early in 2013 and I am = sure you'd be welcomed to submit some content. Its good to talk about = these things. >=20 >> For an example: IPv6 address allocation process currently is = implemented using sparse allocation (binary chop with some = modifications) in the APNIC region. This maximises space around = allocations to equalise the distribution of free blocks such that the = commons, the unallocated space, remains as usefully large as possible = and when the next binary stride is entered, there is some understanding = its going to be applied in common to all occupants of that region of = space (in terms of the size of hole around them, which is not a = reservation per se, but provides for risk-management of future growth to = the largest extent). >=20 > There is no special semantics of EIDs that require you to change this. = EIDs are just addresses that do not get injected into the underlying = routing system. Other than that, they are just like any other address an = RIR allocates. But by not being injected in the routing system they've already got a = qualification against normal allocations, which are for globally routed = addresses. So if under current criteria, somebody fronts to the RIR = system and asks for a unique address assignment NOT to be globally = routed, what do you think happens? We try not to 'just make it up on the fly' -If there is going to be an = EID space, shared footprint, with this behaviour, it will need to be = documented in RIR policy. >=20 >> We're really quite proud of sparse: its extended the life of the /12 = we occupy quite markedly. What impact will EID have on this? Is sparse = an appropriate allocation engine to use for EID? What if eg you have = expectations of almost-geographic aspects of address management in EID. = Doesn't that require documentation as a process? And, you may be = specifying a cost on the RIR system, to engineer support for the new = allocation logic. If it doesn't logically fit in sparse allocation, we = need to know. And we need to know why. >=20 > What Joel said. 4. Expected use Sites planning to deploy LISP may request a prefix in the IPv6 EID Block. Such prefix will be used for routing and endpoint identification inside the site requesting it. Mappings related to such prefix, or part of it, will be made available through the mapping system in use or registered to one or more Map Server(s). Too guarantee reachability from the Legacy Internet the prefix could be announced in the BGP routing infrastructure by one or more PITR(s), possibly as part of a larger prefix, AGGREGATING several prefixes of several sites. [my emphasis] >=20 7. Routing Considerations In order to provide connectivity between the Legacy Internet and LISP sites, PITRs announcing large AGGREGATES of the IPv6 EID Block could be deployed. By doing so, PITRs will attract traffic destined to LISP sites in order to encapsulate and forward it toward the specific destination LISP site. Routers in the Legacy Internet must treat announcements of prefixes from the IPv6 EID Block as normal announcements, applying best current practice for traffic engineering and security. [my emphasis] thats in the 03 draft. So, naievely, I read that as meaning global = unicast Aggregation. If it refers inside LISP only and is not implying = aggregatable assignment to end entities holding EID, if EID are unique = only and can be sparse and disjoint, Thats good to know. >> EID are not going to be used like 'normal' addresses. So, the normal = justifications don't look entirely >=20 > Define how a 'normal address" is used. globally routable (normally) for starters. With assignment dynamics = which relate an end-site to a customer, so with some scaling which = reflects demand and the depth of network complexity to achieve it. Which = is specified at time of assignment and tracked for subsequent = reallocation/growth.=20 Address management has costs btw. I expect many people in this community = are concerned by that and there are times quite unpleasant language is = used about the RIR process and its cost recovery needs, but it can't be = avoided. So in that context, did you expect EID allocation and address = management to be free? Its got to reflect its societal costs like other = addresses is a possible position. >=20 >> appropriate to me from 10,000ft. The document needs to say "maybe we = need to understand the allocation processes that the RIR should = objectively apply" or maybe you need to step outside of draft space and = engage inside the RIR policy process and seek a global policy which can = document the process. >=20 > The working decided that this draft is solely for request purposes. We = could use help from RIRs to write a document on how to allocate EIDs. = But I am pretty sure it would look like documents that already exist. Yes, but the conversation would be useful. So why not come into RIR = policy development process and kick off a conversation about global = address policy (which this clearly is) Seriously: this could be talked about. >=20 > I don't understand why you think they look different or need to be = treated differently. So you have to do the explaining. ;-) Cute. I'd like this document to explore the need for work in the area = and say its for further study, and observe the IAB/IANA instruction = might be pending that further work, because assigning a block without = objective criteria and a global policy in RIR Process is not a good = idea. I really don't think the IAB should simply give the /12 on the basis of = this document. If another document needs to be spun then this one can = sit at IETF last call and share fate. >=20 >> To ask for an IANA allocation without having undertaken this process = looks wrong to me. So, I stand by my concern the document isn't ready = for IETF last call: it hasn't addressed substantive issues around the = process and expectations of address/registry function, to manage the = /16, and it hasn't documented the basis of asking for a /16 in the first = place, or a /12 reservation. >=20 > Here is a real world example we have been using on the LISP beta = network. It is so simple that it really needs no more explanation than = what I am going to explain below: >=20 > (1) We have 2610:00d0::/32 allocated for EIDs. > (2) Each site on the LISP beta network gets a /48 out of that. > (3) Each site xTRs register their /48 with the mapping system using = RLOCs that are PA addresses they use to attach to the Internet. >=20 > That is it. So I am not getting why there are so many issues. Can't we = keep this simple and experiment please? Ok. So work with me on this a bit Dino. I realize you are very busy, but = I want to understand. 1) how many /48 have been allocated thus far from this experimental /32? = it has 65,000 of them. The dynamics of the rollout would be very = interesting. I'm really interested in this number. Its pretty fundamental to an = address application/reservation facing the IAB/IANA and I expect you = will be asked it more formally anyway (not by me. I dont do this stuff, = but its forseeable). Bearing in mind that Sander Steffan has already = shown global-unicast can be used for EID, I don't expect it to be = equivalent to the count of EID visible in LISP routing. t Anyway, even with that caveat 65,000 is quite a lot. If you've achieved = high density, the experiment has very interesting scaling and we need to = know. In particular, I would suggest that its possibly less an = experiment, and more a product. If its in production, then applying = under experimental criteria is a bit of a concern for me. 2) how many /48 do you foresee being allocated in a 1,2,5 year footprint = heading to the /16 horizon? There are 4 billion /48 in a /16=20 3) how many /48 do you foresee being allocated in the 5,10,20 year = footprint heading to the /12 horizon?=20 I have to say that to achieve 2) I do not believe this could be in any = real sense "an experiment" except to the extent the entire IPv4 network = we have is an 'experiment' because 2^32 is looking like a very large = amount of EID, equivalent to the entire IPv4 space. So from here, I can't grasp the /16, let alone the /12. If this is an = experiment, then I think we should be having a conversation about what = size above a /32 achieves your goals. If there is to be a reservation, = we should understand the scoping it can grow to, which begins to look = more like the /16 than the /12, although I suspect its a lot smaller = than the /16 and more like a /22 [I am not a hostmaster and this is most definitely not an APNIC = position: its my personal view] BTW, comparisons to the /12 of 2002: are very unhelpful to your case. = Firstly, it was a transition technology, in the main an automatic = tunnelling mechanism and not structured, and the sub assigns in the = space reflected their global routing via the IPv4 label embedded. Secondly, there were very real administrative issues facing 2002: in = terms of reverse-DNS, and the over-reach of an ISPs routing footprint = and intrusion of services. I think the /12 reflected the needs of the format to embed the = server,client pairs into the footprint of address. Since you have = demonstrated your EID is in /48, the size of the parent above that in = global routing does not need to be the same as 2002 which depended on = totally ad-hoc server IPs and the anycast cloud instance as fallback.=20 I may be wrong, but I suspect if the 2002 protocol spec had been written = not to need the /12 it would not have been assigned a /12. I think in hindsight the Teredo footprint of a single /32 in 2001:0: is = equally instructive. Microsoft deployed this into their core technology = worldwide. clearly, a single /32 can scale to an entire global Internet = for this class of tunnel. I appreciate that EID is a different kind of = tunnel, but the difference tends to less EID doesn't it? cheers -george >=20 > Dino >=20 >>=20 >> cheers >>=20 >> -George >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ggm+ietf@apnic.net Fri Nov 16 00:42:07 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF3A21F86DE; Fri, 16 Nov 2012 00:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 kJAb8wYqlc-H; Fri, 16 Nov 2012 00:42:07 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id B88B821F8504; Fri, 16 Nov 2012 00:42:06 -0800 (PST) Received: from [IPv6:2001:67c:2e8:13:3490:ce58:7e8b:5eb0] (unknown [IPv6:2001:67c:2e8:13:3490:ce58:7e8b:5eb0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C22D6B684D; Fri, 16 Nov 2012 18:42:04 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: George Michaelson In-Reply-To: <149720A8-FC8D-4BD0-9A7A-0EB42E8CCE75@apnic.net> Date: Fri, 16 Nov 2012 09:42:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <951612FB-F1A5-4EBE-8792-57CC9BDC71A2@apnic.net> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> <37436188-2E53-40DC-839F-AC52E5CA8188@apnic.net> <766205F6-48FB-4962-9F43-EDCACC73D1DA@gmail.com> <149720A8-FC8D-4BD0-9A7A-0EB42E8CCE75@apnic.net> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) Cc: "ietf@ietf.org list" , lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 08:42:07 -0000 s/12/16/ wrt 2002: doh. the principle stands. 2002://16 did not imply a = reservation to a /12 and would have been given less than a /16 if the = technology had allowed it. -G= From brian.e.carpenter@gmail.com Fri Nov 16 01:05:16 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A6D21F8477; Fri, 16 Nov 2012 01:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.557 X-Spam-Level: X-Spam-Status: No, score=-101.557 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 5vjgoUzD86s0; Fri, 16 Nov 2012 01:05:15 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 48D9821F845A; Fri, 16 Nov 2012 01:05:15 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so977044wgb.13 for ; Fri, 16 Nov 2012 01:05:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=H8F9Psv3wh+2N96lmDrohYem/whPh6va7BSXpAA+F3w=; b=tSvLeayaX550ZBUDDBGHEBdHSRJWGe1mnXbRYNJLvyPkV1pn1na5u+wkLnzqF2ZXEh CsWE6mz1k6Dsas8REmXG0wpisWvKO0pSf4iB9MUk+KOxy7OLmtsn8jb0Y2qHGpODAyBh dqcJ6ApRkNnewH75TtL+zamemPUdsT3qfoBQ6NEC5MA6CmvKnWZ/4xov0AsUUCTB4nE4 dZzyw6MDTs+2IaT0E71wbCJTkLANt7Q/3yNTRBv3cNTqc6lhyzi2QQj0FTR0/7AJA4ul rYmzCNzBqpopEF0ks2kuOaxo8O12U7E08ch8fMDS7XG/l03bAGv9ZYx1uvMJkoqfjvSL yYdg== Received: by 10.216.140.87 with SMTP id d65mr1653927wej.131.1353056714314; Fri, 16 Nov 2012 01:05:14 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-111.as13285.net. [2.102.216.111]) by mx.google.com with ESMTPS id d16sm14433728wiw.8.2012.11.16.01.05.12 (version=SSLv3 cipher=OTHER); Fri, 16 Nov 2012 01:05:13 -0800 (PST) Message-ID: <50A601D6.6080701@gmail.com> Date: Fri, 16 Nov 2012 09:05:26 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sander Steffann References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> <22AD9545-DDC9-4FE9-A984-1D0E3987D02D@steffann.nl> In-Reply-To: <22AD9545-DDC9-4FE9-A984-1D0E3987D02D@steffann.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 09:05:16 -0000 On 15/11/2012 22:41, Sander Steffann wrote: ... >>> b) as a user of that EID space I would be at the mercy of >>> PITR operators that I don't even know >> You are at the mercy of a lot of infrastructure components >> today. This is no different. > > Yes it is. *please*please*please* study what happened to 6to4 > and the 2002::/16 prefix before continuing this discussion. The problem there was that the design of 6to4 assumed, and relied on, altruistic cooperation between operators, to ensure that there was a useable route to 2002::/16 *everywhere* in the IPv6 network. That assumption was naive and led to black holes. My main concern with LISP deployment is whether there will be a useable route to EID space *everywhere* in the (non-LISP) network. If that also relies on altruism, I would share Sander's concern. Brian From sander@steffann.nl Fri Nov 16 02:18:17 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6C521F868A; Fri, 16 Nov 2012 02:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 HcraAW0+4tC6; Fri, 16 Nov 2012 02:18:17 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5BE21F867F; Fri, 16 Nov 2012 02:18:16 -0800 (PST) Received: from [192.168.222.59] (unknown [87.249.115.10]) by mail.sintact.nl (Postfix) with ESMTP id A827B2011; Fri, 16 Nov 2012 11:18:15 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <149720A8-FC8D-4BD0-9A7A-0EB42E8CCE75@apnic.net> Date: Fri, 16 Nov 2012 11:18:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> <37436188-2E53-40DC-839F-AC52E5CA8188@apnic.net> <766205F6-48FB-4962-9F43-EDCACC73D1DA@gmail.com> <149720A8-FC8D-4BD0-9A7A-0EB42E8CCE75@apnic.net> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) Cc: George Michaelson , "ietf@ietf.org list" , "lisp@ietf.org list" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 10:18:17 -0000 Hi Dino, > George: >> Maybe this is something you could come to an RIR meeting and present = on or discuss? We've got an APNIC/APRICOT coming up early in 2013 and I = am sure you'd be welcomed to submit some content. Its good to talk about = these things. +1 Let's make it official :-) It would be very good to discuss this idea in the RIR communities. I = think both the LISP community and the RIR communities can learn from = each other. As co-chair of the RIPE Address Policy Working Group I would = really appreciate it if you could come to the next RIPE meeting to = discuss this. I'll make sure that there is a slot on the working group = agenda. RIPE 66 will take place from 13-17 May 2013 at the Burlington = Hotel in Dublin. Thanks, Sander From aservin@lacnic.net Fri Nov 16 02:51:12 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D6E21F852D; Fri, 16 Nov 2012 02:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[AWL=-1.655, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 L843Wz7MXWfZ; Fri, 16 Nov 2012 02:51:11 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA8921F862D; Fri, 16 Nov 2012 02:51:10 -0800 (PST) Received: from [192.168.1.133] (r186-48-193-143.dialup.adsl.anteldata.net.uy [186.48.193.143]) by mail.lacnic.net.uy (Postfix) with ESMTP id 68764308455; Fri, 16 Nov 2012 08:51:06 -0200 (UYST) Message-ID: <50A61A97.9060005@lacnic.net> Date: Fri, 16 Nov 2012 08:51:03 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dino Farinacci References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> <37436188-2E53-40DC-839F-AC52E5CA8188@apnic.net> <766205F6-48FB-4962-9F43-EDCACC73D1DA@gmail.com> <149720A8-FC8D-4BD0-9A7A-0EB42E8CCE75@apnic.net> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "ietf@ietf.org list" , "lisp@ietf.org list" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 10:51:12 -0000 Dino, +1 In LACNIC, may 6th to 10th 2013 in Medellin Colombia. I am not the policiy guy but I can get you time in the technical and policy plenaries and assit you in the discussion. Also, if you plan to write some text about the allocation mechanics let me know, I will be happy to help to review, comment and even write some text if that is useful for lisp. Regards, as On 16/11/2012 08:18, Sander Steffann wrote: > Hi Dino, > >> George: >>> Maybe this is something you could come to an RIR meeting and present on or discuss? We've got an APNIC/APRICOT coming up early in 2013 and I am sure you'd be welcomed to submit some content. Its good to talk about these things. > > +1 > > Let's make it official :-) > > It would be very good to discuss this idea in the RIR communities. I think both the LISP community and the RIR communities can learn from each other. As co-chair of the RIPE Address Policy Working Group I would really appreciate it if you could come to the next RIPE meeting to discuss this. I'll make sure that there is a slot on the working group agenda. RIPE 66 will take place from 13-17 May 2013 at the Burlington Hotel in Dublin. > > Thanks, > Sander > From rogerj@gmail.com Fri Nov 16 03:57:35 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA6921F893C; Fri, 16 Nov 2012 03:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 JPovIDKDwfLf; Fri, 16 Nov 2012 03:57:34 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A197721F8524; Fri, 16 Nov 2012 03:57:33 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hm14so1494388wib.13 for ; Fri, 16 Nov 2012 03:57:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HlfwgW+KVPE5fz7Uo97DepTITgjWfd8Ld9aMCN/+ZHM=; b=AoMzRppe3xOO5UunmuE9HtlRzQ9mIvA48CDrsrBMh1vOO31PyY7b3gI0a+VbBiSSED yTKzAOVKX8MuHX/ZuieDMGSIPemEq9l+KPT1JoLwa77CTZgeeH6MdVzfibp8Fofw2xPN bbIdhB1eOBF52/tAhf9MgVuykUujRVNYtV5GA+Cc1Y6t4iCDTDlW5qFaFOMTB03yR05r zz08tKv7qQBt/DEBw0WkZ696K/5IAnlyNXrvj+xIHl0F5BPmnJmcrW9ibrSiQ7ExXcFr xhuGuNugfFapjQQ5gdhLnHFK9isu8m3zKrjehd9T9WvX0F3fspL/LR+Ry5sgRLxZMVAo oDjQ== MIME-Version: 1.0 Received: by 10.180.19.197 with SMTP id h5mr4698792wie.22.1353067052713; Fri, 16 Nov 2012 03:57:32 -0800 (PST) Received: by 10.217.83.4 with HTTP; Fri, 16 Nov 2012 03:57:32 -0800 (PST) In-Reply-To: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> Date: Fri, 16 Nov 2012 12:57:32 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: ietf@ietf.org, lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: =?ISO-8859-1?Q?Roger_J=F8rgensen?= Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 11:57:35 -0000 On Tue, Nov 13, 2012 at 3:45 PM, The IESG wrote: > > The IESG has received a request from the Locator/ID Separation Protocol > WG (lisp) to consider the following document: > - 'LISP EID Block' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. I think LISP is an important factor in the future of Internet and I do support the idea of having different IP block for LISP based network. However, I can not support the publication of this document, it has some unclear issues that need good answers first. Anyhow, I see two issues that need to be addressed better 1.) How should the address space be administrated, RIR structure or something else closer to 6bone? I support the suggested idea of discussing this part with the different RIRs to look more into how this are going to work in practice. And as Dino said, "No, I am not making any assumptions either way. How allocation gets done is subject to more work." the document should state this. 2.) The interaction between none-LISP and LISP Internet. This problem has two sub-problems within it a.) Why is there a need for a special LISP block. This is partly answered in section 3. Rationale and Intent. Is this the entire reason? With the current specifications, if an ITR is sending to all types of destinations (i.e., non-LISP destinations, LISP destinations not in the IPv6 EID Block, and LISP destinations in the IPv6 EID Block) the only way to understand whether or not to encapsulate the traffic is to perform a cache lookup and, in case of cache-miss, send a Map- Request to the mapping system. In the meanwhile, packets can be dropped. b.) the routing integration between none-LISP and LISP internet, how are that going to work? The current document isn't clear enough on that as I see it. Are there an assumption that some ISPs will announce the entire LISP space (/16 are mention) for free ? If each and every EID space holder (/32 or similiar) each have to connect to Internet and get their address space routed, then it's nothing different than regular RIR allocated /32's. Address these thing somehow in the document, even just mention that it's subject for other document and I'm happy... :-) -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From pvinci@VinciConsulting.com Fri Nov 16 05:06:05 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915AD21F850D; Fri, 16 Nov 2012 05:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 tCfX7ih0gDHS; Fri, 16 Nov 2012 05:06:05 -0800 (PST) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id D69DC21F84E4; Fri, 16 Nov 2012 05:06:04 -0800 (PST) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Fri, 16 Nov 2012 08:06:03 -0500 From: Paul Vinciguerra To: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "ietf@ietf.org" , "lisp@ietf.org" Thread-Topic: [lisp] Last Call: (LISP EID Block) to Informational RFC Thread-Index: AQHNw/GsxGi1EUnc4EWrahCjLHXJF5fsY22w Date: Fri, 16 Nov 2012 13:06:02 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C94AA6DA4@NYDC-EXCH01.vinci-consulting-corp.local> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.14] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 13:06:05 -0000 So, I had originally thought that the reason for this was to change the cha= racteristics of a new flow with a cache-hit from the ..!!! that we see to a= !!!!! But even if you know that the destination is an EID, you still need to look= up the RLOCs, so how does this help? If the destination is a non-LISP endp= oint, and there is a cache-miss, isn't the packet forwarded to the destinat= ion, hoping that the packet can be delivered unencapsulated because it is n= ot and EID, or that there is a legacy aggregate being announced that knows = the destination to deliver the encapsulated packet until the xTR's cache po= pulates?=20 Section 3 states: By defining an IPv6 EID Block [, it] is possible to configure the router so to natively forward all packets that have not a destination address in the block, without performing any lookup whatsoever. This reads as if the intent is to set a policy that would only allow LISP e= ncapsulation to IPv6 destinations within this new block and to remove the e= xisting ability to encapsulate to existing v6 EID's in the DDT. The implic= ation to me is that if I have existing v6 space, I must provide legacy tran= sit through my own PxTR's, almost as a second class citizen as I will be as= sured a suboptimal path. Do I have this wrong? =20 From jnc@mercury.lcs.mit.edu Fri Nov 16 06:00:23 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B941C21F8485; Fri, 16 Nov 2012 06:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 NkCNJ-GrOjcD; Fri, 16 Nov 2012 06:00:23 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED9921F847F; Fri, 16 Nov 2012 06:00:23 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id F2C2618C095; Fri, 16 Nov 2012 09:00:21 -0500 (EST) To: ietf@ietf.org, lisp@ietf.org Message-Id: <20121116140021.F2C2618C095@mercury.lcs.mit.edu> Date: Fri, 16 Nov 2012 09:00:21 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 14:00:23 -0000 > From: > the routing integration between none-LISP and LISP internet, how are > that going to work? The current document isn't clear enough on that as > I see it. The way the routing will work would take a couple of PhD theses to fully cover (I know of one that's already underway). So it's not really a topic that can be covered in this ID. Adding to the complexity is that if LISP becomes widely deployed, how the routing works will likely change over time; in the early stages, when there are small islands of LISP, it'll be one thing; later on, when there are islands of legacy stuff, it'll be totally different. Etc, etc. > Address these thing somehow in the document, even just mention that > it's subject for other document and I'm happy... :-) The IETF used to have this concept of 'rough consensus and _running code_'; i.e. we tried stuff out to see if it works. When did we change into an organization that had to have every 'i' dotted, and every 't' crossed, before we could move an inch? (Saying 'just refer to the document where it is covered' doesn't help, if the other document isn't written yet.) All this ID is trying to do is allocate a rather modest chunk (~ one quarter of one tenth of one percent - .025% - if I've done the math right) of address space for an experiment; exactly how it will be best used, and what the best allocation process is, is to some degree part of that experiment. Noel From jmh@joelhalpern.com Fri Nov 16 08:00:29 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC7521F84DE; Fri, 16 Nov 2012 08:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.115 X-Spam-Level: X-Spam-Status: No, score=-102.115 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 EkuQfvisapT9; Fri, 16 Nov 2012 08:00:28 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id BE1A021F8459; Fri, 16 Nov 2012 08:00:28 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 7FC7255995C; Fri, 16 Nov 2012 08:00:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 086D41BD1FBC; Fri, 16 Nov 2012 08:00:26 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-174.clppva.btas.verizon.net [71.161.50.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 126351BD1FCC; Fri, 16 Nov 2012 08:00:24 -0800 (PST) Message-ID: <50A66313.9090002@joelhalpern.com> Date: Fri, 16 Nov 2012 11:00:19 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 16:00:29 -0000 It is a fair question to ask whether the allocation strategy and polices need to be spelled out at the time of the reservation. Possibly we made the wrong call on keeping them separate. Part of the issue is that fo current experimentation having the block is more important, but for longer term experiments, and for implications on other parties, the allocation policies matter more. With regard to interworking and deployment, there are a number of documents that deal with that. They discuss what the currently understood deployment incentives are, and what paths are currently seen. (As Noel noted, this is an experiment, and one should expect that the actual path will be different from the expectation.) Given that interworkng dives are data plane devices, altruism is clearly not a sufficient incentive to get this to scale, and the models do not depend upon that. Yours, Joel On 11/16/2012 6:57 AM, Roger Jørgensen wrote: > On Tue, Nov 13, 2012 at 3:45 PM, The IESG wrote: >> >> The IESG has received a request from the Locator/ID Separation Protocol >> WG (lisp) to consider the following document: >> - 'LISP EID Block' >> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. > > > I think LISP is an important factor in the future of Internet and I do > support the idea of having different IP block for LISP based network. > > However, I can not support the publication of this document, it has > some unclear issues that need good answers first. > > > > Anyhow, I see two issues that need to be addressed better > > 1.) How should the address space be administrated, RIR structure or > something else closer to 6bone? I support the suggested idea of > discussing this part with the different RIRs to look more into how > this are going to work in practice. > And as Dino said, "No, I am not making any assumptions either way. How > allocation gets done is subject to more work." the document should > state this. > > > > > 2.) The interaction between none-LISP and LISP Internet. This problem > has two sub-problems within it > > a.) Why is there a need for a special LISP block. This is partly > answered in section 3. Rationale and Intent. Is this the entire > reason? > > > With the current specifications, if an ITR is sending to all types of > destinations (i.e., non-LISP destinations, LISP destinations not in > the IPv6 EID Block, and LISP destinations in the IPv6 EID Block) the > only way to understand whether or not to encapsulate the traffic is > to perform a cache lookup and, in case of cache-miss, send a Map- > Request to the mapping system. In the meanwhile, packets can be > dropped. > > > > > b.) the routing integration between none-LISP and LISP internet, how > are that going to work? > The current document isn't clear enough on that as I see it. Are there > an assumption that some ISPs will announce the entire LISP space (/16 > are mention) for free ? > If each and every EID space holder (/32 or similiar) each have to > connect to Internet and get their address space routed, then it's > nothing different than regular RIR allocated /32's. > > > > Address these thing somehow in the document, even just mention that > it's subject for other document and I'm happy... :-) > > > From sm@resistor.net Thu Nov 15 09:25:57 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896AF21F8996; Thu, 15 Nov 2012 09:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 b3yhQcMhShsK; Thu, 15 Nov 2012 09:25:54 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C3E21F8549; Thu, 15 Nov 2012 09:25:40 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAFHPQk7021137; Thu, 15 Nov 2012 09:25:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353000337; bh=k3eONktwbbqFfREu22oKAe+/aOxsbkY3Q2/j0emFr2c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=x8LI7nMarJH5Pct5gESm+4huYtdaa/UW8iK7jKCGQ+HSMQNmZNcVfN7TWMH2NzSQa R0imqnfNXtLaU8x4ykm+YvsDqPyDceTiNj1d2T6ReaukuJFu8pAxZnN38ZZZmaD7ST LIM7YfgkrZ4g1VnverpSUzzpzE/zSaA0F6jjYMYs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353000337; i=@resistor.net; bh=k3eONktwbbqFfREu22oKAe+/aOxsbkY3Q2/j0emFr2c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Grn0pO8VWH7WvjZi8dZUh5FS45eT35AO4zgOEKxLUHHR8uvJfZwURAPgY3jJok8fp t0kpg3vaGkb5gi5DPintig/zgUH2kCx3K6J6oWqFIR5cRnI0r6u4pDjCSQaSrI6BXq uJ/n39L8dN5ErGgudzGZBizW4uJbhrc2y2/eVQlQ= Message-Id: <6.2.5.6.2.20121115075935.0a4c3298@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 15 Nov 2012 09:08:08 -0800 To: Luigi Iannone From: SM In-Reply-To: <63359CE6-0009-45D1-B2AE-3F2B4384D5D4@gigix.net> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <6.2.5.6.2.20121114030352.0da0e888@resistor.net> <63359CE6-0009-45D1-B2AE-3F2B4384D5D4@gigix.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Fri, 16 Nov 2012 08:01:44 -0800 Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:25:57 -0000 Hi Luigi, At 06:32 15-11-2012, Luigi Iannone wrote: > thanks for the comments. Few answers inline. Thanks for the response. >Well, if we go along that road we should put the whole document in a >single "IANA Considerations" Section. ;-) Yes. :-) >Actually the current IANA Considerations section states the same >request but does not specify "/12". >You are right that it should be clearly stated, to make the document >coherent. Will fix. Ok. >It refers to the IANA allocation policies. May be it could be >changed in the following way: > > If in the future there will be need for a larger EID Block the > address space adjacent the EID Block could be allocate by IANA > according to its current allocation policies." > >Would that work? Not yet. :-) You did not answer my question about which IANA allocation policies the draft is referring to. >I agree that this point has been not discussed thoroughly, the idea >is not to create any new "manager", rather to make ISPs (or whoever >interested in deploying LISP) to request an EID address >sub-block as they do with usual prefixes. I'll comment below. >Well, this is standard, to have a reserved space we have to go >through the (now called) "IETF Review", which is what we are doing ;-) What the draft is doing is reserving address space. According to Section 10 address blocks from that reserved address space (the /16) will be assigned through IETF review. I read the previous comment as meaning that the EID address block will be assigned to ISPs by RIRs. There isn't any mention of that in the draft. Even if it was mentioned it is doubtful that ISPs would be able to get that address space assigned through RIRs at present. The issue was mentioned in the AD review [1]. I didn't find any discussion of that in the LISP mailing list archives. According to the LISP Charter the document is to request "address space to be used for the LISP experiment as identifier space". The draft is reserving a /16 and there is scope to have that extended to a /12 in future. This goes beyond the usual experiments. There isn't any discussion of how the ip6.arpa delegation will be handled. There isn't any discussion of how long the experiment will last. I understand that IPv6 is not a scare resource. However, that is not a reason for handing out address space and leaving it to someone in future to figure out what to do if this becomes a problem. I haven't seen anyone asking why the document is not a BCP. If the aim is to have: "Routers in the Legacy Internet must treat announcements of prefixes from the IPv6 EID Block as normal announcements, applying best current practice for traffic engineering and security." I think that the document might have to be a BCP. It would be good to be clear about whether the address space should be listed in the IANA IPv6 Special Purpose Address Registry. Section 5 mentions that "The working group reached consensus on an initial allocation". Could the document shepherd upload the write-up and provide some details about that? Regards, -sm 1. http://www.ietf.org/mail-archive/web/lisp/current/msg03848.html From wesley.george@twcable.com Fri Nov 16 05:27:08 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA48E21F8641; Fri, 16 Nov 2012 05:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 JWoLXFhG29W1; Fri, 16 Nov 2012 05:27:08 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id DAE4621F852D; Fri, 16 Nov 2012 05:27:02 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.83,264,1352091600"; d="scan'208";a="471923801" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 16 Nov 2012 08:26:42 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Fri, 16 Nov 2012 08:26:52 -0500 From: "George, Wes" To: Brian E Carpenter , Sander Steffann Date: Fri, 16 Nov 2012 08:26:50 -0500 Thread-Topic: [lisp] Last Call: (LISP EID Block) to Informational RFC Thread-Index: Ac3D2ZB7DjJwipvuSwOSIMmOy4m4IwAIWyTA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592303373BDF01@PRVPEXVS15.corp.twcable.com> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> <22AD9545-DDC9-4FE9-A984-1D0E3987D02D@steffann.nl> <50A601D6.6080701@gmail.com> In-Reply-To: <50A601D6.6080701@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 16 Nov 2012 08:01:44 -0800 Cc: "ietf@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 13:27:08 -0000 PiBGcm9tOiBpZXRmLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppZXRmLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZg0KPiBCcmlhbiBFIENhcnBlbnRlcg0KDQo+ID4gKnBsZWFzZSpwbGVh c2UqcGxlYXNlKiBzdHVkeSB3aGF0IGhhcHBlbmVkIHRvIDZ0bzQgYW5kIHRoZQ0KPiA+IDIwMDI6 Oi8xNiBwcmVmaXggYmVmb3JlIGNvbnRpbnVpbmcgdGhpcyBkaXNjdXNzaW9uLg0KPg0KPiBUaGUg cHJvYmxlbSB0aGVyZSB3YXMgdGhhdCB0aGUgZGVzaWduIG9mIDZ0bzQgYXNzdW1lZCwgYW5kIHJl bGllZCBvbiwNCj4gYWx0cnVpc3RpYyBjb29wZXJhdGlvbiBiZXR3ZWVuIG9wZXJhdG9ycywgdG8g ZW5zdXJlIHRoYXQgdGhlcmUgd2FzIGENCj4gdXNlYWJsZSByb3V0ZSB0byAyMDAyOjovMTYgKmV2 ZXJ5d2hlcmUqIGluIHRoZQ0KPiBJUHY2IG5ldHdvcmsuIFRoYXQgYXNzdW1wdGlvbiB3YXMgbmFp dmUgYW5kIGxlZCB0byBibGFjayBob2xlcy4NCg0KW1dFR10gVGhlIG90aGVyIHByb2JsZW0gd2l0 aCA2dG80IGlzIHRoYXQgYnkgdGhlIHRpbWUgd2UgdHJpZWQgdG8gc2h1dCBpdCBkb3duIGJlY2F1 c2Ugd2UgZGV0ZXJtaW5lZCB0aGF0IGl0IHdhc24ndCB3b3JraW5nIGFjY2VwdGFibHkgYW5kL29y IGhhZCBmYXRhbCBmbGF3cyBpbiBpdHMgZGVzaWduLCB0aGVyZSB3YXMgYSBzbWFsbCAoYnV0IGV4 dHJlbWVseSB2b2NhbCkgZ3JvdXAgb2YgcGVvcGxlIHdobyBiYXNpY2FsbHkgc2FpZCAieW91IGNh biBoYXZlIDZ0bzQgYmFjayB3aGVuIHlvdSBwcnkgaXQgZnJvbSBteSBjb2xkLCBkZWFkIGZpbmdl cnMhISIgLS0gcGVyaGFwcyB3ZSBjYW4ga2lsbCB0d28gYmlyZHMgd2l0aCBvbmUgc3RvbmUgaWYg eW91IGNhbiBjb252aW5jZSB0aG9zZSBzYW1lIHBlb3BsZSB0byBsZXQgeW91IHJlcHVycG9zZSB0 aGUgMjAwMjo6LzE2IHNwYWNlIGZvciBMSVNQPw0KDQoqZHVja3MqIDotKQ0KDQpNb3JlIHNlcmlv dXNseToNCg0KSSBlY2hvIHRoZSBjb25jZXJucyB0aGF0IG90aGVycyBoYXZlIHJhaXNlZCBhYm91 dCB0aGUgcXVlc3Rpb25hYmxlIGp1c3RpZmljYXRpb24gZm9yIGEgLzEyIG9yIC8xNiwgdGhlIGxp bWl0ZWQgZGV0YWlscyBhcm91bmQgaG93IGFsbG9jYXRpb24gYW5kIG1hbmFnZW1lbnQgbWlnaHQg d29yaywgYW5kIHRoZSByZWNvbW1lbmRhdGlvbiB0byBnbyB0YWxrIHRvIHRoZSBSSVJzIGFuZCBs ZWFybiBob3cgYWRkcmVzcyBhbGxvY2F0aW9uIG1pZ2h0IHdvcmsgc28gdGhhdCB5b3UgY2FuIGdp dmUgdGhlbSBoZWxwZnVsIHJlY29tbWVuZGF0aW9ucyB3aGVuIChhbmQgaWYpIGl0IGNvbWVzIHRp bWUgdG8gd3JpdGUgUklSIHBvbGljeSB0byBtYW5hZ2UgdGhpcyBzcGFjZS4gSSdkIHJhdGhlciB0 aGlzIG5vdCBiZSBkZWZlcnJlZCB0byBhIGxhdGVyIGRvY3VtZW50LCBiZWNhdXNlIHRoZXJlIGlz IGxpdHRsZSBpbmNlbnRpdmUgdG8gY29tcGxldGUgc3VjaCBhIGRvY3VtZW50IG9uY2UgdGhlIGFs bG9jYXRpb24gaXMgYWxyZWFkeSBtYWRlLiBFaXRoZXIgeW91IGtub3cgaG93IHRoaXMgd2lsbCBi ZSB1c2VkIGFuZCBjYW4gYXJ0aWN1bGF0ZSBpdCwgb3IgeW91IGRvbid0LiBJZiB5b3UgZG9uJ3Qs IHlvdSBhcmVuJ3QgcmVhZHkgdG8gcmVxdWVzdCBpdC4NCg0KQWRkaXRpb25hbGx5OiBUaGUgTElT UCBkb2N1bWVudHMgYXJlIGNsYXNzaWZpZWQgYXMgZXhwZXJpbWVudGFsICh0aG91Z2ggdGhpcyBv bmUgaXMgbm90Li4uKS4gVGhlcmVmb3JlIEkgc2VlIHR3byBwb3NzaWJsZSBzb2x1dGlvbnMgdGhh dCBkb24ndCBhcHBlYXIgdG8gaGF2ZSBiZWVuIGRpc2N1c3NlZCB5ZXQ6DQoxKSB0aGUgUklScyBo YXZlIGV4aXN0aW5nIHBvbGljeSByZWdhcmRpbmcgZXhwZXJpbWVudHMgKGUuZy4gaHR0cHM6Ly93 d3cuYXJpbi5uZXQvcG9saWN5L25ycG0uaHRtbCNlbGV2ZW4gKS4gWW91IG1pZ2h0IGNvbnNpZGVy IGxvb2tpbmcgYXQgdGhvc2UgcG9saWNpZXMgdG8gc2VlIGlmIGdldHRpbmcgYSBkaXJlY3QgYWxs b2NhdGlvbiBmcm9tIG9uZSBvciBtb3JlIFJJUnMgZm9yIHlvdXIgZXhwZXJpbWVudCB3b3VsZCBi ZSBhIHdvcmthYmxlIHNvbHV0aW9uLCByYXRoZXIgdGhhbiBsb2NraW5nIHNwYWNlIGludG8gdGhp cyB2aWEgSUFOQS4NCjIpIFJlcXVlc3QgdGhlIHNwYWNlICh3aXRoIGltcHJvdmVtZW50cyB0byB0 aGUgcmVxdWVzdCBhcyBzdGF0ZWQgYWJvdmUgYW5kIGVsc2V3aGVyZSBpbiB0aGlzIHRocmVhZCkg YnV0IGluY2x1ZGUgYSBzdW5zZXQgZGF0ZSBmb3IgdGhlIGFsbG9jYXRpb24gZnJvbSBJQU5BLiBJ ZiB0aGUgZXhwZXJpbWVudCBpcyBzdWNjZXNzZnVsLCB0aGUgZXhwZWN0YXRpb24gaXMgdGhhdCB5 b3Ugd2lsbCB3cml0ZSBwcm9wb3NlZCBzdGFuZGFyZCBkcmFmdHMgcmVmaW5lIHRoZSBpbXBsZW1l bnRhdGlvbiBhbmQgdG8gbWFrZSBpdCBub3QgZXhwZXJpbWVudGFsLCBhbmQgeW91IGNhbiBtYWtl IHRoZSBJQU5BIGFsbG9jYXRpb24gcGVybWFuZW50IGF0IHRoZSBzYW1lIHRpbWUuIElmIHRoZSBl eHBlcmltZW50IGlzIG5vdCBzdWNjZXNzZnVsIGFuZCB0aGlzIHNwYWNlIGlzIG5vIGxvbmdlciBu ZWVkZWQgaW4gYSBmZXcgeWVhcnMsIHdlIGRvbid0IGhhdmUgdG8gZmlnaHQgYSBzbWFsbCB2b2Nh bCBtaW5vcml0eSB0byBzaHV0IGl0IGRvd24uIChjLmYuIFJGQzM3MDEpLiBXaGlsZSBJJ20gKmxl c3MqIHdvcnJpZWQgYWJvdXQgdXMgIndhc3RpbmciIElQdjYgc3BhY2UsIGl0J3Mgbm90IGluZmlu aXRlLCBhbmQgSSdtIGhhdmluZyB2aXNpb25zIG9mIHRoZSBJUHY0IENsYXNzIEUgc3BhY2UsIHdo ZXJlIHdlIGhhdmUgdGhpcyBzaXphYmxlIGNodW5rIG9mIGFkZHJlc3NlcyBhbGxvY2F0ZWQgZm9y IGEgc3BlY2lhbCBwdXJwb3NlIHRoYXQgMTAgeWVhcnMgZnJvbSBub3cgY291bGQgKGFuZCBzaG91 bGQpIGJlIHVzZWQgZm9yIHNvbWV0aGluZyBlbHNlLCBhbmQgaW5lcnRpYSBtZWFucyB0aGF0IHRo ZXkgbmV2ZXIgZG8sIGZpbGVkIHVuZGVyICJpdCBzZWVtZWQgbGlrZSBhIGdvb2QgaWRlYSBhdCB0 aGUgdGltZS4uLiINCg0KV2VzIEdlb3JnZQ0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZv cm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRv IGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlz IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg dG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBk aXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiBy ZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWls IGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNv cHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From brian.e.carpenter@gmail.com Fri Nov 16 08:35:41 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1127D21F8779; Fri, 16 Nov 2012 08:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.566 X-Spam-Level: X-Spam-Status: No, score=-101.566 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 kcNQjVjMWTZ3; Fri, 16 Nov 2012 08:35:40 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE9D721F8777; Fri, 16 Nov 2012 08:35:39 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id hj6so1873655wib.13 for ; Fri, 16 Nov 2012 08:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TU1V+kSxTg6fj4LjO+FotVvXmrHWlwXUkHjUr4Asr3g=; b=Pe+O7GY4nJB0/oHTA9NqmQj/evjOjnlGJ5d+DJvEQAB8Gy4MptE3wgEglYsyhetsPw DjJHFwGkT+2F+juilKCkHBR512beVUVYsAjc6WmRcAm3eEkbhk6FpGjk82TzdEzz3Tfv +CAE1yDAN0RVSU4+2xDByma8GQaXZ0JXEoS/Ocjn280e/eZFMypa6MOdGSQHFQKbDw26 veYeynxklgBih9OrDfHoc2VaqTtoWYI/PTp411cyopY4VUWrH9NDBDmfWOLHdMCh/IPc tUkSErCuNIoYc0XiHP6q3hzwPBF1I6eyeviciovnzSlXpDclOA7D28kBxDOtKfmuzufv i3cg== Received: by 10.180.101.231 with SMTP id fj7mr3282247wib.4.1353083738698; Fri, 16 Nov 2012 08:35:38 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-111.as13285.net. [2.102.216.111]) by mx.google.com with ESMTPS id gz3sm1447499wib.2.2012.11.16.08.35.36 (version=SSLv3 cipher=OTHER); Fri, 16 Nov 2012 08:35:37 -0800 (PST) Message-ID: <50A66B67.5000609@gmail.com> Date: Fri, 16 Nov 2012 16:35:51 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Joel M. Halpern" References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> In-Reply-To: <50A66313.9090002@joelhalpern.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?Um9nZXIgSsO4cmdlbnNlbg==?= , ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 16:35:41 -0000 Joel, On 16/11/2012 16:00, Joel M. Halpern wrote: ... > With regard to interworking and deployment, there are a number of > documents that deal with that. They discuss what the currently > understood deployment incentives are, and what paths are currently seen. > (As Noel noted, this is an experiment, and one should expect that the > actual path will be different from the expectation.) Given that > interworkng dives are data plane devices, altruism is clearly not a > sufficient incentive to get this to scale, and the models do not depend > upon that. My concern with this allocation request was not about scaling but about black holes. What are the incentives for operators not very interested in LISP to carry the routes that make it work? That's the root of many of the problems with 6to4 (and, I think, many of the problems of the MBONE, for those with long memories). Regards Brian From jmh@joelhalpern.com Fri Nov 16 09:26:57 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697EC21F858E; Fri, 16 Nov 2012 09:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.253 X-Spam-Level: X-Spam-Status: No, score=-102.253 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 ty1RC+ay3Lw4; Fri, 16 Nov 2012 09:26:57 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 01AFF21F84FF; Fri, 16 Nov 2012 09:26:57 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id E734A558350; Fri, 16 Nov 2012 09:26:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id AC0EB1C0928; Fri, 16 Nov 2012 09:26:54 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-174.clppva.btas.verizon.net [71.161.50.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E78291C0751; Fri, 16 Nov 2012 09:26:53 -0800 (PST) Message-ID: <50A67758.8000001@joelhalpern.com> Date: Fri, 16 Nov 2012 12:26:48 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> In-Reply-To: <50A66B67.5000609@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 17:26:57 -0000 Why does any operator have a reason to carr any routes other than their paying customers? Because it provides connectivity for their customers. If we get this block allocaed, then it results in 1 extra routing entry in the global routing table to support LISP inter-working. An entry that some of their customers may use, whether the operator carrying it knows that or not. In fact, it would take significant extra work for the operator to somehow block this aggregate. If LISP fails, this is a small cost to find out. If LISP succeeds, this results in significant reduction in core tabl sizes for everyone. Yours, Joel On 11/16/2012 11:35 AM, Brian E Carpenter wrote: > Joel, > > On 16/11/2012 16:00, Joel M. Halpern wrote: > ... >> With regard to interworking and deployment, there are a number of >> documents that deal with that. They discuss what the currently >> understood deployment incentives are, and what paths are currently seen. >> (As Noel noted, this is an experiment, and one should expect that the >> actual path will be different from the expectation.) Given that >> interworkng dives are data plane devices, altruism is clearly not a >> sufficient incentive to get this to scale, and the models do not depend >> upon that. > > My concern with this allocation request was not about scaling > but about black holes. What are the incentives for operators not > very interested in LISP to carry the routes that make it work? > That's the root of many of the problems with 6to4 (and, I think, > many of the problems of the MBONE, for those with long memories). > > Regards > Brian > From sander@steffann.nl Fri Nov 16 13:13:15 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1410621F8B3B; Fri, 16 Nov 2012 13:13:15 -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 6zXFBpV9So6y; Fri, 16 Nov 2012 13:13:14 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id C11D221F8AF0; Fri, 16 Nov 2012 13:13:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 0477F2043; Fri, 16 Nov 2012 22:13:12 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvMxcuNnQb8n; Fri, 16 Nov 2012 22:12:55 +0100 (CET) Received: from [IPv6:2a00:8640:1::ac6c:1708:e194:c8c0] (unknown [IPv6:2a00:8640:1:0:ac6c:1708:e194:c8c0]) by mail.sintact.nl (Postfix) with ESMTP id E27362013; Fri, 16 Nov 2012 22:12:54 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <50A67758.8000001@joelhalpern.com> Date: Fri, 16 Nov 2012 22:12:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1499) Cc: lisp@ietf.org, Brian E Carpenter , ietf@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 21:13:15 -0000 Hi Joel, > Why does any operator have a reason to carr any routes other than = their paying customers? Because it provides connectivity for their = customers. > If we get this block allocaed, then it results in 1 extra routing = entry in the global routing table to support LISP inter-working. > An entry that some of their customers may use, whether the operator = carrying it knows that or not. >=20 > In fact, it would take significant extra work for the operator to = somehow block this aggregate. >=20 > If LISP fails, this is a small cost to find out. > If LISP succeeds, this results in significant reduction in core tabl = sizes for everyone. That still assumes the altruistic routing of the prefix. And I am afraid = that if the usage of this block gets a bad reputation that all LISP = usage will share that reputation. I really like LISP but I am still not = convinced that it's a good idea. If we can find a way to get the EID = prefix routed in a reliable way then I would love it! I really care about LISP and I am afraid that: people see unreliable = routing for EID /16 =3D> assume LISP is unreliable. That is why I am = pushing so hard to get this sorted out. Hmmm. What about the following strategy: - Start with the EID prefix being handed out like PI - Either through the RIRs if they are willing to take the = responsibility - Or from a separate registry - Some altruistic /16 PITRs might show up in the global BGP table - A holders of a (assume) /48 from the EID prefix can arrange PITRs for = their own space - And announce it as a separate route in the global BGP table (for = now) - Keep the routing and reliability under their own control - If the experiment is a success we advise ISPs to: - Install their own PITRs for the /16 - Filter out the /48s at their border The filtering of the more-specifics once they have their own PITRs will = make sure that they use those PITRs and that they will use the most = optimal path to the locators as soon as possible. It will also keep = their routing table smaller. If enough big transit providers offer /16 = PITRs to their customers then the more-specifics might be filtered on a = larger scale. So, summary: The ways to reach a PITR would be a) Run your own PITR (big networks, LISP users) b) Use one from your transit(s) (smaller networks that don't have their = own) c) Use an altruistic one as last resort As long as (a) and (b) aren't a reality the LISP users who don't want to = rely on (c) can run/rent/etc a PITR for their own space. I think the = routing community would really appreciate it if all those more-specific = routes would be temporary until wide deployment of (a) and (b) make them = unnecessary. And if this doesn't become a success we have a bunch of /48 prefixes to = the separate PITRs in the BGP table. It won't be much, otherwise we = would have declared success. So the risk of messing the BGP table up is = very limited. And when can tell people: if you are bothered by those = more-specifics in your routing table you can always deploy your own = PITRs and filter the more-specifics at your border. That might keep = everyone happy. What do you think? Thanks, Sander From jmh.direct@joelhalpern.com Fri Nov 16 13:19:21 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD5821F8B01; Fri, 16 Nov 2012 13:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 aDH9wqlfuOq2; Fri, 16 Nov 2012 13:19:20 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id C0AAD21F8AED; Fri, 16 Nov 2012 13:19:20 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 4BA6B559828; Fri, 16 Nov 2012 13:19:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id CDE5D1607E8; Fri, 16 Nov 2012 13:19:18 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-174.clppva.btas.verizon.net [71.161.50.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 96A841607E5; Fri, 16 Nov 2012 13:19:17 -0800 (PST) Message-ID: <50A6ADD0.3040000@joelhalpern.com> Date: Fri, 16 Nov 2012 16:19:12 -0500 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Sander Steffann References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> In-Reply-To: <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 16 Nov 2012 13:28:33 -0800 Cc: lisp@ietf.org, Brian E Carpenter , ietf@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 21:19:21 -0000 Most of what you describe Sander sounds reasonable, and sounds aligned with what is i the deployment documents. The WG debated the EID allocation extensively. One could argue that there is no need for it, that we could merely request that PI allocations be granted for LISP EID usage individually. The WG felt that if we could get all IPv6 LISP EID allocations from a single block that was not used for anything else, that would simplify avoiding lookups in the mapping system that were inevitably going to fail. Thus the allocations request. Yours, Joel On 11/16/2012 4:12 PM, Sander Steffann wrote: > Hi Joel, > >> Why does any operator have a reason to carr any routes other than their paying customers? Because it provides connectivity for their customers. >> If we get this block allocaed, then it results in 1 extra routing entry in the global routing table to support LISP inter-working. >> An entry that some of their customers may use, whether the operator carrying it knows that or not. >> >> In fact, it would take significant extra work for the operator to somehow block this aggregate. >> >> If LISP fails, this is a small cost to find out. >> If LISP succeeds, this results in significant reduction in core tabl sizes for everyone. > > That still assumes the altruistic routing of the prefix. And I am afraid that if the usage of this block gets a bad reputation that all LISP usage will share that reputation. I really like LISP but I am still not convinced that it's a good idea. If we can find a way to get the EID prefix routed in a reliable way then I would love it! > > I really care about LISP and I am afraid that: people see unreliable routing for EID /16 => assume LISP is unreliable. That is why I am pushing so hard to get this sorted out. > > Hmmm. What about the following strategy: > - Start with the EID prefix being handed out like PI > - Either through the RIRs if they are willing to take the responsibility > - Or from a separate registry > - Some altruistic /16 PITRs might show up in the global BGP table > - A holders of a (assume) /48 from the EID prefix can arrange PITRs for their own space > - And announce it as a separate route in the global BGP table (for now) > - Keep the routing and reliability under their own control > - If the experiment is a success we advise ISPs to: > - Install their own PITRs for the /16 > - Filter out the /48s at their border > > The filtering of the more-specifics once they have their own PITRs will make sure that they use those PITRs and that they will use the most optimal path to the locators as soon as possible. It will also keep their routing table smaller. If enough big transit providers offer /16 PITRs to their customers then the more-specifics might be filtered on a larger scale. > > So, summary: > > The ways to reach a PITR would be > a) Run your own PITR (big networks, LISP users) > b) Use one from your transit(s) (smaller networks that don't have their own) > c) Use an altruistic one as last resort > > As long as (a) and (b) aren't a reality the LISP users who don't want to rely on (c) can run/rent/etc a PITR for their own space. I think the routing community would really appreciate it if all those more-specific routes would be temporary until wide deployment of (a) and (b) make them unnecessary. > > And if this doesn't become a success we have a bunch of /48 prefixes to the separate PITRs in the BGP table. It won't be much, otherwise we would have declared success. So the risk of messing the BGP table up is very limited. And when can tell people: if you are bothered by those more-specifics in your routing table you can always deploy your own PITRs and filter the more-specifics at your border. That might keep everyone happy. > > What do you think? > > Thanks, > Sander > From farinacci@gmail.com Fri Nov 16 18:19:45 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC26B21F87E1; Fri, 16 Nov 2012 18:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 HR76zudq53G7; Fri, 16 Nov 2012 18:19:45 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 69B0821F85ED; Fri, 16 Nov 2012 18:19:45 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so2322103pbc.31 for ; Fri, 16 Nov 2012 18:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=nxqD2DppsvtAUYqVmLLkhk5b6A9YS99+ESasvATviXk=; b=ObDYvjQ/B6AnsC3Ub4A1wZUZlnrdombMj2BEbdC6BvicUA2Z7FDvnjwV1H+xGOu0W0 7IJT6PEmVhQdSi8ZVQMrgapcr4rOx1/mHONvYpLukxKFAsKjryFzmim9Yc0pwvLKYGCG ldZXTxsr+NsNX4QLk2CDOn3Rr8NwJLs80NKNmGUj3Svb+zPj5FRTlZAiJPJhTtKxxw9U AbtneqMP5sWZjMLsINI1tEiZUVKng4rRvQRCEMmfCG/wbiSlrxqmoKCt5mxrPqGMkVGG tGAaAUSSYzhvzajjiiNok7xLV/lL+SEtFm5oCDj5Jo6MaYEwFs8veNSowloeCIdZQZ+i SzCA== Received: by 10.66.88.136 with SMTP id bg8mr17983155pab.54.1353118785170; Fri, 16 Nov 2012 18:19:45 -0800 (PST) Received: from [192.168.1.6] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPS id se4sm2125554pbb.13.2012.11.16.18.19.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Nov 2012 18:19:43 -0800 (PST) References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> Mime-Version: 1.0 (1.0) In-Reply-To: <50A67758.8000001@joelhalpern.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <29234776-5E6B-4B21-9FB4-F7FA0989A6B0@gmail.com> X-Mailer: iPhone Mail (10A525) From: Dino Farinacci Date: Fri, 16 Nov 2012 18:19:42 -0800 To: "Joel M. Halpern" Cc: "lisp@ietf.org" , Brian E Carpenter , "ietf@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 02:19:46 -0000 Good points Joel. I completely agree.=20 Dino On Nov 16, 2012, at 9:26 AM, "Joel M. Halpern" wrote: > Why does any operator have a reason to carr any routes other than their pa= ying customers? Because it provides connectivity for their customers. > If we get this block allocaed, then it results in 1 extra routing entry in= the global routing table to support LISP inter-working. > An entry that some of their customers may use, whether the operator carryi= ng it knows that or not. >=20 > In fact, it would take significant extra work for the operator to somehow b= lock this aggregate. >=20 > If LISP fails, this is a small cost to find out. > If LISP succeeds, this results in significant reduction in core tabl sizes= for everyone. >=20 > Yours, > Joel >=20 > On 11/16/2012 11:35 AM, Brian E Carpenter wrote: >> Joel, >>=20 >> On 16/11/2012 16:00, Joel M. Halpern wrote: >> ... >>> With regard to interworking and deployment, there are a number of >>> documents that deal with that. They discuss what the currently >>> understood deployment incentives are, and what paths are currently seen.= >>> (As Noel noted, this is an experiment, and one should expect that the >>> actual path will be different from the expectation.) Given that >>> interworkng dives are data plane devices, altruism is clearly not a >>> sufficient incentive to get this to scale, and the models do not depend >>> upon that. >>=20 >> My concern with this allocation request was not about scaling >> but about black holes. What are the incentives for operators not >> very interested in LISP to carry the routes that make it work? >> That's the root of many of the problems with 6to4 (and, I think, >> many of the problems of the MBONE, for those with long memories). >>=20 >> Regards >> Brian >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From cb.list6@gmail.com Fri Nov 16 13:33:20 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEE121F852B; Fri, 16 Nov 2012 13:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0yxGYFKcMb1g; Fri, 16 Nov 2012 13:33:15 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E80221F84BC; Fri, 16 Nov 2012 13:33:14 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2595260lah.31 for ; Fri, 16 Nov 2012 13:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YzbCvrcext7rdVZtAjfQBi//dQ65PoWop9at0zUSR/c=; b=JmPQ7VUdRYPmo7OWb8jyB/fZ6RbehbOYfwOXwio2rzxBVXfiyjJFWiHy7ov/QYJLCJ KrYtyWSpxAZ+CmA0YbE2OyvciYR5ozeETMq0mg5QbYHOhwzSpF/a7nc+LZBLIoT68B2C D+tANt5VsdOheb+1Bp3gZFSDwZWaGXevQ5wzt+uBgEkVG7ZkCyF+2/ZBWujwHsIZgNFj 1RkV7MWVqTOZj1lA7NSX4W5lJc75QOlEB7DN2HVcHBYh+My1y5FQHeZOR6l8XOJJVw5h xNrPtTF3S26iZRGSJyToSQ1vfoidvvuLruQjTGm5A+Wz0rTDgvExxTcArzEsTQQYeHLs oQnA== MIME-Version: 1.0 Received: by 10.112.29.102 with SMTP id j6mr342970lbh.21.1353101593097; Fri, 16 Nov 2012 13:33:13 -0800 (PST) Received: by 10.112.81.167 with HTTP; Fri, 16 Nov 2012 13:33:12 -0800 (PST) Received: by 10.112.81.167 with HTTP; Fri, 16 Nov 2012 13:33:12 -0800 (PST) In-Reply-To: <50A67758.8000001@joelhalpern.com> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> Date: Fri, 16 Nov 2012 13:33:12 -0800 Message-ID: From: Cameron Byrne To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=f46d04016815cd363804cea383c9 X-Mailman-Approved-At: Sat, 17 Nov 2012 08:24:31 -0800 Cc: ietf@ietf.org, lisp@ietf.org, Brian E Carpenter Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 21:33:20 -0000 --f46d04016815cd363804cea383c9 Content-Type: text/plain; charset=ISO-8859-1 On Nov 16, 2012 9:27 AM, "Joel M. Halpern" wrote: > > Why does any operator have a reason to carr any routes other than their paying customers? Because it provides connectivity for their customers. > If we get this block allocaed, then it results in 1 extra routing entry in the global routing table to support LISP inter-working. > An entry that some of their customers may use, whether the operator carrying it knows that or not. > > In fact, it would take significant extra work for the operator to somehow block this aggregate. > > If LISP fails, this is a small cost to find out. > If LISP succeeds, this results in significant reduction in core tabl sizes for everyone. > Not everyone. Only people who carry core tables. That is LISP twist, it transfers cost from a few cores to many edges. Associated pros and cons exist. CB > Yours, > Joel > > > On 11/16/2012 11:35 AM, Brian E Carpenter wrote: >> >> Joel, >> >> On 16/11/2012 16:00, Joel M. Halpern wrote: >> ... >>> >>> With regard to interworking and deployment, there are a number of >>> documents that deal with that. They discuss what the currently >>> understood deployment incentives are, and what paths are currently seen. >>> (As Noel noted, this is an experiment, and one should expect that the >>> actual path will be different from the expectation.) Given that >>> interworkng dives are data plane devices, altruism is clearly not a >>> sufficient incentive to get this to scale, and the models do not depend >>> upon that. >> >> >> My concern with this allocation request was not about scaling >> but about black holes. What are the incentives for operators not >> very interested in LISP to carry the routes that make it work? >> That's the root of many of the problems with 6to4 (and, I think, >> many of the problems of the MBONE, for those with long memories). >> >> Regards >> Brian >> --f46d04016815cd363804cea383c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 16, 2012 9:27 AM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:
>
> Why does any operator have a reason to carr any routes other than thei= r paying customers? =A0Because it provides connectivity for their customers= .
> If we get this block allocaed, then it results in 1 extra routing entr= y in the global routing table to support LISP inter-working.
> An entry that some of their customers may use, whether the operator ca= rrying it knows that or not.
>
> In fact, it would take significant extra work for the operator to some= how block this aggregate.
>
> If LISP fails, this is a small cost to find out.
> If LISP succeeds, this results in significant reduction in core tabl s= izes for everyone.
>

Not everyone. Only people who carry core tables.=A0 That is = LISP twist, it transfers cost from a few cores to many edges. Associated pr= os and cons exist.

CB
> Yours,
> Joel
>
>
> On 11/16/2012 11:35 AM, Brian E Carpenter wrote:
>>
>> Joel,
>>
>> On 16/11/2012 16:00, Joel M. Halpern wrote:
>> ...
>>>
>>> With regard to interworking and deployment, there are a number= of
>>> documents that deal with that. =A0They discuss what the curren= tly
>>> understood deployment incentives are, and what paths are curre= ntly seen.
>>> =A0 =A0(As Noel noted, this is an experiment, and one should e= xpect that the
>>> actual path will be different from the expectation.) =A0Given = that
>>> interworkng dives are data plane devices, altruism is clearly = not a
>>> sufficient incentive to get this to scale, and the models do n= ot depend
>>> upon that.
>>
>>
>> My concern with this allocation request was not about scaling
>> but about black holes. What are the incentives for operators not >> very interested in LISP to carry the routes that make it work?
>> That's the root of many of the problems with 6to4 (and, I thin= k,
>> many of the problems of the MBONE, for those with long memories).<= br> >>
>> Regards
>> =A0 =A0 =A0Brian
>>

--f46d04016815cd363804cea383c9-- From jnc@mercury.lcs.mit.edu Sat Nov 17 09:12:40 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54DB21F84E7; Sat, 17 Nov 2012 09:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 JWhOpIoqGT9c; Sat, 17 Nov 2012 09:12:40 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5292E21F84DF; Sat, 17 Nov 2012 09:12:39 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id E4A4118C08F; Sat, 17 Nov 2012 12:12:38 -0500 (EST) To: ietf@ietf.org, lisp@ietf.org Message-Id: <20121117171238.E4A4118C08F@mercury.lcs.mit.edu> Date: Sat, 17 Nov 2012 12:12:38 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 17:12:41 -0000 > From: Cameron Byrne >> If LISP succeeds, this results in significant reduction in core table >> sizes for everyone. > Not everyone. Only people who carry core tables. 'this results in significant reduction in core table sizes for everyone who has core tables' sounds a bit tautological, no? > That is LISP twist, it transfers cost from a few cores to many edges. If you define 'many' is 'people who are actually trying to communicate with a given site', yes. So it has transferred costs for communicating with site X from 'everyone with a core table, everywhere in the entire network' to 'just the people who are actually trying to communicate with site X'. This is bad... how? (When I first quickly read your message, I thought you were making a point about the routing overhead of EIDs being carried in the global routing tables for use by legacy sites, which is an interesting point, but not the one that you make here.) Noel From farinacci@gmail.com Sat Nov 17 09:51:56 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C95521F84EE; Sat, 17 Nov 2012 09:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 HthN7hc+plVK; Sat, 17 Nov 2012 09:51:55 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B932721F86B9; Sat, 17 Nov 2012 09:51:55 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so2601168pbc.31 for ; Sat, 17 Nov 2012 09:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=1r6u/ovuhbgwRDZaS1zKYKBjTjl97TZy2DS94W8WfrA=; b=RRPEhYkBTWVZ2ptZ6ueW0sAv7RbcQTZyNTtDlkEKQGtn+h24Aq0InQWNFqtZHxjHT0 BZ1wzFYuxbrgAwXqloGkO3QNAJsTIQgrds/34a/71FYPKWCT3plMsSluLB2ZecaT250A HYS06SXmhMqUeUTpfRk9l6z6eVWNLeZSOCyDFmOdn+vy3I5aasVBuf4ouB6eOtaWZ0IQ 1+Hir62nXglETeD9GgSWcwZ5w5WKfsEW/ww827QzECxKeaaZjZgmbkPqioTPzasAJYmG SwQD4q6xJrVBWR61zRQ8xqtLHMHeUlKmYSZE1puGm5pIhGdqn8xcSnHEfL9DS8PrWobA 8Pjg== Received: by 10.68.253.4 with SMTP id zw4mr20069978pbc.143.1353174715243; Sat, 17 Nov 2012 09:51:55 -0800 (PST) Received: from [10.21.72.78] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id gu5sm3219792pbc.10.2012.11.17.09.51.52 (version=SSLv3 cipher=OTHER); Sat, 17 Nov 2012 09:51:54 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <50A61A97.9060005@lacnic.net> Date: Sat, 17 Nov 2012 09:51:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7999F86A-5842-4BAE-A68D-8F783F50CA2C@gmail.com> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> <37436188-2E53-40DC-839F-AC52E5CA8188@apnic.net> <766205F6-48FB-4962-9F43-EDCACC73D1DA@gmail.com> <149720A8-FC8D-4BD0-9A7A-0EB42E8CCE75@apnic.net> <50A61A97.9060005@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1499) Cc: "ietf@ietf.org list" , "lisp@ietf.org list" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 17:51:56 -0000 > Dino, >=20 > +1 In LACNIC, may 6th to 10th 2013 in Medellin Colombia. Will consider Singapore and Medellin. > I am not the policiy guy but I can get you time in the technical = and > policy plenaries and assit you in the discussion. >=20 > Also, if you plan to write some text about the allocation = mechanics let > me know, I will be happy to help to review, comment and even write = some > text if that is useful for lisp. Thanks for the offer. Dino >=20 > Regards, > as >=20 > On 16/11/2012 08:18, Sander Steffann wrote: >> Hi Dino, >>=20 >>> George: >>>> Maybe this is something you could come to an RIR meeting and = present on or discuss? We've got an APNIC/APRICOT coming up early in = 2013 and I am sure you'd be welcomed to submit some content. Its good to = talk about these things. >>=20 >> +1 >>=20 >> Let's make it official :-) >>=20 >> It would be very good to discuss this idea in the RIR communities. I = think both the LISP community and the RIR communities can learn from = each other. As co-chair of the RIPE Address Policy Working Group I would = really appreciate it if you could come to the next RIPE meeting to = discuss this. I'll make sure that there is a slot on the working group = agenda. RIPE 66 will take place from 13-17 May 2013 at the Burlington = Hotel in Dublin. >>=20 >> Thanks, >> Sander >>=20 From gih@apnic.net Sat Nov 17 22:21:14 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC7621F850D; Sat, 17 Nov 2012 22:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.891 X-Spam-Level: X-Spam-Status: No, score=-100.891 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] 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 r-oLm7xr8+vl; Sat, 17 Nov 2012 22:21:11 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 0283721F8501; Sat, 17 Nov 2012 22:21:09 -0800 (PST) Received: from [192.168.51.200] (unknown [87.213.29.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 3CA39B684D; Sun, 18 Nov 2012 16:21:03 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Geoff Huston In-Reply-To: <50A6ADD0.3040000@joelhalpern.com> Date: Sun, 18 Nov 2012 17:20:58 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <45813A84-7BE9-4D21-AE3E-F3401D6E1B50@apnic.net> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> <50A6ADD0.3040000@joelhalpern.com> To: Joel Halpern Direct X-Mailer: Apple Mail (2.1499) Cc: ietf@ietf.org, lisp@ietf.org, Brian E Carpenter Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 06:21:14 -0000 But why request the reservation of a /12? Or even a /16 for that matter? If the LISP experimental deployers have filled a /32 with /48 prefixes = then should this imply that the experiment is all over over and its time = to recast this not as an experiment but as an application which = requires global unicast address allocations, and proceed along those = grounds? Indeed if the entire point of this experimental use allocation request = is on the basis that at the time when deployment numbers are = sufficiently large (orders of millions of end sites presumably) then = this block allocation will have some beneficial effects. But thats NOT = an experimental justification. So what is this request? Experimental? Planning for large scale = deployment? If its the latter than I do not understand how this draft, calling for a = allocation from the IANA special purpose address registry on the grounds = of supporting an IETF experimental activity, can be supported by the = existing processes. The IANA Special purpose address registry and RFC = 4773 do not encompass the allocation of address blocks for use in a = global unicast address context in the context of large scale deployment = activities. If its the former then the scale of the allocation is unwarranted. The = broad characterisation of the experiment allocation is to test concepts, = and if that's the case then once the "test" is over what are the plans = to migrate OUT of the "test" allocation and support unicast global = address allocations in the context of LISP under the general framework = of RFC2860 and RFC 2050? What is the scale of this "test"? When would = the "test" be completed? I think this draft is not well thought through and the draft's proposals = for address allocation from the IANA Special Purpose Address Registry = is inconsistent with the processes we use for management of addresses in = the IETF. I do not support the publication of this draft. regards, Geoff On 17/11/2012, at 8:19 AM, Joel Halpern Direct = wrote: > Most of what you describe Sander sounds reasonable, and sounds aligned = with what is i the deployment documents. >=20 > The WG debated the EID allocation extensively. One could argue that = there is no need for it, that we could merely request that PI = allocations be granted for LISP EID usage individually. The WG felt = that if we could get all IPv6 LISP EID allocations from a single block = that was not used for anything else, that would simplify avoiding = lookups in the mapping system that were inevitably going to fail. Thus = the allocations request. >=20 > Yours, > Joel >=20 > On 11/16/2012 4:12 PM, Sander Steffann wrote: >> Hi Joel, >>=20 >>> Why does any operator have a reason to carr any routes other than = their paying customers? Because it provides connectivity for their = customers. >>> If we get this block allocaed, then it results in 1 extra routing = entry in the global routing table to support LISP inter-working. >>> An entry that some of their customers may use, whether the operator = carrying it knows that or not. >>>=20 >>> In fact, it would take significant extra work for the operator to = somehow block this aggregate. >>>=20 >>> If LISP fails, this is a small cost to find out. >>> If LISP succeeds, this results in significant reduction in core tabl = sizes for everyone. >>=20 >> That still assumes the altruistic routing of the prefix. And I am = afraid that if the usage of this block gets a bad reputation that all = LISP usage will share that reputation. I really like LISP but I am still = not convinced that it's a good idea. If we can find a way to get the EID = prefix routed in a reliable way then I would love it! >>=20 >> I really care about LISP and I am afraid that: people see unreliable = routing for EID /16 =3D> assume LISP is unreliable. That is why I am = pushing so hard to get this sorted out. >>=20 >> Hmmm. What about the following strategy: >> - Start with the EID prefix being handed out like PI >> - Either through the RIRs if they are willing to take the = responsibility >> - Or from a separate registry >> - Some altruistic /16 PITRs might show up in the global BGP table >> - A holders of a (assume) /48 from the EID prefix can arrange PITRs = for their own space >> - And announce it as a separate route in the global BGP table (for = now) >> - Keep the routing and reliability under their own control >> - If the experiment is a success we advise ISPs to: >> - Install their own PITRs for the /16 >> - Filter out the /48s at their border >>=20 >> The filtering of the more-specifics once they have their own PITRs = will make sure that they use those PITRs and that they will use the most = optimal path to the locators as soon as possible. It will also keep = their routing table smaller. If enough big transit providers offer /16 = PITRs to their customers then the more-specifics might be filtered on a = larger scale. >>=20 >> So, summary: >>=20 >> The ways to reach a PITR would be >> a) Run your own PITR (big networks, LISP users) >> b) Use one from your transit(s) (smaller networks that don't have = their own) >> c) Use an altruistic one as last resort >>=20 >> As long as (a) and (b) aren't a reality the LISP users who don't want = to rely on (c) can run/rent/etc a PITR for their own space. I think the = routing community would really appreciate it if all those more-specific = routes would be temporary until wide deployment of (a) and (b) make them = unnecessary. >>=20 >> And if this doesn't become a success we have a bunch of /48 prefixes = to the separate PITRs in the BGP table. It won't be much, otherwise we = would have declared success. So the risk of messing the BGP table up is = very limited. And when can tell people: if you are bothered by those = more-specifics in your routing table you can always deploy your own = PITRs and filter the more-specifics at your border. That might keep = everyone happy. >>=20 >> What do you think? >>=20 >> Thanks, >> Sander >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From heinerhummel@aol.com Sun Nov 18 00:40:20 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C5B21F84B9 for ; Sun, 18 Nov 2012 00:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 AgVoppQsGlxp for ; Sun, 18 Nov 2012 00:40:15 -0800 (PST) Received: from imr-ma03.mx.aol.com (imr-ma03.mx.aol.com [64.12.206.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9508B21F84C2 for ; Sun, 18 Nov 2012 00:40:15 -0800 (PST) Received: from mtaomg-mb05.r1000.mx.aol.com (mtaomg-mb05.r1000.mx.aol.com [172.29.41.76]) by imr-ma03.mx.aol.com (8.14.1/8.14.1) with ESMTP id qAI8e0wp009889; Sun, 18 Nov 2012 03:40:00 -0500 Received: from core-dqd004c.r1000.mail.aol.com (core-dqd004.r1000.mail.aol.com [172.29.162.13]) by mtaomg-mb05.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id E9A9AE000081; Sun, 18 Nov 2012 03:39:59 -0500 (EST) References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> <50A6ADD0.3040000@joelhalpern.com> <45813A84-7BE9-4D21-AE3E-F3401D6E1B50@apnic.net> To: gih@apnic.net, jmh.direct@joelhalpern.com In-Reply-To: <45813A84-7BE9-4D21-AE3E-F3401D6E1B50@apnic.net> X-MB-Message-Source: WebUI Received: from 178.27.21.1 by webmail-d037.sysops.aol.com (205.188.181.88) with HTTP (WebMailUI); Sun, 18 Nov 2012 03:39:59 -0500 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CF937F6DE25FD2_D74_822A9_webmail-d037.sysops.aol.com" X-Mailer: Webmail 37185-STANDARD Message-Id: <8CF937F6DCF54D2-D74-23EDD@webmail-d037.sysops.aol.com> X-Originating-IP: [178.27.21.1] Date: Sun, 18 Nov 2012 03:39:59 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1353228000; bh=jEKxeI5A8nXZ5F6d6vtqG79Nt1EFk3MSroTdlK4ADBU=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=FJ0U2cV3271QLKTh67gtUudbOeRPkPzReO/h7MnNEyo6EDoHiFcK5GxzQu5zBA6ZR vB4v0HRXGLI3nDdTRtm8ktCnSPss6Wn6rKJTmdiubbE40vhgzbYkBnH2hxzRsZCV4H MzLnJZDQDe5Nd87Gy0KtyZRJXthsr83yRHzD2J7c= X-AOL-SCOLL-SCORE: 0:2:475858752:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d294c50a89edf1a42 Cc: brian.e.carpenter@gmail.com, ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 08:40:20 -0000 This is a multi-part message in MIME format. ----------MB_8CF937F6DE25FD2_D74_822A9_webmail-d037.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" And: LISP does neither describe how to cope with the address depletion issue nor= prove that it is able to. Imho, there is not even the slightest chance not to fail. Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Geoff Huston An: Joel Halpern Direct Cc: ietf ; lisp ; Brian E Carpenter Verschickt: So, 18 Nov 2012 7:22 am Betreff: Re: [lisp] Last Call: (LISP EID= Block) to Informational RFC But why request the reservation of a /12? Or even a /16 for that matter? If the LISP experimental deployers have filled a /32 with /48 prefixes then= =20 should this imply that the experiment is all over over and its time to reca= st =20 this not as an experiment but as an application which requires global unica= st=20 address allocations, and proceed along those grounds? Indeed if the entire point of this experimental use allocation request is o= n the=20 basis that at the time when deployment numbers are sufficiently large (orde= rs of=20 millions of end sites presumably) then this block allocation will have some= =20 beneficial effects. But thats NOT an experimental justification. So what is this request? Experimental? Planning for large scale deployment? If its the latter than I do not understand how this draft, calling for a=20 allocation from the IANA special purpose address registry on the grounds of= =20 supporting an IETF experimental activity, can be supported by the existing= =20 processes. The IANA Special purpose address registry and RFC 4773 do not=20 encompass the allocation of address blocks for use in a global unicast addr= ess=20 context in the context of large scale deployment activities. If its the former then the scale of the allocation is unwarranted. The broa= d=20 characterisation of the experiment allocation is to test concepts, and if t= hat's=20 the case then once the "test" is over what are the plans to migrate OUT of = the=20 "test" allocation and support unicast global address allocations in the con= text=20 of LISP under the general framework of RFC2860 and RFC 2050? What is the sc= ale=20 of this "test"? When would the "test" be completed? I think this draft is not well thought through and the draft's proposals fo= r=20 address allocation from the IANA Special Purpose Address Registry is=20 inconsistent with the processes we use for management of addresses in the I= ETF.=20 I do not support the publication of this draft. regards, Geoff On 17/11/2012, at 8:19 AM, Joel Halpern Direct = =20 wrote: > Most of what you describe Sander sounds reasonable, and sounds aligned wi= th=20 what is i the deployment documents. >=20 > The WG debated the EID allocation extensively. One could argue that ther= e is=20 no need for it, that we could merely request that PI allocations be granted= for=20 LISP EID usage individually. The WG felt that if we could get all IPv6 LIS= P EID=20 allocations from a single block that was not used for anything else, that w= ould=20 simplify avoiding lookups in the mapping system that were inevitably going = to=20 fail. Thus the allocations request. >=20 > Yours, > Joel >=20 > On 11/16/2012 4:12 PM, Sander Steffann wrote: >> Hi Joel, >>=20 >>> Why does any operator have a reason to carr any routes other than their= =20 paying customers? Because it provides connectivity for their customers. >>> If we get this block allocaed, then it results in 1 extra routing entry= in=20 the global routing table to support LISP inter-working. >>> An entry that some of their customers may use, whether the operator car= rying=20 it knows that or not. >>>=20 >>> In fact, it would take significant extra work for the operator to someh= ow=20 block this aggregate. >>>=20 >>> If LISP fails, this is a small cost to find out. >>> If LISP succeeds, this results in significant reduction in core tabl si= zes=20 for everyone. >>=20 >> That still assumes the altruistic routing of the prefix. And I am afraid= that=20 if the usage of this block gets a bad reputation that all LISP usage will s= hare=20 that reputation. I really like LISP but I am still not convinced that it's = a=20 good idea. If we can find a way to get the EID prefix routed in a reliable = way=20 then I would love it! >>=20 >> I really care about LISP and I am afraid that: people see unreliable rou= ting=20 for EID /16 =3D> assume LISP is unreliable. That is why I am pushing so har= d to=20 get this sorted out. >>=20 >> Hmmm. What about the following strategy: >> - Start with the EID prefix being handed out like PI >> - Either through the RIRs if they are willing to take the responsibili= ty >> - Or from a separate registry >> - Some altruistic /16 PITRs might show up in the global BGP table >> - A holders of a (assume) /48 from the EID prefix can arrange PITRs for = their=20 own space >> - And announce it as a separate route in the global BGP table (for now= ) >> - Keep the routing and reliability under their own control >> - If the experiment is a success we advise ISPs to: >> - Install their own PITRs for the /16 >> - Filter out the /48s at their border >>=20 >> The filtering of the more-specifics once they have their own PITRs will = make=20 sure that they use those PITRs and that they will use the most optimal path= to=20 the locators as soon as possible. It will also keep their routing table sma= ller.=20 If enough big transit providers offer /16 PITRs to their customers then the= =20 more-specifics might be filtered on a larger scale. >>=20 >> So, summary: >>=20 >> The ways to reach a PITR would be >> a) Run your own PITR (big networks, LISP users) >> b) Use one from your transit(s) (smaller networks that don't have their = own) >> c) Use an altruistic one as last resort >>=20 >> As long as (a) and (b) aren't a reality the LISP users who don't want to= rely=20 on (c) can run/rent/etc a PITR for their own space. I think the routing=20 community would really appreciate it if all those more-specific routes woul= d be=20 temporary until wide deployment of (a) and (b) make them unnecessary. >>=20 >> And if this doesn't become a success we have a bunch of /48 prefixes to = the=20 separate PITRs in the BGP table. It won't be much, otherwise we would have= =20 declared success. So the risk of messing the BGP table up is very limited. = And=20 when can tell people: if you are bothered by those more-specifics in your= =20 routing table you can always deploy your own PITRs and filter the more-spec= ifics=20 at your border. That might keep everyone happy. >>=20 >> What do you think? >>=20 >> Thanks, >> Sander >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp =20 ----------MB_8CF937F6DE25FD2_D74_822A9_webmail-d037.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" And:
LISP does neither describe how to cope with the address depletion issu= e nor prove that it is able to.

Imho, there is not even the slightest chance not to fail.

Heiner


-----= Urspr=C3=BCngliche Mitteilung-----
Von: Geoff Huston <gih@apnic.net>
An: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Cc: ietf <ietf@ietf.org>; lisp <lisp@ietf.org>; Brian E Carpent= er <brian.e.carpenter@gmail.com>
Verschickt: So, 18 Nov 2012 7:22 am
Betreff: Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LI= SP EID Block) to Informational RFC

But why request the reservation of a /12=
? Or even a /16 for that matter?

If the LISP experimental deployers have filled a /32 with /48 prefixes then=
=20
should this imply that the experiment is all over over and its time to reca=
st =20
this not as an experiment but as an application which requires global unica=
st=20
address allocations, and proceed along those grounds?

Indeed if the entire point of this experimental use allocation request is o=
n the=20
basis that at the time when deployment numbers are sufficiently large (orde=
rs of=20
millions of end sites presumably) then this block allocation will have some=
=20
beneficial effects. But thats NOT an experimental justification.

So what is this request? Experimental? Planning for large scale deployment?

If its the latter than I do not understand how this draft, calling for a=20
allocation from the IANA special purpose address registry on the grounds of=
=20
supporting an IETF experimental activity, can be supported by the existing=
=20
processes. The IANA Special purpose address registry and RFC 4773 do not=20
encompass the allocation of address blocks for use in a global unicast addr=
ess=20
context in the context of large scale deployment activities.

If its the former then the scale of the allocation is unwarranted. The broa=
d=20
characterisation of the experiment allocation is to test concepts, and if t=
hat's=20
the case then once the "test" is over what are the plans to migrate OUT of =
the=20
"test" allocation and support unicast global address allocations in the con=
text=20
of LISP under the general framework of RFC2860 and RFC 2050? What is the sc=
ale=20
of this "test"? When would the "test" be completed?

I think this draft is not well thought through and the draft's proposals fo=
r=20
address allocation from the IANA Special Purpose Address Registry  is=20
inconsistent with the processes we use for management of addresses in the I=
ETF.=20
I do not support the publication of this draft.

regards,

   Geoff




On 17/11/2012, at 8:19 AM, Joel Halpern Direct <jmh.direct@joelhalpern.com>=20
wrote:

> Most of what you describe Sander sounds reasonable, and sounds aligned=
 with=20
what is i the deployment documents.
>=20
> The WG debated the EID allocation extensively.  One could argue that t=
here is=20
no need for it, that we could merely request that PI allocations be granted=
 for=20
LISP EID usage individually.  The WG felt that if we could get all IPv6 LIS=
P EID=20
allocations from a single block that was not used for anything else, that w=
ould=20
simplify avoiding lookups in the mapping system that were inevitably going =
to=20
fail.  Thus the allocations request.
>=20
> Yours,
> Joel
>=20
> On 11/16/2012 4:12 PM, Sander Steffann wrote:
>> Hi Joel,
>>=20
>>> Why does any operator have a reason to carr any routes other t=
han their=20
paying customers?  Because it provides connectivity for their customers.
>>> If we get this block allocaed, then it results in 1 extra rout=
ing entry in=20
the global routing table to support LISP inter-working.
>>> An entry that some of their customers may use, whether the ope=
rator carrying=20
it knows that or not.
>>>=20
>>> In fact, it would take significant extra work for the operator=
 to somehow=20
block this aggregate.
>>>=20
>>> If LISP fails, this is a small cost to find out.
>>> If LISP succeeds, this results in significant reduction in cor=
e tabl sizes=20
for everyone.
>>=20
>> That still assumes the altruistic routing of the prefix. And I am =
afraid that=20
if the usage of this block gets a bad reputation that all LISP usage will s=
hare=20
that reputation. I really like LISP but I am still not convinced that it's =
a=20
good idea. If we can find a way to get the EID prefix routed in a reliable =
way=20
then I would love it!
>>=20
>> I really care about LISP and I am afraid that: people see unreliab=
le routing=20
for EID /16 =3D> assume LISP is unreliable. That is why I am pushing so =
hard to=20
get this sorted out.
>>=20
>> Hmmm. What about the following strategy:
>> - Start with the EID prefix being handed out like PI
>>   - Either through the RIRs if they are willing to take the respon=
sibility
>>   - Or from a separate registry
>> - Some altruistic /16 PITRs might show up in the global BGP table
>> - A holders of a (assume) /48 from the EID prefix can arrange PITR=
s for their=20
own space
>>   - And announce it as a separate route in the global BGP table (f=
or now)
>>   - Keep the routing and reliability under their own control
>> - If the experiment is a success we advise ISPs to:
>>   - Install their own PITRs for the /16
>>   - Filter out the /48s at their border
>>=20
>> The filtering of the more-specifics once they have their own PITRs=
 will make=20
sure that they use those PITRs and that they will use the most optimal path=
 to=20
the locators as soon as possible. It will also keep their routing table sma=
ller.=20
If enough big transit providers offer /16 PITRs to their customers then the=
=20
more-specifics might be filtered on a larger scale.
>>=20
>> So, summary:
>>=20
>> The ways to reach a PITR would be
>> a) Run your own PITR (big networks, LISP users)
>> b) Use one from your transit(s) (smaller networks that don't have =
their own)
>> c) Use an altruistic one as last resort
>>=20
>> As long as (a) and (b) aren't a reality the LISP users who don't w=
ant to rely=20
on (c) can run/rent/etc a PITR for their own space. I think the routing=20
community would really appreciate it if all those more-specific routes woul=
d be=20
temporary until wide deployment of (a) and (b) make them unnecessary.
>>=20
>> And if this doesn't become a success we have a bunch of /48 prefix=
es to the=20
separate PITRs in the BGP table. It won't be much, otherwise we would have=
=20
declared success. So the risk of messing the BGP table up is very limited. =
And=20
when can tell people: if you are bothered by those more-specifics in your=
=20
routing table you can always deploy your own PITRs and filter the more-spec=
ifics=20
at your border. That might keep everyone happy.
>>=20
>> What do you think?
>>=20
>> Thanks,
>> Sander
>>=20
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
gih@apnic.net




_______________________________________________
lisp mailing list
lisp@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/lisp
----------MB_8CF937F6DE25FD2_D74_822A9_webmail-d037.sysops.aol.com-- From gih@apnic.net Tue Nov 20 22:17:10 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A6F21F880A; Tue, 20 Nov 2012 22:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.695 X-Spam-Level: X-Spam-Status: No, score=-98.695 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Bb8gMmqeqZKU; Tue, 20 Nov 2012 22:17:09 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 2504D21F8808; Tue, 20 Nov 2012 22:17:08 -0800 (PST) Received: from [192.168.51.200] (unknown [87.213.29.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 5418CB6840; Wed, 21 Nov 2012 16:17:03 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Geoff Huston In-Reply-To: <45813A84-7BE9-4D21-AE3E-F3401D6E1B50@apnic.net> Date: Wed, 21 Nov 2012 17:16:58 +1100 Content-Transfer-Encoding: 7bit Message-Id: <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> <50A6ADD0.3040000@joelhalpern.com> <45813A84-7BE9-4D21-AE3E-F3401D6E1B50@apnic.net> To: "ietf@ietf.org List" X-Mailer: Apple Mail (2.1499) Cc: Paul Wilson , John Curran , lisp@ietf.org, "iesg@ietf.org IESG" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 06:17:10 -0000 Hi, We would like to make the following comments in response to the IETF Last Call on the proposal to publish this draft as an Informational RFC. The guidelines for IP address allocations were documented in RFC2050, adopted in November 1996 as a Best Current Practice. This document described the framework of the Internet Registry system, and the roles and responsibilities of various parties involved in the distribution of addresses in the Internet. The document was not intentionally related to any particular routing technology, and addressed guidelines that would maximise the effective use of address space. The Memorandum of Understanding between the IETF and ICANN over the IANA activity, RFC2860, published in June 2000, provides further details of the address management function. In particular, the document notes that "assignments of specialised address blocks (such as multicast or anycast blocks), and experimental assignments are not considered to be policy issues, and shall remain subject to the provisions of this [document]." RFC 4773, published in December 2006, provides some guidelines to the IANA concerning the management of these specialised address assignments in IPv6: "IANA may undertake IPv6 address designations in support of special purposes as requested in "IANA Considerations" sections in IESG- reviewed RFCs, where an address is requested with an intended use of the designated address block for the purpose of testing or experimental usage activities initiated by IETF, or for specialised use of the address block in a context (e.g., anycast) associated with an Internet Standards track protocol." In this context the request to IANA to reserve an IPv6 /12 address and allocate out of it a /16 block for use as an EID space for the experimental LISP protocol presents some questions. It is noted that the LISP experiment already makes use of a /32 prefix, "with more than 250 sites using a /48 sub prefix", as noted in draft-ietf-lisp-eid-block-03.txt. Even with an overall 50% utilisation rate of this prefix there is scope in the current /32 address block to address some 32,000 further sites using a /48 sub prefix. If the LISP experiment fills this /32 prefix to such a level of utilisation then there would be reasonable grounds to make the case that at such a time the LISP activity would no longer be an experimental effort, as it would be an instance of an application that makes use of the global unicast address pool. In this case the provisions of RFC 4773, and the applicability of a special purpose address allocation would not be expected to apply, as this would fall under the terms of RFC2050 and the address allocation function would be administered by the Regional internet Registries, according to RFC2860. If we were to consider this request for the reservation of a /12 and the allocation of a /16 in the context of support for an experiment, then the nature of the experiment is unclear. At the scale of a /16 being capable of supporting a theoretical maximum of some 4.3 billion /48 end sites, and a /12 supporting a theoretical maximum of 68.7 billion /48 end sites, then the boundary conditions of such an experiment become challenging to define. How can one define the experiment to have finished? What are the plans to migrate out of the experimental address allocation? Would this renumbering out of an experimental address allocation even be feasible to contemplate if the experiment achieves a level of deployment that is commensurate with the allocation of /16? Such large scale deployment activities being undertaken under the provisions of an experimental activity also raises a number of questions about the registry services to be provided in support of such a reservation. Given that this particular experiment is intended to operate on the global IPv6 Internet it is apparent that some form of directory (e.g. Whois) and reverse DNS services will be necessary; is the provision of such services on a large scale (i.e. for potentially tens of thousands of individual entities) to be performed by the IANA? If so then this appears contrary to RFC 4773's statement that the "IANA will not maintain further sub-registries for any special purpose address block designated according to this direction." Further, the implementation of any large scale directory such as resulting from this type of experimental reservation would definitely pose serious policy issues, e.g. trading off operational visibility, privacy, and law enforcement needs, and by the spirit of the IETF/ICANN MOU on IANA activities (RFC 2860). It would appear from this perspective that such an assignment of address resources is not suitable to be made as an experimental assignment. The question this draft raises is to identify the basis of the request. An experimental allocation of this size does not appear to be consistent with a conventional view of an experiment. The draft's proposals appear more aligned to the activity of planning for large scale public deployment of a global routing infrastructure for global unicast addresses. But if that is indeed the case then the provisions of RFC4773 do not apply, as the special Purpose Address Allocation Registry does not encompass the allocation of address blocks for use in a global unicast address context in the context of large scale deployment activities. A possible course of action for the LISP Working Group and the IESG to consider would be for the existing /32 address be documented as an IANA Special Purpose Address allocation for use in supporting the current LISP experiment, and for the LISP advocates to make their case for particular requirements in the handling of global unicast address allocations in IPv6 to the regional addressing communities. This would allow the existing address policy development process to generate outcomes that appropriately address the desires and concerns of the broader community of stakeholders in supporting the potential requirements of a broad base of deployment of LISP in the Internet's routing environment. We do not support the publication of this draft as an Informational RFC. regards, John Curran, Paul Wilson, and Geoff Huston From sander@steffann.nl Wed Nov 21 03:21:52 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E6E21F85C1; Wed, 21 Nov 2012 03:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] 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 g0v8btdhvYNq; Wed, 21 Nov 2012 03:21:52 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id EE87D21F85B0; Wed, 21 Nov 2012 03:21:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id DF86F2063; Wed, 21 Nov 2012 12:21:49 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrLF4SzieQ6T; Wed, 21 Nov 2012 12:21:46 +0100 (CET) Received: from [IPv6:2a00:8640:1::bc78:afc:293b:85a0] (unknown [IPv6:2a00:8640:1:0:bc78:afc:293b:85a0]) by mail.sintact.nl (Postfix) with ESMTP id 76C882009; Wed, 21 Nov 2012 12:21:41 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> Date: Wed, 21 Nov 2012 12:16:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> <50A6ADD0.3040000@joelhalpern.com> <45813A84-7BE9-4D21-AE3E-F3401D6E1B50@apnic.net> <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> To: "lisp@ietf.org list" X-Mailer: Apple Mail (2.1499) Cc: "iesg@ietf.org IESG" , Paul Wilson , John Curran , "ietf@ietf.org list" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 11:21:52 -0000 Hi, > A possible course of action for the LISP Working Group and the IESG to > consider would be for the existing /32 address be documented as an = IANA > Special Purpose Address allocation for use in supporting the current > LISP experiment, and for the LISP advocates to make their case for > particular requirements in the handling of global unicast address > allocations in IPv6 to the regional addressing communities. This would > allow the existing address policy development process to generate > outcomes that appropriately address the desires and concerns of the > broader community of stakeholders in supporting the potential > requirements of a broad base of deployment of LISP in the Internet's > routing environment. So, if I understand you correctly you say that this should be a = (global?) policy proposal in the different RIR regions. Is that correct? If yes, then that could mean that every region allocates/assigns LISP = prefixes from a separate block. Together with the current experimental = /32 that would mean 6 prefixes for LISP in total. That's not as ideal as = a single prefix, but still very acceptable for the BGP table. If this wg agrees that this is the way forward then there are a few = things that should be done as far as I can see: - Define when the current experiment with the /32 is successful - Document a vision of how LISP should be deployed using a few prefixes = that cover all the LISP space - Advise on how LISP prefixes could/should be assigned - Probably also looking at different phases, for example: - Early adopters: separate PITRs+BGP routes for each /48? - Middle: central PITRs covering the whole LISP space (public? in = tier-1 nets?) - Long term: LISP PITRs in all major networks - Describe a strategy to go from each phase to the next - How to deal with the prefixes if LISP isn't as widely accepted as we = hope - Writing a (global?) policy proposal for assignment of LISP prefixes - Submitting that proposal to all RIR regions and try to get consensus = there I think that if we do the above we can show the operators a possible = future where the BGP table isn't cluttered with PI prefixes. Worst case = we end up with a prefix in BGP for every LISP end-site, but that's no = worst than with current PI assignments. Best case we end up with a much = smaller routing table (compared to normal PI) where all those end-sites = are covered by a few prefixes. IMHO the most important thing is to plan = on how to get there :-) And yes: of course I volunteer to help writing this stuff :-) Sander From jnc@mercury.lcs.mit.edu Wed Nov 21 05:48:53 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7CD21F85C8; Wed, 21 Nov 2012 05:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 suBmShR9ewl4; Wed, 21 Nov 2012 05:48:52 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8288521F85C7; Wed, 21 Nov 2012 05:48:52 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6FFEF18C0CF; Wed, 21 Nov 2012 08:48:51 -0500 (EST) To: ietf@ietf.org, lisp@ietf.org Message-Id: <20121121134851.6FFEF18C0CF@mercury.lcs.mit.edu> Date: Wed, 21 Nov 2012 08:48:51 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu, jcurran@arin.net, pwilson@apnic.net, iesg@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 13:48:53 -0000 > From: Geoff Huston I don't have any comment, one way or another, on what seems to be the basic point of your note (about what role, if any, the IETF should play in allocation). However, there was one aspect I wanted to comment on (it's not clear, reading your note, if this was clear in your minds): > It is noted that the LISP experiment already makes use of a /32 prefix > ... > If the LISP experiment fills this /32 prefix to such a level of > utilisation > ... > What are the plans to migrate out of the experimental address > allocation? Would this renumbering out of an experimental address > allocation even be feasible to contemplate if the experiment achieves a > level of deployment that is commensurate with the allocation of /16? The concept, as I understand it, is that there will be no migration "out of [that] allocation", for the simple reason that the entire rationale of this range of namespace is that it will be processed differently, i.e. require special casing in the code in various places; something like: if ((dest & EIDSPACEMASK) == EIDSPACEALLOCATION) process_one_way(); else process_another_way(); That being the case, the last thing one would want is either i) changing the block that is handled specially, or ii) having a number of smaller blocks, allocated over time, as either one would require much more complex code to handle: you'd have to have some sort of config file, which could hold multiple blocks, code to read it, the code to process packets (above) would have to be able to handle multiple blocks, yadda-yadda. (Changing the block is the same as having multiple blocks, because past a certain point you're too big for a flag day, which would be the only way to avoid having multiple blocks in use at the same time.) It's that that's driving the suggested reservation, and the smaller actual allocation: the code would handle any address inside the _reservation_ with the special processing, but the bulk of the space would be left _unallocated_, for future allocation in some yet-to-be-determined process (one which would presumably be set up by the existing namespace allocation entities), while a small chunk would be allocated to the experiment, for now. I suspect (I haven't communicated with them directly) that the people who are involved with this scheme don't really care _who_ allocates the space, and how - all they care about is that it's all in one chunk - for the reason laid out above. Noel From jnc@mercury.lcs.mit.edu Wed Nov 21 09:58:38 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6AC21F85B8; Wed, 21 Nov 2012 09:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dsWXT7ct74XF; Wed, 21 Nov 2012 09:58:37 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEC321F8532; Wed, 21 Nov 2012 09:58:37 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id EE11B18C0D3; Wed, 21 Nov 2012 12:58:36 -0500 (EST) To: ietf@ietf.org, lisp@ietf.org Message-Id: <20121121175836.EE11B18C0D3@mercury.lcs.mit.edu> Date: Wed, 21 Nov 2012 12:58:36 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 17:58:38 -0000 > From: "George, Wes" > I don't think that expecting code to handle two blocks (the > experimental one and the permanent one) is asking too much We disagree. For me, it's extra code/complexity, and it buys you absolutely nothing at all. > If a single permanent allocation that never changes is truly necessary Allocation != reservation. Nobody is asking for the entire chunk to be _allocated_ (i.e. given out), just that it be _reserved_ for this use. Noel From sm@resistor.net Wed Nov 21 02:40:29 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E336921F8624; Wed, 21 Nov 2012 02:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5faPZZWASsps; Wed, 21 Nov 2012 02:40:27 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0655021F8440; Wed, 21 Nov 2012 02:40:17 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qALAeA3B015359; Wed, 21 Nov 2012 02:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353494416; bh=XRdU9Pqp3mKfHt3EmHsvTw+10GvMaizVw5iPeiRMw2I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=E3gW6oCvksJww+o2DfAuXOpj9jxUxnb1hSpzivt2adHU53XDfrexqzfKeHeh/RLIU kwwUa5xrScHlDxG2qYRy/cKstzBlOKhDPowWfY7pmbqq6vBA5+mszy+ap6A72Olb/v +kKBtBc/zuM10NVNlZM0SpMCuuU2MmW2H3moh0BI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353494416; i=@resistor.net; bh=XRdU9Pqp3mKfHt3EmHsvTw+10GvMaizVw5iPeiRMw2I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UekhTUtD8yphtTBIX3tKiy1LZEE/8iCa592YgGTqOKgQ80XdJ+QF/rXU2/7AHS9BG mKB4z4vldHKkwGca/lRRQP4ltMYu/hagT+X89Z6flKwWlgDqWsWh7uejJ3yeQL6JBu O0GCVzbxD2OmIKZDT/dueZwI3+IRmKa1wOnBDTBc= Message-Id: <6.2.5.6.2.20121121005659.0a1349a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 21 Nov 2012 02:29:24 -0800 To: ietf@ietf.org From: SM In-Reply-To: <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> <50A6ADD0.3040000@joelhalpern.com> <45813A84-7BE9-4D21-AE3E-F3401D6E1B50@apnic.net> <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Wed, 21 Nov 2012 11:28:21 -0800 Cc: lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 10:40:29 -0000 At 22:16 20-11-2012, Geoff Huston wrote: >The guidelines for IP address allocations were documented in RFC2050, >adopted in November 1996 as a Best Current Practice. This document Some parts of RFC 2050 could be considered as Historic. As a FYI there is only one IANA policy about IPv6 [1]. >It is noted that the LISP experiment already makes use of a /32 prefix, >"with more than 250 sites using a /48 sub prefix", as noted in >draft-ietf-lisp-eid-block-03.txt. Even with an overall 50% utilisation >rate of this prefix there is scope in the current /32 address block to >address some 32,000 further sites using a /48 sub prefix. Yes. >If the LISP experiment fills this /32 prefix to such a level of >utilisation then there would be reasonable grounds to make the case that >at such a time the LISP activity would no longer be an experimental >effort, as it would be an instance of an application that makes use of >the global unicast address pool. In this case the provisions of RFC >4773, and the applicability of a special purpose address allocation >would not be expected to apply, as this would fall under the terms of >RFC2050 and the address allocation function would be administered by the >Regional internet Registries, according to RFC2860. There is ample material in the Last Call comments to generate DISCUSSes. The question is how many DISCUSSes will be filed. It's easier to leave the progress of the draft to a matter of IETF consensus than to invoke the RFC 4773 or RFC 2860. IANA is bound to follow technical guidance exclusively from the IESG. It is improbable that IANA would invoke the dispute clause. >A possible course of action for the LISP Working Group and the IESG to >consider would be for the existing /32 address be documented as an IANA >Special Purpose Address allocation for use in supporting the current >LISP experiment, and for the LISP advocates to make their case for >particular requirements in the handling of global unicast address >allocations in IPv6 to the regional addressing communities. This would Anything more than a /32 might have to be a global policy proposal. It would likely take over a year to get such a proposal through all the RIRs. Regards, -sm P.S. Don't boil the ocean to kill a single fish (credits - Noel Chiappa) 1. https://www.icann.org/en/news/in-focus/global-addressing/allocation-ipv6-rirs From kre@munnari.OZ.AU Wed Nov 21 11:12:30 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6CD21F87E7; Wed, 21 Nov 2012 11:12:30 -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 AZo-WlUu-YFF; Wed, 21 Nov 2012 11:12:24 -0800 (PST) Received: from jade.coe.psu.ac.th (unknown [IPv6:2001:3c8:9009:181::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4839321F87DA; Wed, 21 Nov 2012 11:12:23 -0800 (PST) Received: from epsilon.noi.kre.to (jade.coe.psu.AC.TH [IPv6:2001:3c8:9007:1::21]) by jade.coe.psu.ac.th with ESMTP id qALJC7rA007625; Thu, 22 Nov 2012 02:12:08 +0700 (ICT) Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by epsilon.noi.kre.to (8.14.4/8.14.2) with ESMTP id qALJ9lBF025273; Thu, 22 Nov 2012 02:09:47 +0700 (ICT) From: Robert Elz To: Geoff Huston In-Reply-To: <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> References: <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> <50A6ADD0.3040000@joelhalpern.com> <45813A84-7BE9-4D21-AE3E-F3401D6E1B50@apnic.net> Date: Thu, 22 Nov 2012 02:09:47 +0700 Message-ID: <19339.1353524987@epsilon.noi.kre.to> Sender: kre@munnari.OZ.AU X-Mailman-Approved-At: Wed, 21 Nov 2012 11:28:21 -0800 Cc: "iesg@ietf.org IESG" , Paul Wilson , John Curran , "ietf@ietf.org List" , lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 19:12:30 -0000 Date: Wed, 21 Nov 2012 17:16:58 +1100 From: Geoff Huston Message-ID: <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> I have no idea whether the allocation requested is reasonable or not, I haven't read the draft (and unless it becomes more widely used than currently, might never do so), but I do know that this argument ... | The guidelines for IP address allocations were documented in RFC2050, | adopted in November 1996 as a Best Current Practice. ... is totally bogus in these circumstances. The rules in RFCs and BCPs bind ordinary users making ordinary requests for address space - were I to approach IANA with a request for address space to be allocated, a quick denial quoting the relevant RFC would indeed be the correct response. But when the IETF publishes an updated RFC, that always overrides any earlier RFC, and establishes new policy - either for the general case, or perhaps (as seems to be happening here) just a one off override of the normal rules. Doing that is always acceptable, whatever the issue - it is never adequate to simply refuse to consider such requests upon the basis that they don't follow the rules and should be done some other way. Now, when the IETF (via the last call consensus mechanism) consider whether the proposed RFC should be published, it is perfectly reasonable to point out the existing policy, and ask for reasons why use of that mechanism would not be adequate - if the proponents cannnot explain why doing it the way they are suggesting is required, or at least is better than the normal way, then the request (to publish the RFC, not just to perform whatever allocation it requested - that just falls out of the failure to publish the RFC) should be refused. On the other hand, if the proponents can convince the IETF that the procedure they're suggesting is the best way to proceed, then that's what should happen - and that it isn't being done the way that the normal allocation rules would suggest it should be done is 100% irrelevant. If you have an argument against the proposal, please make it upon the merits of the request, and not based upon some supposed viloation of address allocation quidelines. What the result will be I have no idea - I don't know if this allocation should happen or not. I might suggest however, that if Noel is correct about the way this allocation would be used (and Noel usually is correct) then it may be that an assignment out of the 0::/3 address space (which is out of the ordinary allocation space for which the guidelines apply) sounds like it might be the right thing to do - perhaps something like 10f0::/12 (or something near there not currently allocated). kre From sander@steffann.nl Wed Nov 21 12:03:21 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A8421F83EF; Wed, 21 Nov 2012 12:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 ryv4Ej6jpveY; Wed, 21 Nov 2012 12:03:20 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 618AE21F842B; Wed, 21 Nov 2012 12:03:20 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 2C1F42009; Wed, 21 Nov 2012 21:03:10 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEpz6dW213Gd; Wed, 21 Nov 2012 21:03:05 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 5C94B206A; Wed, 21 Nov 2012 21:03:04 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <20121121175836.EE11B18C0D3@mercury.lcs.mit.edu> Date: Wed, 21 Nov 2012 21:03:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121121175836.EE11B18C0D3@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1499) Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 20:03:22 -0000 Hi Noel, >> I don't think that expecting code to handle two blocks (the >> experimental one and the permanent one) is asking too much >=20 > We disagree. For me, it's extra code/complexity, and it buys you = absolutely > nothing at all. I don't agree. See below. >> If a single permanent allocation that never changes is truly = necessary >=20 > Allocation !=3D reservation. Nobody is asking for the entire chunk to = be > _allocated_ (i.e. given out), just that it be _reserved_ for this use. But if I understand correctly it's going to be hard-coded somewhere. = That will mean that everything that is reserved now will be unusable for = anything else ever. I'm not *that* worried about wasting IPv6 addresses, = but I do worry about any hard-coding of prefixes. What for example if = LISP is such a success that the block is too small? Wouldn't it be better to have a bootstrap method that is more flexible? = The DDT root servers know which prefixes are delegated, so we might = extend the DDT protocol to return that list of prefixes. I write code = myself, so I know it's a lot more work to implement something like that = properly. I'm worried about the consequences of making this hard-coded = though. We can't foresee all the possibilities at this point in time (if = ever). Another benefit of making this flexible is that multiple models of LISP = deployment can be used. It doesn't matter anymore if IANA reserves a = special block, RIRs assign from separate blocks, or even if ISPs offer = LISP based solutions to their customers (which happens to be what I am = doing). You get all that, but yes: it does make the code more complex. On the = other hand: LISP implementations know how to talk to DDT servers and = probably also have prefix-list-matching code already, so it shouldn't be = too difficult to get a list of prefixes and match against it. - Sander From jmh@joelhalpern.com Wed Nov 21 12:20:49 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C76B21F8777 for ; Wed, 21 Nov 2012 12:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.256 X-Spam-Level: X-Spam-Status: No, score=-102.256 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 nVJiDnlShCcD for ; Wed, 21 Nov 2012 12:20:47 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id E588A21F8735 for ; Wed, 21 Nov 2012 12:20:47 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 75742A3630 for ; Wed, 21 Nov 2012 12:20:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 2A75C1E1392; Wed, 21 Nov 2012 12:20:45 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-174.clppva.btas.verizon.net [71.161.50.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 625561E1394; Wed, 21 Nov 2012 12:20:44 -0800 (PST) Message-ID: <50AD3796.2050902@joelhalpern.com> Date: Wed, 21 Nov 2012 15:20:38 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: lisp@ietf.org References: <20121121175836.EE11B18C0D3@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Noel Chiappa Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 20:20:49 -0000 I have to say I rather lik the iea of a query to the mapping system that asks for a simple, small set of prefixes with the property that anything outside of that set is by definition unknown to that mapping system. A mapping system with no clue returns 0/0. Yours, Joel On 11/21/2012 3:03 PM, Sander Steffann wrote: > Hi Noel, > >>> I don't think that expecting code to handle two blocks (the >>> experimental one and the permanent one) is asking too much >> >> We disagree. For me, it's extra code/complexity, and it buys you absolutely >> nothing at all. > > I don't agree. See below. > >>> If a single permanent allocation that never changes is truly necessary >> >> Allocation != reservation. Nobody is asking for the entire chunk to be >> _allocated_ (i.e. given out), just that it be _reserved_ for this use. > > But if I understand correctly it's going to be hard-coded somewhere. That will mean that everything that is reserved now will be unusable for anything else ever. I'm not *that* worried about wasting IPv6 addresses, but I do worry about any hard-coding of prefixes. What for example if LISP is such a success that the block is too small? > > Wouldn't it be better to have a bootstrap method that is more flexible? The DDT root servers know which prefixes are delegated, so we might extend the DDT protocol to return that list of prefixes. I write code myself, so I know it's a lot more work to implement something like that properly. I'm worried about the consequences of making this hard-coded though. We can't foresee all the possibilities at this point in time (if ever). > > Another benefit of making this flexible is that multiple models of LISP deployment can be used. It doesn't matter anymore if IANA reserves a special block, RIRs assign from separate blocks, or even if ISPs offer LISP based solutions to their customers (which happens to be what I am doing). > > You get all that, but yes: it does make the code more complex. On the other hand: LISP implementations know how to talk to DDT servers and probably also have prefix-list-matching code already, so it shouldn't be too difficult to get a list of prefixes and match against it. > > - Sander > > From wesley.george@twcable.com Wed Nov 21 12:25:10 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798EB21F85FC; Wed, 21 Nov 2012 12:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 P39HwDp9I7ew; Wed, 21 Nov 2012 12:25:10 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id B08F321F85DF; Wed, 21 Nov 2012 12:25:09 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.83,294,1352091600"; d="scan'208";a="456095235" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 21 Nov 2012 15:24:51 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 21 Nov 2012 15:25:08 -0500 From: "George, Wes" To: Noel Chiappa , "ietf@ietf.org" , "lisp@ietf.org" Date: Wed, 21 Nov 2012 15:25:12 -0500 Thread-Topic: [lisp] Last Call: (LISP EID Block) to Informational RFC Thread-Index: Ac3IEeLx7gw52o/PQTOjMBiBnBLqwwAE4fQg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592303385FBF7A@PRVPEXVS15.corp.twcable.com> References: <20121121175836.EE11B18C0D3@mercury.lcs.mit.edu> In-Reply-To: <20121121175836.EE11B18C0D3@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 20:25:10 -0000 > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > Noel Chiappa > > > If a single permanent allocation that never changes is truly > necessary > > Allocation !=3D reservation. Nobody is asking for the entire chunk to be > _allocated_ (i.e. given out), just that it be _reserved_ for this use. > [WEG] You're hairsplitting on semantics in a way that is mostly unhelpful t= o the discussion at hand. Reserving the block for LISP means that it cannot= be used for anything else. Whether that's an IANA reservation or an RIR al= location is really immaterial to the point I was making, which is that if y= ou truly believe we have to identify a block once and for all for LISP that= is the correct size to be used permanently and indefinitely, you need a be= tter justification than you've given, and using "experimental" as a justifi= cation for not having the details worked out isn't going to be acceptable. Regards, Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jnc@mercury.lcs.mit.edu Wed Nov 21 12:42:57 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC6E21F887E; Wed, 21 Nov 2012 12:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.602 X-Spam-Level: X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 VHhYQcSQIsXq; Wed, 21 Nov 2012 12:42:56 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 58A7221F8A21; Wed, 21 Nov 2012 12:42:56 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3742818C0C9; Wed, 21 Nov 2012 15:42:55 -0500 (EST) To: ietf@ietf.org, lisp@ietf.org Message-Id: <20121121204255.3742818C0C9@mercury.lcs.mit.edu> Date: Wed, 21 Nov 2012 15:42:55 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 20:42:57 -0000 > From: "George, Wes" >> Allocation != reservation. > You're hairsplitting on semantics in a way that is mostly unhelpful to > the discussion at hand. I _thought_ that the point of the messages from Geoff and others (who were questioning about how there were no details in the document of how the allocation would work) was about _how_ the space was to be handed out - to which the allocation/reservation distinction _is_ important. Noel From jnc@mercury.lcs.mit.edu Wed Nov 21 12:48:06 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1845521F888E for ; Wed, 21 Nov 2012 12:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.602 X-Spam-Level: X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 2PM5-sivMm8o for ; Wed, 21 Nov 2012 12:48:05 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 985ED21F8733 for ; Wed, 21 Nov 2012 12:48:05 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 30D1B18C0C9; Wed, 21 Nov 2012 15:48:05 -0500 (EST) To: lisp@ietf.org Message-Id: <20121121204805.30D1B18C0C9@mercury.lcs.mit.edu> Date: Wed, 21 Nov 2012 15:48:05 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 20:48:06 -0000 > From: "Joel M. Halpern" > I have to say I rather lik[e] the i[d]ea of a query to the mapping > system that asks for a simple, small set of prefixes It makes the code one heck of a lot more complicated, and for very little benefit. If we have those engineering cycles available to burn, I have a _long_ list of more valuable things we can spend them on (e.g. better security, caching bindings in MRs, yadda yadda). Noel From sander@steffann.nl Wed Nov 21 13:04:21 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E2621F8818 for ; Wed, 21 Nov 2012 13:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 CJ3nS28BR0cf for ; Wed, 21 Nov 2012 13:04:21 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 038A521F8816 for ; Wed, 21 Nov 2012 13:04:20 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 0CB7B206C; Wed, 21 Nov 2012 22:04:20 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKcWOP-kXTNi; Wed, 21 Nov 2012 22:04:19 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 7A0A1206A; Wed, 21 Nov 2012 22:04:19 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <20121121204805.30D1B18C0C9@mercury.lcs.mit.edu> Date: Wed, 21 Nov 2012 22:04:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <276126D1-F7E3-4840-B1A9-9615EE872478@steffann.nl> References: <20121121204805.30D1B18C0C9@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1499) Cc: lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 21:04:21 -0000 > It makes the code one heck of a lot more complicated, and for very = little > benefit. I think making sure that LISP is flexible enough to last a long time is = a huge benefit. This WG is designing a protocol that might well be the basis for a huge = part of the future internet. Hard-coding prefixes in code now to save = some development effort is the worst thing we can do. I know it's easy = for me to say as I'm not writing the code, but compare a few days/weeks = of extra development work to years and years of everybody being limited = by a bad decision now. - Sander From jnc@mercury.lcs.mit.edu Wed Nov 21 13:24:20 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8807721F87D2 for ; Wed, 21 Nov 2012 13:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.956 X-Spam-Level: X-Spam-Status: No, score=-5.956 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] 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 CVwfR+bM-TJX for ; Wed, 21 Nov 2012 13:24:20 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0E91321F8733 for ; Wed, 21 Nov 2012 13:24:19 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 50BE818C0CF; Wed, 21 Nov 2012 16:24:19 -0500 (EST) Message-Id: <20121121212419.50BE818C0CF@mercury.lcs.mit.edu> Date: Wed, 21 Nov 2012 16:24:19 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 21:24:20 -0000 > From: Sander Steffann > I think making sure that LISP is flexible enough to last a long time is > a huge benefit. I basically agree with that, but we don't have infinite code-writing cycles available. (Remember, this is not an paper design exercise, this stuff is in significant experimental use.) I can dream up dozens of things that would help make LISP "flexible enough to last a long time", but are we going to do them _all_ Right Now? Somehow I don't think so. Resources for writing code are limited. We have to pick what is most important. The ability to support multiple dynamic EID blocks, without changing config files - something we're unlikely to use for a long time, if ever - is way less important than any number of more desirable upgrades. That's really the bottom line here: saying 'we should do this' is equivalent to saying 'this is more important than X, Y and Z'. (Add to that the fact, as far as I know of, only one organization is even putting energy into doing a commercial LISP implementation at the moment.) > compare a few days/weeks of extra development work to years and years > of everybody being limited by a bad decision now. It seems to me entirely unlikely that changing from i) a single hard-coded block to ii) multiple blocks allocated via some sort of dynamic mechanism is something that would be _particularly_ hard to add later - as opposed to, say, adding the ability to cache mappings in the MR (which requires changing the format of the Map-Reply message). Getting the correct balance between i) getting stuff up and running, and ii) not handcuffing yourself in the long run, is a tricky problem. I lived through one cycle of this (with the initial IPv4 stuff), and lived to see _just how painful_ what one thinks is a 'quick hack to get us up and running' can be (with the 32-bit addresses). I am never going to make that mistake again. This is not in that class. Noel From sander@steffann.nl Wed Nov 21 13:51:36 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6E421F885A for ; Wed, 21 Nov 2012 13:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_31=0.6] 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 5oVA0q0aUAWs for ; Wed, 21 Nov 2012 13:51:25 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 104DD21F84C8 for ; Wed, 21 Nov 2012 13:51:24 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 51E65206C; Wed, 21 Nov 2012 22:51:23 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpp8g9tO7XQf; Wed, 21 Nov 2012 22:51:22 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 66A842009; Wed, 21 Nov 2012 22:51:22 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <20121121212419.50BE818C0CF@mercury.lcs.mit.edu> Date: Wed, 21 Nov 2012 22:51:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1093479D-6BFE-4645-BB6E-95048BEBE6D6@steffann.nl> References: <20121121212419.50BE818C0CF@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1499) Cc: lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 21:51:36 -0000 Hi Noel, >> I think making sure that LISP is flexible enough to last a long time = is >> a huge benefit. >=20 > I basically agree with that, but we don't have infinite code-writing = cycles > available. (Remember, this is not an paper design exercise, this stuff = is in > significant experimental use.) >=20 > I can dream up dozens of things that would help make LISP "flexible = enough to > last a long time", but are we going to do them _all_ Right Now? = Somehow I > don't think so. >=20 > Resources for writing code are limited. We have to pick what is most > important. The ability to support multiple dynamic EID blocks, without > changing config files - something we're unlikely to use for a long = time, if > ever - is way less important than any number of more desirable = upgrades. I understand that. Auto-detection of those prefixes is a nice-to-have = feature, but certainly not necessary for now. What if it's implemented = as a configured prefix-list? > That's really the bottom line here: saying 'we should do this' is = equivalent > to saying 'this is more important than X, Y and Z'. Not hard-coding some prefix in code certainly is as far as I am = concerned. Making extensions to the DDT protocol to auto-configure the = prefix list can wait. > (Add to that the fact, as far as I know of, only one organization is = even > putting energy into doing a commercial LISP implementation at the = moment.) Either you're talking about my company or you now know of two :-) I am now running on old c7200's for a proof-of-concept, but those will = be replaced by (probably) ASR1k's as soon as I start to offer it as a = commercial service. >> compare a few days/weeks of extra development work to years and years >> of everybody being limited by a bad decision now. >=20 > It seems to me entirely unlikely that changing from i) a single = hard-coded > block to ii) multiple blocks allocated via some sort of dynamic = mechanism is > something that would be _particularly_ hard to add later - as opposed = to, > say, adding the ability to cache mappings in the MR (which requires = changing > the format of the Map-Reply message). I am very scared of hard-coded stuff :-) I would be very happy if it's = not hard coded but just configurable in some way! I agree that changing = existing message formats later would be so much worse. > Getting the correct balance between i) getting stuff up and running, = and ii) > not handcuffing yourself in the long run, is a tricky problem. I lived = through > one cycle of this (with the initial IPv4 stuff), and lived to see = _just how > painful_ what one thinks is a 'quick hack to get us up and running' = can be > (with the 32-bit addresses). >=20 > I am never going to make that mistake again. :-) Happy to hear that > This is not in that class. We might disagree a bit on that, but let's look for workable solution. = =46rom an operational point of view I really don't like hard-coded = address blocks that have a special meaning, but I am also certainly not = suggesting that you drop all other work! Would using a prefix-list to = configure this be a good solution for now? (I suspect there must be = existing code to check an address against a prefix-list somewhere ;-) Thanks! Sander From farinacci@gmail.com Wed Nov 21 14:00:35 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4536621F84DF for ; Wed, 21 Nov 2012 14:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 RAyPcvxKNFYP for ; Wed, 21 Nov 2012 14:00:34 -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 A9C4B21F84DD for ; Wed, 21 Nov 2012 14:00:34 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so454604dae.31 for ; Wed, 21 Nov 2012 14:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=RHsGTp1Pb1kb4tGX68uKR6rI4V78lyYLBLTCPEbXg+0=; b=BZ1bu2qF4oMl4CHwbcxc+bWf78rEPyGr1j8pvp05xcpAV+qsKFSY4HUlxcVk4jvqhM 9lOE2uKQgaClO8NhS67z2Xj0lGoEIcXPSIEDA8NDFoJriLK4hX9GZM5hZ00XmhzkEYUB z9Kn1NOX+uy9Mx6+EGVvLTn7ZxvawRPPk3NnWbAORSQa9Z4OR+b8lmge9G/c1p99JS08 rGfFVcW4of0dGMz/5IQHbsrAb2gCh/iaYoz5EV91jkrBMv/dFf1xiBHG6E5BnZT0qICu O1D5BBEeDika6rFaYWsC/aUnBvLHjbX6xhc6TOuUrzp+PCPtWcUXpTodjpgnlNLw8qs3 oqfg== Received: by 10.68.225.232 with SMTP id rn8mr3138888pbc.34.1353535234423; Wed, 21 Nov 2012 14:00:34 -0800 (PST) Received: from sjc-vpn5-1696.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id v9sm661678paz.6.2012.11.21.14.00.32 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 14:00:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <50AD3796.2050902@joelhalpern.com> Date: Wed, 21 Nov 2012 14:00:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121121175836.EE11B18C0D3@mercury.lcs.mit.edu> <50AD3796.2050902@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1499) Cc: lisp@ietf.org, Noel Chiappa Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 22:00:35 -0000 > I have to say I rather lik the iea of a query to the mapping system = that asks for a simple, small set of prefixes with the property that = anything outside of that set is by definition unknown to that mapping = system. A mapping system with no clue returns 0/0. And is already implemented multiple times. ;-) Dino >=20 > Yours, > Joel >=20 > On 11/21/2012 3:03 PM, Sander Steffann wrote: >> Hi Noel, >>=20 >>>> I don't think that expecting code to handle two blocks (the >>>> experimental one and the permanent one) is asking too much >>>=20 >>> We disagree. For me, it's extra code/complexity, and it buys you = absolutely >>> nothing at all. >>=20 >> I don't agree. See below. >>=20 >>>> If a single permanent allocation that never changes is truly = necessary >>>=20 >>> Allocation !=3D reservation. Nobody is asking for the entire chunk = to be >>> _allocated_ (i.e. given out), just that it be _reserved_ for this = use. >>=20 >> But if I understand correctly it's going to be hard-coded somewhere. = That will mean that everything that is reserved now will be unusable for = anything else ever. I'm not *that* worried about wasting IPv6 addresses, = but I do worry about any hard-coding of prefixes. What for example if = LISP is such a success that the block is too small? >>=20 >> Wouldn't it be better to have a bootstrap method that is more = flexible? The DDT root servers know which prefixes are delegated, so we = might extend the DDT protocol to return that list of prefixes. I write = code myself, so I know it's a lot more work to implement something like = that properly. I'm worried about the consequences of making this = hard-coded though. We can't foresee all the possibilities at this point = in time (if ever). >>=20 >> Another benefit of making this flexible is that multiple models of = LISP deployment can be used. It doesn't matter anymore if IANA reserves = a special block, RIRs assign from separate blocks, or even if ISPs offer = LISP based solutions to their customers (which happens to be what I am = doing). >>=20 >> You get all that, but yes: it does make the code more complex. On the = other hand: LISP implementations know how to talk to DDT servers and = probably also have prefix-list-matching code already, so it shouldn't be = too difficult to get a list of prefixes and match against it. >>=20 >> - Sander >>=20 >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Wed Nov 21 14:01:18 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B9821F8528; Wed, 21 Nov 2012 14:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 wY4+CFdZCvqL; Wed, 21 Nov 2012 14:01:18 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2D1621F84DF; Wed, 21 Nov 2012 14:01:17 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so3381321pad.31 for ; Wed, 21 Nov 2012 14:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8XtVZ4N29/ajQjbRF6boaEj6+v/EqX8IbB+wwMAgjWw=; b=WPjcm9eFmqImKzJ1QhL9G8CsG2iGn0XRy0xXiP71bgdCWbUu0uAjQk2ZMhtCFyW7pu OsjxEVEJ/LzWD6YyUv7/KjAX5PLd8Ep2yFwpdYGQt/KdhOM8TJGzrCtaWpySuRVTo4qy Gz7glm+jBqTz6YwCJ25o0WnPxuCMiL18iO6v4qG2qKt2i1/v0XpqVvpdpAeWjby032rD FVFIjIy5KvL0onGgL0E9bOIHWwwhPFf+8hUpmvIyT2y8FMCHuXLrJGAMT3sqcekKSBmW G59e4UkSB/qYfoteA1TdtujmuQBIDnhJh6JtNg+T5FrbuV7qzof9tMCcikVf7Ktd8QZD 5dmA== Received: by 10.66.72.136 with SMTP id d8mr21110216pav.4.1353535277735; Wed, 21 Nov 2012 14:01:17 -0800 (PST) Received: from sjc-vpn5-1696.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id v9sm661678paz.6.2012.11.21.14.01.14 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 14:01:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD592303385FBF7A@PRVPEXVS15.corp.twcable.com> Date: Wed, 21 Nov 2012 14:01:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121121175836.EE11B18C0D3@mercury.lcs.mit.edu> <2671C6CDFBB59E47B64C10B3E0BD592303385FBF7A@PRVPEXVS15.corp.twcable.com> To: "George, Wes" X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" , Noel Chiappa , "ietf@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 22:01:18 -0000 Make it an allocation for EIDs and ILNP can use it too. Dino On Nov 21, 2012, at 12:25 PM, "George, Wes" = wrote: >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf = Of >> Noel Chiappa >>=20 >>> If a single permanent allocation that never changes is truly >> necessary >>=20 >> Allocation !=3D reservation. Nobody is asking for the entire chunk to = be >> _allocated_ (i.e. given out), just that it be _reserved_ for this = use. >>=20 >=20 > [WEG] You're hairsplitting on semantics in a way that is mostly = unhelpful to the discussion at hand. Reserving the block for LISP means = that it cannot be used for anything else. Whether that's an IANA = reservation or an RIR allocation is really immaterial to the point I was = making, which is that if you truly believe we have to identify a block = once and for all for LISP that is the correct size to be used = permanently and indefinitely, you need a better justification than = you've given, and using "experimental" as a justification for not having = the details worked out isn't going to be acceptable. >=20 > Regards, >=20 > Wes George >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Wed Nov 21 14:11:39 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F4721F8903; Wed, 21 Nov 2012 14:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 IFb0AeD2h6ib; Wed, 21 Nov 2012 14:11:39 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD5821F88A7; Wed, 21 Nov 2012 14:11:39 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so3386559pad.31 for ; Wed, 21 Nov 2012 14:11:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=9Lxys3f1ZhkTCa1s6RvD2j0zLKO8P2YiFWcCtNu/R/g=; b=pq9bCorpC+COfzVDvlvQfd2qeNpJ94MiyqMkdffeP2Sklf4hwuMr8x8B1Y6Qhw1/YP 9HbHbyVOe8013WDx7WbPHBvbJ/gqUY/l0L7bAfVCJ9WxBxpKmtsjgGjgpH5QXY2yNOxV 6+p2CY46fXaZY9/Uqky6cdJu+2ozZIdkApwWR9zHyAKm3sIWz1z3Nnu6xfLZbFgTEexp 6fucCeK1C55JIR4yPzUw7/x4qOpaGeyzh4qFTyYUpFQMK966jwTp/J2cqFhfvjga2mrQ suZEytau+TJcEu02ZaFXGAB7G3VlBZ7YQi7MFOqAQF4M9Ln0zmmO3Vw9ekDJGD6p7UtX FBsg== Received: by 10.68.134.233 with SMTP id pn9mr3260133pbb.125.1353535899014; Wed, 21 Nov 2012 14:11:39 -0800 (PST) Received: from sjc-vpn5-1696.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id c1sm668511pav.23.2012.11.21.14.11.36 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 14:11:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> Date: Wed, 21 Nov 2012 14:11:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2227244C-BE63-4CED-A4EE-5DBE2881247A@gmail.com> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> <50A6ADD0.3040000@joelhalpern.com> <45813A84-7BE9-4D21-AE3E-F3401D6E1B50@apnic.net> <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.1499) Cc: "iesg@ietf.org IESG" , Paul Wilson , John Curran , "ietf@ietf.org List" , lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 22:11:40 -0000 > A possible course of action for the LISP Working Group and the IESG to > consider would be for the existing /32 address be documented as an = IANA > Special Purpose Address allocation for use in supporting the current > LISP experiment, and for the LISP advocates to make their case for > particular requirements in the handling of global unicast address > allocations in IPv6 to the regional addressing communities. This would > allow the existing address policy development process to generate > outcomes that appropriately address the desires and concerns of the > broader community of stakeholders in supporting the potential > requirements of a broad base of deployment of LISP in the Internet's > routing environment. I think this is a reasonable suggestion. I do believe the size of the = prefix is less important than having a semantic associated with the = prefix. > We do not support the publication of this draft as an Informational = RFC. >=20 > regards, >=20 > John Curran, > Paul Wilson, and > Geoff Huston Thanks guys. Dino From sander@steffann.nl Wed Nov 21 14:29:09 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE9E21F849A for ; Wed, 21 Nov 2012 14:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.474 X-Spam-Level: X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 Xq67tgBGbv+v for ; Wed, 21 Nov 2012 14:29:09 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id E22B221F8468 for ; Wed, 21 Nov 2012 14:29:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 0392D206C for ; Wed, 21 Nov 2012 23:29:08 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOJw5MlmqOf0 for ; Wed, 21 Nov 2012 23:29:07 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 7B02D2009 for ; Wed, 21 Nov 2012 23:29:07 +0100 (CET) From: Sander Steffann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0EC97CF8-F855-4490-9594-4D3D9F01255C@steffann.nl> Date: Wed, 21 Nov 2012 23:29:06 +0100 To: "lisp@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [lisp] Thanks X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 22:29:09 -0000 Oh, and for everyone who is working on all this LISP stuff: if you ever = see me please remind me that I owe you a few beers :-) Unfortunately I don't have the budget to go to IETF meetings and bring = it to you Cheers, Sander From farinacci@gmail.com Wed Nov 21 15:15:36 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEC321F84CC for ; Wed, 21 Nov 2012 15:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 Dy6aQtpuIHxe for ; Wed, 21 Nov 2012 15:15:35 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC94A21F84C4 for ; Wed, 21 Nov 2012 15:15:35 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so3414699pad.31 for ; Wed, 21 Nov 2012 15:15:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ETz16hLy5NWXJPct4d3sA5iHGnjv9Zpn0QJz0iGoRw8=; b=uru93uy4m6HYpdAc/z07GBLpju4lFu9za3LupLG4aZXBH86MmVwUvZjINaxuig+Cdf s9FQauG7cdyMUr8MZ7Hqa95nfa5D9Iixa077JTZvEKhJaqiJMANCUI4noBYzItGn705e v5ZuWM8L85Ou6wK5U7kqhpzIwGN5j9UyhWffJWiPtXKgCv5ArYxd/IWW4THop783rhmF Dw/sYNJMzdkKUZt5wkHFjAssLHUJx0cinnROSL51ZK4qCBTVvjq+lnuxhZErVQb0O2fH EITIGUgMv5tKPxQoJlWkxkL9NG0JsA4XOq7tqYtpkRK2npsMjwSySqwnDAEJIXJl92rM UzQg== Received: by 10.66.80.194 with SMTP id t2mr21573613pax.43.1353539735546; Wed, 21 Nov 2012 15:15:35 -0800 (PST) Received: from sjc-vpn5-1696.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id c1sm745035pav.23.2012.11.21.15.15.32 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 15:15:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <0EC97CF8-F855-4490-9594-4D3D9F01255C@steffann.nl> Date: Wed, 21 Nov 2012 15:15:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <044521AD-9FED-4DFD-B768-8F17B1264455@gmail.com> References: <0EC97CF8-F855-4490-9594-4D3D9F01255C@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org list" Subject: Re: [lisp] Thanks X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 23:15:36 -0000 > Oh, and for everyone who is working on all this LISP stuff: if you = ever see me please remind me that I owe you a few beers :-) > Unfortunately I don't have the budget to go to IETF meetings and bring = it to you Maybe the LISP WG can come to you Sander. ;-) Dino >=20 > Cheers, > Sander >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From sander@steffann.nl Wed Nov 21 15:16:33 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030CD21F84C7 for ; Wed, 21 Nov 2012 15:16:33 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMngkIsCuGYs for ; Wed, 21 Nov 2012 15:16:32 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 767A021F84C4 for ; Wed, 21 Nov 2012 15:16:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 6EE41206D; Thu, 22 Nov 2012 00:16:31 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqxMdEQlp4tV; Thu, 22 Nov 2012 00:16:31 +0100 (CET) Received: from [IPv6:2a00:8640:1::cded:6dd4:edb0:5502] (unknown [IPv6:2a00:8640:1:0:cded:6dd4:edb0:5502]) by mail.sintact.nl (Postfix) with ESMTP id E655B2009; Thu, 22 Nov 2012 00:16:30 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <044521AD-9FED-4DFD-B768-8F17B1264455@gmail.com> Date: Thu, 22 Nov 2012 00:16:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2F6185E3-C067-4B21-A18D-9F79AF9E6F16@steffann.nl> References: <0EC97CF8-F855-4490-9594-4D3D9F01255C@steffann.nl> <044521AD-9FED-4DFD-B768-8F17B1264455@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org list" Subject: Re: [lisp] Thanks X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 23:16:33 -0000 >> Oh, and for everyone who is working on all this LISP stuff: if you = ever see me please remind me that I owe you a few beers :-) >> Unfortunately I don't have the budget to go to IETF meetings and = bring it to you >=20 > Maybe the LISP WG can come to you Sander. ;-) No problem! Beer will be provided :-) Sander From terry.manderson@icann.org Wed Nov 21 20:23:33 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6930521E8084 for ; Wed, 21 Nov 2012 20:23:33 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKL41a3PruDL for ; Wed, 21 Nov 2012 20:23:32 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 82F2321E8083 for ; Wed, 21 Nov 2012 20:23:32 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 21 Nov 2012 20:23:31 -0800 From: Terry Manderson To: LISP mailing list list Date: Wed, 21 Nov 2012 20:23:30 -0800 Thread-Topic: WG Last Call for draft-ietf-lisp-threats Thread-Index: Ac3IaSAkoxRP2Ngd80ih760CF+5BQA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3436439011_17329236" MIME-Version: 1.0 Subject: [lisp] WG Last Call for draft-ietf-lisp-threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 04:23:33 -0000 --B_3436439011_17329236 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, During the WG meeting at IETF 85 the authors of draft-ietf-lisp-threats-03 requested a work group last call. Here starts a 14 day last call for this document, the last call will end on Tuesday the 6th December, 2012. You will find its text here: http://tools.ietf.org/html/draft-ietf-lisp-threats-03 Please review this WG item and provide any last comments. Cheers Terry --B_3436439011_17329236 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUk1rs2v9VCk0O43AicM4FWThx/XAwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTIyMDQyMzMwWjANBgkqhkiG 9w0BAQEFAASCAQAPHD486Tso3lpgStSdeHKguWqGlNeqPMVWQVETIazgYqs9IozKH9ipZoYc LH0eAIxPoQzpClE8nPspl2C9y8oKZGNU+o9P14ivaHW/poOBRwoumI0EfVmtRyL9XXqKBFq1 N80C0qry0wkzWD4ZH4sKzfiWuqZTVtHLVaC8PO/i+sS9B5YTR8cgkB44MrhT4o/TLwI8/1fa 4P8CInzmBdUENOPtCbXkNplgjQ2Qq3yRZ88N/G0v0wXn+nhnnmuqYN6wX6Y42LVVgKPaZlR5 UN1I2dhApaB19/k5uu1jFOEP1TyYOhij95zPMf9HoSh/D7ltr9nBZl+ee0OYErWk1iPB --B_3436439011_17329236-- From terry.manderson@icann.org Wed Nov 21 20:24:05 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090A521E8084 for ; Wed, 21 Nov 2012 20:24:05 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3kLRo26T5xl for ; Wed, 21 Nov 2012 20:24:04 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 560D021E8083 for ; Wed, 21 Nov 2012 20:23:56 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 21 Nov 2012 20:23:55 -0800 From: Terry Manderson To: LISP mailing list list Date: Wed, 21 Nov 2012 20:23:54 -0800 Thread-Topic: WG Last Call for draft-ietf-lisp-deployment Thread-Index: Ac3IaS5yv4WH35ISD0WXq+N4cGAJ7w== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3436439034_17311287" MIME-Version: 1.0 Subject: [lisp] WG Last Call for draft-ietf-lisp-deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 04:24:05 -0000 --B_3436439034_17311287 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, During the WG meeting at IETF 85 the authors of draft-ietf-lisp-deployment-05 requested a work group last call. Here starts a 14 day last call for this document, the last call will end on Thursday the 6th December, 2012. You will find its text here: http://tools.ietf.org/html/draft-ietf-lisp-deployment-05 Please review this WG item and provide any last comments. Cheers Terry --B_3436439034_17311287 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUum2iKXcRpZ+XPbk/k9tGE3JycpYwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTIyMDQyMzU0WjANBgkqhkiG 9w0BAQEFAASCAQBG5qSJMTzHbv8pKbcfzh1ZYwkzVQZL7qVEds4/SLMmVZ/muuqQwiBtFu2w Hke7ox+YHIldfuofMmOxxxJzHBmwOyuOCK97hCfOZCc1t/+xHjLTo0TALcps938rEMVVNqp/ rulAHNLeVEBJf1USQ3vm8fOsOfBHD92+t4hOiweAwrWRa3LvTdzbqQMfjQ/KvW5JiDQ+/H2I 7PbVazhcQtpdQLE3153fbfhKuVcfXFoSJomxuqg1rJD0ectVU4O6gCF5QuGvjsQRtuzVdL5C 6A+uIih1kdxM9zdSePsrvLXFiRIkZxuxf7W/RTPI20XijqOGi29ggBy2RnjzCj7YkpYF --B_3436439034_17311287-- From terry.manderson@icann.org Wed Nov 21 20:25:15 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08B121E8084 for ; Wed, 21 Nov 2012 20:25:15 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOgdlsvvFc+Y for ; Wed, 21 Nov 2012 20:25:15 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 352B021E8083 for ; Wed, 21 Nov 2012 20:25:15 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 21 Nov 2012 20:25:10 -0800 From: Terry Manderson To: LISP mailing list list Date: Wed, 21 Nov 2012 20:25:04 -0800 Thread-Topic: [lisp] WG Last Call for draft-ietf-lisp-threats Thread-Index: Ac3IaSAkoxRP2Ngd80ih760CF+5BQAAADgGc Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3436439104_17359967" MIME-Version: 1.0 Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 04:25:16 -0000 --B_3436439104_17359967 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Apologies, That is Thursday the 6th December, 2012. T. On 22/11/12 2:23 PM, "Terry Manderson" wrote: > All, > > During the WG meeting at IETF 85 the authors of draft-ietf-lisp-threats-03 > requested a work group last call. > > Here starts a 14 day last call for this document, the last call will end on > Tuesday the 6th December, 2012. > > You will find its text here: > http://tools.ietf.org/html/draft-ietf-lisp-threats-03 > > Please review this WG item and provide any last comments. > > Cheers > Terry --B_3436439104_17359967 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUTp/ZXdXkjSemMMgha7HSG6iI43gwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTIyMDQyNTA0WjANBgkqhkiG 9w0BAQEFAASCAQBD951JO8xJz2gMjJSvzfJ/PcIXurnKx6crL5TB9Pi24vDjxpusURRIv6dz 7z8BiMwiH5eP6er1CiuEtBIVvJjuwo+LewotAAtCD4NyPxnEQ0VIxY5CXAxfuealPFQxRckB Gd/qch5iwc/YHT0Ayy19F2czprMgAyRYk8/Hvcgvg3WlstJAKydZWEhdzG71bttw7VxD0HlU in7RptpvftZzFnxMzX1/3Haw6ry8scTcgltP0Ob4O0c5er2YR2zAVikNLAbLzApoSU1yBVQO cXjPJ4/3n+eZwMVyXZVyYFfDBGM22GaPV9rlj0RuONAaLlt23jHuT2/zDxA1XvXNlX8q --B_3436439104_17359967-- From gih@apnic.net Wed Nov 21 21:51:04 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2343821F850E; Wed, 21 Nov 2012 21:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.559 X-Spam-Level: X-Spam-Status: No, score=-98.559 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 tX53a6AgDUfK; Wed, 21 Nov 2012 21:51:03 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 12B7D21F850D; Wed, 21 Nov 2012 21:51:01 -0800 (PST) Received: from [192.168.51.200] (unknown [87.213.29.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 441B9B68B7; Thu, 22 Nov 2012 15:50:56 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Geoff Huston In-Reply-To: <19339.1353524987@epsilon.noi.kre.to> Date: Thu, 22 Nov 2012 16:50:40 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <08FCD406-F556-4F7E-BA98-9591D161A3A6@apnic.net> References: <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> <50A6ADD0.3040000@joelhalpern.com> <45813A84-7BE9-4D21-AE3E-F3401D6E1B50@apnic.net> <19339.1353524987@epsilon.noi.kre.to> To: Robert Elz X-Mailer: Apple Mail (2.1499) Cc: "iesg@ietf.org IESG" , "ietf@ietf.org List" , lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 05:51:04 -0000 With respect Robert, I disagree with your line of argument and I = disagree with your assertion that a reference to an existing RFC is "bogus under=20= these circumstances" This eid draft does not claim to obsolete or update either the = description of roles and responsibilities in RFC2860 or the directions to the IANA = in=20 RFC4773, yet the document's directions to the IANA appear to me to be = inconsistent with those existing procedures and policies. To claim, if I understand your line of argument correctly, that every=20 RFC essentially is an implicit update of all existing RFCs, and every=20 RFC does not need to explicitly obsolete or update any other RFC, as=20 it does does so by default upon publication of the RFC is not a line of argument that I find that I could agree with. For me, it's like proclaiming that: "everything I do is right, and if=20 whatever I do contravenes existing processes and procedures then my actions implicitly update those processes and procedures such that everything I do is right" I find that I cannot agree with such a=20 circular self-referential line of reasoning. Instead, I believe that the processes and processes that the IETF follow = are deliberative decisions, and that we update and amend those processes and procedures explicitly, and documents that perform such updates say so explicitly, and are accepted and published on the basis of explicit consideration of the processes and procedures and acceptance of the amendment. But I appreciate that I am by training a mathematician and not a lawyer, and you may indeed be making some critical observations about the nature of the IETF's processes and procedures whose finer points may well have escaped me. However, it seems to me that it would be more productive for the IETF to consider that this issue is a distinct issue, and not confound the consideration of the IETF Last Call of this particular eid draft with the broader issue of the manner by which the IETF crafts=20= and maintains its own procedures, processes and policies. regards, Geoff speaking for myself and noone else On 22/11/2012, at 6:09 AM, Robert Elz wrote: > Date: Wed, 21 Nov 2012 17:16:58 +1100 > From: Geoff Huston > Message-ID: <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> >=20 > I have no idea whether the allocation requested is reasonable or not, > I haven't read the draft (and unless it becomes more widely used than > currently, might never do so), but I do know that this argument ... >=20 > | The guidelines for IP address allocations were documented in = RFC2050, > | adopted in November 1996 as a Best Current Practice. ... >=20 > is totally bogus in these circumstances. >=20 > The rules in RFCs and BCPs bind ordinary users making ordinary = requests > for address space - were I to approach IANA with a request for address > space to be allocated, a quick denial quoting the relevant RFC would = indeed > be the correct response. >=20 > But when the IETF publishes an updated RFC, that always overrides any > earlier RFC, and establishes new policy - either for the general case, = or > perhaps (as seems to be happening here) just a one off override of the > normal rules. >=20 > Doing that is always acceptable, whatever the issue - it is never = adequate > to simply refuse to consider such requests upon the basis that they = don't > follow the rules and should be done some other way. >=20 > Now, when the IETF (via the last call consensus mechanism) consider = whether > the proposed RFC should be published, it is perfectly reasonable to = point > out the existing policy, and ask for reasons why use of that mechanism = would > not be adequate - if the proponents cannnot explain why doing it the = way > they are suggesting is required, or at least is better than the normal = way, > then the request (to publish the RFC, not just to perform whatever = allocation > it requested - that just falls out of the failure to publish the RFC) = should > be refused. >=20 > On the other hand, if the proponents can convince the IETF that the > procedure they're suggesting is the best way to proceed, then that's > what should happen - and that it isn't being done the way that the > normal allocation rules would suggest it should be done is 100% = irrelevant. >=20 > If you have an argument against the proposal, please make it upon the > merits of the request, and not based upon some supposed viloation of > address allocation quidelines. >=20 > What the result will be I have no idea - I don't know if this = allocation > should happen or not. I might suggest however, that if Noel is = correct > about the way this allocation would be used (and Noel usually is = correct) > then it may be that an assignment out of the 0::/3 address space = (which is > out of the ordinary allocation space for which the guidelines apply) > sounds like it might be the right thing to do - perhaps something like > 10f0::/12 (or something near there not currently allocated). >=20 > kre From rogerj@gmail.com Thu Nov 22 01:04:46 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070B121F868A; Thu, 22 Nov 2012 01:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 CNMFghDC76cv; Thu, 22 Nov 2012 01:04:44 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C196321F867D; Thu, 22 Nov 2012 01:04:44 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4559187ieb.31 for ; Thu, 22 Nov 2012 01:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7YIuR98Vw24VjMvYpVNv0wnVeVcv+4nPqD/f4LHOemM=; b=xuEaV+pAobBCYGj5FbgGqszRj+b6qZYJWqU95Eom2O9PAgsSc0SAtwKOpSLRruqwvZ 6CoBhZFSlaB7VNiC40OcO4mL23aUnm7AbsPsD+gIHDEwJ7SCSs8XCqICn898GbZnpPZj UwsvXHFxrS5sZRqV5MRXwJqQNqVh4ExMSLFBzYCKApO76myCvEdqKdMDZ6yeblbTjktv Z3IbKGKjOglPsYZjQFV/pCHO5e463KeNnxHgabB5CICgO9wB1mSZPxQQWuHogw9sVGah pB5edLMA8DRfhUIg/9992+HmfuRtoSn89esmKyS5tMPlD4dCsKl5EvWYAyhAn8LM44a3 55jQ== MIME-Version: 1.0 Received: by 10.50.209.65 with SMTP id mk1mr2558029igc.8.1353575083226; Thu, 22 Nov 2012 01:04:43 -0800 (PST) Received: by 10.64.138.169 with HTTP; Thu, 22 Nov 2012 01:04:43 -0800 (PST) In-Reply-To: References: <20121121175836.EE11B18C0D3@mercury.lcs.mit.edu> <2671C6CDFBB59E47B64C10B3E0BD592303385FBF7A@PRVPEXVS15.corp.twcable.com> Date: Thu, 22 Nov 2012 10:04:43 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Cc: "lisp@ietf.org" , "ietf@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 09:04:46 -0000 On Wed, Nov 21, 2012 at 11:01 PM, Dino Farinacci wrote: > Make it an allocation for EIDs and ILNP can use it too. Somehow I hear a voice in the back of my head asking if we're talking about starting to use another big IPv6 block than 2000::/3 for the two above mention usage? 2000::/3 for our current model of Internet with our current style of allocation/assignment of address space to ISP/end users xxxx::/3 for future modells, LISP/EID, ILNP and others? -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From brian.e.carpenter@gmail.com Thu Nov 22 01:44:33 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6023221F88A9; Thu, 22 Nov 2012 01:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.429 X-Spam-Level: X-Spam-Status: No, score=-101.429 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 nJB3NYbQ8xbb; Thu, 22 Nov 2012 01:44:33 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A10621F8735; Thu, 22 Nov 2012 01:44:32 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so3476306wgb.13 for ; Thu, 22 Nov 2012 01:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BvsTk82ZB+qKD/OQdl2Llfha8JttLNjNSjxIejs34CM=; b=StG+MrOx4cTDlkAQdnzLXWhW0DWrOS929dnmd/oIGKHXz6xoNzx2wdT5vc2axA+CQp 0Zt5Clv+dJcvS3NoxZ1ghTQowqEyzd74+lLxd8xzZ5VvbxfYkxIsSI8qfd4AwzaNf5pz 7LVcryWTH3fxx2FOD8IXeq9zZBL41fXPy2eG786h9+MGVSJsV721csQxEnl1o+vZ+9bm 89oYuY01ISaCyaDNa+H8MXBojNqiiHPgUWMEdLqK0Sqrievw2UNZYtQxv4ykTnQJxGnO UOfKFep+JsBYIXjb3h2Yzt8X5Ix0c9pDTTeju5g++jsp8++uIuF/XSi29AKhei8/pLkX aJtw== Received: by 10.216.211.84 with SMTP id v62mr68144weo.158.1353577471087; Thu, 22 Nov 2012 01:44:31 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-157.as13285.net. [2.102.218.157]) by mx.google.com with ESMTPS id w5sm3579846wiz.10.2012.11.22.01.44.28 (version=SSLv3 cipher=OTHER); Thu, 22 Nov 2012 01:44:29 -0800 (PST) Message-ID: <50ADF407.1090300@gmail.com> Date: Thu, 22 Nov 2012 09:44:39 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?Um9nZXIgSsO4cmdlbnNlbg==?= References: <20121121175836.EE11B18C0D3@mercury.lcs.mit.edu> <2671C6CDFBB59E47B64C10B3E0BD592303385FBF7A@PRVPEXVS15.corp.twcable.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "lisp@ietf.org" , "ietf@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 09:44:33 -0000 Hi Roger, On 22/11/2012 09:04, Roger J=C3=B8rgensen wrote: > On Wed, Nov 21, 2012 at 11:01 PM, Dino Farinacci = wrote: >> Make it an allocation for EIDs and ILNP can use it too. >=20 > Somehow I hear a voice in the back of my head asking if we're talking > about starting to use another big IPv6 block than 2000::/3 for the two > above mention usage? >=20 > 2000::/3 for our current model of Internet with our current style of > allocation/assignment of address space to ISP/end users > xxxx::/3 for future modells, LISP/EID, ILNP and others? I've been relatively relaxed for many years about allocation policy in 2000::/3, precisely because that leaves most of the total address space free in case we turn 2000::/3 into a swamp. I would be a bit nervous about dedicating another /3 for unproven use. There's a risk of it ending up unusable like Class E. So if we are going to do this, doing it inside 2000::/3 seems a bit safer to me. Brian From kre@munnari.OZ.AU Thu Nov 22 07:28:08 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D6321F8973; Thu, 22 Nov 2012 07:28:08 -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 UVD4yslEdKMo; Thu, 22 Nov 2012 07:28:07 -0800 (PST) Received: from jade.coe.psu.ac.th (unknown [IPv6:2001:3c8:9009:181::2]) by ietfa.amsl.com (Postfix) with ESMTP id E15F921F8972; Thu, 22 Nov 2012 07:28:06 -0800 (PST) Received: from epsilon.noi.kre.to (jade.coe.psu.AC.TH [IPv6:2001:3c8:9007:1::21]) by jade.coe.psu.ac.th with ESMTP id qAMFRvE9019088; Thu, 22 Nov 2012 22:27:58 +0700 (ICT) Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by epsilon.noi.kre.to (8.14.4/8.14.2) with ESMTP id qAMFPWmx017251; Thu, 22 Nov 2012 22:25:32 +0700 (ICT) From: Robert Elz To: Geoff Huston In-Reply-To: <08FCD406-F556-4F7E-BA98-9591D161A3A6@apnic.net> References: <08FCD406-F556-4F7E-BA98-9591D161A3A6@apnic.net> <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net> <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> <50A6ADD0.3040000@joelhalpern.com> <45813A84-7BE9-4D21-AE3E-F3401D6E1B50@apnic.net> <19339.1353524987@epsilon.noi.kre.to> Date: Thu, 22 Nov 2012 22:25:32 +0700 Message-ID: <16573.1353597932@epsilon.noi.kre.to> Sender: kre@munnari.OZ.AU Cc: "iesg@ietf.org IESG" , "ietf@ietf.org List" , lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 15:28:08 -0000 Date: Thu, 22 Nov 2012 16:50:40 +1100 From: Geoff Huston Message-ID: <08FCD406-F556-4F7E-BA98-9591D161A3A6@apnic.net> | With respect Robert, I disagree with your line of argument and I disagree | with your assertion that a reference to an existing RFC is "bogus under | these circumstances" That's not what I said - what I said was that relying upon an RFC as disqualifying a new one was bogus - that's never going to be possible, nor should it be. Referencing existing RFCs is of course just fine. | This eid draft does not claim to obsolete or update either the description | of roles and responsibilities in RFC2860 or the directions to the IANA in | RFC4773, My guess would be that is because it doesn't intend to do either of those things (still just a guess, I am not arguing the merits or correctness of that particular draft). It is entirely reasonable to leave existing procedures in place, but override them for a specific case. If RFC's had an "Ignores" header, then perhaps this one should say "Ignores: RFC2860 RFC773" (or perhaps Overrides), but there are no such headers. | yet the document's directions to the IANA appear to me to be inconsistent | with those existing procedures and policies. Yes, that is why it is an RFC, and why it should need IETF consensus to proceed. If they were just to follow the existing guidelines, they'd just get address space the normal way. Clearly the proponents of this draft don't believe that is adequate, or they wouldn't have gone to all the trouble of writing a draft and attempting to publish it as an RFC. Before someone else raises it, one issue might be that this is apparently just intended as an Informational RFC, yet the others are BCP or PS or something. That's kind of unfortunate, but indicates something of a lack of categories for RFCs - this is clearly not a BCP (its purpose isn't to sent any policy, or describe how things should be done, aside from for this one specific case), nor can it be on standards track (it isn't capable of multiple independent implementations), Informational is all that is plausible. Ideally we'd have a separate cagegory so we can divide the Info docs that are "This is FYI" (that is agreed useful enough to pubish), from "this is the IETF's consensus about ..." That is, for this, Info is correct (as things stand) and that doesn't have any effect upon my opinions. | To claim, if I understand your line of argument correctly, that every | RFC essentially is an implicit update of all existing RFCs, Of course they are, or at least the ones published as the result of IETF consensus are. Each of them adjusts the overall view of the state of the world, and how things are, or should be done, in some particular area, and necessarily have some impact on all kinds of previous specifications. Where there's a major change, we note that in order to make it easier to keep track of what's happening, but whether that happens or not, clearly anything we agree is the right thing to do is an update. | For me, it's like proclaiming that: "everything I do is right, and if | whatever I do contravenes existing processes and procedures then my | actions implicitly update those processes and procedures such that | everything I do is right" I find that I cannot agree with such a | circular self-referential line of reasoning. There's nothing circular about it. We could adopt all kinds of bureaucratic rules, requiring us to explicitly agree to vary the rules of procedure, before doing anything that is different than has been done before - but there's really no point. If we (the community as a whole) have agreed that X is the right thing to do, then we will do whatever is necessary to be done to make X happen (since that is what we want the result to be). Insisting on lots of meaningless make-work just to get to the result that will happen anyway is pointless, we all have better things to do. | But I appreciate that I am by training a mathematician and not a lawyer, If you attempt to apply rules of mathematics to this kind of process you are certainly doomed - the two are nothing at all alike. Just consider if we did have some rule where earlier RFCs (BCPs or whatever) must always be followed - and then imagine that at some point we decided that we're happy with the rules as we have them, and include in a BCP a rule that says that none of this particular set of RFCs (including itself) may ever be updated or obsoleted. How would progress ever be made in the future given that combination of events? In mathematics it doesn't matter, what is true is true, and undisputable once proved. In other fields, circumstances change, and what was correct yesterday is incorrect today. There's a simple way out, which is one of the basic tenets of any organisation like this - and that is that we cannot bind future instances of ourselves. Anything we agree to do, following the correct procedure to get that agreement (which itself can be altered if that is so agreed), is always correct, and overrides anything inconistent that existed earlier (to the extent necessary to give effect to the new agreement). | However, it seems to me that it would be more productive | for the IETF to consider that this issue is a distinct issue, I doubt it needs consideration at all, I doubt it is even really the kind of thing that can be considered - even if we were to explicitly say that existing rules apply and can't be overridden, that would be meaningless. Attempting to believe that we know better than future generations is one of the best ways to make a mess - they will just ignore us anyway. | and not confound the consideration of the IETF Last Call of this particular | eid draft with the broader issue of the manner by which the IETF crafts | and maintains its own procedures, processes and policies. That's fine, and in that case, the IESG should ignore your earlier message as having almost no relevant content. And of course, my messages have (beyond this point) no relevance to the consideration of the draft at all. If you wanted (and if it is appropriate) you could reasonably request that the authors of the draft explain why the existing procedures are inadequate, and that the draft should be updated to include that explanation, and (or course provided that the pposition is correct, and generally accepted) that would be a push back on publishing this (and assigning the addr block). Or (or perhaps later) you could argue that the authors reasons aren't good ones, and that the existing procedures are adequate. Or you could explain why the whole experiment is useless and a waste of time, and that allocating address space to it would be senseless. Or ... Just not that "we have rules, this ignores them, so dump it" - that line of argument is bogus. kre From farinacci@gmail.com Thu Nov 22 12:56:20 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791C121F867A; Thu, 22 Nov 2012 12:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 IalP1l0FdW3a; Thu, 22 Nov 2012 12:56:20 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A45521F8675; Thu, 22 Nov 2012 12:56:19 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so4073648pad.31 for ; Thu, 22 Nov 2012 12:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=UMy02y22gBXU+oJo3bCrgsflQzMQhLikDfm9GPmh1lI=; b=cv64l7druRyo3oraWP0ca3he5nOGvfx6UPktSh96IMc7RVFn/mfGNhwb6diKO5kaYJ fQOEmYC9qmdmtpajVZzaBrxengOetepMMZJxeIoLaIoYShMcS2qt3j98u8e8I3sD9pSi wwat8buGAVWxL4f4kDnfUXT/c53Ls3D8pqpfR/ROUqhF9IeA6C1YoB7DfuN2G07CNZyq ctr9+vSvWVU/d1yvOQlAfybK9+131U0Wq/qZxDjPc9cmG1Ik+evkRc07b3/x3Yw0cb8k AEHNIN5VX7LrhpMroZpLXnyfOAOGQk7MFWdQjJOKPLUWWQgfnKfN9XaS+r2P0+f4LTbf hOjA== Received: by 10.66.80.194 with SMTP id t2mr4385589pax.43.1353617779760; Thu, 22 Nov 2012 12:56:19 -0800 (PST) Received: from [192.168.1.214] (adsl-107-198-84-82.dsl.pltn13.sbcglobal.net. [107.198.84.82]) by mx.google.com with ESMTPS id mt15sm2570601pbc.49.2012.11.22.12.56.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Nov 2012 12:56:18 -0800 (PST) References: <20121121175836.EE11B18C0D3@mercury.lcs.mit.edu> <2671C6CDFBB59E47B64C10B3E0BD592303385FBF7A@PRVPEXVS15.corp.twcable.com> <50ADF407.1090300@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <50ADF407.1090300@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A525) From: Dino Farinacci Date: Thu, 22 Nov 2012 12:56:17 -0800 To: Brian E Carpenter Cc: =?utf-8?Q?Roger_J=C3=B8rgensen?= , "lisp@ietf.org" , "ietf@ietf.org" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 20:56:20 -0000 > I would be a bit nervous about dedicating another /3 for unproven > use. There's a risk of it ending up unusable like Class E. So > if we are going to do this, doing it inside 2000::/3 seems a > bit safer to me. So what if we could say the use is simply to assign addresses out of this bl= ock that stay relatively permanent to a device that sources packets from thi= s address.=20 The address has no dependency on the topology the device connects to, the nu= mber of interfaces the device has connected to the network, or even if the d= evice is connected at all to the network.=20 So this proposal doesn't have to be associated with LISP or any other mechan= ism being used. This block could be used today as simply a PI block if no ne= w mechanism is deployed. And if a sub-block of this prefix is used for LISP= purposes, then so be it.=20 And I don't think we have to jump in with 2 feet and allocate a very coarse p= refix for this.=20 Dino= From wesley.george@twcable.com Wed Nov 21 06:58:03 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC3721F8477; Wed, 21 Nov 2012 06:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 4aL528nybOl6; Wed, 21 Nov 2012 06:58:02 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 31E5021F8458; Wed, 21 Nov 2012 06:58:02 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.83,293,1352091600"; d="scan'208";a="474942891" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 21 Nov 2012 09:57:47 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 21 Nov 2012 09:57:56 -0500 From: "George, Wes" To: Noel Chiappa , "ietf@ietf.org" , "lisp@ietf.org" Date: Wed, 21 Nov 2012 09:58:01 -0500 Thread-Topic: [lisp] Last Call: (LISP EID Block) to Informational RFC Thread-Index: Ac3H7wPoZ/jx8irBTXOMm522xE1I8wAAU15g Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592303385FBC23@PRVPEXVS15.corp.twcable.com> References: <20121121134851.6FFEF18C0CF@mercury.lcs.mit.edu> In-Reply-To: <20121121134851.6FFEF18C0CF@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 22 Nov 2012 17:56:40 -0800 Cc: "pwilson@apnic.net" , "jcurran@arin.net" Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 14:58:03 -0000 > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > Noel Chiappa > Sent: Wednesday, November 21, 2012 8:49 AM > To: ietf@ietf.org; lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu; jcurran@arin.net; pwilson@apnic.net; > iesg@ietf.org > Subject: Re: [lisp] Last Call: (LISP > EID Block) to Informational RFC > > The concept, as I understand it, is that there will be no migration "out > of [that] allocation", for the simple reason that the entire rationale > of this range of namespace is that it will be processed differently, > i.e. require special casing in the code in various places; something > like: > > if ((dest & EIDSPACEMASK) =3D=3D EIDSPACEALLOCATION) > process_one_way(); > else > process_another_way(); > > That being the case, the last thing one would want is either i) changing > the block that is handled specially, or ii) having a number of smaller > blocks, allocated over time, as either one would require much more > complex code to > handle: you'd have to have some sort of config file, which could hold > multiple blocks, code to read it, the code to process packets (above) > would have to be able to handle multiple blocks, yadda-yadda. > > (Changing the block is the same as having multiple blocks, because past > a certain point you're too big for a flag day, which would be the only > way to avoid having multiple blocks in use at the same time.) > [WEG] Then the draft needs to say some variant of the above - why it can't = migrate, why a flag day won't work, and why it needs that size block right = now for an experimental technology, including some justification about the = size of the block. If the allocation justification is not going to be done = within the RIR community, then it needs to be done here. Noel, you specific= ally complained about IETF not allowing experiments to proceed while some d= etails are still a little hand-wavey [1], but you seem to want it both ways= . If this is to be permanent space, then permanent justification and level = of detail is required. If it's to be an experiment, then it should expect t= hat there will be at least one renumber as it transitions from experiment t= o production. I don't think that expecting code to handle two blocks (the e= xperimental one and the permanent one) is asking too much, nor is it expect= ing too much to require a line in the sand to ensure that the transition be= tween experiment and production happens before "you're too big for a flag d= ay". If a single permanent allocation that never changes is truly necessary, put= ting a sunset date on the allocation from IANA seems a reasonable solution = to me, but no one really responded to that in my last mail [2]. If the expe= riment is wildly successful and leads to a permanent deployment, then the c= urrently experimental RFCs get updates written to elevate them to proposed = standard, and while we're at it, we remove the sunset date from the IANA al= location. If the experiment ends up being a science project and doesn't gai= n wide deployment, this reclaims the space to prevent it from being another= "Class E" space that is essentially stranded by an allocation that is no l= onger used. > > I suspect (I haven't communicated with them directly) that the people > who are involved with this scheme don't really care _who_ allocates the > space, and how > - all they care about is that it's all in one chunk - for the reason > laid out above. > [WEG] and the people who are involved in number allocation have clearly tol= d "the people involved in this scheme" that they do care who allocates the = space and how, especially if the experiment has no bounded end. I think a c= ompromise is doable, but saying "it's not important right now" probably isn= 't going to make the problem go away. Thanks, Wes George [1] http://www.ietf.org/mail-archive/web/ietf/current/msg75920.html [2] http://www.ietf.org/mail-archive/web/ietf/current/msg75919.html This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From brian@innovationslab.net Tue Nov 27 05:30:39 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F5321F8449; Tue, 27 Nov 2012 05:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8K75zqf1Hhx; Tue, 27 Nov 2012 05:30:38 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id DB73621F8444; Tue, 27 Nov 2012 05:30:38 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 5FEBE8809A; Tue, 27 Nov 2012 05:30:38 -0800 (PST) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0BB5B130019; Tue, 27 Nov 2012 05:30:37 -0800 (PST) Message-ID: <50B4C07C.4010807@innovationslab.net> Date: Tue, 27 Nov 2012 08:30:36 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: ietf@ietf.org References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> In-Reply-To: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 13:30:39 -0000 I want to thank everyone who has provided feedback on this draft. Given the issues raised, I am sending the draft back to the LISP WG for additional work. I encourage folks interested in this draft to participate on the LISP mailing list. Regards, Brian On 11/13/12 9:45 AM, The IESG wrote: > > The IESG has received a request from the Locator/ID Separation Protocol > WG (lisp) to consider the following document: > - 'LISP EID Block' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This is a direction to IANA to allocate a /16 IPv6 prefix for use > with the Locator/ID Separation Protocol (LISP). The prefix will be > used for local intra-domain routing and global endpoint > identification, by sites deploying LISP as EID (Endpoint IDentifier) > addressing space. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From ggx@gigix.net Wed Nov 28 00:30:32 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1916521F847B for ; Wed, 28 Nov 2012 00:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6mguYABfPrW for ; Wed, 28 Nov 2012 00:30:29 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8211C21F84FE for ; Wed, 28 Nov 2012 00:30:26 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so2554283wgb.13 for ; Wed, 28 Nov 2012 00:30:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=a702pjWqx/qZG4nvUYPK9cTRJCXegks2fnV1HuvEr0w=; b=HchNb0sxxHhosyRm7BIDcDOUbmiyAHTlahX64HA1B9NpWYo1/5ePwNQSQ6H9vhVQWv ppktLNjd0FfJz2/tD5PM5YVWAz0gj2bf2K0t23Kj6vNuUKA8x7fWPpr24e4k5Tc+ioXs R5dMdwgeFnPi6PYjiwnfSQ9K2BZ/Fl/g2L3gpHpNg6EwWSiCteRdn0qrBdpufvmCt3hu u8nL2cNaaSlfIW1XOal/vGBevkUfuTT5t9LDRe+74AnXq+LY9oQoSNiY4Ic5k4QGN833 vH0feiqtK2pqF+gehPMwmL68Ny2WQVE8wcuer2ayb+aA3rm2OOocx1HzZsNCT1UYAqbA eUUQ== Received: by 10.216.206.152 with SMTP id l24mr3505100weo.93.1354091425498; Wed, 28 Nov 2012 00:30:25 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:3d92:de20:3a6b:8e49? ([2001:660:330f:a4:3d92:de20:3a6b:8e49]) by mx.google.com with ESMTPS id cf6sm5435743wib.3.2012.11.28.00.30.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Nov 2012 00:30:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: <50B4C07C.4010807@innovationslab.net> Date: Wed, 28 Nov 2012 09:30:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <471089C3-7E53-484A-AB2B-CE0E4B9E83A0@gigix.net> References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <50B4C07C.4010807@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlViTtE3PTUjXoPJl/8SZTK3EHUkgoBfxD66nvxz8pMvO5A4ttYTz57iHEIWaz9e753OsBy Cc: ietf@ietf.org, lisp@ietf.org Subject: Re: [lisp] Last Call: (LISP EID Block) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 08:30:32 -0000 +1 Thank all for the insightful discussion that took place around this = draft.=20 Your feedback will be carefully considered to progress the work and we = welcome any further comment/feedback/help. :-) ciao Luigi On 27 Nov. 2012, at 14:30 , Brian Haberman = wrote: > I want to thank everyone who has provided feedback on this draft. = Given the issues raised, I am sending the draft back to the LISP WG for = additional work. I encourage folks interested in this draft to = participate on the LISP mailing list. >=20 > Regards, > Brian >=20 > On 11/13/12 9:45 AM, The IESG wrote: >>=20 >> The IESG has received a request from the Locator/ID Separation = Protocol >> WG (lisp) to consider the following document: >> - 'LISP EID Block' >> as Informational RFC >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments = may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >>=20 >> This is a direction to IANA to allocate a /16 IPv6 prefix for use >> with the Locator/ID Separation Protocol (LISP). The prefix will = be >> used for local intra-domain routing and global endpoint >> identification, by sites deploying LISP as EID (Endpoint = IDentifier) >> addressing space. >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ >>=20 >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ballot/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From terry.manderson@icann.org Wed Nov 28 11:28:26 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5D221F8981 for ; Wed, 28 Nov 2012 11:28:26 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGwnC9eC+peQ for ; Wed, 28 Nov 2012 11:28:25 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4469C21F87F6 for ; Wed, 28 Nov 2012 11:28:25 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 28 Nov 2012 11:28:24 -0800 From: Terry Manderson To: LISP mailing list list Date: Wed, 28 Nov 2012 11:28:20 -0800 Thread-Topic: Atlanta minutes uploaded Thread-Index: Ac3NnoX7x9Qnn6/bO0uUhm7ILWjR0Q== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3437011700_27356138" MIME-Version: 1.0 Subject: [lisp] Atlanta minutes uploaded X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 19:28:26 -0000 --B_3437011700_27356138 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Folks, The minutes from Atlanta have been uploaded ( http://www.ietf.org/proceedings/85/minutes/minutes-85-lisp) Please review them, and please make the appropriate noise levels if you see something that doesn't match your memory of the meeting.. Cheers Terry --B_3437011700_27356138 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUn0ZQIMoOSSr0UWjWnEwaRncHnqYwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTI4MTkyODIwWjANBgkqhkiG 9w0BAQEFAASCAQAh6VDR4xOyiiUlKyPdp+Rsfg139VXzkHNNaDAQYA7Y/+JswSnO55O490RZ TH+ZHwwp4xIJU3SgETsPQHGkkcwR/hVyfvHffhcnye9/FkZVMdy4iWkkGCzOkqhu1/a3E97z mbK2Pq3mZlFS16LVehWyGMYxZh+LwtoC/EFNyRwHn7nHFOTsCNPQCNoUOMrYoLNMiPeaj5md ggwCbHN6lt5xodV/NcY8tRNOJzV4O1fzHwMEw7xfA+22YUaDHwgoejKl4DXEK90QQ98UWzFk bZZqrYsuUAaRf2G8WtxdtKwAciD0zKut3vglGXT0QbfaB3twzVO0eAtUrG+KElQrrmdk --B_3437011700_27356138--