From nobody Wed Oct 1 05:58:09 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEE61A038C for ; Wed, 1 Oct 2014 05:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnUcBpSBUftM for ; Wed, 1 Oct 2014 05:58:05 -0700 (PDT) Received: from BLU004-OMC3S3.hotmail.com (blu004-omc3s3.hotmail.com [65.55.116.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1061A0346 for ; Wed, 1 Oct 2014 05:58:05 -0700 (PDT) Received: from BLU436-SMTP55 ([65.55.116.72]) by BLU004-OMC3S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22724); Wed, 1 Oct 2014 05:58:04 -0700 X-TMN: [uyTsbXWENLYjZT9JDXDjiPUKtGbyPCNY] X-Originating-Email: [pds@lugs.com] Message-ID: User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Wed, 1 Oct 2014 13:57:54 +0100 From: Peter Schoenmaker To: Thread-Topic: WGLC draft-ietf-grow-filtering-threats-03 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B_3495016683_6685390" X-OriginalArrivalTime: 01 Oct 2014 12:58:03.0838 (UTC) FILETIME=[5674DDE0:01CFDD77] Archived-At: http://mailarchive.ietf.org/arch/msg/grow/4YC8GXVxi53d2SPVbqyH00wBtnc Subject: [GROW] WGLC draft-ietf-grow-filtering-threats-03 X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 12:58:07 -0000 --B_3495016683_6685390 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello group: I would like to initiate a working group last call on draft-ietf-grow-filtering-threats-03. Between the last last call and now we received feedback on the draft and the authors have updated the draft. Please review the draft and voice your opinion as to yea or nay on this draft. WGLC will end 17th October 2014. Abstract This document describes how unexpected traffic flows can emerge across an autonomous system, as the result of other autonomous systems filtering, or restricting the propagation of overlapping prefixes. We provide a review of the techniques to detect the occurrence of this issue and defend against it. Thanks Peter --B_3495016683_6685390 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello group:

I would like to initiate a working group last call on draft-ietf-gr= ow-filtering-threats-03. Between the last last call and now we receive= d feedback on the draft and the authors have updated the draft.

Please review the draft and voice your opinion as to yea or nay= on this draft. WGLC will end 17th October 2014.

<= div>

Abstract

This document d= escribes how unexpected traffic flows can emerge

acro= ss an autonomous system, as the result of other autonomous

= systems filtering, or restricting the propagation of overlapping

prefixes. We provide a review of the techniques to d= etect the

occurrence of this issue and defend against= it.

Thanks

Pe= ter

--B_3495016683_6685390-- From nobody Fri Oct 10 10:41:39 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D60D1A908B for ; Fri, 10 Oct 2014 10:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.348 X-Spam-Level: * X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGV1NFCf9Drg for ; Fri, 10 Oct 2014 10:41:36 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0F01A6EE2 for ; Fri, 10 Oct 2014 10:41:35 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,693,1406606400"; d="scan'208";a="541197480" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 10 Oct 2014 13:36:43 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 10 Oct 2014 13:41:34 -0400 From: "George, Wes" To: Peter Schoenmaker , "grow@ietf.org" Date: Fri, 10 Oct 2014 13:43:14 -0400 Thread-Topic: [GROW] WGLC draft-ietf-grow-filtering-threats-03 Thread-Index: Ac/ksW8acVHhxFdtQTClRwtrqYKfhA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/grow/9MT__P9jKGSR378hDI5fJ0rJ6eE Subject: Re: [GROW] WGLC draft-ietf-grow-filtering-threats-03 X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 17:41:38 -0000 SSd2ZSBkb25lIGFub3RoZXIgcmV2aWV3IHBhc3MuDQpNb3N0IG9mIG15IHByZXZpb3VzIGNvbW1l bnRzIGhhdmUgYmVlbiBhZGRyZXNzZWQsIGFuZCB0aGUgZG9jdW1lbnQgaGFzDQppbXByb3ZlZCBh IGxvdCwgYnV0IHRoZXJlIGFyZSBhIGNvdXBsZSBvZiB0aGluZ3Mgc3RpbGwgb3V0c3RhbmRpbmcs IGFzDQp3ZWxsIGFzIGEgZmV3IG5ldyBjb21tZW50cy4gSSB0aGluayB0aGV5IG5lZWQgdG8gYmUg YWRkcmVzc2VkIGJlZm9yZSB0aGlzDQpwcm9jZWVkcyB0byBJRVNHLCBlc3BlY2lhbGx5IHNpbmNl IHRoZSBkb2N1bWVudCB3b24ndCBldmVuIHBhc3MgYSBOSVRTDQpjaGVjayByaWdodCBub3cgKGNs aWNrIE5JVFMgb24gdGhlIHVwcGVyIHJpZ2h0IG9mIHRoZSBIVE1MIHZlcnNpb24gb2YgdGhlDQpk b2N1bWVudCB0byBzZWUgdGhlbSkuDQoNCk1heSB3YW50IHRvIGNvbnNpZGVyIHRoZSB0ZXJtaW5v bG9neSB3aXRoIHJlbGF0aW9uIHRvIFNJRFIncyBkZWZpbml0aW9ucw0Kb2YgY292ZXJlZCBwcmVm aXhlcy4gUmlnaHQgbm93IGl0IGNvbmZsaWN0cyBhbmQgY2FuIGJlIHBvdGVudGlhbGx5DQpjb25m dXNpbmcsIHNvIHlvdSBtaWdodCB3YW50IHRvIHVzZSBhIGRpZmZlcmVudCB0ZXJtLiAoc2VlIFJG QyA2OTA3KQ0KDQpJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoaXMgaXMgdGl0bGVkICJtYWtpbmcg QkdQIGZpbHRlcmluZyBhIGhhYml0IiBhcyBpdA0KaXMgcmVhbGx5IGRpc2N1c3NpbmcgcHJvYmxl bXMgd2l0aCBCR1AgZmlsdGVyaW5nLCByYXRoZXIgdGhhbiBhZHZvY2F0aW5nDQpkb2luZyBpdC4N Cg0KMi4xIGZpbHRlcmluZyBjYW4gYWxzbyBiZSBkdWUgdG8gaGFyZHdhcmUgbGltaXRhdGlvbnMg KHRoZSBoYXJkd2FyZSBpcyBub3QNCmNhcGFibGUgb2YgYSBmdWxsIERGWiB0YWJsZSkuIEJhc2lj YWxseSAiSSBkb24ndCBjYXJlIGFib3V0IG90aGVyDQpuZXR3b3JrcycgVEUgZGVhZ2dyZWdhdGlv biwgSSBjYW4ndCBjYXJyeSBhbGwgb2YgdGhhdCBmbHVmZiwgc28gSSdtIGdvaW5nDQp0byBmaWx0 ZXIgZGVhZ2dyZWdhdGVzIGJlY2F1c2Ugb3RoZXIgbmV0d29ya3MgaGF2aW5nIHRvIGRlYWwgd2l0 aCBzb21lDQp1bndhbnRlZCB0cmFmZmljIHNoaWZ0cyBpcyBiZXR0ZXIgdGhhbiBteSByb3V0ZXJz IGFsbCBmYWxsaW5nIG92ZXIgZHVlIHRvDQpyb3V0aW5nIHRhYmxlIGJsb2F0Ig0KDQozLjEgLSBt YXkgd2FudCB0byBzcGVjaWZpY2FsbHkgbWVudGlvbiBCR1AgYW5vbWFseSBkZXRlY3Rpb24gdG9v bHMsIGkuZS4NCnRvb2xzIHRoYXQgbW9uaXRvciB0aGUgQkdQIHRhYmxlIHZpYSBvbmUgb3IgbW9y ZSBsb29raW5nIGdsYXNzZXMsIGFuZA0KYWxlcnQgd2hlbiBhIHNpZ25pZmljYW50IGNoYW5nZSBp cyBkZXRlY3RlZC4gV2hpbGUgdGhlc2Ugd29uJ3QgZGV0ZWN0DQpjb25zdGFudC9jb25zaXN0ZW50 IHByZWZpeCBmaWx0ZXJpbmcsIHRoZXkgc2hvdWxkIGRldGVjdCBuZXcgaW5zdGFuY2VzDQpzaW5j ZSB0aGV5J2xsIGxvb2sgZGlmZmVyZW50IGZyb20gcHJldmlvdXMgc25hcHNob3RzLg0KDQo0LjEg InN0b3AgYW5ub3VuY2luZyBjb3ZlcmluZyBwcmVmaXgiIC0gYWRkIHRleHQgdG8gd2FybiBvZiB0 aGUgbmVlZCB0bw0KbWFrZSBzdXJlIHRoYXQgdGhlcmUgYXJlIG90aGVyIHN1Ym5ldCBwcmVmaXhl cyB0aGF0IGNvdmVyIHRoZSByZXN0IG9mIHRoZQ0KY292ZXJpbmcgcHJlZml4LiB5b3VyIGV4YW1w bGVzIHVzZSAvMzIgYW5kIC8zNC4gSWYgeW91IHJlbW92ZSB0aGUgLzMyLCB5b3UNCm5lZWQgdG8g YWRkIGFkZGl0aW9uYWwgYW5ub3VuY2VtZW50cyB0byBtYWtlIHN1cmUgdGhhdCB0aGVyZSBpcyBz dGlsbA0KcmVhY2hhYmlsaXR5IHRvIHRoZSByZXN0IG9mIHRoZSAvMzIgKHRoZSBvdGhlciAzIC8z NHMpIHRoYXQgaXMgbm90DQppbmNsdWRlZCBpbiB0aGUgbW9yZSBzcGVjaWZpYyAvMzQuIEhhdmUg dG8gY29uc2lkZXIgd2hldGhlciB0aGlzIGlzDQphbHJlYWR5IHBlcm1pdHRlZCB0aHJvdWdoIHRo ZSB1cHN0cmVhbSBCR1AgZmlsdGVycyBvciBtYXkgY2F1c2UgdGhlDQpvcHBvc2l0ZSBlZmZlY3Qg b2YgcHJvdmlkaW5nIGEgbW9yZSBzcGVjaWZpYyByb3V0ZSBmb3IgdGhvc2Ugb3RoZXINCnByZWZp eGVzIG5vdyBpbnN0ZWFkDQoNCiAgICAgICJJbiB0aGlzIGNhc2UsIG5vdCBhbGwgdHJhZmZpYw0K ICAgICAgaGVhZGluZyB0byB0aGUgcHJlZml4IDIwMDE6REI4OjovMzIgZnJvbSBBUzY0NTAxIHdv dWxkIG5vIGxvbmdlcg0KICAgICAgdHJhdmVyc2UgQVM2NDUwMi4gIg0KSSdtIGhhdmluZyB0cm91 YmxlIHBhcnNpbmcgdGhlIG1lYW5pbmcgb2YgdGhpcyBzZW50ZW5jZS4gV2hhdCBkb2VzICJub3QN CmFsbCB0cmFmZmljIiBtZWFuIGluIHRoaXMgY2FzZT8gU29tZSBzdGlsbCBkb2VzPyBBbHNvIG1h eSBiZSBjbGVhbmVyIHRvDQpzYXkgIndvdWxkIHRyYXZlcnNlIGEgZGlmZmVyZW50IEFTTiIgKGlu c3RlYWQgb2YgIndvdWxkIG5vIGxvbmdlcg0KdHJhdmVyc2UuLi4iKQ0KDQo0LjIuMSAiY29uZmln dXJlIGl0cyByb3V0ZXJzIHRvIGluc3RhbGwgZHluYW1pY2FsbHkgYW4gYWNjZXNzLWxpc3QuLi4i IC0tDQpob3c/IEZlYXR1cmUgbmFtZT8gSXMgdGhpcyBjb21tb25seSBzdXBwb3J0ZWQsIG9yIHNw ZWNpZmljIHRvIGEgc2V0IG9mDQp2ZW5kb3JzPw0KRHluYW1pY2FsbHkgaW1wbGllcyB0aGF0IHRo aXMgaXMgZG9uZSBhdXRvbWF0aWNhbGx5IHZpYSBzb21lIHNvcnQgb2YNCmJhY2tncm91bmQgcHJv Y2VzcyBpbiB0aGUgcm91dGVyLCByYXRoZXIgdGhhbiBiYXNlZCBvbiBhIG1hbnVhbCwgYnV0DQpj aGFuZ2luZyBjb25maWd1cmF0aW9uLCBzbyBpdCBtYXkganVzdCBiZSB0aGF0IHlvdSBuZWVkIHRv IGNsYXJpZnkgdGhhdA0KdGhpcyBpcyBkb25lIG1hbnVhbGx5IGJ1dCBtYXkgY2hhbmdlIGZyZXF1 ZW50bHkuDQoNCnJlZmVyZW5jZXMgYXJlIHN0aWxsIG5vdCBzdGFuZGFyZCB0byBJRVRGIGZvcm1h dCwgYW5kIHRoZSBkaXN0aW5jdGlvbg0KYmV0d2VlbiBVUkkgYW5kIHJlZmVyZW5jZXMgd2l0aCBv dmVybGFwcGluZyBmb290bm90ZSBudW1iZXJzIGlzDQpwb3RlbnRpYWxseSBjb25mdXNpbmcuIHVz ZSBhbm90aGVyIEktRCBhcyBhIGd1aWRlbGluZSwgb3Igc2VlIHAgMTQtMTUgb2YNCmh0dHA6Ly93 d3cucmZjLWVkaXRvci5vcmcvcmZjLXN0eWxlLWd1aWRlL3JmYy1zdHlsZQ0KUmVmZXJlbmNlIFsz XSBubyBsb25nZXIgc2VlbXMgdG8gYmUgcmVmZXJlbmNlZCBpbiB0aGUgdGV4dCBhdCBhbGwsIGFu ZA0KeW91ciByZWZlcmVuY2VzIHRvIFsyXSBhbmQgWzRdIGluIHRoZSB0ZXh0IHdvdWxkIGJlIG1v cmUgdXNlZnVsIGlmIHRoZXkNCmRpc2N1c3NlZCB0aGUgbGluayBiZXR3ZWVuIHRoZSBwcm9wb3Nl ZCBzb2x1dGlvbiBhbmQgdGhlIHJlZmVyZW5jZWQgcGFwZXINCmluIG1vcmUgZGV0YWlsLiBSaWdo dCBub3cgdGhlIGxpbmsgYmV0d2VlbiB0aGUgdHdvIGlzIG5vdCBjbGVhciBldmVuIGFmdGVyDQpy ZXZpZXdpbmcgdGhlIHJlZmVyZW5jZS4gSXQgbWF5IGJlIHRoYXQgdGhlcmUgaXMgYW5vdGhlciBk cmFmdCBuZWVkZWQgdG8NCmRpc2N1c3MgdGhlIGFwcGxpY2F0aW9uIG9mIHRoZSByZWZlcmVuY2Vk IHNvbHV0aW9uIHRvIHRoaXMgcHJvYmxlbSByYXRoZXINCnRoYW4gY292ZXJpbmcgaXQgaGVyZSwg YnV0IGVpdGhlciB3YXksIHNpbXBseSBwcm92aWRpbmcgdGhlIHJlZmVyZW5jZSB3aXRoDQpubyBh ZGRpdGlvbmFsIGRpc2N1c3Npb24gaXNu4oCZdCBlbm91Z2guDQoNCkkgc2VlIHRoYXQgdGhlIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gaGFzIGJlZW4gYWRkZWQsIGJ1dCBpdCdzDQpz dGlsbCBwcmV0dHkgdGhpbi4gSXQgbWF5IGJlIGFwcHJvcHJpYXRlIHRvIHJlZmVyZW5jZSB0aGUg cm91dGUgbGVha3MNCmRyYWZ0IGFzIGEgc29tZXdoYXQgcmVsYXRlZCB0eXBlIG9mIHJvdXRpbmcg c2VjdXJpdHkgZGlzY3Vzc2lvbiwgYW5kIGF0IGENCm1pbmltdW0geW91IG5lZWQgdG8gYmUgZXhw bGljaXQgaW4gdGhpcyBzZWN0aW9uIHRoYXQgdGhlcmUgYXJlIHJlYWxseSBubw0KZXhpc3Rpbmcg b3IgcHJvcG9zZWQgdG9vbHMgdG8gcHJvdGVjdCBhZ2FpbnN0IHRoYXQgc29ydCBvZiBiZWhhdmlv ciBzaW5jZQ0KZmlsdGVyaW5nIHBvbGljeSBpcyBtb3N0bHkgb2YgbG9jYWwgc2lnbmlmaWNhbmNl Lg0KDQoNCk5pdHM6DQolcy9lY29ub21pY2FsL2Vjb25vbWljDQo0IC0gbWF5IHdhbnQgdG8gdXNl ICJwcm9hY3RpdmUiIGluc3RlYWQgb2YgYW50aWNpcGFudCwgc2luY2UgdGhhdCdzIGEgbW9yZQ0K Y29tbW9uIGFudG9ueW0gZm9yIHJlYWN0aXZlDQoNCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQoNCkZy b206ICBQZXRlciBTY2hvZW5tYWtlciA8cGRzQGx1Z3MuY29tPg0KRGF0ZTogIFdlZG5lc2RheSwg T2N0b2JlciAxLCAyMDE0IGF0IDg6NTcgQU0NClRvOiAgImdyb3dAaWV0Zi5vcmciIDxncm93QGll dGYub3JnPg0KU3ViamVjdDogIFtHUk9XXSBXR0xDIGRyYWZ0LWlldGYtZ3Jvdy1maWx0ZXJpbmct dGhyZWF0cy0wMw0KDQoNCkhlbGxvIGdyb3VwOg0KDQpJIHdvdWxkIGxpa2UgdG8gaW5pdGlhdGUg YSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KZHJhZnQtaWV0Zi1ncm93LWZpbHRlcmluZy10 aHJlYXRzLTAzLiAgQmV0d2VlbiB0aGUgbGFzdCBsYXN0IGNhbGwgYW5kIG5vdw0Kd2UgcmVjZWl2 ZWQgZmVlZGJhY2sgb24gdGhlIGRyYWZ0IGFuZCB0aGUgYXV0aG9ycyBoYXZlIHVwZGF0ZWQgdGhl IGRyYWZ0Lg0KDQpQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQgdm9pY2UgeW91ciBvcGluaW9u IGFzIHRvIHllYSBvciBuYXkgb24gdGhpcw0KZHJhZnQuICBXR0xDIHdpbGwgZW5kIDE3dGggT2N0 b2JlciAyMDE0Lg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cg dW5leHBlY3RlZCB0cmFmZmljIGZsb3dzIGNhbiBlbWVyZ2UNCiAgIGFjcm9zcyBhbiBhdXRvbm9t b3VzIHN5c3RlbSwgYXMgdGhlIHJlc3VsdCBvZiBvdGhlciBhdXRvbm9tb3VzDQogICBzeXN0ZW1z IGZpbHRlcmluZywgb3IgcmVzdHJpY3RpbmcgdGhlIHByb3BhZ2F0aW9uIG9mIG92ZXJsYXBwaW5n DQogICBwcmVmaXhlcy4gIFdlIHByb3ZpZGUgYSByZXZpZXcgb2YgdGhlIHRlY2huaXF1ZXMgdG8g ZGV0ZWN0IHRoZQ0KICAgb2NjdXJyZW5jZSBvZiB0aGlzIGlzc3VlIGFuZCBkZWZlbmQgYWdhaW5z dCBpdC4NCg0KDQoNClRoYW5rcw0KDQpQZXRlcg0KDQoNCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55 IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmll dGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBz dWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMg RS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0 aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0 YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRo aXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBh bmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Mon Oct 13 08:00:32 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9CD1A0195 for ; Mon, 13 Oct 2014 08:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umDJynKcds9l for ; Mon, 13 Oct 2014 08:00:27 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33841A02DC for ; Mon, 13 Oct 2014 08:00:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id 127861C8E24; Mon, 13 Oct 2014 17:00:18 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta21.imdea.org ([127.0.0.1]) by localhost (estafeta21.imdea.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spZ-wLCPuOkU; Mon, 13 Oct 2014 17:00:17 +0200 (CEST) Received: from dhcp-10-61-106-6.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: juancamilo.cardona) by estafeta21.imdea.org (imdea mail daemon) with ESMTPSA id 7F6031C8E23; Mon, 13 Oct 2014 17:00:13 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_26D44CD1-EC83-4E0C-8ED0-FB1D2BC2F751" Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: Camilo Cardona In-Reply-To: Date: Mon, 13 Oct 2014 17:00:17 +0200 Message-Id: <0C407E55-73C3-4056-9A4B-42C33DB477F2@imdea.org> References: To: "George, Wes" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/grow/Mjf0NXGzcazQtLTkgyi11OMavEc Cc: "grow@ietf.org" Subject: Re: [GROW] WGLC draft-ietf-grow-filtering-threats-03 X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:00:31 -0000 --Apple-Mail=_26D44CD1-EC83-4E0C-8ED0-FB1D2BC2F751 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Wes, Thank you again for all your detailed comments and recommendations. = Please give us a few days to take a careful look at them and come back = with an answer. Regards, Camilo Cardona On 10 Oct 2014, at 19:43, George, Wes wrote: > I've done another review pass. > Most of my previous comments have been addressed, and the document has > improved a lot, but there are a couple of things still outstanding, as > well as a few new comments. I think they need to be addressed before = this > proceeds to IESG, especially since the document won't even pass a NITS > check right now (click NITS on the upper right of the HTML version of = the > document to see them). >=20 > May want to consider the terminology with relation to SIDR's = definitions > of covered prefixes. Right now it conflicts and can be potentially > confusing, so you might want to use a different term. (see RFC 6907) >=20 > I don't understand why this is titled "making BGP filtering a habit" = as it > is really discussing problems with BGP filtering, rather than = advocating > doing it. >=20 > 2.1 filtering can also be due to hardware limitations (the hardware is = not > capable of a full DFZ table). Basically "I don't care about other > networks' TE deaggregation, I can't carry all of that fluff, so I'm = going > to filter deaggregates because other networks having to deal with some > unwanted traffic shifts is better than my routers all falling over due = to > routing table bloat" >=20 > 3.1 - may want to specifically mention BGP anomaly detection tools, = i.e. > tools that monitor the BGP table via one or more looking glasses, and > alert when a significant change is detected. While these won't detect > constant/consistent prefix filtering, they should detect new instances > since they'll look different from previous snapshots. >=20 > 4.1 "stop announcing covering prefix" - add text to warn of the need = to > make sure that there are other subnet prefixes that cover the rest of = the > covering prefix. your examples use /32 and /34. If you remove the /32, = you > need to add additional announcements to make sure that there is still > reachability to the rest of the /32 (the other 3 /34s) that is not > included in the more specific /34. Have to consider whether this is > already permitted through the upstream BGP filters or may cause the > opposite effect of providing a more specific route for those other > prefixes now instead >=20 > "In this case, not all traffic > heading to the prefix 2001:DB8::/32 from AS64501 would no longer > traverse AS64502. " > I'm having trouble parsing the meaning of this sentence. What does = "not > all traffic" mean in this case? Some still does? Also may be cleaner = to > say "would traverse a different ASN" (instead of "would no longer > traverse...") >=20 > 4.2.1 "configure its routers to install dynamically an access-list..." = -- > how? Feature name? Is this commonly supported, or specific to a set of > vendors? > Dynamically implies that this is done automatically via some sort of > background process in the router, rather than based on a manual, but > changing configuration, so it may just be that you need to clarify = that > this is done manually but may change frequently. >=20 > references are still not standard to IETF format, and the distinction > between URI and references with overlapping footnote numbers is > potentially confusing. use another I-D as a guideline, or see p 14-15 = of > http://www.rfc-editor.org/rfc-style-guide/rfc-style > Reference [3] no longer seems to be referenced in the text at all, and > your references to [2] and [4] in the text would be more useful if = they > discussed the link between the proposed solution and the referenced = paper > in more detail. Right now the link between the two is not clear even = after > reviewing the reference. It may be that there is another draft needed = to > discuss the application of the referenced solution to this problem = rather > than covering it here, but either way, simply providing the reference = with > no additional discussion isn=92t enough. >=20 > I see that the security considerations section has been added, but = it's > still pretty thin. It may be appropriate to reference the route leaks > draft as a somewhat related type of routing security discussion, and = at a > minimum you need to be explicit in this section that there are really = no > existing or proposed tools to protect against that sort of behavior = since > filtering policy is mostly of local significance. >=20 >=20 > Nits: > %s/economical/economic > 4 - may want to use "proactive" instead of anticipant, since that's a = more > common antonym for reactive >=20 >=20 > Thanks, >=20 > Wes >=20 >=20 >=20 > From: Peter Schoenmaker > Date: Wednesday, October 1, 2014 at 8:57 AM > To: "grow@ietf.org" > Subject: [GROW] WGLC draft-ietf-grow-filtering-threats-03 >=20 >=20 > Hello group: >=20 > I would like to initiate a working group last call on > draft-ietf-grow-filtering-threats-03. Between the last last call and = now > we received feedback on the draft and the authors have updated the = draft. >=20 > Please review the draft and voice your opinion as to yea or nay on = this > draft. WGLC will end 17th October 2014. >=20 > Abstract >=20 > This document describes how unexpected traffic flows can emerge > across an autonomous system, as the result of other autonomous > systems filtering, or restricting the propagation of overlapping > prefixes. We provide a review of the techniques to detect the > occurrence of this issue and defend against it. >=20 >=20 >=20 > Thanks >=20 > Peter >=20 >=20 >=20 >=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. > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow --Apple-Mail=_26D44CD1-EC83-4E0C-8ED0-FB1D2BC2F751 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Wes,

Thank you again for all your detailed comments and recommendations. Please give us a few days to take a careful look at = them and come back with an answer.

Regards,

Camilo = Cardona

On 10 Oct 2014, at 19:43, George, Wes <wesley.george@twcable.com>= ; wrote:

I've done another review = pass.
Most of my previous comments have been addressed, and the = document has
improved a lot, but there are a couple of things still = outstanding, as
well as a few new comments. I think they need to be = addressed before this
proceeds to IESG, especially since the document = won't even pass a NITS
check right now (click NITS on the upper right = of the HTML version of the
document to see them).

May want to = consider the terminology with relation to SIDR's definitions
of = covered prefixes. Right now it conflicts and can be = potentially
confusing, so you might want to use a different term. = (see RFC 6907)

I don't understand why this is titled "making BGP = filtering a habit" as it
is really discussing problems with BGP = filtering, rather than advocating
doing it.

2.1 filtering can = also be due to hardware limitations (the hardware is not
capable of a = full DFZ table). Basically "I don't care about other
networks' TE = deaggregation, I can't carry all of that fluff, so I'm going
to = filter deaggregates because other networks having to deal with = some
unwanted traffic shifts is better than my routers all falling = over due to
routing table bloat"

3.1 - may want to = specifically mention BGP anomaly detection tools, i.e.
tools that = monitor the BGP table via one or more looking glasses, and
alert when = a significant change is detected. While these won't = detect
constant/consistent prefix filtering, they should detect new = instances
since they'll look different from previous = snapshots.

4.1 "stop announcing covering prefix" - add text to = warn of the need to
make sure that there are other subnet prefixes = that cover the rest of the
covering prefix. your examples use /32 and = /34. If you remove the /32, you
need to add additional announcements = to make sure that there is still
reachability to the rest of the /32 = (the other 3 /34s) that is not
included in the more specific /34. = Have to consider whether this is
already permitted through the = upstream BGP filters or may cause the
opposite effect of providing a = more specific route for those other
prefixes now = instead

     "In this case, not all = traffic
     heading to the prefix = 2001:DB8::/32 from AS64501 would no = longer
     traverse AS64502. "
I'm = having trouble parsing the meaning of this sentence. What does = "not
all traffic" mean in this case? Some still does? Also may be = cleaner to
say "would traverse a different ASN" (instead of "would no = longer
traverse...")

4.2.1 "configure its routers to install = dynamically an access-list..." --
how? Feature name? Is this commonly = supported, or specific to a set of
vendors?
Dynamically implies = that this is done automatically via some sort of
background process = in the router, rather than based on a manual, but
changing = configuration, so it may just be that you need to clarify that
this = is done manually but may change frequently.

references are still = not standard to IETF format, and the distinction
between URI and = references with overlapping footnote numbers is
potentially = confusing. use another I-D as a guideline, or see p 14-15 of
http://www.rf= c-editor.org/rfc-style-guide/rfc-style
Reference [3] no longer = seems to be referenced in the text at all, and
your references to [2] = and [4] in the text would be more useful if they
discussed the link = between the proposed solution and the referenced paper
in more = detail. Right now the link between the two is not clear even = after
reviewing the reference. It may be that there is another draft = needed to
discuss the application of the referenced solution to this = problem rather
than covering it here, but either way, simply = providing the reference with
no additional discussion isn=92t = enough.

I see that the security considerations section has been = added, but it's
still pretty thin. It may be appropriate to reference = the route leaks
draft as a somewhat related type of routing security = discussion, and at a
minimum you need to be explicit in this section = that there are really no
existing or proposed tools to protect = against that sort of behavior since
filtering policy is mostly of = local significance.

Nits:
%s/economical/economic
4 - = may want to use "proactive" instead of anticipant, since that's a = more
common antonym for = reactive

Thanks,

Wes

From: Peter = Schoenmaker <pds@lugs.com>
Date: = Wednesday, October 1, 2014 at 8:57 AM
To: "grow@ietf.org" <grow@ietf.org>
Subject: = [GROW] WGLC draft-ietf-grow-filtering-threats-03

Hello = group:

I would like to initiate a working group last call = on
draft-ietf-grow-filtering-threats-03. Between the last last = call and now
we received feedback on the draft and the authors have = updated the draft.

Please review the draft and voice your opinion = as to yea or nay on this
draft. WGLC will end 17th October = 2014.

Abstract

  This document describes how = unexpected traffic flows can emerge
  across an autonomous = system, as the result of other autonomous
  systems = filtering, or restricting the propagation of = overlapping
  prefixes. We provide a review of the = techniques to detect the
  occurrence of this issue and = defend against = it.

Thanks

Peter

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.
_______________________________________________
GROW = mailing list
GROW@ietf.org
https://www.ietf.org/m= ailman/listinfo/grow

= --Apple-Mail=_26D44CD1-EC83-4E0C-8ED0-FB1D2BC2F751-- From nobody Wed Oct 15 05:29:40 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663A81A6EF8; Wed, 15 Oct 2014 05:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By1W2EU2bYwf; Wed, 15 Oct 2014 05:29:37 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BDA1A1F70; Wed, 15 Oct 2014 05:29:37 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:bdfd:214d:a71:4d8c] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9FCRROk053916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2014 14:27:27 +0200 (CEST) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 15 Oct 2014 14:29:25 +0200 To: v6ops@ietf.org, grow@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/grow/zDqGNYeqoilcLvDYse0GsqHbpWQ Subject: [GROW] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 12:29:39 -0000 We are all familiar with PA (provider aggregatable) and PI (provider = independent) address space. But it turns out a new type of IPv6 address = space is starting to show up, which I'll call organization = deaggregatable (OD) address space (until someone suggests a better = name). How it works is like this: a large organization obtains a large block of = IPv6 address space, either as a very large PI block or by becoming a = local internet registry (LIR) and getting a regular LIR assignment = directly from one of the five regional registries. However, rather than = advertising that block in BGP as a single prefix, or perhaps a handful = of prefixes, like an ISP would, they subdivide this block within the = organization and then many subunits advertise subprefixes though = different ISPs. The aggregate may or may not be advertised. The advantage to the organization is that they have provider independent = address space that they'll never have to renumber out of, as well as = having a single prefix that identifies all of the organization, which = makes filtering easy. There seem to be two types of organizations that do this: geographically = dispersed ones that advertise subprefixes in different locations, such = as multinationals, and organizations with very independent subunits but = with more limited geographical scope, such as national governments. This practice, especially if/when it becomes more common, presents two = challenges: 1. Large numbers of prefixes may show up in the global routing table. = For instance, there is a number plan for all of the German government, = which could potentially inject more than 5000 municipality prefixes into = the global IPv6 routing table. 2. Filtering. If people want to avoid large numbers of deaggregates in = their routing tables, they may employ some kind of filtering, especially = if the deaggregates are very long prefixes. This means that packets are = no longer reliably delivered to the place announcing a more specific = prefix. Ideally, a set of best practices would be developed that strike a good = balance between the needs of large organizations and the needs of the = global routing system, and allow everyone to predict the consequences of = different kinds of behavior and thus avoid unpleasant surprises. These are some of the things that could go into such best practices: - A well-understood maximum prefix length for IPv6, similar to /24 for = IPv4. - An understanding of how the service providers that provide = connectivity to multiple subunits of a large organization can work = together in order to maximize availability and minimize costs for the = organization, the service providers and other network operators. - A way to provide a point of last resort where traffic for the = aggregate can be sent to if more specifics are filtered. - A set of communities that indicate whether a prefix is a more specific = that is covered by an aggregate and/or is safe to filter without loss of = connectivity. - A set of communities that indicate geographical origin of prefixes so = remote more specific prefixes can be filtered while local prefixes are = kept. - Guidelines for reserving address space in address plans. Is it better = to have free space reserved so existing prefixes can grow, or keep = reserved space together so tight prefix length filters are possible and = reserved space isn't broken up into small pieces? Please note that I'm crosspositing this to v6ops and grow initially. If = the chairs have any guidance on which working group is more appropriate = for this discussion, please let us know and we can drop the other one. Also note that I haven't been following discussions in both wgs = recently, so if this has been discussed previously, my apologies. Last but not least, this treads on RIR policy. But in my opinion, this = is foremost a technical matter with global implications and as such is = best discussed within the IETF rather than in the five respective policy = development forums.= From nobody Wed Oct 15 05:41:43 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB4A1A6F47; Wed, 15 Oct 2014 05:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c5_uFfMDMXW; Wed, 15 Oct 2014 05:41:41 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3AC1A6F41; Wed, 15 Oct 2014 05:41:40 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9FCfBEc036309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2014 13:41:33 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <543E6B66.5050803@inex.ie> Date: Wed, 15 Oct 2014 13:41:10 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Iljitsch van Beijnum , v6ops@ietf.org, grow@ietf.org References: In-Reply-To: X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/grow/NGTt3E-MdUf91hlf_URcb2vAHNI Subject: Re: [GROW] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 12:41:42 -0000 On 15/10/2014 13:29, Iljitsch van Beijnum wrote: > There seem to be two types of organizations that do this: geographically > dispersed ones that advertise subprefixes in different locations, such > as multinationals, and organizations with very independent subunits but > with more limited geographical scope, such as national governments. and organisations who have a requirement for traffic engineering, whether this requirement is real or imaginary - there are well known examples of each. Nick From nobody Wed Oct 15 05:44:01 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAC11A1B74; Wed, 15 Oct 2014 05:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6REXdMSOmW0; Wed, 15 Oct 2014 05:43:56 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8617D1A01AA; Wed, 15 Oct 2014 05:43:56 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:bdfd:214d:a71:4d8c] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9FCfkIm054018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2014 14:41:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: Iljitsch van Beijnum In-Reply-To: <543E6B66.5050803@inex.ie> Date: Wed, 15 Oct 2014 14:43:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <543E6B66.5050803@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/grow/sQ2daBYh7cMLxRa6eqY6aOGTduM Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [GROW] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 12:43:59 -0000 On 15 Oct 2014, at 14:41, Nick Hilliard wrote: >> There seem to be two types of organizations that do this: = geographically >> dispersed ones that advertise subprefixes in different locations, = such >> as multinationals, and organizations with very independent subunits = but >> with more limited geographical scope, such as national governments. > and organisations who have a requirement for traffic engineering, = whether this requirement is real or imaginary - there are well known = examples of each. Right, we should probably add that. Although I wouldn't expect an organization to deaggregate down to = hundreds or thousands of more specifics just for traffic engineering.= From nobody Wed Oct 15 05:47:09 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F31E1A1B94; Wed, 15 Oct 2014 05:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4LMTC4QbAhy; Wed, 15 Oct 2014 05:47:03 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8169D1A1B8B; Wed, 15 Oct 2014 05:47:03 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9FCl1sY036579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2014 13:47:01 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <543E6CC3.5020202@inex.ie> Date: Wed, 15 Oct 2014 13:46:59 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <543E6B66.5050803@inex.ie> In-Reply-To: X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/grow/Alq7r3oX_exSwsDJOfDRn00lYPE Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [GROW] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 12:47:05 -0000 On 15/10/2014 13:43, Iljitsch van Beijnum wrote: > Although I wouldn't expect an organization to deaggregate down to hundreds or thousands of more specifics just for traffic engineering. probably not no, but on the basis of visibility into IXP announcements with prefix analysis to see what's going on, some organisations do spectacularly bizarre things with no possible rational explanation. Nick From nobody Wed Oct 15 08:14:20 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE4C1A86DE; Wed, 15 Oct 2014 08:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr69Pfi49-7y; Wed, 15 Oct 2014 08:14:15 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5248B1A8546; Wed, 15 Oct 2014 08:14:09 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 39FB61B8305; Wed, 15 Oct 2014 08:14:09 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 31AD553E076; Wed, 15 Oct 2014 08:14:09 -0700 (PDT) Received: from [192.168.1.63] (71.201.198.58) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 15 Oct 2014 08:14:08 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: Ted Lemon In-Reply-To: Date: Wed, 15 Oct 2014 10:14:02 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <5B13739D-5BFD-467C-8DF0-D391508EB5C0@nominum.com> References: To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.201.198.58] Archived-At: http://mailarchive.ietf.org/arch/msg/grow/F-nZIUF30SKRp6n-u6FwlwDNOVg Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [GROW] [v6ops] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:14:18 -0000 On Oct 15, 2014, at 7:29 AM, Iljitsch van Beijnum = wrote: > However, rather than advertising that block in BGP as a single prefix, = or perhaps a handful of prefixes, like an ISP would, they subdivide this = block within the organization and then many subunits advertise = subprefixes though different ISPs. The aggregate may or may not be = advertised. Yuck. Has anybody done an analysis of how this works with RPKI? = Seems like an obvious attack surface if the RPKI isn't present or isn't = done right. From nobody Wed Oct 15 15:04:53 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FC81ACDDD; Wed, 15 Oct 2014 15:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7XFtB27xd6r; Wed, 15 Oct 2014 15:04:36 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B711ACDC6; Wed, 15 Oct 2014 15:04:35 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id im17so1721712vcb.24 for ; Wed, 15 Oct 2014 15:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Us4QXQ88bVisLNU5vQSRHP9Tc3AMKGO93gn6ZFpeW4s=; b=qxyQdjCY7g1yg7DjIJ5SCQBzsExNdV1epTXQnjXm9u8l4L/yHIItMvV/OOO3uf+xwX v4B2+ee51xikQ6KbCvHXxD900XIxrmaWu7mJx6wrBTbcO6mdjaJfqzRoxfpqJCbSLaLv 6cM4YNUBy+ogRsGDhQkMNRkoV0BdXPzeTX0Z0sibHRXRaE+qcUDiuWR3YxP4XHFNO5P1 2JuMnMxVn98xC8n1m6KblDi4dcHorAEvss0EyXlM+gtD7pte96VEeaoyIsBCG4VedFhS TswPoatfDrYeYVD+B6UyfU+Wp4Sl77r18VFAXleJdnVMNH08rrdm92XRbet1SiwwbY9I acdg== MIME-Version: 1.0 X-Received: by 10.52.170.4 with SMTP id ai4mr3649599vdc.48.1413410674132; Wed, 15 Oct 2014 15:04:34 -0700 (PDT) Received: by 10.220.186.193 with HTTP; Wed, 15 Oct 2014 15:04:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Oct 2014 18:04:33 -0400 Message-ID: From: Christopher Morrow To: Iljitsch van Beijnum Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/grow/ezfgdYVmqOsLRF7i0sftuMrkufU Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [GROW] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 22:04:43 -0000 (man mac-mail and gmail don't play well... I'm not re-formatting this, sorr= y) On Wed, Oct 15, 2014 at 8:29 AM, Iljitsch van Beijnum wrote: > We are all familiar with PA (provider aggregatable) and PI (provider inde= pendent) address space. But it turns out a new type of IPv6 address space i= s starting to show up, which I'll call organization deaggregatable (OD) add= ress space (until someone suggests a better name). > your OD sounds like (from reading below) like what PI is for, or ... OD =3D=3D PI, from what i can tell. > How it works is like this: a large organization obtains a large block of = IPv6 address space, either as a very large PI block or by becoming a local = internet registry (LIR) and getting a regular LIR assignment directly from = one of the five regional registries. However, rather than advertising that = block in BGP as a single prefix, or perhaps a handful of prefixes, like an = ISP would, they subdivide this block within the organization and then many = subunits advertise subprefixes though different ISPs. The aggregate may or = may not be advertised. > sure, this is what enterprises are sort of forced into in the v6 world. They MAY have a contiguous backbone behind their ISP links, or may not. They MAY have ASN for some/all of their sites, they may not. They have v6 address space for each office (say a /48 for instance from a larger /) and they've gotten agreement from their various ISPs to announce the 48's to the world. > The advantage to the organization is that they have provider independent = address space that they'll never have to renumber out of, as well as having= a single prefix that identifies all of the organization, which makes filte= ring easy. > yup > There seem to be two types of organizations that do this: geographically = dispersed ones that advertise subprefixes in different locations, such as m= ultinationals, and organizations with very independent subunits but with mo= re limited geographical scope, such as national governments. > ok, not clear how the type-o-org matters here. "People do this, see the routing table." > This practice, especially if/when it becomes more common, presents two ch= allenges: > > 1. Large numbers of prefixes may show up in the global routing table. For= instance, there is a number plan for all of the German government, which c= ould potentially inject more than 5000 municipality prefixes into the globa= l IPv6 routing table. > ok <1% growth. > 2. Filtering. If people want to avoid large numbers of deaggregates in th= eir routing tables, they may employ some kind of filtering, especially if t= he deaggregates are very long prefixes. This means that packets are no long= er reliably delivered to the place announcing a more specific prefix. > ok, maybe.. but this depends a bunch on what upstream setup is used as well. It seems that if there is arbitrary filtering other solutions will work themselves out (announce aggregate, keep all sites connected to a single/small-set of isps, etc). it's messy, but... > Ideally, a set of best practices would be developed that strike a good ba= lance between the needs of large organizations and the needs of the global = routing system, and allow everyone to predict the consequences of different= kinds of behavior and thus avoid unpleasant surprises. > i feel like we sort of have that already, or we know how the global table works and people live within those constraints. > These are some of the things that could go into such best practices: > > - A well-understood maximum prefix length for IPv6, similar to /24 for IP= v4. > do we want to draw that line in the sand though? I think so far 'let operations folks work that out' has worked out pretty well. There's no official standard in v4, why would we want one in v6? > - An understanding of how the service providers that provide connectivity= to multiple subunits of a large organization can work together in order to= maximize availability and minimize costs for the organization, the service= providers and other network operators. > "cannibalize customers from your neighbors" isn't what you're looking for here, eh? I think TODAY there isn't a problem (nothing is broken, yet) so it's a bit hard to talk about the 'right' answer here. (sure we could take a guess, but...) > - A way to provide a point of last resort where traffic for the aggregate= can be sent to if more specifics are filtered. > this, to me, is the 'headquarters' facility announces the aggregate and maintains a tunneled path to their subunits out over the world. you could slice/dice this in a number of other ways, clearly. I'm not sure more complexity is good though. > - A set of communities that indicate whether a prefix is a more specific = that is covered by an aggregate and/or is safe to filter without loss of co= nnectivity. > so, add communities to global routes, because people don't strip these in ingress as a matter of best practice? (if you don't you REALLY should consider it, i think) > - A set of communities that indicate geographical origin of prefixes so r= emote more specific prefixes can be filtered while local prefixes are kept. > we ran over the geo-prefix rat in SIDR, I don't know that running over it again is especially great for time management. (see terry manderson's geo-data-rpki presentations/drafts, in stockholm and 1/2 meetings after/around then) > - Guidelines for reserving address space in address plans. Is it better t= o have free space reserved so existing prefixes can grow, or keep reserved = space together so tight prefix length filters are possible and reserved spa= ce isn't broken up into small pieces? > uhm... this is a bit of a religious debate isn't it? You'd also be imposing the 'one true way' on people who generally have issues with that sort of thing. Not to mention how does excel manage ipv6 prefix splitting? :) > Please note that I'm crosspositing this to v6ops and grow initially. If t= he chairs have any guidance on which working group is more appropriate for = this discussion, please let us know and we can drop the other one. > > Also note that I haven't been following discussions in both wgs recently,= so if this has been discussed previously, my apologies. > > Last but not least, this treads on RIR policy. But in my opinion, this is= foremost a technical matter with global implications and as such is best d= iscussed within the IETF rather than in the five respective policy developm= ent forums. i don't see it hitting RIR policy so much, sinc ethe RIR's absolved themselves of 'routability' of prefixes long ago. 'if you can't reach your shiney new allocation it ain't ARIN's problem'. -chris > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow From nobody Wed Oct 15 15:08:03 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FA31A9030; Wed, 15 Oct 2014 11:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B09n08DygVuv; Wed, 15 Oct 2014 11:09:09 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5CF1A902D; Wed, 15 Oct 2014 11:09:07 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id ft15so1664967pdb.31 for ; Wed, 15 Oct 2014 11:09:06 -0700 (PDT) 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=x6BvnyTAB7PXtpzAbmQjnp9ecnbpTsw8Sr/UlAnbM/0=; b=PHgGZUiYKWzLMe4JeBIQTHsF9rVJqf/35T7M31rQG69HgrOF2vNnSvZCZDnAXNwhg0 M6TKW0o2DXx3z7WpGN8hRySxEg8/ibOonc6fXXPcu9fdBEU/3EabGwcTqn3i2r6fWB1T WUb5NsOYjjxTeSNQi8+TMb4U4o3wwAd7j23wOLSoOCXXrhv9fb89Qr8Y4JeOu9kHqCVW pt5/ykwEk6HMtd/gRmAZ341NoubrkDZL08r3xNIySyVkN9yZMQ2Q00B1IYxt8eIWbbkz b7cIRlm05t8xxaaGf6YNLJ+nJZsBXXLJCt4Fn2Y4sVcw+pogVMD4L1MSx7yKkXwDIGfC 8OLA== X-Received: by 10.70.94.199 with SMTP id de7mr14446802pdb.3.1413396546741; Wed, 15 Oct 2014 11:09:06 -0700 (PDT) Received: from [172.17.1.55] (219-89-120-188.adsl.xtra.co.nz. [219.89.120.188]) by mx.google.com with ESMTPSA id sa6sm17305650pbb.29.2014.10.15.11.09.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 11:09:05 -0700 (PDT) Message-ID: <543EB83E.9010301@gmail.com> Date: Thu, 16 Oct 2014 07:09:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <543E6B66.5050803@inex.ie> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/grow/Cd0KELnsXcFLv06m6W5dO0wu8i0 X-Mailman-Approved-At: Wed, 15 Oct 2014 15:08:01 -0700 Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [GROW] [v6ops] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 18:09:16 -0000 On 16/10/2014 01:43, Iljitsch van Beijnum wrote: > On 15 Oct 2014, at 14:41, Nick Hilliard wrote: > >>> There seem to be two types of organizations that do this: geographically >>> dispersed ones that advertise subprefixes in different locations, such >>> as multinationals, and organizations with very independent subunits but >>> with more limited geographical scope, such as national governments. > >> and organisations who have a requirement for traffic engineering, whether this requirement is real or imaginary - there are well known examples of each. > > Right, we should probably add that. > > Although I wouldn't expect an organization to deaggregate down to hundreds or thousands of more specifics just for traffic engineering. Not to hundreds, but I would expect a large multinational with operations in most countries to deaggregate down to something close to one per country, to keep its traffic patterns reasonably local. That's nothing new. Brian From nobody Wed Oct 15 23:55:33 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089A51A0369 for ; Wed, 15 Oct 2014 23:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obG__2xpuixZ for ; Wed, 15 Oct 2014 23:55:31 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397811A0362 for ; Wed, 15 Oct 2014 23:55:31 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CFAE4A1; Thu, 16 Oct 2014 08:55:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413442529; bh=K6ZleZyn8+485eJ0FtSmL+FmKRLnCMSM4rN/yjjvjkg=; h=Date:From:To:cc:Subject:In-Reply-To:References:ReSent-Date: ReSent-From:ReSent-To:From; b=b4uJsSvR+82UVyUP9nxiWzWaFj/nfjhllLEcDZvsqKwhFu+p4Wfc5BK5sCIZGNt4F YiKk7lLk7rnO9fNdB9UDBM+f+dUprV55b1+eRZeDN7l0LloyVDOSrY0lRgs1mdjHSq 2aS1g5RkHa1CguHQAk2hfTFH+rPiCLO+S9yFxs5M= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CB3369F for ; Thu, 16 Oct 2014 08:55:29 +0200 (CEST) Date: Thu, 16 Oct 2014 08:53:38 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <543EB83E.9010301@gmail.com> Message-ID: References: <543E6B66.5050803@inex.ie> <543EB83E.9010301@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Thu, 16 Oct 2014 08:55:24 +0200 (CEST) ReSent-From: Mikael Abrahamsson ReSent-To: grow@ietf.org ReSent-Subject: Re: [v6ops] [GROW] Deaggregation by large organizations ReSent-Message-ID: ReSent-User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Archived-At: http://mailarchive.ietf.org/arch/msg/grow/O6Em3mK1meNJhpavk0Ym99V631U Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [GROW] [v6ops] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 06:55:32 -0000 On Thu, 16 Oct 2014, Brian E Carpenter wrote: > Not to hundreds, but I would expect a large multinational with > operations in most countries to deaggregate down to something close to > one per country, to keep its traffic patterns reasonably local. That's > nothing new. Breakouts done from PA space is normal in ARIN-land, but it's less common in RIPE land for instance. We need to make sure renumbering is easy, otherwise we're going to see more and more entries going into the DFZ BGP table. The /24 boundary and IPv4 scarcity was a natural hindrance for this in IPv4, we need to create equal "hindrance" for de-aggregation in IPv6 otherwise I fear that we're going to sit with millions of routes in IPv6 DFZ in 10-20 years. Unless of course this is a cheaper way of handling things than making renumbering possible. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Oct 16 02:41:29 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1151A6FE9; Thu, 16 Oct 2014 02:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1ZnICz2zEet; Thu, 16 Oct 2014 02:41:11 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB061A904D; Thu, 16 Oct 2014 02:41:09 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:5562:b8bc:1f02:25a8] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9G9cx1h059811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 11:38:59 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 16 Oct 2014 11:40:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/grow/U2PuIzhkKMtQfXAVJY_zooP4Yb8 Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [GROW] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 09:41:14 -0000 On 16 Oct 2014, at 0:04, Christopher Morrow = wrote: >> This practice, especially if/when it becomes more common, presents = two challenges: >> 1. Large numbers of prefixes may show up in the global routing table. = For instance, there is a number plan for all of the German government, = which could potentially inject more than 5000 municipality prefixes into = the global IPv6 routing table. > ok <1% growth. What do you mean? >> Ideally, a set of best practices would be developed that strike a = good balance between the needs of large organizations and the needs of = the global routing system, and allow everyone to predict the = consequences of different kinds of behavior and thus avoid unpleasant = surprises. > i feel like we sort of have that already, or we know how the global > table works and people live within those constraints. I've only heard from a few people who do this / want to do this so far, = but from what I hear they really want some clarity in this area. = Spending a lot of time and money to set all of this up and then = discovering your prefixes are filtered is rather suboptimal. Iljitsch From nobody Thu Oct 16 02:44:31 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455DE1A19FE; Thu, 16 Oct 2014 02:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2IjirTlETVZ; Thu, 16 Oct 2014 02:44:02 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE051A19F6; Thu, 16 Oct 2014 02:44:02 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:5562:b8bc:1f02:25a8] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9G9ejiP059851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 11:41:52 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 16 Oct 2014 11:43:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> References: To: v6ops@ietf.org, grow@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/grow/CreNh4UhXbXqTft6HnbPrzCTiVo Subject: Re: [GROW] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 09:44:08 -0000 Let me address a few points that were brought up by different people. Renumbering: We had great plans for making renumbering easy in the early days of = IPv6. Remember A6 records and bitlabels in the DNS? But none of that = went anywhere. The problem isn't so much that we can't push a prefix = down the network or update the DNS (although both of these still have = challenges associated with them), but that addresses tend to get = hardcoded all over the place, starting with firewalls all the way up to = homegrown applications. I don't think renumbering addresses this issue, = although it could help steer some smaller organizations away from PI. A prefix length limit for the IPv6 DFZ: Someone mentioned that this didn't work in IPv6. When Sprint decided to = make that /18, that didn't really work. But there's a de facto /24 limit = that everyone understands. With IPv6, that would translate into a /48. = Obviously no router can hold 2^48 or 2^45 prefixes, so as a backstop = against accidental/malicious IPv6 routing table explosion this doesn't = help. Even exploding a /28 or so into individual /48s would kill the = IPv6 DFZ. What COULD work is to have prefix length limits depending on the = allocation size by the RIRs. Something like: 2100::/16 -> /48 2200::/16 -> /32 2200::/15 -> /29 However, for this to work well the RIRs would have to group allocations = of the same size into separate blocks, with the result that it would no = longer be possible to reserve space to grow an allocation. (Things like = allocating a /48 but reserving a /44 reduce the opportunities for prefix = length filtering because now the strictest filter you can make allows 16 = x as many prefixes worst case than average case. The worst and average = case need to be as close together as possible.) I'd say that allowing two or three extra bits for traffic engineering = for PA blocks would be good. So for the part of the IPv6 space where = /29s are allocated, allow /31s or /32s. As traffic engineering incoming = traffic by deaggregation requires that different parts of the aggregate = all generate similar levels of incoming traffic, this wouldn't usually = work for organizations using PI so I'd say don't allow deaggregating = below /48. Geographic communities: I know this is controversial. "Topology ain't geography". Actually, most = of the time there is a significant correlation. If all German cities = inject a more specific, do you really need to hear those in Tokyo or = Seattle? Just send the traffic to Europe as per the aggregate and let = them figure it out there. Compiling a list of communities that identify regions/countries/cities = would allow for experimentation in this place without any downsides that = I can see. Don't like this? Filter the communities. There's a handy list = that you can copy and paste into your filter. Injecting an aggregate as a point of last resort: I think this can be done today and probably is done today. But a = document describing how to do it would probably be helpful. I'm thinking = along the following lines: The AoLR (Aggregate of Last Resort) service would entail a service = provider announcing the aggregate without necessarily providing = connectivity towards all the places announcing more specifics covered by = the aggregate. So if ISP A announces the AoLR and ISP B provides = connectivity to a more specific, ISP C would send traffic to A as per = the aggregate and then A would immediately hand it over to B. So as part of the AoLR service, a service provider would agree to accept = all more specifics that fall under the aggregate (up to an agreed prefix = length) from all the networks providing connectivity towards those more = specifics. This would be an attractive service for tier-1s to provide, = because presumably, they peer with everyone everywhere, so in the case = where they receive the traffic over peering and need to deliver it to = another service provider over peering, this could probably happen in the = same city, so they wouldn't carry the traffic over long distances. But = the (sub-)organization(s) in question still gets to buy connectivity = from a wider range of smaller service providers. In practice an organization would contract two or more service providers = to provide the AoLR service for redundancy. Wouldn't they just get PI: Yes. That's why I think it's important to find a way to give these = organizations what they need in a way that keeps the IPv6 DFZ growth on = a workable trajectory. AS numbers: BGP assumes that an AS always has internal connectivity. This can be = accomplished using tunnels, but it's much better to simply have separate = AS numbers for each subunit. Would it make sense to allocate ranges of = AS numbers to enterprise LIRs? Certainly with 32-bit AS numbers there's = no lack of numbers, and this would allow tools to be developed to work = on CIDR-like AS number ranges in the future. From nobody Thu Oct 16 03:43:41 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7430F1ACFF5; Thu, 16 Oct 2014 03:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W44rJJ4RvA3H; Thu, 16 Oct 2014 03:43:34 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0991ACFFA; Thu, 16 Oct 2014 03:43:33 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9GAhUgO050301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2014 11:43:30 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <543FA152.4080907@foobar.org> Date: Thu, 16 Oct 2014 11:43:30 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Iljitsch van Beijnum , v6ops@ietf.org, grow@ietf.org References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> In-Reply-To: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/grow/oA-LNxhumBuwObp7kN-W7KugI6Q Subject: Re: [GROW] [v6ops] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 10:43:36 -0000 On 16/10/2014 10:43, Iljitsch van Beijnum wrote: > Yes. That's why I think it's important to find a way to give these > organizations what they need in a way that keeps the IPv6 DFZ growth on > a workable trajectory. This brings up a more general issue: IPv6 dfz growth for the last several years has been linear. > https://ripe68.ripe.net/presentations/156-2014-05-12-bgp2013.pdf Even if the curves go the wrong way for a couple of years, there isn't an issue of much concern here, at least in the short to medium term, and probably not the longer term either. Nick From nobody Thu Oct 16 04:39:30 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BD01AD065; Thu, 16 Oct 2014 04:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV0JrLOkOiip; Thu, 16 Oct 2014 04:39:21 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359011A1A66; Thu, 16 Oct 2014 04:39:20 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:53944 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1XejOn-0007BF-3Z; Thu, 16 Oct 2014 11:39:17 +0000 From: "Russ White" To: "'Iljitsch van Beijnum'" , , References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> In-Reply-To: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> Date: Thu, 16 Oct 2014 07:39:14 -0400 Message-ID: <011101cfe935$d0e8a600$72b9f200$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIU7+zpyiakeI4w4w1+I7Zew5YFCQFFO9hQm55hjDA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/grow/2Xe9F1LkycsFZ5M0v3UttAOTADg Subject: Re: [GROW] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 11:39:24 -0000 > Injecting an aggregate as a point of last resort: > > I think this can be done today and probably is done today. But a document > describing how to do it would probably be helpful. I'm thinking along the > following lines: > > The AoLR (Aggregate of Last Resort) service would entail a service provider > announcing the aggregate without necessarily providing connectivity towards > all the places announcing more specifics covered by the aggregate. So if ISP A > announces the AoLR and ISP B provides connectivity to a more specific, ISP C > would send traffic to A as per the aggregate and then A would immediately > hand it over to B. Or perhaps something simpler would work here -- bounding longest match. :-) Russ From nobody Thu Oct 16 06:03:17 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AAB1A1B3B; Thu, 16 Oct 2014 06:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah4RS5sb71kd; Thu, 16 Oct 2014 06:03:11 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73251A1A71; Thu, 16 Oct 2014 06:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1038; q=dns/txt; s=iport; t=1413464591; x=1414674191; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pQaPuBfw6UB84xzbSeq8E7XP/WpVKeHVctphtZyvev4=; b=OSR6DLXgpFn0/fBzcJhabSpsXcNa3hbX4vcZx3C0HYPwXzs58jSxb82X otozRmK7uGynVoDPyuC6e95LR5WUTZxCcd/T1Igd3gYGs+LLv3P2W9F0x snHsVcIOY7pigGLbHiZdIRmwutn5oJOw9HAOPVIE85zHVR4WdBiqF5nUR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAFnBP1StJA2D/2dsb2JhbABbgw5TXMwch00CgRUWAX2EAwEBBHkQAgEIRiERJQIEAQ0FiCoDEQ3DZQ2GPQEBAQEBAQEDAQEBAQEBHI4ZggEzB4RLAQSPY4IchEaFAYIRgWyNWoZWg3dsgQYFPYECAQEB X-IronPort-AV: E=Sophos;i="5.04,732,1406592000"; d="scan'208";a="363798526" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 16 Oct 2014 13:03:10 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9GD3AAT016522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 13:03:10 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.127]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 08:03:10 -0500 From: "Alvaro Retana (aretana)" To: Christopher Morrow , Iljitsch van Beijnum Thread-Topic: [GROW] Deaggregation by large organizations Thread-Index: AQHP6HO0Yw6tGmdMOUO+hU2KqJts6JwyCuqAgAC3/IA= Date: Thu, 16 Oct 2014 13:03:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/grow/HCXfO0GDGggqLBrwpnqSbuy5NmQ Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [GROW] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 13:03:12 -0000 On 10/15/14, 6:04 PM, "Christopher Morrow" wrote: >> >>- A set of communities that indicate whether a prefix is a more specific >>that is covered by an aggregate and/or is safe to filter without loss of >>connectivity. >> > >so, add communities to global routes, because people don't strip these >in ingress as a matter of best practice? (if you don't you REALLY >should consider it, i think) Right.. Even if we could make the communities not be stripped (not proposing that), the originator would still not know the policy between any two ASNs =8B not even the receive policy of its direct neighbor! So the originator still couldn=B9t guarantee that the route is in fact covered= . The only way to determine coverage and no connectivity loss is on the receive side. There you can look at the incoming routes and determine how the routes overlap and mark them appropriately according to local policy. http://tools.ietf.org/html/draft-white-grow-overlapping-routes Alvaro. From nobody Thu Oct 16 06:18:51 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4567E1A1BA3; Thu, 16 Oct 2014 06:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz4gpolqypAD; Thu, 16 Oct 2014 06:18:46 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366A11A1BA0; Thu, 16 Oct 2014 06:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1646; q=dns/txt; s=iport; t=1413465526; x=1414675126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=q96tiCibrSArwwp4CXNjQLTudCP0HYEB4xuTFZntR/E=; b=DRJ7vflvsBlGzNkJ314tVByBGPLvANe3lRgmF6IMcdJFaqcb4a4IMYYH 1HRGyB1s7xgI/jOR9Hx23SHgwwkTXnfrgMAIB3uoyhY36Mg8dby2hWzJM pyqr0qyf+UlfL0gOgsrU46sogXhW4aLxn3W3BXK1yoh+4FPKVK+xY7fBl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOvEP1StJV2b/2dsb2JhbABbgw6BL9NqAoEUFgF9hAMBAQQnUhACAQhGMiUCBAENBYg+ykgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkBozB4RLAQSLI4RAghyLWJYcg3dsgQgkHIECAQEB X-IronPort-AV: E=Sophos;i="5.04,732,1406592000"; d="scan'208";a="87481529" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 16 Oct 2014 13:18:45 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9GDIj8Q015856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 13:18:45 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.127]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 08:18:44 -0500 From: "Alvaro Retana (aretana)" To: Ted Lemon , Iljitsch van Beijnum Thread-Topic: [GROW] [v6ops] Deaggregation by large organizations Thread-Index: AQHP6IqzJ0bq5e0sx0KpNLmfoN9dGpwyxxcA Date: Thu, 16 Oct 2014 13:18:44 +0000 Message-ID: References: <5B13739D-5BFD-467C-8DF0-D391508EB5C0@nominum.com> In-Reply-To: <5B13739D-5BFD-467C-8DF0-D391508EB5C0@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <456526549296BE41AFC508FC513085C8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/grow/PVuLJ-MTihbpJh4HjsMmyOkSoFM Cc: "v6ops@ietf.org" , "grow@ietf.org" Subject: Re: [GROW] [v6ops] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 13:18:49 -0000 On 10/15/14, 11:14 AM, "Ted Lemon" wrote: >On Oct 15, 2014, at 7:29 AM, Iljitsch van Beijnum >wrote: >> However, rather than advertising that block in BGP as a single prefix, >>or perhaps a handful of prefixes, like an ISP would, they subdivide this >>block within the organization and then many subunits advertise >>subprefixes though different ISPs. The aggregate may or may not be >>advertised. > >Yuck. Has anybody done an analysis of how this works with RPKI? Seems >like an obvious attack surface if the RPKI isn't present or isn't done >right. Yup. I don=B9t have an analysis, but it is a common discussion point when creating ROAs: what should the ROA cover? Both the max-length of the advertisement and the origin ASNs could result in a =B3validated=B2 attack. On one hand, creating ROAs that cover exactly what is advertised reduces the surface, but it can result in a higher operational cost and maybe some hassle if something different (like a more specific) needs to be advertised *right now*. OTOH, creating a more =B3flexible=B2 ROA (2100::5/= 32 -> /48, for example) provides more operational flexibility, but it may in fact open up the door to =B3valid=B2 announcements. I=B9ve worked with LACNIC in some of their RPKI deployments in Latin Americ= a and I suspect that a significant number of people opt for the =B3flexible ROA=B2..even after we explain the risks. LACNIC may have some insight in what is being created right now (with the caveat of course that there=B9s just one place in the world that is in fact filtering). Alvaro. From nobody Thu Oct 16 07:11:50 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56471A1A70; Thu, 16 Oct 2014 07:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV7sjSidVp_o; Thu, 16 Oct 2014 07:11:44 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572421A1A37; Thu, 16 Oct 2014 07:11:43 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id n15so2814588lbi.39 for ; Thu, 16 Oct 2014 07:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=swMeA9grUx06Ljtj2Pcpcz8kKPET8I6JLTVFmrZ6V1I=; b=OrI0Fe3HFHgrP8UifWBwkayTDjbWkclC+QpjJe5sYc0MCn/dD2KTZY8g0EQjUrTnF/ PyNhj8rUN1cUfQx0NmqlOfogJwTDy7dVKzyyY06rsAb0ZzYcbfZdQJIY3b1B192HLjWy KwBvTChVxIQRanduOJdaolkcxGLtZI16mrGwhOL8S5SpdgNFOQ4SJeTl7MHggmFYTJyx TsNC17dpxdPCyNILR8OTIwwkLFi4mlYIb2txURjw6axvQGhY3h5G/qcBX30Y7n2VfpRJ mTDk2+H+RxmNO/53mBnoYalALUE4gnQo6qPBrUKMG8zqSpV4YttBkMMi03hmzq8jk898 oOvg== MIME-Version: 1.0 X-Received: by 10.152.45.105 with SMTP id l9mr1859321lam.69.1413468701582; Thu, 16 Oct 2014 07:11:41 -0700 (PDT) Received: by 10.152.88.17 with HTTP; Thu, 16 Oct 2014 07:11:41 -0700 (PDT) In-Reply-To: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> Date: Thu, 16 Oct 2014 10:11:41 -0400 Message-ID: From: Christopher Morrow To: Iljitsch van Beijnum Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/grow/nvDYilftE7kQFq63IEfd32o0zfo Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [GROW] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:11:46 -0000 On Thu, Oct 16, 2014 at 5:40 AM, Iljitsch van Beijnum wrote: > On 16 Oct 2014, at 0:04, Christopher Morrow wrote: > >>> This practice, especially if/when it becomes more common, presents two = challenges: > >>> 1. Large numbers of prefixes may show up in the global routing table. F= or instance, there is a number plan for all of the German government, which= could potentially inject more than 5000 municipality prefixes into the glo= bal IPv6 routing table. > >> ok <1% growth. > > What do you mean? 5000 is less than 1% of 540k... (I think, math is hard and all that busines= s) for the (since someone else shot me a note behind the scenes about this as well) forseable future we'll have v4 + v6 to deal with in a DFZ device, so call it even at 540k routes today in the table, your 5k extra is less than 1% of that. >>> Ideally, a set of best practices would be developed that strike a good = balance between the needs of large organizations and the needs of the globa= l routing system, and allow everyone to predict the consequences of differe= nt kinds of behavior and thus avoid unpleasant surprises. > >> i feel like we sort of have that already, or we know how the global >> table works and people live within those constraints. > > I've only heard from a few people who do this / want to do this so far, b= ut from what I hear they really want some clarity in this area. Spending a = lot of time and money to set all of this up and then discovering your prefi= xes are filtered is rather suboptimal. > So, some folk thought: "Hey, not announcing my aggregate and not providing connectivity between the aggregate announcement and the little islands I created is a grand plan!" and were surprised when things went badly... Do you want a document that says: "Sure, announce your aggregate as a bunch of de-aggs, and be sure there's a fall back ASIDE FROM ::/0 which has reachability to your islands, if you want to be sure to not run afoul of random isp route filtering." From nobody Thu Oct 16 07:45:29 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984321A1BB4; Thu, 16 Oct 2014 07:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3cNmpnda6s1; Thu, 16 Oct 2014 07:45:25 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45F31A1BA9; Thu, 16 Oct 2014 07:45:24 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id lf12so2792579vcb.17 for ; Thu, 16 Oct 2014 07:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hvkL3deYj8F2qyrWFvLwOeD/vC2Xu8FjEE33zT1EPpE=; b=p8QYnSv9eXn2wRvghj9LwUuzjA6b/ckQ2xhcKhmEn+PnQbHJdHBxh2cdZf+AUpU31F EvnEc7RaC5jwOuPefzirMf2qWZhwVUOEgh9aa/7ZJzl8k979vBrEcnSyG6ey9B645fB9 8LQrSYQXr2AobODHVJsx8jSfwZda57MGOpqcSTCb5jzss9ClYVcVgzxTtjgvlFFsQvku tN23vn+7qUHC/MgGNOQQaIM6O46lWYCB0kaO6utp1S/CE7ygXg/NmqmUNpx9R+Yko/Zk EjX7lrYOG1QQt5tFQ3xEY5ehUYAkP2DAozyEf2cOisv0tXtnsnpO5x2KX5wK+mq0VOba x6Ow== MIME-Version: 1.0 X-Received: by 10.52.34.42 with SMTP id w10mr1194665vdi.57.1413470723927; Thu, 16 Oct 2014 07:45:23 -0700 (PDT) Received: by 10.220.186.193 with HTTP; Thu, 16 Oct 2014 07:45:23 -0700 (PDT) In-Reply-To: <20141016143743.GC31092@Space.Net> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016143743.GC31092@Space.Net> Date: Thu, 16 Oct 2014 10:45:23 -0400 Message-ID: From: Christopher Morrow To: Gert Doering Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/grow/Bhknd-TKMkuaUp_Vv3wm-e24RXs Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [GROW] [v6ops] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:45:26 -0000 On Thu, Oct 16, 2014 at 10:37 AM, Gert Doering wrote: > Hi, > > On Thu, Oct 16, 2014 at 10:11:41AM -0400, Christopher Morrow wrote: >> So, some folk thought: "Hey, not announcing my aggregate and not >> providing connectivity between the aggregate announcement and the >> little islands I created is a grand plan!" and were surprised when >> things went badly... >> >> Do you want a document that says: >> "Sure, announce your aggregate as a bunch of de-aggs, and be sure >> there's a fall back ASIDE FROM ::/0 which has reachability to your >> islands, if you want to be sure to not run afoul of random isp route >> filtering." > > A strong message to that extent would be good :-) - coupled with > some recommendations how the conflicting goals ("I want all ISPs in > my neighbourhood to use optimal routing" vs. "someone in Asia might > not be interested in all in 5k routes for german municipality") > could be solved. > ok, perhaps iljitsch can drop some text into a document so we can get a good read going and decide whether or not GROW wants to spend cycles on it? The problem exists in v4 and v6 and likely will persist in whatever comes next. It's directly related to routing operations work on the global intertubes, so it SEEMS like GROW is the 'right place' to discuss this... we can't go anywhere without text and a draft though. > I get that question fairly often from "largish networks", and so far, > I always have to answer "there is no routing police, so it's hard to > say what is allowed on the Internet and what not" - which is a humorous > way to say "there is no consensus here what consists 'good' and > 'responsible'"... I sort of don't want there to be 'routing police' though :( In a way this whole debate sounds like something a 'cisco training class' (or other example) would have covered, or should cover. I suppose it's fairly experiential at this point though. From nobody Thu Oct 16 08:21:02 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917741A1BF4; Thu, 16 Oct 2014 08:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G7Bp6ewaNpx; Thu, 16 Oct 2014 08:20:50 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096AE1A1BC0; Thu, 16 Oct 2014 08:20:49 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id 10so2987968lbg.14 for ; Thu, 16 Oct 2014 08:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0z89qqxScjReCiBUtpWo2m1Ear8fCavMT5ERJCQBDG8=; b=APu+EcIntC06Lsdc+mskwVrdOO3YzvuRE1XILCauxRWX4v/sUWGVuiL77HwQFDdpkW tYWLaf3qXRaWht8ckCYFc6BXGGEvpZ3HzAq3dGyT6SqkIO5BUBXPAeuCUul5PIQOKq99 CwiCmqHXa5D8QIyq2UDL33Z5pMV//sIhOsf6+bK/zbfy4LEAooAHbVg/hfcH0q4I0kEX xEnpedxLKy2lKtG35qB+cNySyefjLW2o5nwGNtFnfCLLIY4kDkCyxls0b0FlJvMMFtPl nc6VNHIlvoxuX3LyGazkaO0DnKCQQrp50YBk7ihN+DMbnxVstFTcIZXddYWKUmh0hUCg WTKg== MIME-Version: 1.0 X-Received: by 10.153.11.133 with SMTP id ei5mr2291514lad.75.1413472848218; Thu, 16 Oct 2014 08:20:48 -0700 (PDT) Received: by 10.152.88.17 with HTTP; Thu, 16 Oct 2014 08:20:48 -0700 (PDT) In-Reply-To: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> Date: Thu, 16 Oct 2014 11:20:48 -0400 Message-ID: From: Christopher Morrow To: Iljitsch van Beijnum Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/grow/OoPpnhBlhbQOc10Wt3OcRtaH8BE Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [GROW] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:20:54 -0000 (apologies for again not reformatting apple-mail->gmail issues) On Thu, Oct 16, 2014 at 5:43 AM, Iljitsch van Beijnum wrote: > Let me address a few points that were brought up by different people. > > Renumbering: I think the renumbering ship sailed, and like the titanic had a bad voyage. You seem to agree. > A prefix length limit for the IPv6 DFZ: > > Someone mentioned that this didn't work in IPv6. When Sprint decided to m= ake that /18, that didn't really work. But there's a de facto /24 limit tha= t everyone understands. With IPv6, that would translate into a /48. Obviously no router can hold 2^48 or 2^45 I suppose there's a question about: "Is a /24 a LAN (/64) or a SITE (/48)" to be answered still. I believe SITE works better, but :) prefixes, so as a backstop against accidental/malicious IPv6 routing table explosion this doesn't help. Even exploding a /28 or so into individual /48s would kill the IPv6 DFZ. mostly this is from motherhood + apple-pie bgp neighbor configs though, right? (max-prefix in particular). > What COULD work is to have prefix length limits depending on the allocati= on size by the RIRs. Something like: > > 2100::/16 -> /48 > 2200::/16 -> /32 > 2200::/15 -> /29 This looks, to me, like the 'PA space is >=3D /32, PI >=3D /48' in each region's PA/PI splits... which ends up being fairly stable and fairly simple prefix-list/etc configs on devices, right? so that seems kind of sane even. I had thought the cymru folk had something like this in their templates: isn't what I was looking for, sadly...and is the only sort of ipv6 / route-filter related thing I quickly find on their site... perhaps some room for improvement in this area exists. Should that be an IETF action or 'get the defacto standards/bcop folk to update their docs based on the best shared wisdom' ? > > However, for this to work well the RIRs would have to group allocations o= f the same size into separate blocks, with the result that it would no long= er be possible to reserve space to grow an allocation. (Things like allocat= ing a /48 but reserving a /44 reduce the opportunities for prefix length fi= ltering because now the strictest filter you can make allows 16 x as many p= refixes worst case than average case. The worst and average case need to be= as close together as possible.) > my impression (and I stopped paying close attention to ARIN at least 2+ yrs ago) was that RIR's were allocating PA from one large (/23?) block per RIR and PI from a different... For my work-location-provider: 2620:0:1000::/40 - PI /40 2001:4860::/32 - PA /32 2607:F8B0::/32 - PA /32 doesn't delineate the difference between 2001:4800::/23 and 2600::/12 and 2620::/23 ... bummer. I suppose this though: is meant to delineate the differences as 'allocation blocks' vs 'assignment blocks'... (I didn't search the same sort of stuff out on ripe/apnic/etc...) > I'd say that allowing two or three extra bits for traffic engineering for= PA blocks would be good. So for the part of the IPv6 space where /29s are = allocated, allow /31s or /32s. As traffic engineering incoming traffic by d= eaggregation requires that different parts of the aggregate all generate si= milar levels of incoming traffic, this wouldn't usually work for organizati= ons using PI so I'd say don't allow deaggregating below /48. > sure, this gets into the above 'give me a default understanding of the iana -> rir ranges + RIR purposes (alloc/assign) and add +N bits for TE. It's not quite answering the other part of your question about: "What will the DE gov't do? how will they run their new shiney network such that they don't have reachability concerns?" > Geographic communities: > > I know this is controversial. "Topology ain't geography". Actually, most = of the time there is a significant correlation. If all German cities inject= a more specific, do you really need to hear those in Tokyo or Seattle? Jus= t send the traffic to Europe as per the aggregate and let them figure it ou= t there. > this argues for the DE gov't having 1 ISP's for all their cities and putting the aggregate into BGP as well with the more specifics no-export'd from the ISP, not for communities, which won't reliably make it across AS boundaries. > Compiling a list of communities that identify regions/countries/cities wo= uld allow for experimentation in this place without any downsides that I ca= n see. Don't like this? Filter the communities. There's a handy list that y= ou can copy and paste into your filter. > > Injecting an aggregate as a point of last resort: > > I think this can be done today and probably is done today. But a document= describing how to do it would probably be helpful. I'm thinking along the = following lines: > ok > The AoLR (Aggregate of Last Resort) service would entail a service provid= er announcing the aggregate without necessarily providing connectivity towa= rds all the places announcing more specifics covered by the aggregate. So i= f ISP A announces the AoLR and ISP B provides connectivity to a more specif= ic, ISP C would send traffic to A as per the aggregate and then A would imm= ediately hand it over to B. > > So as part of the AoLR service, a service provider would agree to accept = all more specifics that fall under the aggregate (up to an agreed prefix le= ngth) from all the networks providing connectivity towards those more speci= fics. This would be an attractive service for tier-1s to provide, because p= resumably, they peer with everyone everywhere, so in the case where they re= ceive the traffic over peering and need to deliver it to another service pr= ovider over peering, this could probably happen in the same city, so they w= ouldn't carry the traffic over long distances. But the (sub-)organization(s= ) in question still gets to buy connectivity from a wider range of smaller = service providers. > > In practice an organization would contract two or more service providers = to provide the AoLR service for redundancy. > this doesn't sound unreasonable, make txt pls appear in draft form, then email that to grow@ and see what debate happens there. > Wouldn't they just get PI: > > Yes. That's why I think it's important to find a way to give these organi= zations what they need in a way that keeps the IPv6 DFZ growth on a workabl= e trajectory. > > AS numbers: > > BGP assumes that an AS always has internal connectivity. This can be acco= mplished using tunnels, but it's much better to simply have separate AS num= bers for each subunit. Would it make sense to allocate ranges of AS numbers= to enterprise LIRs? Certainly with 32-bit AS numbers there's no lack of nu= mbers, and this would allow tools to be developed to work on CIDR-like AS n= umber ranges in the future. > it seems like the AS here is really not relevant, unless you were thinking that: "AS is a proxy for GEO data." (or AS =3D=3D SITE) One thought is that AS provides the mapping to 'authoritative entity for the routing policy surrounding/using the prefixes originated by the AS in question', so is it simpler to remember: "DE govt is AS65534" or "DE gov't could be one of 160 AS numbers" (a range might help, but ranges imply some idea about growth in the future. Would you have planned for RU to add Crimea?) The AoLR (or 'how to be an enterprise that participates in the global routing system') seems like a good start though. -chris From nobody Thu Oct 16 08:21:39 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1831A026E; Wed, 15 Oct 2014 22:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHzgESvDbuUU; Wed, 15 Oct 2014 22:43:29 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 610301A86F3; Wed, 15 Oct 2014 22:43:29 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s9G5fmZq013027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Oct 2014 22:41:48 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s9G5fmZq013027 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1413438109; bh=22HPwOwtaLd0/tn+kro7+mY61GI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=j9LUkWLzYObsPy89e0IRHd3b9TU+nqpVRc9zprtV6hd++Nuz+6ZjeVMAmNnKIhoLa RWSg66Ytj1rQ9PvS5bBtED6Pn+axduQm79HieVYUF1R6/IkX/UjlYg1GSHqZ9Unmxl TACGZQHRqQvoEV1kKjJokH80/qSWXLrg780OyoRI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: Owen DeLong In-Reply-To: Date: Wed, 15 Oct 2014 22:41:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1DB6393A-D039-4998-AC07-6868BEE5B20B@delong.com> References: To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 15 Oct 2014 22:41:49 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/grow/1mzih10vAPL34WdASXeAoeQbcIs X-Mailman-Approved-At: Thu, 16 Oct 2014 08:21:27 -0700 Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [GROW] [v6ops] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 05:43:31 -0000 On Oct 15, 2014, at 05:29 , Iljitsch van Beijnum = wrote: > We are all familiar with PA (provider aggregatable) and PI (provider = independent) address space. But it turns out a new type of IPv6 address = space is starting to show up, which I'll call organization = deaggregatable (OD) address space (until someone suggests a better = name). >=20 > How it works is like this: a large organization obtains a large block = of IPv6 address space, either as a very large PI block or by becoming a = local internet registry (LIR) and getting a regular LIR assignment = directly from one of the five regional registries. However, rather than = advertising that block in BGP as a single prefix, or perhaps a handful = of prefixes, like an ISP would, they subdivide this block within the = organization and then many subunits advertise subprefixes though = different ISPs. The aggregate may or may not be advertised. >=20 > The advantage to the organization is that they have provider = independent address space that they'll never have to renumber out of, as = well as having a single prefix that identifies all of the organization, = which makes filtering easy. >=20 > There seem to be two types of organizations that do this: = geographically dispersed ones that advertise subprefixes in different = locations, such as multinationals, and organizations with very = independent subunits but with more limited geographical scope, such as = national governments. >=20 > This practice, especially if/when it becomes more common, presents two = challenges: >=20 > 1. Large numbers of prefixes may show up in the global routing table. = For instance, there is a number plan for all of the German government, = which could potentially inject more than 5000 municipality prefixes into = the global IPv6 routing table. How would this differ from 500 multihomed municipal governments getting = PI space? > 2. Filtering. If people want to avoid large numbers of deaggregates in = their routing tables, they may employ some kind of filtering, especially = if the deaggregates are very long prefixes. This means that packets are = no longer reliably delivered to the place announcing a more specific = prefix. I would think that if/when this becomes an issue, the organizations = engaging in the behavior will take the necessary steps to get the = traffic they care about. Seems to me that this is the desirable situation as some form of = equilibrium will be reached where organizations limit their deaggregates = to something they can get adequately routed and operators will limit = their routing tables to something they can handle. > Ideally, a set of best practices would be developed that strike a good = balance between the needs of large organizations and the needs of the = global routing system, and allow everyone to predict the consequences of = different kinds of behavior and thus avoid unpleasant surprises. Hard to develop a set of best practices for this that would have any = real longevity. The boundary between usable routing table maximum size = and oblivion is a moving target. We don't have sufficient experience = with this problem in the IPv6 space to really know how far it will = extend. > These are some of the things that could go into such best practices: >=20 > - A well-understood maximum prefix length for IPv6, similar to /24 for = IPv4. I don't think this helps. The /48 seems to pretty much already be there = as a de-facto answer to this question. However, 2^45 routes (unicast is = a /3) is probably beyond the capability of any router yet available. > - An understanding of how the service providers that provide = connectivity to multiple subunits of a large organization can work = together in order to maximize availability and minimize costs for the = organization, the service providers and other network operators. If you can find answers to this question, they would certainly be = beneficial to the community, but I think that scope extends well beyond = the deaggregation issue described here and that would be only one aspect = of such a document. > - A way to provide a point of last resort where traffic for the = aggregate can be sent to if more specifics are filtered. There are many ways to do this. Ranging from the simple build a network = of tunnels between your sites and anchor the aggregate as a less = specific from a few key sites to much more elaborate solutions. These = solutions seem to me to be reasonably well known to most network = engineers. I don't think a document rehashing them in yet another place = is of any particular benefit. > - A set of communities that indicate whether a prefix is a more = specific that is covered by an aggregate and/or is safe to filter = without loss of connectivity. This seems like a reasonably good idea... If you write up an ID for = v6ops to do this one simple thing, I would support it. > - A set of communities that indicate geographical origin of prefixes = so remote more specific prefixes can be filtered while local prefixes = are kept. Since geography !=3D topology (and dramatically so in some cases), I = think this would do more harm than good in many cases. > - Guidelines for reserving address space in address plans. Is it = better to have free space reserved so existing prefixes can grow, or = keep reserved space together so tight prefix length filters are possible = and reserved space isn't broken up into small pieces? There are many documents describing various ways to do sparse allocation = and allocation by bisection for IPv6. I have written some that have = achieved some distribution. RIPE has one or two at least. I don't think = having the IETF rewrite yet another one is particularly useful. > Please note that I'm crosspositing this to v6ops and grow initially. = If the chairs have any guidance on which working group is more = appropriate for this discussion, please let us know and we can drop the = other one. The one tidbit that strikes me as useful is, IMHO, something that = belongs in v6ops. YMMV. > Last but not least, this treads on RIR policy. But in my opinion, this = is foremost a technical matter with global implications and as such is = best discussed within the IETF rather than in the five respective policy = development forums. I don't think anything proposed above really treads on RIR policy. It = makes recommendations for utilization of address space by end-user = organizations, but does not make any attempt to set policy for how those = addresses are acquired or what amount of space should be granted in = response to such a request. I'm pretty sure I'm one of the most RIR-oriented people on the planet in = any such discussion, so I think you're safe in that regard. (I was, = after-all, the leader of the original RIR rebellion against oppressive = IETF policies regarding PI for end-users in IPv6). Owen From nobody Thu Oct 16 08:21:47 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5E61A036C; Wed, 15 Oct 2014 23:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.238 X-Spam-Level: X-Spam-Status: No, score=0.238 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7wRCyWCEKum; Wed, 15 Oct 2014 23:53:41 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5A51A0369; Wed, 15 Oct 2014 23:53:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E987DA1; Thu, 16 Oct 2014 08:53:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413442418; bh=K6ZleZyn8+485eJ0FtSmL+FmKRLnCMSM4rN/yjjvjkg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=V/64vD8wyvjy3cTN1z01hgUIAQhyAqvTyrTMBwE0gyZWwwVeorYDha9MWAVEIkoFr fnuZHhAp1YYSJN//pm9mRdPIRYDVtUBCIu+eP83LAASpDa1cm9k3YtFRkqbNWL5FVh w4oTcHc/kixmLTP9qKOiPARdzM2Hdl9oBhiYzPGY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E2F809F; Thu, 16 Oct 2014 08:53:38 +0200 (CEST) Date: Thu, 16 Oct 2014 08:53:38 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <543EB83E.9010301@gmail.com> Message-ID: References: <543E6B66.5050803@inex.ie> <543EB83E.9010301@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/grow/O6Em3mK1meNJhpavk0Ym99V631U X-Mailman-Approved-At: Thu, 16 Oct 2014 08:21:31 -0700 Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [GROW] [v6ops] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 06:53:42 -0000 On Thu, 16 Oct 2014, Brian E Carpenter wrote: > Not to hundreds, but I would expect a large multinational with > operations in most countries to deaggregate down to something close to > one per country, to keep its traffic patterns reasonably local. That's > nothing new. Breakouts done from PA space is normal in ARIN-land, but it's less common in RIPE land for instance. We need to make sure renumbering is easy, otherwise we're going to see more and more entries going into the DFZ BGP table. The /24 boundary and IPv4 scarcity was a natural hindrance for this in IPv4, we need to create equal "hindrance" for de-aggregation in IPv6 otherwise I fear that we're going to sit with millions of routes in IPv6 DFZ in 10-20 years. Unless of course this is a cheaper way of handling things than making renumbering possible. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Oct 16 08:21:49 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52971A1AEF for ; Thu, 16 Oct 2014 07:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT0hWQHrlzbl for ; Thu, 16 Oct 2014 07:37:45 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416791A1AB8 for ; Thu, 16 Oct 2014 07:37:44 -0700 (PDT) X-Original-To: grow@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5657D60788 for ; Thu, 16 Oct 2014 16:37:43 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2BC6B60102 for ; Thu, 16 Oct 2014 16:37:43 +0200 (CEST) Received: (qmail 92260 invoked by uid 1007); 16 Oct 2014 16:37:43 +0200 Date: Thu, 16 Oct 2014 16:37:43 +0200 From: Gert Doering To: Christopher Morrow Message-ID: <20141016143743.GC31092@Space.Net> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/grow/hD1E23GqZIuhtKaMpjAqwWYKcvE X-Mailman-Approved-At: Thu, 16 Oct 2014 08:21:28 -0700 Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [GROW] [v6ops] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:37:48 -0000 Hi, On Thu, Oct 16, 2014 at 10:11:41AM -0400, Christopher Morrow wrote: > So, some folk thought: "Hey, not announcing my aggregate and not > providing connectivity between the aggregate announcement and the > little islands I created is a grand plan!" and were surprised when > things went badly... > > Do you want a document that says: > "Sure, announce your aggregate as a bunch of de-aggs, and be sure > there's a fall back ASIDE FROM ::/0 which has reachability to your > islands, if you want to be sure to not run afoul of random isp route > filtering." A strong message to that extent would be good :-) - coupled with some recommendations how the conflicting goals ("I want all ISPs in my neighbourhood to use optimal routing" vs. "someone in Asia might not be interested in all in 5k routes for german municipality") could be solved. I get that question fairly often from "largish networks", and so far, I always have to answer "there is no routing police, so it's hard to say what is allowed on the Internet and what not" - which is a humorous way to say "there is no consensus here what consists 'good' and 'responsible'"... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Oct 16 08:21:50 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C8C1A1BC0 for ; Thu, 16 Oct 2014 07:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 101-OQQeb9QX for ; Thu, 16 Oct 2014 07:59:37 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87EAC1A1BC7 for ; Thu, 16 Oct 2014 07:59:33 -0700 (PDT) X-Original-To: grow@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id BBD24607F0 for ; Thu, 16 Oct 2014 16:59:31 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8E36060344 for ; Thu, 16 Oct 2014 16:59:31 +0200 (CEST) Received: (qmail 97967 invoked by uid 1007); 16 Oct 2014 16:59:31 +0200 Date: Thu, 16 Oct 2014 16:59:31 +0200 From: Gert Doering To: Christopher Morrow Message-ID: <20141016145931.GE31092@Space.Net> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016143743.GC31092@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E+PR0/1ruOTysuoe" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/grow/T9O0H6COUBFEQiCFx5QaI3fnaqs X-Mailman-Approved-At: Thu, 16 Oct 2014 08:21:30 -0700 Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" , Gert Doering Subject: Re: [GROW] [v6ops] Deaggregation by large organizations X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:59:39 -0000 --E+PR0/1ruOTysuoe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Oct 16, 2014 at 10:45:23AM -0400, Christopher Morrow wrote: > > A strong message to that extent would be good :-) - coupled with > > some recommendations how the conflicting goals ("I want all ISPs in > > my neighbourhood to use optimal routing" vs. "someone in Asia might > > not be interested in all in 5k routes for german municipality") > > could be solved. >=20 > ok, perhaps iljitsch can drop some text into a document so we can get > a good read going and decide whether or not GROW wants to spend cycles > on it? That would be nice (as I see the problem but have no cycles to write something useful). > The problem exists in v4 and v6 and likely will persist in whatever > comes next. It's directly related to routing operations work on the > global intertubes, so it SEEMS like GROW is the 'right place' to > discuss this... we can't go anywhere without text and a draft though. It seems to be made worse by the fact that "this" can be done more easily with IPv6, as you just can't get enough v4 space to subdivide it into 5000 globally visible prefixes today - and those entities that discover the "must have reliability! must have independence!" mantra *now* will hit the v6 space... (given that I see this argument in this dimension more often from governmental structures who have been hiding behind single-IPv4-NAT so far). > > I get that question fairly often from "largish networks", and so far, > > I always have to answer "there is no routing police, so it's hard to > > say what is allowed on the Internet and what not" - which is a humorous > > way to say "there is no consensus here what consists 'good' and > > 'responsible'"... >=20 > I sort of don't want there to be 'routing police' though :( In a way > this whole debate sounds like something a 'cisco training class' (or > other example) would have covered, or should cover. I suppose it's > fairly experiential at this point though. I *do* want a routing police, in the sense that "the operator community" agrees on what is considered "good" and "bad" behaviour, so end users can ask someone (me, Iljitsch, ...) what to do in their network planning, and we can tell them - if you do *this*, it's "guaranteed" to work - if you do *that*, you can be sure that you will be filtered while today, I have to tell them - well, today it is likely to work, but it might stop working tomorrow, and there is no document that you could show around to those that break your connectivity to show them that "you are doing the right thin= g" ISPs develop their own guidelines on prefix-length filtering, some with better understanding on what they want to achieve, others by using 10 year old example documents for never-updated filters... So, yes, guidance, please :-) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --E+PR0/1ruOTysuoe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVD/dU99WwGXkzn/FAQI9oxAAmiOZy3vvE8LJvSYU3l8keVjtm5tPe/1n qBfAikwfvZV5TCiOdGKjrTJ2Ojw4IN9M3jo6TjNptwpp9nHacPleNlt9BkH+UDOL 4L4dpDkbarPciH5EK/65QuBPrrA5h+bxGsqilPHc/EZmJi1zuGzhjBVv++96/s4s pOI2p8dEzVORkRHPWAcncfqcPMzi0sot3LJA/lFKgf2z8PdSdd3581koHvmH832V JigAez9rp71Qk3AORF99fvK3bheLZvCrOJni9Cdl4w4YP65toxsRryo0+zfw2kXb UgLGmbRIcZbrHlZal/jsXYngVMPfO77Gx8I4aeLy8efMYjRDENZxyKGoVYQsrLUb 9UTfJXdBkWIExbTQiHrOCtMwW+BdJz/WLnnl1kN+wQhlV8ZyR8sSOKNd9TTlt4dZ W0n3/n8krmEFtzkMU47NECJGzVAklnCWQkqXJ3zlPbxp5ao5HVX7e6wVAnHzxcyW 2q4wlFFzpRmq3girTGcyqubBMSprf6FVXH+gi6OR8wjtPfGV7CpbmhaZrsai0Uan zn7cac9kMFP7ieY2JgywD8Y94pPvjB/gkKloCXdCW1SBHgiO+QgMcqmUADLSaK1I R90Zukkh5slU49iw5qAFUSdER1juUrk0XzzlP1OGXE2kaobjHJPlaXJTrgX05td2 qQVdzWC85M0= =lBU2 -----END PGP SIGNATURE----- --E+PR0/1ruOTysuoe-- From nobody Thu Oct 16 08:38:34 2014 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4E21A1BCC; Thu, 16 Oct 2014 08:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt4URGXSivKK; Thu, 16 Oct 2014 08:38:27 -0700 (PDT) Received: from minorthreat.org (ec2-54-68-221-247.us-west-2.compute.amazonaws.com [54.68.221.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27691A1BAE; Thu, 16 Oct 2014 08:38:27 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by minorthreat.org (8.14.9/8.14.9) with ESMTP id s9GFc34F015472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Oct 2014 15:38:03 GMT (envelope-from joelja@bogus.com) Message-ID: <543FE66F.9020309@bogus.com> Date: Thu, 16 Oct 2014 08:38:23 -0700 From: joel jaeggli