From nobody Sat Oct 1 01:38:54 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BECE112B229; Sat, 1 Oct 2016 01:38:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> Date: Sat, 01 Oct 2016 01:38:50 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2016 08:38:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Large BGP Communities Authors : Jakob Heitz Keyur Patel Job Snijders Ignas Bagdonas Adam Simpson Filename : draft-ietf-idr-large-community-01.txt Pages : 8 Date : 2016-10-01 Abstract: This document describes the Large BGP Community attribute, an extension to BGP (RFC 4271). This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use in 4-byte ASNs (RFC 6793). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-large-community-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 1 01:54:44 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AAD12B067 for ; Sat, 1 Oct 2016 01:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 1pDgqKXwAmSW for ; Sat, 1 Oct 2016 01:54:41 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 A6EFB127A90 for ; Sat, 1 Oct 2016 01:54:41 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bqG48-0003eF-9e (job@us.ntt.net); Sat, 01 Oct 2016 08:54:41 +0000 Date: Sat, 1 Oct 2016 10:54:34 +0200 From: Job Snijders To: idr@ietf.org Message-ID: <20161001085434.GW20697@Vurt.local> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2016 08:54:43 -0000 Dear working group, ChangeLog from -00 to -01: o Reworded abstract avoid citation (Thanks John Heasley, Tom Scholl, Tom Petch) o Add early IANA Allocation codepoint (Thanks Susan Hares & John Scudder) o Reserve 0, AS_MAX, AS4_MAX ranges (Thanks Jeff, Brian, John Heasley) o Use "communities" vs "community" in a consistent manner (thanks Nick) o Clarification that Global Administrator should usually be the ASN o Removed EBNF in favor of textual guidelines o remove hints on PDU transmission, this is implied well enough by the ASCII art (Nick) o remove most of the text about Global Administrator usage, this is better handled in the "Usage" document which will go to GROW o clarify duplicate handling o clarify re-ordering o reduce routing semantics to a single sentence o reword security section, add reference to rfc7454 o move note about 'invalid' ASNs into the error handling section o worksmithing in Textual Representation and Aggregation sections (Jakob, Nick) o use documentation ASN 64496 as example instead of reserved 65000 (Nick) o spelling/grammar/style changes Kind regards, Job On Sat, Oct 01, 2016 at 01:38:50AM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing of the IETF. > > Title : Large BGP Communities > Authors : Jakob Heitz > Keyur Patel > Job Snijders > Ignas Bagdonas > Adam Simpson > Filename : draft-ietf-idr-large-community-01.txt > Pages : 8 > Date : 2016-10-01 > > Abstract: > This document describes the Large BGP Community attribute, an > extension to BGP (RFC 4271). This attribute provides a mechanism to > signal opaque information within separate namespaces to aid in > routing management. The attribute is suitable for use in 4-byte ASNs > (RFC 6793). > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-large-community-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Oct 3 02:31:53 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087D912B255 for ; Mon, 3 Oct 2016 02:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 hSSqdVZAXBP6 for ; Mon, 3 Oct 2016 02:31:49 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00124.outbound.protection.outlook.com [40.107.0.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B481912B251 for ; Mon, 3 Oct 2016 02:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PTz0WQsZgkYD7vGpu0FJdKBcTUhvOKr24L0Ufc1uRZo=; b=PU5PgIEjFZrJPJPVjP/UKqn+ZEENmdy2dBc7+/QJq5WU5nYOzJpOcvikUl0wWnHloISitpEZBBHV+UdfiLZXUmshxucEmfeG3gt6AqNgjAsUHsKOvhla5h/WokOcZVGOKEDLthK79KXarO0E0wZBclIZjT1F7uSPnxn0JUm206A= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by DB6PR0701MB3000.eurprd07.prod.outlook.com (10.168.84.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Mon, 3 Oct 2016 09:31:46 +0000 Message-ID: <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> From: t.petch To: Job Snijders , References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> Date: Mon, 3 Oct 2016 10:13:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: DB5PR07CA0018.eurprd07.prod.outlook.com (10.167.223.28) To DB6PR0701MB3000.eurprd07.prod.outlook.com (10.168.84.138) X-MS-Office365-Filtering-Correlation-Id: 956e6213-8a12-45a6-4fa6-08d3eb701831 X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 2:NFeKYG9QIhznvMT5LFMXEhpz/mWwNJrrgdfWU3W2+bMVhwt8bYHrhdphW0rVjrO9YNSH51wp5uCgog93yOypst+yGpzmaXWx+SaAW86DZ79i2vujgglTOjReKVGEJt8TmbzkZGefJMd6tWlFkHqZrzGoU4GZezQJnNcoRRqNiIrgk/mcL28mCyGHjGGfULoFxLwBzQsW24flFzrFyBFtBw==; 3:Q4qVKsJ/cny5CBPiL6sXYWEJqlTx7iHpWLLR1myJJIb2LLCN2DNZhTLQS+AD77eH8qPeYBkT+apiORwmnwbAIdYU+hKo9QLh2HI7/iiBatZXqmQiOY53hj1QvSLVxy3o3s7E5lW+u9rYE4iGfqFHAQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0701MB3000; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 25:OrosQEcoSF/2PEHHkvmiahRltlL5iOiCuoIKYQkLzSkvTF246P0rGihmYWSTJls0688fyx2imQHyE8z7Rl+uA6y5/wPVYaeChKjsPfaK0UYi8wAEjWzCAbcuTgEK6a3C6aCIaoV8Qg0iG9HbWYfluaJmSU0uDX61/AKuwwFw9CAGvdI2pTBvHulyl3wVdBkRFaUMyZQE4VlesJHq56Y0JicBwAl4BF6HW8/cC/jWczlmzSfqFPMD6HitZCXeastuqJ4pzcGDM7AIcbpLKwqWQqsITy7SfXN/cnyxKX3YgHtFci68CLGFdINuvXe/b/YoHXOFQopckYVQk/CwMdefwgmaRaNBbjPU9rPEBYBDFjKIQvJkh5gGzz1e5j1G+9gfQ0Su+2LGFUS8x4zKjZdq37nZeJMNksnBGFTs0gbEewHgrKqOEBWQEitdlN1G7ohEBYsYhOtGcAD11QrlPyphU3kWEDFxujKq1IUK5Vpuh3oZYtadCKgueQsauOA2QtVaXWVLWE6upp9afvt3XKsrenvWMUJ3BIusI5guipxiR/0eBiTEatoraSrNNnuvy09pTBn02qAfWMUqFprHmsaUCkR5vXnoMY21TSB2QxSrDx0OWAZJnTw3w27J8XT90YRWHHxcfhw1KDOteZBMw6Gb2Gp9NRcEj0Ol5Rt3s4Psas1DJ0fdeSBVQl+yQXC+j7bUjINvLAPVnBznU+ko7crpurwgWVeYGpCTtsYYYMmuWsM= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 31:DrvSDGTObSCPpxqSPlkqjMC7sXGaB/vglDBAigdjnLS+ipZbGudh1qVoqYwflbqi75xnUL9bq9ego2rrpCp4CFBBsXWiPMPi5K7WbpUNFR6s5ah/05Vy04bM6YkM9RGRWT9nwsCHEU7AVQMBO1iUy+2urnGEva543rI01NSKsDBO9ZopT7wHtXehdnXA3JuyLW+HoOhI0CmTURTFMswlX8/ARBPg7F5d8LK+FMQ0L5X4mhg1yhBSWB5oLskS2WT4KAqALiCk7l1MaSm+YkoMBA==; 4:aJWo6tcQuv9atjM6J1JH61QtfSFO8WKmxs3Nc/NpZpCDuMSvodG0mP1XykTZr3HpmKMVjslqRwDe0Fi6kl51JBlExyXQYDW8vTs/K/0U+MT57mDZSU9Rtna+/Y7e4QHEvDn29HIvmAmQ7gy22lKF5CbxzHUd5cuqERZ8rT2HNJjcOFCMiuRiQk0RQXf1S+hI8flDy9jMbwihrG9niiY1JBjZwrRonDXQYVYF5MN2O35AvVCsad/otsy417td5tRC4AV/dvkROtEJqem4ViUqsqeluPOY77OA5QXFu+l1EoITgYs/h3sh4dzX5pl6bvisEGAD4rTl+g0NL9ZGE7SekVMoM1L5svTA8PJkOXTlPAfvQT2mBcCqjnVmfK5tpxD4XuPp3AxyvyONzV6lgsrKToLnHzVsipNbGQsl3V+reYA67ZPC2QIm6mfoqoyoMhVYYb4VqKOazJ4yzXU33AxgmQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB6PR0701MB3000; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB3000; X-Forefront-PRVS: 008421A8FF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(13464003)(189002)(377454003)(54534003)(55674003)(51444003)(199003)(71364002)(105586002)(106356001)(81156014)(81166006)(97736004)(5001770100001)(14496001)(19580405001)(86362001)(66066001)(50466002)(1556002)(3846002)(230700001)(47776003)(61296003)(42186005)(7846002)(84392002)(1456003)(7736002)(305945005)(6116002)(586003)(2906002)(68736007)(50226002)(77096005)(19580395003)(101416001)(23756003)(50986999)(116806002)(92566002)(81816999)(189998001)(81686999)(8676002)(44736004)(107886002)(9686002)(62236002)(44716002)(6666003)(4720700002)(5660300001)(33646002)(76176999)(230783001)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB3000; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB3000; 23:BdBWBi+cO1bqYxEtd+dm3yI0iNslCyd2AYU9J?= =?iso-8859-1?Q?yk+wrhqtFCwJcV12CfqrKsIXEcvUS62sSHRnAwVzDKM+/YrwTedsJzeAxt?= =?iso-8859-1?Q?fuJ9+lvnzuVj/FOUs2CzAe6Egy0tylytp86BLQSiMRsCOpB9m45cln885B?= =?iso-8859-1?Q?IzqK5vzk0zH/zeg0k1K6hlgRihnf6YYMoU3OFDibdjauYjrdYaiiyB2Boo?= =?iso-8859-1?Q?35UVJJZnpBYT14Ofwwuy+A6jsVAkQfCiKazJHXwzwob3LVt/oElbXIdA7Y?= =?iso-8859-1?Q?mpm7VLyr07jfYHg6W3EBLGAtDXGW2b/u8jYaEdy/U0MCT/hkWRuYgXNmoD?= =?iso-8859-1?Q?4FMS72jvxSEpCNrbZqYWqaNbZypRiheQxlOykPGmss54WtYDiavz7Y3lv0?= =?iso-8859-1?Q?OKAhksA3jYOLm0DK4x1qec51lcPK15zdCBIxCNwwGRHdJO1IEVvx/UAmHb?= =?iso-8859-1?Q?OXKw/eLYaLWwn6zvAAId91BWExrGcihl9igDX40Do0n3PtOhDErGl/DbO9?= =?iso-8859-1?Q?BsAKpEMHiMBQUuMNa5vXT84fppqguKoS/yrADWfx0K6GWWLKfgT0iz9q4O?= =?iso-8859-1?Q?t+7LDOzO9FmCkQtZ9KKVyeDYLE8iAVqzKsKO2VXtypBih+n1fkzJeKF9cC?= =?iso-8859-1?Q?yjhANjgH6DwB38tVwNYgikf+bD8qCmIJI3Nm4gUzOMjnCna0GpYld0e37w?= =?iso-8859-1?Q?nHJFVK+eYSZwXgEDGvnpr8/UtVLjXMshvq6fCT9FB6l5nBURoznchPAXEQ?= =?iso-8859-1?Q?tK8D7KMZmVDKx03Li4IWjHa9LjTS/n2N92UqgSujPn1Yi3K+jsK/cL3uCv?= =?iso-8859-1?Q?Cf7p6qhrKgr8kp5Dp4iajA8rXLyAw6cZ6TustHlD6MCSO/1Ge7QTAlJ5wl?= =?iso-8859-1?Q?RRbBWQcjIkJYqppMbTH55mrjjxWenpFynfBnHKYXF/ABVTjyCWTIczFHXe?= =?iso-8859-1?Q?YzFg92D7gIv9k3Dxgoe8x10sePN6t0FSCEXQMKDIlBwR7iUkT9pNztJWn0?= =?iso-8859-1?Q?EaAOKD7YqhMFqWNz4ELH2jACU9D2mw6i/dDUKnqGUtgBsbe1uHWQNb9FJe?= =?iso-8859-1?Q?+DtdIPPo3MhYughIvAvTwt33oKkuCK/QxXc1ywjACxyf9DzcpbObhaTMam?= =?iso-8859-1?Q?r9FSoQihN5t1H0D0ao2vFx+i11gYlNHfbcScLHgGT8bkq/R4lXzm1T4a5H?= =?iso-8859-1?Q?1gpf17nSztGY0Ibb8zdBd/zax1zyJtwFErCj+SMF85BYkhf+SKhmS8jMWC?= =?iso-8859-1?Q?a2rZ70rJqDhXfUNq2hlvutQu1ZDtBJOf5IfYUcduf6Us5DGH36gvBidBDR?= =?iso-8859-1?Q?96VZVCXaCbbqRxzM9jx8kwGsIWfwP1eqb3/UFytzmH4rVfmkq1c5xH9Hmc?= =?iso-8859-1?Q?4vwQrh5adsoMkpJfIPTjEmlL8t2/lJZvpie1CUeQKKsKCkG/sVhNW4jSs4?= =?iso-8859-1?Q?ilR4CUc6nFnIDAWnu+f+XKUpFaGZWcdBcFpwNNRAbV0VrebNtj0YkAJYuv?= =?iso-8859-1?Q?NH5y+oAJNxovbK6TtbE2ivbZUj5tgoYSWITwDqjW8XDx8adYkPsED72Qg3?= =?iso-8859-1?Q?VZUqqhinSe2o81UNQJ2Lrpq7xsCQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 6:1I2f2iAwxDsYJgEpPETxfarH7ltTRmAx6yKNhV0vOnf/LjoL27sView8Rf44oU9RAQJVh8aWNA3qxq/0LOHT5lvuA1yrSsWh2cSlCLlxjhWRQh/X9/QSH22fQHN/11qZ42GwbcydGvKi329kLbPGSWinplubjX6eS6DAfgIieD833K/QQPutRKp/slgSnky0mUiHmcsGyAh7YYBUvWxpqIauJHTPhm6sScfas30fa51JcRL/04WhjdNGY8/nVJa0XnS4355J3uTaMYvB1hLKEwJRDObKsYj6SVMp2kEggCwd5F8fRnEPFqZViyn2T3RR; 5:S05EDrXdMilv0QpZYlT7AGw6acVZvlzzmMS+iJVVK+epvbe4depn6OwrjKNVTLhBHFCIZuyLhAemgwFAyecmyon9I+miPKcmOTaLOTCbwuS+9r/aSDv4TordGua2mGSwNiHfRvcpYK4UIZl6YHv0vfDioM0uqGOqbYCFhOj8e60=; 24:BWGK4FFb5E76EEuAwF3feSwIknLStRxIAWObODLcEyXcEsNUXX1Njp2YKM+P9SShQkMb7U+HQbZkOrr2Gg2Jt8z8+0ZD0RHyOy+jgon0P58=; 7:KJyMgTeud0q2+audBnrI5Wpg+DmFp/vTqIdPKs0GWs0kNeODzunH8ULs3CH/wN07IvwsDVdoB7dMSBcXcoar43bCVJ20HDrAbc4Z9xTT7OjyA4/W0cJTkfHd3iOVao56LEjCW6OTaEsaj/QM4n7RTE6CUkXk+UGaV9ECOOijIsZmw2GP6fpZKHacvX20g9JJRcXyxc6Ip+fccmYXcKmx7hTkFU0/pYv86Ni2f2JMjiNKqfCMzM5hGxMD06gHOcCEMDV3Fe5es6FqKDLLKUbK4YTKdyqyIqlwzxiatoQcam6pF/SRIAHJrViZZOiuifaDttKJNqiNB8PjmXS8ty/tpw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2016 09:31:46.1759 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB3000 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 09:31:52 -0000 Um The changes are not quite what I had in mind. Abstract - the idea is not just to remove the formal reference but to remove any mention thereof. I think that 'RFC 4271' and 'RFC 6793' should be removed in their entirety. If people want to know more, having read the Abstract, then they get the document and have the links. I would only put in 'RFC4271' if the I-D was closely tied to it, e.g. obsoleting it. IANA Considerations; I proposed 'registry' and 'group' because that is what draft-leiba-cotton-iana-5226bis recommends (one day, perhaps in the coming decade, that I-D will become an RFC but in the meantime, it is the best guidance we have:-). That I-D says " When creating a registry, the group that it is a part of must be identified using its full name, exactly as it appears in the IANA registry list. " And the mention of value 30 should make it clear that this is an early allocation. I like to make IANA's work simple. On more challenging matters, I think s.2 should specify the encoding of a 16-bit ASN - left or right justified? The use of 'SHOULD' implies that there are cases when this can be ignored and I would expect the I-D to point them out, perhaps there are occasions when reserved, not global, ASN could appear there. I find ' There are no routing semantics implied by the Global Administrator field.' a bit vague and perhaps wrong. I see the point of communities as being routing semantics, for some meaning of the phrase! I think Section 3 needs qualifying; it should allow for there being no communities in the routes being aggregated; and what happens if the communities are a mix of large and not large? (Something that RFC4360 s.6 addresses) More generally, a big issue with 4 octet ASN was migration, the world becoming a mix of boxes that supported 4 octet ASN and those that did not. I think that that issue needs addressing. Will boxes convert traditional communities to large, or should that be specifically prohibited (I think that latter)? Tom Petch ----- Original Message ----- From: "Job Snijders" To: Sent: Saturday, October 01, 2016 9:54 AM > Dear working group, > > ChangeLog from -00 to -01: > > o Reworded abstract avoid citation (Thanks John Heasley, Tom Scholl, Tom Petch) > o Add early IANA Allocation codepoint (Thanks Susan Hares & John Scudder) > o Reserve 0, AS_MAX, AS4_MAX ranges (Thanks Jeff, Brian, John Heasley) > o Use "communities" vs "community" in a consistent manner (thanks Nick) > o Clarification that Global Administrator should usually be the ASN > o Removed EBNF in favor of textual guidelines > o remove hints on PDU transmission, this is implied well enough by the ASCII art (Nick) > o remove most of the text about Global Administrator usage, this is > better handled in the "Usage" document which will go to GROW > o clarify duplicate handling > o clarify re-ordering > o reduce routing semantics to a single sentence > o reword security section, add reference to rfc7454 > o move note about 'invalid' ASNs into the error handling section > o worksmithing in Textual Representation and Aggregation sections (Jakob, Nick) > o use documentation ASN 64496 as example instead of reserved 65000 (Nick) > o spelling/grammar/style changes > > Kind regards, > > Job > From nobody Mon Oct 3 03:02:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91FE12B3B7 for ; Mon, 3 Oct 2016 03:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 RA-nZEpYWaFk for ; Mon, 3 Oct 2016 03:02:22 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 7BEC812B2A8 for ; Mon, 3 Oct 2016 02:59:41 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1br027-0002tq-N4 (job@us.ntt.net); Mon, 03 Oct 2016 09:59:41 +0000 Date: Mon, 3 Oct 2016 11:59:36 +0200 From: Job Snijders To: "t.petch" Message-ID: <20161003095936.GC20697@Vurt.local> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 10:02:24 -0000 Hi Tom, On Mon, Oct 03, 2016 at 10:13:02AM +0100, t.petch wrote: > The changes are not quite what I had in mind. Luckily we can try to get it right in -02! :) > Abstract - the idea is not just to remove the formal reference but to > remove any mention thereof. I think that 'RFC 4271' and 'RFC 6793' > should be removed in their entirety. If people want to know more, > having read the Abstract, then they get the document and have the links. > I would only put in 'RFC4271' if the I-D was closely tied to it, e.g. > obsoleting it. How about: "This document describes the Large BGP Community attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use in 4-octet ASNs." > IANA Considerations; I proposed 'registry' and 'group' because that is > what draft-leiba-cotton-iana-5226bis recommends (one day, perhaps in the > coming decade, that I-D will become an RFC but in the meantime, it is > the best guidance we have:-). That I-D says > > " When creating a registry, the group that it is a part of must be > identified using its full name, exactly as it appears in the IANA > registry list. > " > > And the mention of value 30 should make it clear that this is an early > allocation. > > I like to make IANA's work simple. I am not entirely clear on where you propose to use the word 'group' and 'registry', can you contribute a sentence that is aligned with draft-leiba-cotton-iana-5226bis-18 ? > On more challenging matters, I think s.2 should specify the encoding > of a 16-bit ASN - left or right justified? I am not sure that is required. Technically speaking, all ASNs are now 32-bit ASNs. > The use of 'SHOULD' implies that there are cases when this can be > ignored and I would expect the I-D to point them out, perhaps there are > occasions when reserved, not global, ASN could appear there. The contents of that field are entirely at the operator's discretion. Hence the 'SHOULD'. > I find ' There are no routing semantics implied by the Global > Administrator field.' a bit vague and perhaps wrong. I see the point > of communities as being routing semantics, for some meaning of the > phrase! I am not sure I follow what isnt clear about the sentence. Would the section benefit if the sentence is removed all together? > I think Section 3 needs qualifying; it should allow for there being no > communities in the routes being aggregated; and what happens if the > communities are a mix of large and not large? (Something that RFC4360 > s.6 addresses) If we add the following, would that address your concern? "A route may carry both the BGP Communities attribute, as defined in [RFC1997]), and the Extended BGP Communities attribute, as defined in [RFC4360], and the Large BGP Community attribute. In this case, the BGP Communities attribute is handled as specified in [RFC1997], and the Extended BGP Communities attribute is handled as specified in [RFC4360], and the Large BGP Community is handed as specified in this document." > More generally, a big issue with 4 octet ASN was migration, the world > becoming a mix of boxes that supported 4 octet ASN and those that did > not. I think that that issue needs addressing. Will boxes convert > traditional communities to large, or should that be specifically > prohibited (I think that latter)? I consider the topic of 'mapping' out of scope for an IDR document. See my earlier message here: https://mailarchive.ietf.org/arch/msg/idr/GHxOF9Y6wsdQ2e_-4jI2ejUZ2kk Mapping is up to the operator's local routing policy and by extend, the vendors. Kind regards, Job From nobody Mon Oct 3 04:23:59 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323EE12B0DA for ; Mon, 3 Oct 2016 04:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 2FuYzzcb6caV for ; Mon, 3 Oct 2016 04:23:55 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0101.outbound.protection.outlook.com [104.47.2.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1122312B166 for ; Mon, 3 Oct 2016 04:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yFfYVdyL2Tzevpf3Iy+QEE6/5Lj9lFaDf7St6XhECX8=; b=depYQbwgu2LbhnsSsOJaIjhSlYu5WZgmjP+vOx7H9OfacJogD13xR99XJaG/WElf8oHm9eQea+G9EhPPqAgSWjquBg5hvNzsRCdLnSWeH9anDPuYm3AE1D70qC1fhXMTE2EuhXpcPfLSfeAtK4mCpvqrBLU5MRbu5JNd0A3Zpp0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by HE1PR0701MB3004.eurprd07.prod.outlook.com (10.168.93.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Mon, 3 Oct 2016 11:23:49 +0000 Message-ID: <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> From: t.petch To: Job Snijders References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> Date: Mon, 3 Oct 2016 12:06:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: DB5PR07CA0005.eurprd07.prod.outlook.com (10.167.223.15) To HE1PR0701MB3004.eurprd07.prod.outlook.com (10.168.93.138) X-MS-Office365-Filtering-Correlation-Id: 10028b80-1986-4bcd-ca27-08d3eb7fbff1 X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 2:+pzbr1/SfQ/qMDCtOTpKRs9Dlb0hDXgKqbYUzgGCq1ayx/F//7lyLfPLC7Sv7s/gUj1w6952GHnvGcLvgJsL6LrRN78fUaOmNdNx/WLAs6fPai2HwdOfl/5gd/gJB2gg9SU4IYpgL2Rz6dqaCiGhwlmkudUCwP/RKsN8MQ1Lo7VWoyY6W16XjNtZpCgdXFoC; 3:HNyW2emOQXBNQSSHvt2SVYka2F/sOsBkAWIDRwtHFs3Rpl9+Z32S3BI4e68oKikt/TOxmTKZpU8Rx5wtdo8EPc4VMnTk2uBKii9fpReN+vwTg4WQ/RVYt1NB++B50Lol X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3004; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 25:BksZ0f1hBA67MBqVG9NyqbITqAJqKI/mhOkvMMdu0Nv0qbBce3cAo9L0/WY5nNvCIRAbJAE2dtaeszSmGGDVb2uy+hYaOpzbZMMUuy3ruaJ6ld1efIwsfbMvwx0H/baMcU0Bd39lVbsDl07ivEW+7SRWi5f74jisMatk5Ngr89sX5qk2X6DqTzwG83B+GUsZl6BChsPJ8g4SD0ouG1RxscWSUmfznJEOcaDkVxXIw1qtxIee3JLdfwEg3iBF31bpqApiZJs8HeBmoRYWjojei5TqIgn39klwuSSmUcPB+9XVSqvj0SxvpZfvOr/qc/kYc8y4IzrdDvmckoDZHYB5RkjJOvAkCCLbX7fHPWWJoea8uM7DykA2CIantAogglio0b7RIbAz1ayOMku0q4Iz7MZ9sweF0anNejRUpnS5LdQFhbOj+MBDqXtup3PxEvGcQ0GtFIEY2cV9VEn1/9GyNbDnntXW2g8HqAtiyw9ABz6sOeiT3uSHXSI0x2gVsltEIde7Yupt7jerhhnsapcBk7hdEotiXPZzG773mOIlKWKC07YddZ11VmnuDbqpdvsuuFRm/YTE+M3ElD808qs+YZgGkRJb52Zt80lZFRlim9s7b/QG7EkgfEUdtml49hKVnNHi2hjq/XcOBMa2EDUEYw7C68iMjG2Y1KOfsM9MmFbmYD4Jk/urOkVlwgZqOpsEOgb+tfnfzhk/qmIeXeF5Jq0Ct6bKBrIYDzXM3wPttPNh+oIImXURal05o/03sDeck/JTVOHw/GD0qo1LtTON1RUqi3NBqp1non5c5ovKeEOT0lwS1/uztjSo+T9iM4WM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 31:Q8ZWBukgBKeo3VeLr5dPU/80+7+/trJz4UjBkYZ8Xecgg0C7hEXlrFzValKZyvsdTXTlWo/b0tqUB7vs3FVuvUsK/Q0u3RnydMavUKs29k498JjveMWVheJbKtWtefxNPms/7b+LAtwctSQTE4Nm6EMUIFv06oijVzIaq8Ag9n2Xexn3qAZxDYG1zBy0D9lHaAlOudYNiJpLZRmIJ/aAw4RhC1p8x4yPEJXpTT4llgU=; 4:adKT8psd4lgikLvs2bhiLToG/uBouzffG/xf4VpUGpbDz8qpyLwfYT6dPKo1BK7w1Q1McJZUOzUhrZDZ91NYeyu0OIi9fR1xFitmEsMnDsaveiPR+3+8vWrWGE7sDfY3pSlNQ4xotJF5v8d9Qdz1qjm/epfc9DLncxflod4EN09JCO/iifBClMpecHP5pFg47UWYjDus2gz6BhO0PW4mmFxz5NKWjEGXSbCL4QuJ2xf6vHqWmhu/brRzKFq8ISWSTxAqikw0Ht62pa2JWdc4VsVPWMhZk5frYU+IJwAiLis+TYddmyR3QnpzfAhOFmvdsQwkIVsdQLAkTY2Z0L/E1a3cgySHSaAuWaYFQcWFtn27L7wUgs2nQoilW45GVpWiI5PUxD4Xy7ZLQe4AkrroUIXCBZz6TOuebE/MjdqF2mfwJtHgKESQiDcE+mMDTpsO X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:HE1PR0701MB3004; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3004; X-Forefront-PRVS: 008421A8FF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(189002)(13464003)(55674003)(377454003)(24454002)(51444003)(71364002)(68736007)(33646002)(101416001)(86362001)(62236002)(15975445007)(47776003)(77096005)(305945005)(66066001)(92566002)(1456003)(81686999)(230700001)(19580395003)(14496001)(19580405001)(50986999)(116806002)(4326007)(84392002)(189998001)(76176999)(81816999)(44716002)(7846002)(7736002)(23756003)(8676002)(50226002)(50466002)(230783001)(81156014)(81166006)(4720700002)(6666003)(9686002)(2906002)(6916009)(106356001)(97736004)(3846002)(5660300001)(61296003)(44736004)(1556002)(6116002)(93886004)(42186005)(586003)(110136003)(105586002)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3004; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3004; 23:cS+YWIzP4QIGS2K5ozU0x+ZQ2Ca2xW9LqQsLq?= =?iso-8859-1?Q?Qj5PlUW4GbALUmXVeLb1eHlrPAHd0gc9Y8qKd9I2qWPhfz09ytm8Mjjdsk?= =?iso-8859-1?Q?rXtPoS974ox6Q+MnrL5mvROkszogb4VI8nUIGx0xdDfm45GpTFDtI0rXGK?= =?iso-8859-1?Q?PohEySaizOzV4PSJ+Uos0kzcy0xKbBpw1+q+Z7dckjKq+c85I+q8FFhFXP?= =?iso-8859-1?Q?o0nbU6qQmGptIyn3b77UVYsUg7ZrZ44kH7heswuALmV6SL1TajKNgmHn1B?= =?iso-8859-1?Q?lo1HR6UV5FXJ9t93Uwvlxz0wgtzHiNtO7lzDEBDRMle1lwxf8Hyp3BeOBs?= =?iso-8859-1?Q?7EHgQDnXIEIYjX9Kt4d5wpKDaABKLL8XZ2pfJwLbw8pulmfLZQmmeb+c+Y?= =?iso-8859-1?Q?KnKqCeIYnYyGjkeqRV3uxmKIr0X2DmRHDUoaAfTd82TmCB/eCWrOPeDGiM?= =?iso-8859-1?Q?mgG6UHpE3XP6uSTS5pFn7VxsM2/+TfN3bHdfys9lMgpCyVu3bnIAgnFHNh?= =?iso-8859-1?Q?28ZceybRt6UYp48my0wrqtHK0Fj5dZov3rQw593WzzvetXYxMU/PRm4NH1?= =?iso-8859-1?Q?9KYJ7+CxZ4b8U4jLj5i5c4ZuYUQKLbjdpYxs/wroL0+Ze/lSloycdk1jBg?= =?iso-8859-1?Q?2MWd5Wms88eECEE1oaRxH1TLBy0tjR1gvIpDAPido//0pU2tnWAzlfaQn9?= =?iso-8859-1?Q?+YN35A2eb+30UREYPdG7609TUerYHIa+NoH0oGD5wtPTKvHBq62bEp08uF?= =?iso-8859-1?Q?c0910rDFkCMAx5iRXhbg1ACeMbEAklRECFCk3cAhKRfCEeEEb94yF6wncY?= =?iso-8859-1?Q?aQIA/hdXAGcfz53krN2bvSUE20NPvSh/h0DvGyPy/YwT9nidkDtErK9rzK?= =?iso-8859-1?Q?+S1rwsrulpDuHK+Rectd0ec2KcX6nfBtgSGH646V7gs2PkGBKZvFmyCHCl?= =?iso-8859-1?Q?GVFpf7a5K97y0Xd8F/FcAWchrsHBv8yr5VkTyt04bsDd1tUzsOApK9FUPN?= =?iso-8859-1?Q?0ktW2wInF1bD51HtJUBZuCM8N+6HdpfGQiAaCzAgzWxl8reRw2HRQKRPRu?= =?iso-8859-1?Q?2HJxiaJvEHZKnM9hClAyBTboPmsPPaMVoYe7dWH72Kmg46kYJWcbiWn2pR?= =?iso-8859-1?Q?6+dgaaWESa9jDSTZo/Hv3WBJEBtwy4x40fCbtylO3UuDuJbs6/BsBpuH7X?= =?iso-8859-1?Q?0IfTVIhq//Byih2xKbUXUGeGso943eLjdJnGInoLoayRsKR99ZiG/5H6de?= =?iso-8859-1?Q?N6B7KZVO84G0SjQ/tKFbjfB1HTEvshDApLfjgiZRJpLtyaQ9IpUAZ2Qvut?= =?iso-8859-1?Q?ZxAff4nNvll9w6KOYLC2vbzRNaiIrckudtUb704AIYINQFoEzv6AOlj0bK?= =?iso-8859-1?Q?iK6km0INkZnapRhs6Jz5jOqV2Wur/QY5K1sB3tYZj0jhFgJDitoWLPWY6K?= =?iso-8859-1?Q?XkwpHntiv+z+FYfGyYiSrPLOVKDoS4IGmwYj+csRIQ6gcuAj5Az3VK0m+F?= =?iso-8859-1?Q?fv59/rg8jfbvFlgnyp3qt7xlhx4Nh45R5w5AJct60GqMQ2NO9AfCOFloXM?= =?iso-8859-1?Q?WGWslxlNSqtdeLRqFOtZy6oegoTleQNadZ7Qk8ZlMT7Vp40zupmwk0AF2e?= =?iso-8859-1?Q?2y/vJzc3yfCDIbTMPMpohpnkJIx96JDJvM=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 6:h8O5kRfYRhBiK62baDqSHhMgyh8AgV8+eweD3L6h0lb3PLnWn/ziKAM+ib78sR5bo1Lw9BTBwAtuc6IXKdi+6F1D8+95ahAwCZF2GIgGVPYRYn3Udf3vHWyYq5rI9KtQh+XworMFlJgeu2fMuo7LT2rr4JH6/GkRurOQV62BC/buSvEqRNuR65d/cB2WK4G/69ER0dRO8TGdSoJtJeB3W5hOvn8iqm+ZHxW1zYlERFY5W3bH2E7k1eB7RcSbHdJiyjgshJrsC/7QnlYgdzpLpmHLtzEh3N+s5rDjl+++3C0=; 5:zM5uA0LYHstZgpEJwh6TQeIvvtGBLT1x3JM+LCVTq19UiSumZd7xbIFyReng0pz08KBr5P8CBtwofOM2/ajefwhJzjprmQYETQxjeRT034s6PlJb3QY6O6nggniL1nYq5Rma6kbK4aMQ8L50/HYgEw==; 24:axGGuyyRDyWljiwQEahT+Hb19swUOmSYdKl3NXcbzYDZChyU+Qk6A+N2vnq4tXmT0+kpOsq20dakpdKuDaacBf5Vh+UwnyPQFsAxnqyOHbY=; 7:C0k4TL71ABPO3KM51r1Pj7dFpfsfVOIjOdousMzpFfz+fnfvVBhiCCLG//P42usde9zJleQQDP6m8kfviAApgqG13YiiyAaF3/H+on0p60lnzYVagc2XvqIOTjhAZNL9BbhDHCxDqHl1S49+EwlKgXaGrqYTYMyCHFxD/mAwuuzMtWodsrFmTTWQzX8CMSQ3QXQvwBqL+6XqQrU8r+4pdO8eyrDQ5bgCbCdMyfrxARbA0I/uTPkis6RrCcdHPAabnUm2n4XFoFDlX5Au2n+H5/FOzGBRqNm7DuOQLXmk93bMmzb58n9boHQvV5jsNUlA SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2016 11:23:49.8564 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3004 Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 11:23:57 -0000 ----- Original Message ----- From: "Job Snijders" To: "t.petch" Cc: Sent: Monday, October 03, 2016 10:59 AM > > On Mon, Oct 03, 2016 at 10:13:02AM +0100, t.petch wrote: > > The changes are not quite what I had in mind. > > Luckily we can try to get it right in -02! :) > > > Abstract - the idea is not just to remove the formal reference but to > > remove any mention thereof. I think that 'RFC 4271' and 'RFC 6793' > > should be removed in their entirety. If people want to know more, > > having read the Abstract, then they get the document and have the links. > > I would only put in 'RFC4271' if the I-D was closely tied to it, e.g. > > obsoleting it. > > How about: > > "This document describes the Large BGP Community attribute, an > extension to BGP-4. This attribute provides a mechanism to signal > opaque information within separate namespaces to aid in routing > management. The attribute is suitable for use in 4-octet ASNs." Yes > > IANA Considerations; I proposed 'registry' and 'group' because that is > > what draft-leiba-cotton-iana-5226bis recommends (one day, perhaps in the > > coming decade, that I-D will become an RFC but in the meantime, it is > > the best guidance we have:-). That I-D says > > > > " When creating a registry, the group that it is a part of must be > > identified using its full name, exactly as it appears in the IANA > > registry list. > > " > > And the mention of value 30 should make it clear that this is an early > > allocation. > > I am not entirely clear on where you propose to use the word 'group' and > 'registry', can you contribute a sentence that is aligned with > draft-leiba-cotton-iana-5226bis-18 ? IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY ) in the "BGP Path Attributes" registry under the "Border Gateway Protocol (BGP) Parameters" group and is now asked to make that Permanent. (I am assuming that all goes well between now and IETF Last Call:-) > > On more challenging matters, I think s.2 should specify the encoding > > of a 16-bit ASN - left or right justified? > > I am not sure that is required. Technically speaking, all ASNs are now > 32-bit ASNs. Well, not in traditional communities so if anyone 'knows' that the first 16 bit are an ASN, they will be disappointed, so I think it worth spelling out. > > The use of 'SHOULD' implies that there are cases when this can be > > ignored and I would expect the I-D to point them out, perhaps there are > > occasions when reserved, not global, ASN could appear there. > > The contents of that field are entirely at the operator's discretion. > Hence the 'SHOULD'. > > > I find ' There are no routing semantics implied by the Global > > Administrator field.' a bit vague and perhaps wrong. I see the point > > of communities as being routing semantics, for some meaning of the > > phrase! > > I am not sure I follow what isnt clear about the sentence. Would the > section benefit if the sentence is removed all together? For me, yes; you say that it identifies the namespace and for me, that is enough. > > I think Section 3 needs qualifying; it should allow for there being no > > communities in the routes being aggregated; and what happens if the > > communities are a mix of large and not large? (Something that RFC4360 > > s.6 addresses) > > If we add the following, would that address your concern? > > "A route may carry both the BGP Communities attribute, as defined in > [RFC1997]), and the Extended BGP Communities attribute, as defined > in [RFC4360], and the Large BGP Community attribute. In this case, > the BGP Communities attribute is handled as specified in [RFC1997], > and the Extended BGP Communities attribute is handled as specified > in [RFC4360], and the Large BGP Community is handed as specified in > this document." Yes, that would allay my concern. > > More generally, a big issue with 4 octet ASN was migration, the world > > becoming a mix of boxes that supported 4 octet ASN and those that did > > not. I think that that issue needs addressing. Will boxes convert > > traditional communities to large, or should that be specifically > > prohibited (I think that latter)? > > I consider the topic of 'mapping' out of scope for an IDR document. See > my earlier message here: https://mailarchive.ietf.org/arch/msg/idr/GHxOF9Y6wsdQ2e_-4jI2ejUZ2kk > > Mapping is up to the operator's local routing policy and by extend, the > vendors. Well, Bertrand Duvivier seemed to be proposing something along these lines last week, and I for one would see a mapping from old protocol to new protocol as very much is scope for the new protocol I-D, if only to say there is none. Tom Petch > Kind regards, > > Job From nobody Mon Oct 3 04:41:38 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F5812B114 for ; Mon, 3 Oct 2016 04:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Dwmc9Eg1582D for ; Mon, 3 Oct 2016 04:41:35 -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 47A8512B05B for ; Mon, 3 Oct 2016 04:41:34 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u93BfUcM024656 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Oct 2016 12:41:31 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <57F243E9.3010902@foobar.org> Date: Mon, 03 Oct 2016 12:41:29 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.3 (Macintosh/20160930) MIME-Version: 1.0 To: "t.petch" References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> In-Reply-To: <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 11:41:37 -0000 t.petch wrote: > Well, Bertrand Duvivier seemed to be proposing something along these > lines last week, and I for one would see a mapping from old protocol to > new protocol as very much is scope for the new protocol I-D, if only to > say there is none. creating a mapping between 1997 and large does very little in practice, except to increase complexity. Certainly it doesn't make 1997 community support any more or less available. I'd be in favour of not having any mapping between the two Nick From nobody Mon Oct 3 04:57:32 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1762D12B199 for ; Mon, 3 Oct 2016 04:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 E55zp5XS585V for ; Mon, 3 Oct 2016 04:57:29 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 89FEF12B189 for ; Mon, 3 Oct 2016 04:57:29 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1br1s7-000F6Z-Sy (job@us.ntt.net); Mon, 03 Oct 2016 11:57:29 +0000 Date: Mon, 3 Oct 2016 13:57:23 +0200 From: Job Snijders To: "t.petch" Message-ID: <20161003115723.GD20697@Vurt.local> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 11:57:31 -0000 Dear Tom, On Mon, Oct 03, 2016 at 12:06:53PM +0100, t.petch wrote: > > > Abstract - the idea is not just to remove the formal reference but > > > to remove any mention thereof. I think that 'RFC 4271' and 'RFC > > > 6793' should be removed in their entirety. If people want to know > > > more, having read the Abstract, then they get the document and > > > have the links. I would only put in 'RFC4271' if the I-D was > > > closely tied to it, e.g. obsoleting it. > > > > How about: > > > > "This document describes the Large BGP Community attribute, an > > extension to BGP-4. This attribute provides a mechanism to signal > > opaque information within separate namespaces to aid in routing > > management. The attribute is suitable for use in 4-octet ASNs." > > Yes This has been incorporated for -02. > > can you contribute a sentence that is aligned with > > draft-leiba-cotton-iana-5226bis-18 ? > > IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY ) > in the "BGP Path Attributes" registry under the "Border Gateway > Protocol (BGP) Parameters" group and is now asked to make that > Permanent. > > (I am assuming that all goes well between now and IETF Last Call:-) OK, i've updated the -02 draft with this text. Thank you. > > > On more challenging matters, I think s.2 should specify the encoding > > > of a 16-bit ASN - left or right justified? > > > > I am not sure that is required. Technically speaking, all ASNs are now > > 32-bit ASNs. > > Well, not in traditional communities so if anyone 'knows' that the > first 16 bit are an ASN, they will be disappointed, so I think it > worth spelling out. I am not convinced, it does feel somewhat superfluous to me. Section 2 clearly depicts an ascii art with 32 bits for the Global Administrator. We could add something which is akin to what rfc4893 states: "For Autonomous System numbers which can be encoded as a 2-octet value, the two high-order octets of the Global Administrator field are set to zero." Do you have a better suggested sentence? The above feels like a kludge. > > > I find ' There are no routing semantics implied by the Global > > > Administrator field.' a bit vague and perhaps wrong. I see the > > > point of communities as being routing semantics, for some meaning > > > of the phrase! > > > > I am not sure I follow what isnt clear about the sentence. Would the > > section benefit if the sentence is removed all together? > > For me, yes; you say that it identifies the namespace and for me, that > is enough. OK, removed the sentence. > > > I think Section 3 needs qualifying; it should allow for there > > > being no communities in the routes being aggregated; and what > > > happens if the communities are a mix of large and not large? > > > (Something that RFC4360 s.6 addresses) > > > > If we add the following, would that address your concern? > > > > "A route may carry both the BGP Communities attribute, as > > defined in [RFC1997]), and the Extended BGP Communities > > attribute, as defined in [RFC4360], and the Large BGP Community > > attribute. In this case, the BGP Communities attribute is > > handled as specified in [RFC1997], and the Extended BGP > > Communities attribute is handled as specified in [RFC4360], and > > the Large BGP Community is handed as specified in this > > document." > > Yes, that would allay my concern. OK, I've added this in a new section called "Operations" in -02. > > > More generally, a big issue with 4 octet ASN was migration, the > > > world becoming a mix of boxes that supported 4 octet ASN and those > > > that did not. I think that that issue needs addressing. Will > > > boxes convert traditional communities to large, or should that be > > > specifically prohibited (I think that latter)? > > > > I consider the topic of 'mapping' out of scope for an IDR document. See > > my earlier message here: https://mailarchive.ietf.org/arch/msg/idr/GHxOF9Y6wsdQ2e_-4jI2ejUZ2kk > > > > Mapping is up to the operator's local routing policy and by extend, the > > vendors. > > Well, Bertrand Duvivier seemed to be proposing something along these > lines last week, and I for one would see a mapping from old protocol > to new protocol as very much is scope for the new protocol I-D, if > only to say there is none. I am really not sure we should specify everything the document is _not_. (Similar to your agreement to remove the sentence about 'no routing semantics are implied') I also do not see precedent for 'there is no mapping between 1997 and extended communities' in the rfc4360 document. I agree that mapping in and of itself is an interesting challenge, but the concept is probably is better served as an internet-draft targetted to be of Informational status in the GROW working group. Kind regards, Job From nobody Mon Oct 3 07:15:22 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D22112B302 for ; Mon, 3 Oct 2016 07:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HSr19MadbGpf for ; Mon, 3 Oct 2016 07:15:17 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 09B1312B333 for ; Mon, 3 Oct 2016 07:14:11 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id 94B0D5407E1; Mon, 3 Oct 2016 10:14:10 -0400 (EDT) Date: Mon, 3 Oct 2016 10:14:10 -0400 From: Jared Mauch To: Nick Hilliard Message-ID: <20161003141409.GA18150@puck.nether.net> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <57F243E9.3010902@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57F243E9.3010902@foobar.org> User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 14:15:20 -0000 On Mon, Oct 03, 2016 at 12:41:29PM +0100, Nick Hilliard wrote: > t.petch wrote: > > Well, Bertrand Duvivier seemed to be proposing something along these > > lines last week, and I for one would see a mapping from old protocol to > > new protocol as very much is scope for the new protocol I-D, if only to > > say there is none. > > creating a mapping between 1997 and large does very little in practice, > except to increase complexity. Certainly it doesn't make 1997 community > support any more or less available. I'd be in favour of not having any > mapping between the two I don't think any mapping is a protocol-level thing, it's something providers may decide to do internally, just like supporting any other protocol extensions, eg: multicast nlri, flowspec, 2547-vpn, etc. Some may, others amy decide not to. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Mon Oct 3 08:25:45 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB15129617 for ; Mon, 3 Oct 2016 08:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 i4dN8ecruG_P for ; Mon, 3 Oct 2016 08:25:42 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40130.outbound.protection.outlook.com [40.107.4.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29F9127ABE for ; Mon, 3 Oct 2016 08:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=weDsf1h8nLG6Lgr2H806bVOtCVUBFaci2b6k2z/VBec=; b=daSbv1YmUF+omr1BYF1AZgWNhlWr4Bjqbrt2YYrxqIguYbk+kL5zArQQOBWiSltoMdCOHrhUy1uI+EF7oqI2ilWVzCxoXTLULzu9uZS+7viGdSUT8wDvUzj3Rgr0A5o3ot4yb/RF/T4n3eOtdhuZjapoI1Jsv7cleyh+rI2li8k= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by VI1PR0701MB3005.eurprd07.prod.outlook.com (10.173.72.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Mon, 3 Oct 2016 15:25:39 +0000 Message-ID: <01a401d21d8a$1aa6d840$4001a8c0@gateway.2wire.net> From: t.petch To: Nick Hilliard References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <57F243E9.3010902@foobar.org> Date: Mon, 3 Oct 2016 15:59:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: DB5PR08CA0084.eurprd08.prod.outlook.com (10.166.166.180) To VI1PR0701MB3005.eurprd07.prod.outlook.com (10.173.72.147) X-MS-Office365-Filtering-Correlation-Id: 22200acd-bf32-4b43-22d9-08d3eba1883b X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3005; 2:C9BCUfcvG7kONQ/jLDfZmxzOBZ2VPiqJj8PXekh9iPyLGYRu86hjgOrpVgBHTqtTZOag86edHWxf9xVwbo/Z30WN0dGGdSk8GJfdJZmItVFlmTA33UN0iraFk7ZreowTbyKyklvMwOUG6e7/5nfkl8Xls+nxmRS/Nw+wQvftgk202R/C0Gg7E5HiSbqGI8Hc; 3:YDuM31Vbu9smK+UPbHA+LdedsE+15ImRKZuHlZIcn2FpylCzJsi1XIAGGYVnG0WoaKMjhEsIqm+w4hTWohjtWgzraE1RdzEZik+4ZFu5S//GW0DKwxt9ElD+AolSIeLT; 25:QFRTM+VwA7CBTZRH0i97d6Jem3BIAnKVfEsUNmn3KLjDw8iaa9wMcIAhY6348j6dkv3cRHyJF2CFl5+Md9dY2u/hSQKgaCz9BEnlbIXFh1rZFQtOgmvPx3tyrUm03Y0MSkaJ15XVHDq4TVNFW4dJMUpGnkQLrQIKoQDjd2qdA7wbubECCmzOroSN+ww1M2n3o7V04caAypVs1dyu//roxG4iAJCHHK9z5llc2n7D6w6YQBD6B7B1Iuf0WeJ1vxzShmpvSG4B9Ouu8oLB+PaEEya0T9NC1uCOD62+C1pwwjO18IaFVn7yYxP9RQzTl5vA3mNsamamPwK8AJrZYtmRKa4HMKZbqr0+UeY/TBHX5KK6BVrxw9AFIBCZBlMtBdf0joxaovk9JEfp/mDWH0ito6V3HcR48vSsD51Px+lFwD0= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0701MB3005; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3005; 31:kF1XN0NavGWe/e1SnvvVg7kaym6tPgk9AsSbDhzzyb3C1/fA8agP8+8JLQq/ZcOgMKiqN2KjbG7JqC+G6miImI/znWOMyTEMVK+DbG7IKndWySk36u5MM30tSHF3ymwsur+4p4Qi6AtsSTrZa2+LESCw3YLobrrp4CpzcrqUb+cmw1qxzrTqzlRQuFdivRAkJUSR4ZDifvepL03B0cXORhc0rYN3HAR4asFsz2V60jo=; 4:pkX/YwM7XUJy9ug1lAptmSsvVP3hwIkhYfJZxKzMAS/q4qYvAPZ85kYeTEevtFkN1RDYCSemuHvATWYIK0R4osU/4Xt6Z5z41O9OOejav3aihNT9XElAyWHQv81p3UyvpKKvxbZb6ueRvUq1KKPgpNtUg9kALnYIHgdO5xK5+8NrmK6yx+jR1UsBz2fWR5Olz5qP5Qd1XuvusoPVoBhG1jppFaAfQgLMAqqwWxpxLGpT9rm2oXBDIOI0CzhNCvDmeLJzdwT2UevmC+aZrOeSvpl6mu55oRID5umYFJGksqJJ98iICuCt6c2x1eSFq4DcNtHaOGb0M03MMqgnW7GaqFsEkW508igOOf37d1ZWGug2HVmVF0oISPEL+Au10ftvFsbWlZKJKUOSDNYTTb67g01xkybRbSAoFxZLAl2jUk0BxmPzvV1xGWwHt9NZjEC0 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR0701MB3005; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3005; X-Forefront-PRVS: 008421A8FF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(377454003)(54094003)(189002)(13464003)(24454002)(101416001)(105586002)(23676002)(61296003)(42186005)(81816999)(81686999)(76176999)(81166006)(189998001)(97736004)(9686002)(44736004)(1456003)(116806002)(68736007)(3846002)(14496001)(8676002)(81156014)(77096005)(50986999)(19580395003)(19580405001)(106356001)(230783001)(6116002)(93886004)(62236002)(586003)(230700001)(50226002)(7846002)(50466002)(33646002)(5660300001)(4326007)(86362001)(84392002)(7736002)(1556002)(92566002)(2906002)(66066001)(305945005)(47776003)(4720700002)(6666003)(110136003)(44716002)(6916009)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3005; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3MDFNQjMwMDU7MjM6RWtRNDNTUDI4cG0rZFdFY2pCRFIrZmE3?= =?utf-8?B?VCtBanNxaFo4ZFJhL3hnaW9qM0xiRk9CY2dwNXF6YTZ1ZWhvSG5DcTQyMUlU?= =?utf-8?B?V09pNTg2aWdxL2ZsWXFKNVBvN0RUVTFMakM5eno4T1lBQUlRVlFHSG9MbVdR?= =?utf-8?B?dG1HSnNFSmNFejZGUDFxRFBYdDBuZUhqYjdRTm5iNlhxMDM1UzlrdUVScitR?= =?utf-8?B?SXpSaks0R0M2TU44SEtTQWlqMFJSOGFPU0orRTA4QjVjZ0Yxb2hPYk45M2Ex?= =?utf-8?B?cmRMWHByUktMckFHVmJDcnM3RVd6dWY1OGd5ekZEaGdXY2lVcmFONWkrQTF0?= =?utf-8?B?dFdVTjhIVjN4YU8vRU5jYm9UZDBkUWZNQ05KSFdNY0NSMUdBdEZ2cVpMcFhx?= =?utf-8?B?QUNHeXB6dFNIZWNoSVkrRGF0akdyY1lFYWFnbVFyeHQ4WERyMzBpVkxNVUdQ?= =?utf-8?B?dDZzdURrbmI5MlRGWE1EejlKczNMSHRQNXBIa0YzU2FIV09Fc0VIU0VwZGFw?= =?utf-8?B?bWlrS1ZQbFRLbzI1SnA4U3A5dGd6QkVESVJVYkxNbExmSW9YZVNFeUNYVlZi?= =?utf-8?B?YkxkRi8zdVdrYzluYnE0WEQ4T2k4Tzl5UmtGVDBqbmZWMlJwT3U5cWwyeXRN?= =?utf-8?B?SUgxaEV0QU9BYnVXS3d4TVJmY2g1eVVJcGk3bDFDd1h5bWlueEIyU1l0SjA2?= =?utf-8?B?L0c2L2FHU2hMZEFVa2trM0N3b3QwSHVSUVFkTy92Y3A0UzFSakFwVWFuRUR6?= =?utf-8?B?dllMNGJHT3FVQVZuQmw3RW9yZW5PazB1byt1c1FmUTd3anZCZkdPaUxBaHh1?= =?utf-8?B?NUR6cExDSVIvaERYTkNaV3Jra0lZa3FmU0JIQWdpK01RbmZWSUp3YzZSZUti?= =?utf-8?B?L1VUdlFpb0NzdzFMWSt1cDlZNG4zcnBBOEJzazFYL1JsV2V6VUUzQ3cvVXo2?= =?utf-8?B?ZFUwbzhUSHJMUWxhSVV0Ty94NDlsYkJHZjkyY2NnU3YzMlRxSVZ2L2Z5RHZv?= =?utf-8?B?Z21DMm1nNGpnQWlXS2loNGxUSzAyZTJtZlgzd3E2c21GTm9ydExhakpUTFVO?= =?utf-8?B?cVlaK2JSME95QiswTC8yazJZL1BrNDBabW5mYmM5eVJ2L09jWDJVbDVHS2Fv?= =?utf-8?B?QkUxditDaEJBelpNUml3M3RpSEJNWUdEQk04cHpVdzlpaDRZdzVVZERUQi9J?= =?utf-8?B?T0Yzc0FNUFE3WGczQmcrbnlrdzNaN3EzQmczZzZZeDZoVnFvWU83WldGKzhY?= =?utf-8?B?b1RLbDIrblNLcWVhSHVSNXJ0Qmw5TERNTm1Oa2xGVHhYb3JzM1hibzg3SzRk?= =?utf-8?B?NTR3K2JySW5RemVWWER6Qlc3OU94KzQzQkJKbm5LYWdmeWVCYnBpZWF3ZjlH?= =?utf-8?B?eFZjcFhMS0R2aGljUCs1THlHN2MzV2t1a1M2M01HNk05NXB1SGNUM3A0OWJC?= =?utf-8?B?RUVSbTZYdjBDVTBZclFob3BJYmk0QVQ2enBwcWpaRkh1aEttc1lVUEN1a3hm?= =?utf-8?B?U2IwbjkvMXdXK01TYjgyOEQvTmpwOFBmaHFhT0JKTkQ3bFl3MlZmRnVGN1lV?= =?utf-8?B?YUFzbW5HNEljTEtkWTlKYklBUjMvUGdTTmhFbU5rTEZqQ2V4aGltS3JQazNY?= =?utf-8?B?MEZzOG5SL1p3RkliOVJYc1B0RFpWYzJpcU9XSi9BQStaT1JTcUNCclhnOTNz?= =?utf-8?B?YU9QNFRVY0hxQ2hFYzVZVWd0c0FWd25LMWJ2Nm51VHpNWm1oejBHMVVUajMx?= =?utf-8?B?OFYyekdzVEdLKzg1Zi9JVTZ0ZlB2dEcwL1BaeWc5ZGZIWWVlTHZBOUhTNEVh?= =?utf-8?B?S1BoN0RIdk5yTUlkWkhUcmR2VkFkSXcyQVJIVklHY0RxeENTbFFwV1ZuMUtE?= =?utf-8?B?QThaV21rS2RyVWpjeGZic0x5YUdqR2txd0dMOTJBN3RaU3ZWNCtxZ1J6QWFj?= =?utf-8?B?ZXBLSFc0N3ZYZDVpY24wbTZZQ1A2d0ZWa3REOFIyYUN3d1c0L0tXMklQb285?= =?utf-8?B?Z3R0bDE3WUdyZkxjL2JNcXIzUHBoSTlqYUJJNlRLc1crY0VneTNaYUZDYlRi?= =?utf-8?Q?1549wU=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3005; 6:t5bLnwfPhZ/Olqb/paFdsjoPnKS92lWH2li60ZZunkW5r0Hf10eNJF+lXWuQHSNlAa0jsDrb9k5NKNl6H1emwLF1TfSNyU0gJp3yooQc7I8YCywahYDV8FdpIF+j9zPzz/lpbqwryYnsdBGHL4m5uepJhO4GDHvXK1kd5H+TAKrvtPxlTGI6dYZzTcwKdX9tzmZ7aOSkpqW0mdZSNkjbVzrWLEMp7VrBCmppgag2r60QebXIXvoBw8JL6X0gRpAFlOsib2XoFoiHfFSiiuX4yIIA4Japv9KCzUgJ249Gvxs=; 5:KWcnjGqBZ2fm+aDcg+U9jyV9OpA69jq0GuRq5Msz7lCeU0KtmLA92fA7AIZHC/wxHybJ2JppEgO85vohJaBoFw+Zes/4zPHURii6CY7+hjvK0Of9bl/oyt8o4ZcoT7YYAqzFh8PvHWX2vu9px4GqXQ==; 24:lZa1V1ts4PtjDYQTSEjgEyhUZE6woOzzj+6pYXgwqn29s4gddPa0hnTJm+pQK97PDSSHIlZtkVaGO4BY1jF7XbT/L5Gw3fH/5AkHDd9kzjk=; 7:SxeKOCPhjJizPnzA2ygc0clsZLCJkuPNWuf2/LrNvL+fx9KmBeo901YTjHZHOwLgy5lTUAENlfeR6fTbRjshP0GEPHufzBSC6S9Yade3IS++mApp0cau8hCVGj4ua0qIacIPEfWmaqxqzbjooyRJYGIpZolqAcrPXuYksUh572UWScTclg8Y1wC0mHrmglgoVxEUh7vLv7zkamfLgmyq0I30F19cuLmLM1QSY427MNHp0II3ooMySuzCqXdGPpuv2wRSMKc0vMG1fvbCMOOlRoZBuWbApP21FlySaj5B0uB4hP0UAlfJr7Su+Mr906pN SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2016 15:25:39.2757 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3005 Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 15:25:43 -0000 ----- Original Message ----- From: "Nick Hilliard" To: "t.petch" Cc: "Job Snijders" ; Sent: Monday, October 03, 2016 12:41 PM > t.petch wrote: > > Well, Bertrand Duvivier seemed to be proposing something along these > > lines last week, and I for one would see a mapping from old protocol to > > new protocol as very much is scope for the new protocol I-D, if only to > > say there is none. > > creating a mapping between 1997 and large does very little in practice, > except to increase complexity. Certainly it doesn't make 1997 community > support any more or less available. I'd be in favour of not having any > mapping between the two Me too and I would go so far as to put in a sentence to that effect. Perhaps I am oversensitive to the issues of ASN conversion that arose at the time of 4-octet ASN - except that what we are doing now is in a sense continuing the work of 4-octet ASN which was not completed at the time, which makes me want to dot a few more 'i's. Long term, I wonder if old style communities will be replaced by these new style ones as and when support and familiarity grows and so a mapping will be wanted at some point in the future to migrate out the old style but I would not want to try and specify that now. Tom Petch > Nick From nobody Mon Oct 3 08:25:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB90129617 for ; Mon, 3 Oct 2016 08:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 WNIfSXPlcp80 for ; Mon, 3 Oct 2016 08:25:41 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40130.outbound.protection.outlook.com [40.107.4.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1475B12A7A9 for ; Mon, 3 Oct 2016 08:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HfthY/8+YZPYk2zuep5b4sua+z4ZwL+WCDmFUCrTWxQ=; b=dfhXV0ejKCcvJ0iP0KJTvuVn4wnO52zfovfvT5c0amvoYYmkIUZi+1rVC+CygYff1s2jsADi62PXOUh4tW6YCzbK04qYCkJadMktQSLG4jQRSw1JmGyGHt7l8cgaS52yAkTtExA13zdx3InZLUa3HcRP/Hp1MO0pPneKDc3NRe4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by VI1PR0701MB3005.eurprd07.prod.outlook.com (10.173.72.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Mon, 3 Oct 2016 15:25:38 +0000 Message-ID: <01a301d21d8a$1a18f020$4001a8c0@gateway.2wire.net> From: t.petch To: Job Snijders References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> Date: Mon, 3 Oct 2016 15:54:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: DB5PR08CA0084.eurprd08.prod.outlook.com (10.166.166.180) To VI1PR0701MB3005.eurprd07.prod.outlook.com (10.173.72.147) X-MS-Office365-Filtering-Correlation-Id: 5072ed70-6494-4fb5-ae94-08d3eba187a8 X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3005; 2:hSMSQyjWqVJD6qhy5aPXs2zK2GstxOKHkceWKMPY4aExLA/POgoRzcQ7FOCAmPYvYOiJtqu/zd7x5IXWqyeKxmcAt16PGaoTWH9DQYbYXrWBB4KH0fr/L4MHr2ROqd2ffWemaAQpN0vmEv6Vx8HIHomM/jQs6T/+F4C5TFfah8GBrY1o7LycVqyfr9+btXFE; 3:8SEG6vOFH820uJ8ighkXmn29IP7HZPbdgv66l0NKnGQzc13IaTHPujH2k4FsxbIUZYUGZGOJfRXGnIfFqpOeVRu9GDE9XDbFROzsAympwCRkL4vPWLvHJ1SUzxWkSmoN; 25:UL7beHF52qYG9EKcipcopwofv5V0ijXkfvcpQ7AouuL3HFRs4shjaD/S4seGs0kCY7E8NDImwO/XVfqs269O9FpfpkrIWhewnR1giShU/dhoj2TuswlqgPJoihIvpshWQeP0o6x0HXSsg9Lq6AN3ofWpWMSJ2KR8fzu3sXcAI5yeWvCR7d/tESp9+msoH9RjvycQK8J4Yj4IzfF7QDZHng55vx2CsfZeetusy7VOKYnmzRAqH9rCOTzPBi5T8rKJ+pciV/DtD76nH2NSkXD1XHX9XNMD+N1J5UfWBOOpqL3ZJK/kSLVrkOiPiOGeG5Eq8z7SvAMv6QWEuIrI4ANpDytpnDHr8A1AadUCRmMuTRnGSRJYwpB4oXSXhGhFOh09AmUYuO18DLZZCyzDQTJdjJo7Synqbwf9oMB+wkeg5jA= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0701MB3005; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3005; 31:cv6vXvzGJbW/QfQx6O6mwayQa/7K1TLN1Tx9sgmorJW/XMQ05T/UyjOuRhfs7M1UeRNNMaGHWM5AEtZBCUaag1epeBN+aL4naYXmXbXq40l+nf6DfzqAvxq0b5nPQlpEwuSD5ioM1Hd+qBhRpkRvY3yGUS4tGsqHg+QaKft27h0d7QdsHZHQJKnEe9Edg51nynF095b6cAkY2aBYHJ/tlt6PvIyF+Gu2toLvD9nxs9HAleeWzy8zYtQpNH9ksDE1; 4:BfhNppaWqE6zlWUDPYr46mVtdSZ1MGQaGLO6Obg/RVyK3Shm2zZ1zJKJiqWjThFqRGPAOrvpepJcyPAT6V6fYOzwEf2+nGz703AWo6UgGC2V75LPxddgAlubCN7JRUinVS9B6qEpyVbFjl/pY1PtC4IvMjs4iGzGF1x9Ym658sX4w2fdxx3tH79YEysoHqXSShkpBnVCdJllHWy6McGU/v9RPf95LekI7C3GLy0MC6ZKOnyoLcC/JIGdeYIYUU4eW4qW3XDej+BoemPEc0rUIFEIaMT5R2Vwlnjnz7PCxgUbaiU+CRR3TuzA3zwWjvDDFvjCyFRArVoopmFVDyvZUNL5fq5EwHR0LYCFDg156+5KiEzhghecQ81e/6uhJM7pf6TQaNATc/kBrMqA5K604JAzwP9esQwXSeRyrIZK+A7D0B1gOpmnXEjIZAO9sOSW X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR0701MB3005; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3005; X-Forefront-PRVS: 008421A8FF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(71364002)(199003)(377454003)(189002)(51444003)(13464003)(24454002)(101416001)(105586002)(61296003)(42186005)(81816999)(81686999)(76176999)(81166006)(189998001)(23756003)(97736004)(9686002)(44736004)(1456003)(116806002)(15975445007)(68736007)(3846002)(14496001)(8676002)(81156014)(77096005)(50986999)(19580395003)(19580405001)(106356001)(230783001)(6116002)(93886004)(62236002)(586003)(230700001)(50226002)(7846002)(50466002)(33646002)(5660300001)(4326007)(86362001)(84392002)(7736002)(1556002)(92566002)(2906002)(66066001)(305945005)(47776003)(4720700002)(6666003)(110136003)(44716002)(6916009)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3005; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB3005; 23:7oyDtdtohG/TZ9jYHhl0ImjFtuI0s+poy2/at?= =?iso-8859-1?Q?6dWYMgWUGBEiXNTZixhd+XFHr4nHVra1eJnHK98LoUdeag8Ztev8nBQzXy?= =?iso-8859-1?Q?m5sudT2J1P1HMufC5aFIopFmrsvGNPbmcH0ZZaKS8057pQhFBePzcl4IAM?= =?iso-8859-1?Q?B9asiky6HpNym1h2/DHewm7l7pGt9xnaMiqPbuvKVopEYlHmc/DIBeXxBm?= =?iso-8859-1?Q?BWwCczvQqLwTLXHu6acjRkz3sNUwgtxewU2XyvUT3HZvb3fXR0hMd1PPJA?= =?iso-8859-1?Q?avjpQuaCa5+jmPcgxAFOY9r6bigwBlpzAG1U3zQkEiOwUvVvNlgDilrgzR?= =?iso-8859-1?Q?bHyKjmtk5YLGg+PoASuhWH8UpWoI45QUoxs5jVeUCRcH93OErno9UQCBqM?= =?iso-8859-1?Q?kDOMRT/6xs9CxEd1yaOcTV+wDHH8J/jI3PNC7oeu8PnIHCIxi5p3dUPnnK?= =?iso-8859-1?Q?owrWTfiVia9g8FItGLF8D8RpHBe8GTNVREhJ0+zYVESHTcQE9Gi8kGTGIm?= =?iso-8859-1?Q?uxpclSsso7Rg4aya6RFd510K5ot7T52S5RqZALIVRHzTd89VY6DfTHAedE?= =?iso-8859-1?Q?W58RHrhxWmWFqhpstDUTeSGi+zVwAYdCGx0pxa3AhrwUgCG9NWKdvY19U6?= =?iso-8859-1?Q?XcaZJa+OltyzjMHi53o8p4wq7mi2Z6SJMwtvPu2UoqtGFpnyF9CPaXf5y3?= =?iso-8859-1?Q?DbBc+9N/QDPZepLDVKq0Yw7gw6hFT6g+ijXkbRwZT+juTkdpdOae3Oejzu?= =?iso-8859-1?Q?sF+2THFwKGQpznV2ur3/4th6VYviiOKcxSFzEOBcaiKP375vUOQyi5RJFQ?= =?iso-8859-1?Q?FHCHpgHQKqMzDitjuEvI7I8hWIxoajz7HgQuvIn6PbxGZUzH1Z0mOxdthR?= =?iso-8859-1?Q?m2Hv/Dnjnv/b6ccIGMk+J908AwoEjc2lTrr37TB+KE6krbAAoH2ZGnuJGb?= =?iso-8859-1?Q?8liTdXASBc4z19bOBkH1CfpopUqYp1wDK6hAZ0L72qFhaxV+CLHEVQ3Ql5?= =?iso-8859-1?Q?Z2wRBADLCAdNgaRHQpMO9mSBVE51W1iN58Gt8A8FLC/gmO36q48Wyh75VS?= =?iso-8859-1?Q?bdyJjrKkOWwZ30OgEvOSQFyFkqrxurqQoaret23b3ZCnltHwxiLui4GMPe?= =?iso-8859-1?Q?ca939Hv6maQOAD6qMV+uDr2TKxPWfR/WKCItAA9WXR6JzS7Q53v7QMRbdV?= =?iso-8859-1?Q?uwg/7o/KX6xqA2TCUSJ3zAUw2AwFxzh60+ic7EvYcDjRwZTJrZSr8Qqfce?= =?iso-8859-1?Q?aPOuKllLnqKHFp5O6IUc3baO1ze7ncn7J6Sq51idVNZYKa9OicGMhMU8L0?= =?iso-8859-1?Q?t+G0EFOwK4vLWbqZ6ID6wShQ3K1yyqOTPJeOLTK1RuIwm/WE3o9llXb3NH?= =?iso-8859-1?Q?nytH8Xs2/gN6Ai74WjgYvjQw65CPoWgBLj+9g+ndudKKOIqvHvjo7IQoZF?= =?iso-8859-1?Q?RA3TwuI4cmoz/MvMdvplM51nFCUrobh12ZeJQScz/OQFWFxHzimMr6KZQl?= =?iso-8859-1?Q?BJ0JcUrySkii+eWMDooc3GkXfpXQb0W2kHpgandh/hbA24YICgdg2HuwHx?= =?iso-8859-1?Q?tn4q5QCqSyrUn1YooIu/XGYzuIxNpnhtZZ79NhYFQ9aEFfwO86eUXAJifS?= =?iso-8859-1?Q?meIrzGsNParIA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3005; 6:OLP0aNxBXHf8kkAMigRjHq6Bl6xf/CQmPCmt8zSMz8tod3+L+6yyPGXEsIVN2L2bMkqPpJueuHV6rH6f4C13Dv+zWNzWb0DYGKnb8f8oRj6aRHnmDHCTrD8MDmmpaLKnvnUskmP+PLjA1cCqWus9DPXpPTNWiOTVV1pCje8MHPz0k5vbdFhxvoAsH95ShXaY5Tf1Az4ShvlpYZCNnwKEHoXuB9lNGPzBtUEOIoJA161Yoq70lni6WtwrxaBIRZmghKkolcvWB5SCBBbFVsWTtD7/V6p6WRaE3//TgAFp6PI=; 5:zFyvwKnzF+l2bSk2BpVQ+Tgm218QsUBBp3ZnZRbite5/9rp0FjYx4PdSilk3Yh8IBry0fq9/QiN/BzvpPNLR5IQNL2YgN7T2UAMJtmpI9QrRe5lEdvH+33l+gChCRcZR3kva15k+GT9geWuzscXLHQ==; 24:q5zSth3l8k7tNkZtjXqTJcnFU/zmsl2ScKodZYrSQhwv/InLKYQY+r2e6/T1xMhiAp5RSZhEfbKclmq/0ci31M5PNjPUVrtDk74CHRt2cVE=; 7:TeRtV/xfzRI1ClW4QG1+0WJFXx86FaI1nZ0VQT7BhU8gCrZUv99G6GSeiMse4VdZSwrbHKItReQuYhtqbOiab8+b52FPpV1nzQ8JHIRi/aiWkM8gd75yK2Nx4/Voya+TTk6izxYW2wFuuEW75UkNJAdhYJorTO7xMG5bqNaxU480EMqB6TT3QobGkn9NS36vEk0tq67QdxyLtYTjRfG2ScdTqPyzI2B3DZupvWxgzatkW/hH+4h2AiwioQKaPcuq+mlllRQW5MbiWBVT+Tf9U5Gw6ci9OmH6EC31YaRG6FahebBjelx6vTnJhi0HnicX SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2016 15:25:38.3889 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3005 Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 15:25:45 -0000 Tom Petch ----- Original Message ----- From: "Job Snijders" To: "t.petch" Cc: Sent: Monday, October 03, 2016 12:57 PM > Dear Tom, > > On Mon, Oct 03, 2016 at 12:06:53PM +0100, t.petch wrote: > > > > > On more challenging matters, I think s.2 should specify the encoding > > > > of a 16-bit ASN - left or right justified? > > > > > > I am not sure that is required. Technically speaking, all ASNs are now > > > 32-bit ASNs. > > > > Well, not in traditional communities so if anyone 'knows' that the > > first 16 bit are an ASN, they will be disappointed, so I think it > > worth spelling out. > > I am not convinced, it does feel somewhat superfluous to me. Section 2 > clearly depicts an ascii art with 32 bits for the Global Administrator. > > We could add something which is akin to what rfc4893 states: > > "For Autonomous System numbers which can be encoded as a 2-octet > value, the two high-order octets of the Global Administrator field > are set to zero." > > Do you have a better suggested sentence? The above feels like a kludge. > I think that that text is fine. Tom Petch > > > > > > More generally, a big issue with 4 octet ASN was migration, the > > > > world becoming a mix of boxes that supported 4 octet ASN and those > > > > that did not. I think that that issue needs addressing. Will > > > > boxes convert traditional communities to large, or should that be > > > > specifically prohibited (I think that latter)? > > > > > > I consider the topic of 'mapping' out of scope for an IDR document. See > > > my earlier message here: https://mailarchive.ietf.org/arch/msg/idr/GHxOF9Y6wsdQ2e_-4jI2ejUZ2kk > > > > > > Mapping is up to the operator's local routing policy and by extend, the > > > vendors. > > > > Well, Bertrand Duvivier seemed to be proposing something along these > > lines last week, and I for one would see a mapping from old protocol > > to new protocol as very much is scope for the new protocol I-D, if > > only to say there is none. > > I am really not sure we should specify everything the document is _not_. > (Similar to your agreement to remove the sentence about 'no routing > semantics are implied') I also do not see precedent for 'there is no > mapping between 1997 and extended communities' in the rfc4360 document. > > I agree that mapping in and of itself is an interesting challenge, but > the concept is probably is better served as an internet-draft targetted > to be of Informational status in the GROW working group. > > Kind regards, > > Job From nobody Mon Oct 3 08:46:16 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C4B12949B for ; Mon, 3 Oct 2016 08:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 p-WHAWYlAfpn for ; Mon, 3 Oct 2016 08:46:13 -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 1D96B12949C for ; Mon, 3 Oct 2016 08:46:11 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u93Fk8A6031589 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Oct 2016 16:46:08 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <57F27D3F.7090404@foobar.org> Date: Mon, 03 Oct 2016 16:46:07 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.3 (Macintosh/20160930) MIME-Version: 1.0 To: Job Snijders References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> In-Reply-To: <20161003115723.GD20697@Vurt.local> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 15:46:15 -0000 Job Snijders wrote: > "For Autonomous System numbers which can be encoded as a 2-octet > value, the two high-order octets of the Global Administrator field > are set to zero." > > Do you have a better suggested sentence? The above feels like a kludge. I don't understand why this is necessary. This is a global administrator field, i.e. it's not guaranteed that it's an ASN, so there can be no protocol level assumption that any number configured to fit in there should be treated any differently to any other number, even if that number incidentally happens to be the same as the ASN configured on the device. Secondly, the field is 32 bits wide, so if you have a number between 0 and 65535, there is exactly one way of fitting that number into a a 32 bit placeholder in network byte order. This is why big endian encoding works so well on the wire, and little-endian is terribly broken. The text would be better if this were left out completely. Nick From nobody Mon Oct 3 09:12:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DED91293E0 for ; Mon, 3 Oct 2016 09:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.516 X-Spam-Level: X-Spam-Status: No, score=-17.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 B81OhKKVmNYV for ; Mon, 3 Oct 2016 09:12:07 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C77D1293DA for ; Mon, 3 Oct 2016 09:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5521; q=dns/txt; s=iport; t=1475511127; x=1476720727; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ciOeULxfZWvEE1BQNt26WIEf3cU5l6Fnn5EbSXrbSxk=; b=J2fRpyW9TJbqLf05DoJD4CL5eXunl6TboF805Ylp47Gbt3PC6oe1Oa8E doA9t8oxNTkPvnY5xvQCgYVjqAcotpSvMVkoMYywdrHvzlr0FlFpfwzI7 VQ48wuZHVNcZaEjo2Wn4gn2MTeQJ0R+4TToE7Hvue3PYqWB2FVb+n7nTF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgCLgvJX/4sNJK1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgwc2AQEBAQEeV3yNMqYQhRKCBhkBCoV6AoFlOBQBAgEBAQEBAQFeHAuEYgE?= =?us-ascii?q?BBAEBAWsbAgEIPwcnCxQRAgQTFIg5DrphAQEBAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?wWGOIF9CIJQh3OCLwWIOotmhVgBiSqGRo9yjG6DfQEeNoMbgXFyh1UBAQE?= X-IronPort-AV: E=Sophos;i="5.31,438,1473120000"; d="scan'208,217";a="331171238" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Oct 2016 16:12:06 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u93GC60m029810 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 3 Oct 2016 16:12:06 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Oct 2016 11:12:05 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 3 Oct 2016 11:12:05 -0500 From: "Jakob Heitz (jheitz)" To: "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt Thread-Index: AQHSG79TGAvzbRTYaUOLNdatGR0q+6CTny8AgALbUg+AAFuDAP//w9BUgABdGYCAAD/ogP//s3Bt Date: Mon, 3 Oct 2016 16:12:05 +0000 Message-ID: <74D0D4D0-0885-4E11-BDAB-85F9356B4AA1@cisco.com> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local>,<57F27D3F.7090404@foobar.org> In-Reply-To: <57F27D3F.7090404@foobar.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_74D0D4D008854E11BDAB85F9356B4AA1ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 16:12:08 -0000 --_000_74D0D4D008854E11BDAB85F9356B4AA1ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One thing of substance that changed is the definition of 3 reserved ranges. 0:0:0 - 0:4294967295:4294967295 65535:0:0 - 65535:4294967295:4294967295 4294967295:0:0 - 4294967295:4294967295:4294967295 3 is messy. 1 is enough. Which one do we want? Thanks, Jakob. On Oct 3, 2016, at 8:46 AM, Nick Hilliard > wrote: Job Snijders wrote: "For Autonomous System numbers which can be encoded as a 2-octet value, the two high-order octets of the Global Administrator field are set to zero." Do you have a better suggested sentence? The above feels like a kludge. I don't understand why this is necessary. This is a global administrator field, i.e. it's not guaranteed that it's an ASN, so there can be no protocol level assumption that any number configured to fit in there should be treated any differently to any other number, even if that number incidentally happens to be the same as the ASN configured on the device. Secondly, the field is 32 bits wide, so if you have a number between 0 and 65535, there is exactly one way of fitting that number into a a 32 bit placeholder in network byte order. This is why big endian encoding works so well on the wire, and little-endian is terribly broken. The text would be better if this were left out completely. Nick _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_74D0D4D008854E11BDAB85F9356B4AA1ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
One thing of substance that changed is the definition of 3 reserved ra= nges.

       =
     0:0:0 -          0:4294967295:4294967295 
65535:0=
:0 -      65535:4294967295:4294967295 
4294967=
295:0:0 - 4294967295:4294967295:4294967295

 3 is messy. 1 is enough. Which one do = we want?

Thanks,
Jakob.


On Oct 3, 2016, at 8:46 AM, Nick Hilliard <nick@foobar.org> wrote:

Job Snijders wrote:
   "For Autonomous Syst= em numbers which can be encoded as a 2-octet
   value, the two high-order= octets of the Global Administrator field
   are set to zero."

Do you have a better suggested sentence? Th= e above feels like a kludge.

I don't understand why this is necessary.

This is a global administrator field, i.e. it's not guaranteed that i= t's
an ASN, so there can be no protocol level assumption that any number<= /span>
configured to fit in there should be treated any differently to any
other number, even if that number incidentally happens to be the same= as
the ASN configured on the device.

Secondly, the field is 32 bits wide, so if you have a number between = 0
and 65535, there is exactly one way of fitting that number into a a 3= 2
bit placeholder in network byte order.  This is why big endian e= ncoding
works so well on the wire, and little-endian is terribly broken.

The text would be better if this were left out completely.

Nick

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
--_000_74D0D4D008854E11BDAB85F9356B4AA1ciscocom_-- From nobody Mon Oct 3 09:16:22 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CE51293FB for ; Mon, 3 Oct 2016 09:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 HFnHJ4umoOER for ; Mon, 3 Oct 2016 09:16:14 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01EC1293DA for ; Mon, 3 Oct 2016 09:16:13 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id f193so116527676wmg.0 for ; Mon, 03 Oct 2016 09:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=E3G62w4hoZBvP9AmQg5mx/Vl4PlYiCvYnAvLTXsoSLM=; b=PYreqrDpqg7NZgrXlMVxYoCAmaHPEpJqCq92zXkQfIr2nZQ4wjfvv5IjUO0UrO7Qas t8mj4o9y1CBCTUqDI2Z5bsiqdxigDKUemJPZzdPrCS1N7jwb7KbBypoiecJIM/ZQ1mTg MWZEKvLYeAVMf9xm/cySBA1V0JO/xpASZ8OMptJRBWYBDe8tKN69qMir9m7yYIBbo8Bh Fja3B6MomEVF9FVN12Og4WpgRC2c4C7D6vgnpCDLMrutwLx/+gxJDFRL54XC3n0tdDxX hlxZ3w5xaTL0uX1QBTQvsA0ozS9RFZxm7Unw4exTpdooVATMwqKXH0gNAi6mNSOhozMU 5SpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=E3G62w4hoZBvP9AmQg5mx/Vl4PlYiCvYnAvLTXsoSLM=; b=Ao/GvJmP0nTg7JOR4pFCvmFiCH3Cu76e4xpviyDtfzZ6knhOKcZd2jgKB/cuyzJUv5 JrqCpZYqRVWDPlDnVRhMdw9F9rQIMxuAz7p3QxDSxvPVzeOyPqxBT24Lc6jvXVCFyr8L F7HeoeLxW+m1GT9RxwIHHvt7ejSEiYY/znCL+Sh6GIp620tQioaFZaPDSg+0Q+DEoUuB Lx+x7zFF/ehBjjqL+T56bRftBj/0KyB7tp29OJpm7zoRhBTU/RRE8FarqTplvYykppTC ihSe8tMiwl1qjjo4sKMfeKyJxFwvYzRg5dpZbyyrCIRVZtW9DRUzgXELojR7Aoom4NpK 4MXg== X-Gm-Message-State: AA6/9RlbJoYBQL+qm12egrdmfusbFAdHAhY+ZTwEnBesphKzDxuXYv1GrrPOihiX7IOu1A== X-Received: by 10.28.134.136 with SMTP id i130mr11530680wmd.76.1475511372067; Mon, 03 Oct 2016 09:16:12 -0700 (PDT) Received: from localhost ([188.207.92.247]) by smtp.gmail.com with ESMTPSA id w9sm34915014wjf.47.2016.10.03.09.16.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Oct 2016 09:16:10 -0700 (PDT) Date: Mon, 3 Oct 2016 18:16:08 +0200 From: Job Snijders To: "Jakob Heitz (jheitz)" Message-ID: <20161003161608.GG3127@Vurt.local> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <74D0D4D0-0885-4E11-BDAB-85F9356B4AA1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74D0D4D0-0885-4E11-BDAB-85F9356B4AA1@cisco.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 16:16:15 -0000 On Mon, Oct 03, 2016 at 04:12:05PM +0000, Jakob Heitz (jheitz) wrote: > One thing of substance that changed is the definition of 3 reserved > ranges. > > 0:0:0 - 0:4294967295:4294967295 > 65535:0:0 - 65535:4294967295:4294967295 > 4294967295:0:0 - 4294967295:4294967295:4294967295 > > 3 is messy. 1 is enough. Which one do we want? My personal take is to keep all three of them reserved. I don't consider it messy at all. More feedback from the working group is appreciated. Kind regards, Job From nobody Mon Oct 3 09:53:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A45A1293F9 for ; Mon, 3 Oct 2016 09:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 sqaLn45bsRaw for ; Mon, 3 Oct 2016 09:53:18 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099AE129415 for ; Mon, 3 Oct 2016 09:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=789; q=dns/txt; s=iport; t=1475513595; x=1476723195; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=b7CumeRjIf2dK8z3Sn0nfeybliYxPL6J9bxdirE05LQ=; b=GOC/K0e9zW/pD2Kax3aHzJ+iydqIhe/1xiQ40kwheaPlaX5RmcjyDlAm LVJO0Ea1vxSXbubzHygZ0monP19XkKzmdwM2oDpq4hw3ceeqt9kz16bzp B5hcUtGmt5EgwPubeToqPcWHqfCRZvTlYv3Q1tUJ0PdJjepM+RwVB5ODr I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAwAOjPJX/4cNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgz0BAQEBAR6BU6QxlCOCBoYeAoFlORMBAgEBAQEBAQFeJ4RhAQEBAwE?= =?us-ascii?q?6PwULAgEIGB4QMiUCBA4FFIgxCLp2AQEBAQEBAQEBAQEBAQEBAQEBAQEBHIY4g?= =?us-ascii?q?X0IglCERIMvgi8BBJl4AY9wj3KMboN9ASABM4UMcodVAQEB?= X-IronPort-AV: E=Sophos;i="5.31,438,1473120000"; d="scan'208";a="157924692" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Oct 2016 16:53:15 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u93GrFJI008152 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Oct 2016 16:53:15 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Oct 2016 11:53:14 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 3 Oct 2016 11:53:14 -0500 From: "Jakob Heitz (jheitz)" To: Job Snijders Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt Thread-Index: AQHSG79TGAvzbRTYaUOLNdatGR0q+6CTny8AgALbUg+AAFuDAP//w9BUgABdGYCAAD/ogP//s3BtgABU8wD//7aMOw== Date: Mon, 3 Oct 2016 16:53:14 +0000 Message-ID: References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <74D0D4D0-0885-4E11-BDAB-85F9356B4AA1@cisco.com>, <20161003161608.GG3127@Vurt.local> In-Reply-To: <20161003161608.GG3127@Vurt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 16:53:20 -0000 I write code. I watch people write code and test code. It adds to developme= nt time. 3 ranges is not necessary. It's messy. Thanks, Jakob. > On Oct 3, 2016, at 9:16 AM, Job Snijders wrote: >=20 >> On Mon, Oct 03, 2016 at 04:12:05PM +0000, Jakob Heitz (jheitz) wrote: >> One thing of substance that changed is the definition of 3 reserved >> ranges. >>=20 >> 0:0:0 - 0:4294967295:4294967295 >> 65535:0:0 - 65535:4294967295:4294967295 >> 4294967295:0:0 - 4294967295:4294967295:4294967295 >>=20 >> 3 is messy. 1 is enough. Which one do we want? >=20 > My personal take is to keep all three of them reserved. I don't consider > it messy at all. More feedback from the working group is appreciated. >=20 > Kind regards, >=20 > Job From nobody Mon Oct 3 09:57:16 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B106129420 for ; Mon, 3 Oct 2016 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 Omn6HHcEh4Ix for ; Mon, 3 Oct 2016 09:57:11 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 4329A129405 for ; Mon, 3 Oct 2016 09:57:11 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1br6Y9-000Dgk-7K (job@us.ntt.net); Mon, 03 Oct 2016 16:57:09 +0000 Date: Mon, 3 Oct 2016 18:57:06 +0200 From: Job Snijders To: "Jakob Heitz (jheitz)" Message-ID: <20161003165706.GM20697@Vurt.local> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <74D0D4D0-0885-4E11-BDAB-85F9356B4AA1@cisco.com> <20161003161608.GG3127@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 16:57:15 -0000 On Mon, Oct 03, 2016 at 04:53:14PM +0000, Jakob Heitz (jheitz) wrote: > I write code. I watch people write code and test code. It adds to > development time. 3 ranges is not necessary. It's messy. As an implementor, you are not supposed to do anything with these ranges0. They are just reserved in the sense that they belong to IANA, not to a single operator. For the moment, operators should avoid using values from these ranges, but implementations shouldn't prohibit them from doing so. This is no different than RFC1997 which reserves the following two: 0x00000000 - 0x0000FFFF 0xFFFF0000 - 0xFFFFFFFF Can you elaborate on whether IOS XR treats RFC1997 values from those ranges in a special way? (aside from the well known communities ofcourse) Kind regards, Job From nobody Mon Oct 3 10:12:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51448129418 for ; Mon, 3 Oct 2016 10:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.518 X-Spam-Level: X-Spam-Status: No, score=-17.518 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 HFsK1mjZbl06 for ; Mon, 3 Oct 2016 10:12:24 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BBB12941D for ; Mon, 3 Oct 2016 10:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1177; q=dns/txt; s=iport; t=1475514742; x=1476724342; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=V+Fwu2D66Qi64Pvvo8MLH20xXvtIifm1GnEy6mt1hfw=; b=JonPdVLuXMor+lQ29pNcDqq87rAPIZZ4CMYzHYEEXLx4ox6kFmq97iL9 8RQyX6EDr0Hgc62/o0qvqJNimOocF0TjteDXp8egucllpTJwPOvLS+hCG o/LJQM803yzvDWJ4SnaXEMpinKp2mI2T92+t/Ur5SbNAp6EK1ZAqJLUuq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAwC/kPJX/5hdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgz0BAQEBAR6BU6QxlCOCBoYeAoFlORMBAgEBAQEBAQFeJ4RhAQEBAwE?= =?us-ascii?q?6PwULAgEIGB4QMiUCBA4FFIgxCLp4AQEBAQEBAQEBAQEBAQEBAQEBAQEBHIY4g?= =?us-ascii?q?X0IglCERIMvgi8BBJQghVgBj3CBboRmiR6MboN9AR8BNIUMcodVAQEB?= X-IronPort-AV: E=Sophos;i="5.31,438,1473120000"; d="scan'208";a="159350915" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2016 17:12:21 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u93HCLse031406 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Oct 2016 17:12:21 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Oct 2016 12:12:20 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 3 Oct 2016 12:12:20 -0500 From: "Jakob Heitz (jheitz)" To: Job Snijders Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt Thread-Index: AQHSG79TGAvzbRTYaUOLNdatGR0q+6CTny8AgALbUg+AAFuDAP//w9BUgABdGYCAAD/ogP//s3BtgABU8wD//7aMOwAKnNYA//+wcOU= Date: Mon, 3 Oct 2016 17:12:20 +0000 Message-ID: <9C759C3F-0571-45C7-ADB2-618A6A0D78D1@cisco.com> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <74D0D4D0-0885-4E11-BDAB-85F9356B4AA1@cisco.com> <20161003161608.GG3127@Vurt.local> , <20161003165706.GM20697@Vurt.local> In-Reply-To: <20161003165706.GM20697@Vurt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 17:12:25 -0000 An implementation may give you a match condition for reserved range. I have= n't (yet). Private AS has 2 ranges. The match for that is still on my todo = list. If it were one range, then it would be done. One range please. Thanks, Jakob. > On Oct 3, 2016, at 9:57 AM, Job Snijders wrote: >=20 >> On Mon, Oct 03, 2016 at 04:53:14PM +0000, Jakob Heitz (jheitz) wrote: >> I write code. I watch people write code and test code. It adds to >> development time. 3 ranges is not necessary. It's messy. >=20 > As an implementor, you are not supposed to do anything with these > ranges0. They are just reserved in the sense that they belong to IANA, > not to a single operator. For the moment, operators should avoid using > values from these ranges, but implementations shouldn't prohibit them > from doing so. >=20 > This is no different than RFC1997 which reserves the following two: >=20 > 0x00000000 - 0x0000FFFF > 0xFFFF0000 - 0xFFFFFFFF >=20 > Can you elaborate on whether IOS XR treats RFC1997 values from those > ranges in a special way? (aside from the well known communities > ofcourse) >=20 > Kind regards, >=20 > Job From nobody Mon Oct 3 11:42:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5287912949B for ; Mon, 3 Oct 2016 11:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1dMhmLVqsB2F for ; Mon, 3 Oct 2016 11:42:16 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87A1129477 for ; Mon, 3 Oct 2016 11:42:16 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 395027B392; Mon, 3 Oct 2016 18:42:16 +0000 (UTC) Date: Mon, 3 Oct 2016 18:42:16 +0000 From: heasley To: "Jakob Heitz (jheitz)" Message-ID: <20161003184216.GU74863@shrubbery.net> References: <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <74D0D4D0-0885-4E11-BDAB-85F9356B4AA1@cisco.com> <20161003161608.GG3127@Vurt.local> <20161003165706.GM20697@Vurt.local> <9C759C3F-0571-45C7-ADB2-618A6A0D78D1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C759C3F-0571-45C7-ADB2-618A6A0D78D1@cisco.com> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 18:42:18 -0000 Mon, Oct 03, 2016 at 05:12:20PM +0000, Jakob Heitz (jheitz): > An implementation may give you a match condition for reserved range. I haven't (yet). Private AS has 2 ranges. The match for that is still on my todo list. If it were one range, then it would be done. > > One range please. they aren't arbitrary ranges - they are the reserved ASNs. Why is it difficult to match if (field1 == (0|0xffff|0xffffffff))? > Thanks, > Jakob. > > > On Oct 3, 2016, at 9:57 AM, Job Snijders wrote: > > > >> On Mon, Oct 03, 2016 at 04:53:14PM +0000, Jakob Heitz (jheitz) wrote: > >> I write code. I watch people write code and test code. It adds to > >> development time. 3 ranges is not necessary. It's messy. > > > > As an implementor, you are not supposed to do anything with these > > ranges0. They are just reserved in the sense that they belong to IANA, > > not to a single operator. For the moment, operators should avoid using > > values from these ranges, but implementations shouldn't prohibit them > > from doing so. > > > > This is no different than RFC1997 which reserves the following two: > > > > 0x00000000 - 0x0000FFFF > > 0xFFFF0000 - 0xFFFFFFFF > > > > Can you elaborate on whether IOS XR treats RFC1997 values from those > > ranges in a special way? (aside from the well known communities > > ofcourse) > > > > Kind regards, > > > > Job > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Oct 3 14:25:30 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C079A12956B for ; Mon, 3 Oct 2016 14:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2a5Om3BvZ6yA for ; Mon, 3 Oct 2016 14:25:27 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0DA12955B for ; Mon, 3 Oct 2016 14:25:26 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id f193so131800925wmg.0 for ; Mon, 03 Oct 2016 14:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jihMwjvLERpwyW3EhdFhkRhrQB6OvCu5puyLO6FqV14=; b=D98v/TmvGGLkNGapk6KAglFUr8TkspwgFGHsvpfNNrblmRkro3IthbMy2shrX49S8V Sw6zkAM5mOUCxRMeTYsIl4thECky7x7F9mk0AICpYIIk70jhUz8u0kU35lGAJrTfFH/e hiAntINgFJVliOdi/FCZ8JLmLGvG4M3gjpAXSNW5WoFPbd+0eVV5+dA1locp/JEuj4rS 4Y+xPLBwSoDMUD8Zm/inAmSRX3nsFdOXeMAMy2QGJLjI0sXE0sQBl9pw4Oedobm+VFBk DqgdPQJHXZ51/nT+YdDQMovXJpNWVVckdgGv4Dg/UJ+kEdC0dOJBtH/zrmM2+9OFXVGE mKOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jihMwjvLERpwyW3EhdFhkRhrQB6OvCu5puyLO6FqV14=; b=fIf7Y3QQ5wjtkAqJ3RZTbrwcnYGmf7PDWpr9+DH1szxNcmrHZHfzy8CJnVB05WPDKc 0AVy5YSDnJsWGB0GgoUw7eq9WF4VFrLSYzz+IZEjvwBWUGwHS+YzIORbsOr7hM/rwCCp zaIabGQo1sqNiqIQpuGMRP2tjU+ehxcKaSz/lzLV5WxKnJtGeeMKQWM7tfcSzKNwJwtb hBefOShk44TjfrkAsVBtP3ofvNP0zbGiFWBN+658TGk6YJvPapjLVmX21aoQH/A6I0lN 1mnvPxwKzdYKK/ZtLutX4xvm7W3abl/BEEvtB3CLmQH/Hp7fviMnG7cNjNJvEbXY4AJA v6mA== X-Gm-Message-State: AA6/9RmZO4zrYrmZL4WPkek4WyhqXf2yKKbE8hAwaAxchN5lkIqwlz03avmKjYz5k2QwcGlqSHj0CyZ9KfpXZQ== X-Received: by 10.194.74.5 with SMTP id p5mr112432wjv.92.1475529924950; Mon, 03 Oct 2016 14:25:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.207 with HTTP; Mon, 3 Oct 2016 14:25:24 -0700 (PDT) In-Reply-To: <20161003184216.GU74863@shrubbery.net> References: <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <74D0D4D0-0885-4E11-BDAB-85F9356B4AA1@cisco.com> <20161003161608.GG3127@Vurt.local> <20161003165706.GM20697@Vurt.local> <9C759C3F-0571-45C7-ADB2-618A6A0D78D1@cisco.com> <20161003184216.GU74863@shrubbery.net> From: Brian Dickson Date: Mon, 3 Oct 2016 14:25:24 -0700 Message-ID: To: heasley Content-Type: multipart/alternative; boundary=047d7bd9111a083edb053dfc952f Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 21:25:29 -0000 --047d7bd9111a083edb053dfc952f Content-Type: text/plain; charset=UTF-8 On Mon, Oct 3, 2016 at 11:42 AM, heasley wrote: > Mon, Oct 03, 2016 at 05:12:20PM +0000, Jakob Heitz (jheitz): > > An implementation may give you a match condition for reserved range. I > haven't (yet). Private AS has 2 ranges. The match for that is still on my > todo list. If it were one range, then it would be done. > > > > One range please. > > they aren't arbitrary ranges - they are the reserved ASNs. Why is it > difficult to match if (field1 == (0|0xffff|0xffffffff))? > > > Thanks, > > Jakob. > > > > > On Oct 3, 2016, at 9:57 AM, Job Snijders wrote: > > > > > >> On Mon, Oct 03, 2016 at 04:53:14PM +0000, Jakob Heitz (jheitz) wrote: > > >> I write code. I watch people write code and test code. It adds to > > >> development time. 3 ranges is not necessary. It's messy. > > The problem with *not* reserving all 3 is this: there may be, in future, a new set of "Well-Known Large Communities". The (best or feasible) choice(s) of WHICH of the 3 reserved values should get used as the range containing WKLCs (and here I presume one of the three MUST be the place for WKLCs), could depend on some number of factors not known to us at this time. If we attempt to make that decision now, based on zero information about possible unseen consequences, our future selves (or our successors) might be very unhappy. Reserving all 3 (but not requiring any action on those reservations, per se) costs nothing, and leaves all 3 open for future use as WKLCs. Reserving all 3 does, however, warn off operators from using any of those, so they don't get some later surprise when an implementation starts interpreting WKLCs that happen to conflict with what the operator has been using. It is anticipatory principal of least astonishment. > > > As an implementor, you are not supposed to do anything with these > > > ranges0. They are just reserved in the sense that they belong to IANA, > > > not to a single operator. For the moment, operators should avoid using > > > values from these ranges, but implementations shouldn't prohibit them > > > from doing so. > > > > > > This is no different than RFC1997 which reserves the following two: > > > > > > 0x00000000 - 0x0000FFFF > > > 0xFFFF0000 - 0xFFFFFFFF > > > > > > Can you elaborate on whether IOS XR treats RFC1997 values from those > > > ranges in a special way? (aside from the well known communities > > > of course) > I think this illustrates the problem quite well. It may not be the case that all implementations prevent some operator from using an RFC1997 community in a non-conformist way. But if the operator does use such a community, and unexpected (to that operator) things happen, well, "caveat emptor". It would be nice if implementations provided warnings, or even prevented people from shooting themselves in . It isn't strictly necessary, and as long as the RFCs provide enough warnings against doing so, that's probably enough. ICANN/IANA only provide the regulatory frameworks for the public Internet; there are other "internets" that exist, where re-use of assigned IP addresses (outside of RFC1918) is a non-issue. (And only so long as the networks involved do not attempt to interconnect with "the Internet".) But, where the intent is that the first 32-bit value is "the public ASN" of the operator (and this should be the case for any Internet-announced NLRIs with this new attribute), we should warn off any "off-label" use. E.g. advise on the "private use ASNs" available, and on the "reserved values". That's my $0.02. Brian --047d7bd9111a083edb053dfc952f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Oct 3, 2016 at 11:42 AM, heasley <heas@shrubbery.net> wrote:
Mon, Oct 03, 2016 at 05:12:20PM= +0000, Jakob Heitz (jheitz):
> An implementation may give you a match condition for = reserved range. I haven't (yet). Private AS has 2 ranges. The match for= that is still on my todo list. If it were one range, then it would be done= .
>
> One range please.

they aren't arbitrary ranges - they are the reserved ASNs.=C2=A0= Why is it
difficult to match if (field1 =3D=3D (0|0xffff|0xffffffff))?

> Thanks,
> Jakob.
>
> > On Oct 3, 2016, at 9:57 AM, Job Snijders <job@ntt.net> wrote:
> >
> >> On Mon, Oct 03, 2016 at 04:53:14PM +0000, Jakob Heitz (jheitz= ) wrote:
> >> I write code. I watch people write code and test code. It add= s to
> >> development time. 3 ranges is not necessary. It's messy.<= br>

The problem with *not* res= erving all 3 is this: there may be, in future, a new set of "Well-Know= n Large Communities".

The (best or feasible) = choice(s) of WHICH of the 3 reserved values should get used as the range co= ntaining WKLCs (and here I presume one of the three MUST be the place for W= KLCs), could depend on some number of factors not known to us at this time.=

If we attempt to make that decision now, based on= zero information about possible unseen consequences, our future selves (or= our successors) might be very unhappy.

Reserving = all 3 (but not requiring any action on those reservations, per se) costs no= thing, and leaves all 3 open for future use as WKLCs.

<= div>Reserving all 3 does, however, warn off operators from using any of tho= se, so they don't get some later surprise when an implementation starts= interpreting WKLCs that happen to conflict with what the operator has been= using.

It is anticipatory principal of least asto= nishment.

=C2=A0
> > As an implementor, you are not supposed to do anything with these=
> > ranges0. They are just reserved in the sense that they belong to = IANA,
> > not to a single operator. For the moment, operators should avoid = using
> > values from these ranges, but implementations shouldn't prohi= bit them
> > from doing so.
> >
> > This is no different than RFC1997 which reserves the following tw= o:
> >
> >=C2=A0 =C2=A0 0x00000000 - 0x0000FFFF
> >=C2=A0 =C2=A0 0xFFFF0000 - 0xFFFFFFFF
> >
> > Can you elaborate on whether IOS XR treats RFC1997 values from th= ose
> > ranges in a special way? (aside from the well known communities > > of course)

I thin= k this illustrates the problem quite well.=C2=A0
It may not be th= e case that all implementations prevent some operator from using an RFC1997= community in a non-conformist way.
But if the operator does use = such a community, and unexpected (to that operator) things happen, well, &q= uot;caveat emptor".

It would be nice if imple= mentations provided warnings, or even prevented people from shooting themse= lves in <body part>.
It isn't strictly necessary, and a= s long as the RFCs provide enough warnings against doing so, that's pro= bably enough.

ICANN/IANA only provide the regulato= ry frameworks for the public Internet; there are other "internets"= ; that exist, where re-use of assigned IP addresses (outside of RFC1918) is= a non-issue.
(And only so long as the networks involved do not a= ttempt to interconnect with "the Internet".)

=
But, where the intent is that the first 32-bit value is "the publ= ic ASN" of the operator (and this should be the case for any Internet-= announced NLRIs with this new attribute), we should warn off any "off-= label" use.
E.g. advise on the "private use ASNs" = available, and on the "reserved values".

That's my $0.02.

Brian
--047d7bd9111a083edb053dfc952f-- From nobody Mon Oct 3 14:29:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7CF129584 for ; Mon, 3 Oct 2016 14:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 TsJFQfdDbpJF for ; Mon, 3 Oct 2016 14:29:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6A073129566 for ; Mon, 3 Oct 2016 14:29:35 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id CD4981E334; Mon, 3 Oct 2016 17:31:18 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: Jeffrey Haas In-Reply-To: Date: Mon, 3 Oct 2016 17:29:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0C1E2FBC-C452-4177-AADD-509AC1E21909@pfrc.org> References: <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <74D0D4D0-0885-4E11-BDAB-85F9356B4AA1@cisco.com> <20161003161608.GG3127@Vurt.local> <20161003165706.GM20697@Vurt.local> <9C759C3F-0571-45C7-ADB2-618A6A0D78D1@cisco.com> <20161003184216.GU74863@shrubbery.net> To: Brian Dickson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: heasley , "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 21:29:36 -0000 > On Oct 3, 2016, at 5:25 PM, Brian Dickson = wrote: >=20 >=20 > Reserving all 3 does, however, warn off operators from using any of = those, so they don't get some later surprise when an implementation = starts interpreting WKLCs that happen to conflict with what the operator = has been using. >=20 > It is anticipatory principal of least astonishment. I wish. (Says the vendor guy dealing with people using 0:* and 65535:* = and having "weirdness".) -- Jeff From nobody Mon Oct 3 14:30:42 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663E812957D for ; Mon, 3 Oct 2016 14:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 txhlPDi2xnkS for ; Mon, 3 Oct 2016 14:30:38 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2507F129566 for ; Mon, 3 Oct 2016 14:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18986; q=dns/txt; s=iport; t=1475530238; x=1476739838; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N1hEgAi9kyRe5duSrZZIEn8VzmPPqLgMFKDL+3rJL8s=; b=ggVjqckB9VLM+zPYLCOkVhfsteIEl/JOCSOUxBIY90AujzDFZ+MuDIVT WBabTk2B8oo1filYnph4NVhPH8s2mIu5tiB41JxMXf9Gt9LjOIyW0UdrD RgB/o28H25l2owSw7hYPrhdSKNbcI8JCdw/qndwlewl5Tq9V8VnW9sBkh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AQBAzfJX/5xdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgwc2AQEBAQEeV3wHjSuXAIdYhzmFEoIGhh4CHIFPOBQBAgEBAQEBAQF?= =?us-ascii?q?eJ4RhAQEBAwEjCkwFCwIBCBEEAQEBJwMCAgIfERQJCAIEAQ0FCAyIHwMPCK8si?= =?us-ascii?q?RANg1kBAQEBAQEBAQEBAQEBAQEBAQEBAQEchjiEVYJHgjOCToJaBYkZiweFIzU?= =?us-ascii?q?BjHCCeYF1hGaHcYEtiF2EEYN9AR42hQxyAYYUAX8BAQE?= X-IronPort-AV: E=Sophos;i="5.31,291,1473120000"; d="scan'208,217";a="331329579" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2016 21:30:37 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u93LUaCU012616 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Oct 2016 21:30:36 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Oct 2016 16:30:35 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 3 Oct 2016 16:30:36 -0500 From: "Jakob Heitz (jheitz)" To: Brian Dickson , heasley Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt Thread-Index: AQHSG79TGAvzbRTYaUOLNdatGR0q+6CTny8AgALbUg+AAFuDAP//w9BUgABdGYCAAD/ogP//s3BtgABU8wD//7aMOwAKnNYA//+wcOWAAGzyAIAALZQAgABSerA= Date: Mon, 3 Oct 2016 21:30:36 +0000 Message-ID: References: <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <74D0D4D0-0885-4E11-BDAB-85F9356B4AA1@cisco.com> <20161003161608.GG3127@Vurt.local> <20161003165706.GM20697@Vurt.local> <9C759C3F-0571-45C7-ADB2-618A6A0D78D1@cisco.com> <20161003184216.GU74863@shrubbery.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.58] Content-Type: multipart/alternative; boundary="_000_b5de6ce139174bc8a4efbd64c9e0be03XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 21:30:40 -0000 --_000_b5de6ce139174bc8a4efbd64c9e0be03XCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmluZS4gSXQncyBub3QgdGhhdCBpbXBvcnRhbnQgYW55d2F5Lg0KDQpUaGFua3MsDQpKYWtvYi4N Cg0KRnJvbTogQnJpYW4gRGlja3NvbiBbbWFpbHRvOmJyaWFuLnBldGVyLmRpY2tzb25AZ21haWwu Y29tXQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDAzLCAyMDE2IDI6MjUgUE0NClRvOiBoZWFzbGV5 IDxoZWFzQHNocnViYmVyeS5uZXQ+DQpDYzogSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBj aXNjby5jb20+OyBpZHJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWRyXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLWlkci1sYXJnZS1jb21tdW5pdHktMDEudHh0DQoNCg0KT24gTW9uLCBPY3QgMywg MjAxNiBhdCAxMTo0MiBBTSwgaGVhc2xleSA8aGVhc0BzaHJ1YmJlcnkubmV0PG1haWx0bzpoZWFz QHNocnViYmVyeS5uZXQ+PiB3cm90ZToNCk1vbiwgT2N0IDAzLCAyMDE2IGF0IDA1OjEyOjIwUE0g KzAwMDAsIEpha29iIEhlaXR6IChqaGVpdHopOg0KPiBBbiBpbXBsZW1lbnRhdGlvbiBtYXkgZ2l2 ZSB5b3UgYSBtYXRjaCBjb25kaXRpb24gZm9yIHJlc2VydmVkIHJhbmdlLiBJIGhhdmVuJ3QgKHll dCkuIFByaXZhdGUgQVMgaGFzIDIgcmFuZ2VzLiBUaGUgbWF0Y2ggZm9yIHRoYXQgaXMgc3RpbGwg b24gbXkgdG9kbyBsaXN0LiBJZiBpdCB3ZXJlIG9uZSByYW5nZSwgdGhlbiBpdCB3b3VsZCBiZSBk b25lLg0KPg0KPiBPbmUgcmFuZ2UgcGxlYXNlLg0KDQp0aGV5IGFyZW4ndCBhcmJpdHJhcnkgcmFu Z2VzIC0gdGhleSBhcmUgdGhlIHJlc2VydmVkIEFTTnMuICBXaHkgaXMgaXQNCmRpZmZpY3VsdCB0 byBtYXRjaCBpZiAoZmllbGQxID09ICgwfDB4ZmZmZnwweGZmZmZmZmZmKSk/DQoNCj4gVGhhbmtz LA0KPiBKYWtvYi4NCj4NCj4gPiBPbiBPY3QgMywgMjAxNiwgYXQgOTo1NyBBTSwgSm9iIFNuaWpk ZXJzIDxqb2JAbnR0Lm5ldDxtYWlsdG86am9iQG50dC5uZXQ+PiB3cm90ZToNCj4gPg0KPiA+PiBP biBNb24sIE9jdCAwMywgMjAxNiBhdCAwNDo1MzoxNFBNICswMDAwLCBKYWtvYiBIZWl0eiAoamhl aXR6KSB3cm90ZToNCj4gPj4gSSB3cml0ZSBjb2RlLiBJIHdhdGNoIHBlb3BsZSB3cml0ZSBjb2Rl IGFuZCB0ZXN0IGNvZGUuIEl0IGFkZHMgdG8NCj4gPj4gZGV2ZWxvcG1lbnQgdGltZS4gMyByYW5n ZXMgaXMgbm90IG5lY2Vzc2FyeS4gSXQncyBtZXNzeS4NCg0KVGhlIHByb2JsZW0gd2l0aCAqbm90 KiByZXNlcnZpbmcgYWxsIDMgaXMgdGhpczogdGhlcmUgbWF5IGJlLCBpbiBmdXR1cmUsIGEgbmV3 IHNldCBvZiAiV2VsbC1Lbm93biBMYXJnZSBDb21tdW5pdGllcyIuDQoNClRoZSAoYmVzdCBvciBm ZWFzaWJsZSkgY2hvaWNlKHMpIG9mIFdISUNIIG9mIHRoZSAzIHJlc2VydmVkIHZhbHVlcyBzaG91 bGQgZ2V0IHVzZWQgYXMgdGhlIHJhbmdlIGNvbnRhaW5pbmcgV0tMQ3MgKGFuZCBoZXJlIEkgcHJl c3VtZSBvbmUgb2YgdGhlIHRocmVlIE1VU1QgYmUgdGhlIHBsYWNlIGZvciBXS0xDcyksIGNvdWxk IGRlcGVuZCBvbiBzb21lIG51bWJlciBvZiBmYWN0b3JzIG5vdCBrbm93biB0byB1cyBhdCB0aGlz IHRpbWUuDQoNCklmIHdlIGF0dGVtcHQgdG8gbWFrZSB0aGF0IGRlY2lzaW9uIG5vdywgYmFzZWQg b24gemVybyBpbmZvcm1hdGlvbiBhYm91dCBwb3NzaWJsZSB1bnNlZW4gY29uc2VxdWVuY2VzLCBv dXIgZnV0dXJlIHNlbHZlcyAob3Igb3VyIHN1Y2Nlc3NvcnMpIG1pZ2h0IGJlIHZlcnkgdW5oYXBw eS4NCg0KUmVzZXJ2aW5nIGFsbCAzIChidXQgbm90IHJlcXVpcmluZyBhbnkgYWN0aW9uIG9uIHRo b3NlIHJlc2VydmF0aW9ucywgcGVyIHNlKSBjb3N0cyBub3RoaW5nLCBhbmQgbGVhdmVzIGFsbCAz IG9wZW4gZm9yIGZ1dHVyZSB1c2UgYXMgV0tMQ3MuDQoNClJlc2VydmluZyBhbGwgMyBkb2VzLCBo b3dldmVyLCB3YXJuIG9mZiBvcGVyYXRvcnMgZnJvbSB1c2luZyBhbnkgb2YgdGhvc2UsIHNvIHRo ZXkgZG9uJ3QgZ2V0IHNvbWUgbGF0ZXIgc3VycHJpc2Ugd2hlbiBhbiBpbXBsZW1lbnRhdGlvbiBz dGFydHMgaW50ZXJwcmV0aW5nIFdLTENzIHRoYXQgaGFwcGVuIHRvIGNvbmZsaWN0IHdpdGggd2hh dCB0aGUgb3BlcmF0b3IgaGFzIGJlZW4gdXNpbmcuDQoNCkl0IGlzIGFudGljaXBhdG9yeSBwcmlu Y2lwYWwgb2YgbGVhc3QgYXN0b25pc2htZW50Lg0KDQoNCj4gPiBBcyBhbiBpbXBsZW1lbnRvciwg eW91IGFyZSBub3Qgc3VwcG9zZWQgdG8gZG8gYW55dGhpbmcgd2l0aCB0aGVzZQ0KPiA+IHJhbmdl czAuIFRoZXkgYXJlIGp1c3QgcmVzZXJ2ZWQgaW4gdGhlIHNlbnNlIHRoYXQgdGhleSBiZWxvbmcg dG8gSUFOQSwNCj4gPiBub3QgdG8gYSBzaW5nbGUgb3BlcmF0b3IuIEZvciB0aGUgbW9tZW50LCBv cGVyYXRvcnMgc2hvdWxkIGF2b2lkIHVzaW5nDQo+ID4gdmFsdWVzIGZyb20gdGhlc2UgcmFuZ2Vz LCBidXQgaW1wbGVtZW50YXRpb25zIHNob3VsZG4ndCBwcm9oaWJpdCB0aGVtDQo+ID4gZnJvbSBk b2luZyBzby4NCj4gPg0KPiA+IFRoaXMgaXMgbm8gZGlmZmVyZW50IHRoYW4gUkZDMTk5NyB3aGlj aCByZXNlcnZlcyB0aGUgZm9sbG93aW5nIHR3bzoNCj4gPg0KPiA+ICAgIDB4MDAwMDAwMDAgLSAw eDAwMDBGRkZGDQo+ID4gICAgMHhGRkZGMDAwMCAtIDB4RkZGRkZGRkYNCj4gPg0KPiA+IENhbiB5 b3UgZWxhYm9yYXRlIG9uIHdoZXRoZXIgSU9TIFhSIHRyZWF0cyBSRkMxOTk3IHZhbHVlcyBmcm9t IHRob3NlDQo+ID4gcmFuZ2VzIGluIGEgc3BlY2lhbCB3YXk/IChhc2lkZSBmcm9tIHRoZSB3ZWxs IGtub3duIGNvbW11bml0aWVzDQo+ID4gb2YgY291cnNlKQ0KDQpJIHRoaW5rIHRoaXMgaWxsdXN0 cmF0ZXMgdGhlIHByb2JsZW0gcXVpdGUgd2VsbC4NCkl0IG1heSBub3QgYmUgdGhlIGNhc2UgdGhh dCBhbGwgaW1wbGVtZW50YXRpb25zIHByZXZlbnQgc29tZSBvcGVyYXRvciBmcm9tIHVzaW5nIGFu IFJGQzE5OTcgY29tbXVuaXR5IGluIGEgbm9uLWNvbmZvcm1pc3Qgd2F5Lg0KQnV0IGlmIHRoZSBv cGVyYXRvciBkb2VzIHVzZSBzdWNoIGEgY29tbXVuaXR5LCBhbmQgdW5leHBlY3RlZCAodG8gdGhh dCBvcGVyYXRvcikgdGhpbmdzIGhhcHBlbiwgd2VsbCwgImNhdmVhdCBlbXB0b3IiLg0KDQpJdCB3 b3VsZCBiZSBuaWNlIGlmIGltcGxlbWVudGF0aW9ucyBwcm92aWRlZCB3YXJuaW5ncywgb3IgZXZl biBwcmV2ZW50ZWQgcGVvcGxlIGZyb20gc2hvb3RpbmcgdGhlbXNlbHZlcyBpbiA8Ym9keSBwYXJ0 Pi4NCkl0IGlzbid0IHN0cmljdGx5IG5lY2Vzc2FyeSwgYW5kIGFzIGxvbmcgYXMgdGhlIFJGQ3Mg cHJvdmlkZSBlbm91Z2ggd2FybmluZ3MgYWdhaW5zdCBkb2luZyBzbywgdGhhdCdzIHByb2JhYmx5 IGVub3VnaC4NCg0KSUNBTk4vSUFOQSBvbmx5IHByb3ZpZGUgdGhlIHJlZ3VsYXRvcnkgZnJhbWV3 b3JrcyBmb3IgdGhlIHB1YmxpYyBJbnRlcm5ldDsgdGhlcmUgYXJlIG90aGVyICJpbnRlcm5ldHMi IHRoYXQgZXhpc3QsIHdoZXJlIHJlLXVzZSBvZiBhc3NpZ25lZCBJUCBhZGRyZXNzZXMgKG91dHNp ZGUgb2YgUkZDMTkxOCkgaXMgYSBub24taXNzdWUuDQooQW5kIG9ubHkgc28gbG9uZyBhcyB0aGUg bmV0d29ya3MgaW52b2x2ZWQgZG8gbm90IGF0dGVtcHQgdG8gaW50ZXJjb25uZWN0IHdpdGggInRo ZSBJbnRlcm5ldCIuKQ0KDQpCdXQsIHdoZXJlIHRoZSBpbnRlbnQgaXMgdGhhdCB0aGUgZmlyc3Qg MzItYml0IHZhbHVlIGlzICJ0aGUgcHVibGljIEFTTiIgb2YgdGhlIG9wZXJhdG9yIChhbmQgdGhp cyBzaG91bGQgYmUgdGhlIGNhc2UgZm9yIGFueSBJbnRlcm5ldC1hbm5vdW5jZWQgTkxSSXMgd2l0 aCB0aGlzIG5ldyBhdHRyaWJ1dGUpLCB3ZSBzaG91bGQgd2FybiBvZmYgYW55ICJvZmYtbGFiZWwi IHVzZS4NCkUuZy4gYWR2aXNlIG9uIHRoZSAicHJpdmF0ZSB1c2UgQVNOcyIgYXZhaWxhYmxlLCBh bmQgb24gdGhlICJyZXNlcnZlZCB2YWx1ZXMiLg0KDQpUaGF0J3MgbXkgJDAuMDIuDQoNCkJyaWFu DQo= --_000_b5de6ce139174bc8a4efbd64c9e0be03XCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJMdWNpZGEgQ29uc29s ZSI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNCA1IDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNv bG9yOiM3MDMwQTA7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0K CXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPkZpbmUuIEl0 J3Mgbm90IHRoYXQgaW1wb3J0YW50IGFueXdheS48bzpwPjwvbzpwPjwvc3Bhbj48L2E+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjoj NzAzMEEwIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEg Q29uc29sZSZxdW90Oztjb2xvcjojNzAzMEEwIj5KYWtvYi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJyaWFuIERpY2tzb24gW21h aWx0bzpicmlhbi5wZXRlci5kaWNrc29uQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBN b25kYXksIE9jdG9iZXIgMDMsIDIwMTYgMjoyNSBQTTxicj4NCjxiPlRvOjwvYj4gaGVhc2xleSAm bHQ7aGVhc0BzaHJ1YmJlcnkubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSmFrb2IgSGVpdHogKGpo ZWl0eikgJmx0O2poZWl0ekBjaXNjby5jb20mZ3Q7OyBpZHJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtJZHJdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaWRyLWxhcmdlLWNvbW11 bml0eS0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIE1vbiwgT2N0IDMsIDIwMTYgYXQgMTE6NDIgQU0sIGhlYXNsZXkgJmx0Ozxh IGhyZWY9Im1haWx0bzpoZWFzQHNocnViYmVyeS5uZXQiIHRhcmdldD0iX2JsYW5rIj5oZWFzQHNo cnViYmVyeS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb24sIE9jdCAwMywgMjAxNiBhdCAwNToxMjoyMFBNICYjNDM7 MDAwMCwgSmFrb2IgSGVpdHogKGpoZWl0eik6PGJyPg0KJmd0OyBBbiBpbXBsZW1lbnRhdGlvbiBt YXkgZ2l2ZSB5b3UgYSBtYXRjaCBjb25kaXRpb24gZm9yIHJlc2VydmVkIHJhbmdlLiBJIGhhdmVu J3QgKHlldCkuIFByaXZhdGUgQVMgaGFzIDIgcmFuZ2VzLiBUaGUgbWF0Y2ggZm9yIHRoYXQgaXMg c3RpbGwgb24gbXkgdG9kbyBsaXN0LiBJZiBpdCB3ZXJlIG9uZSByYW5nZSwgdGhlbiBpdCB3b3Vs ZCBiZSBkb25lLjxicj4NCiZndDs8YnI+DQomZ3Q7IE9uZSByYW5nZSBwbGVhc2UuPGJyPg0KPGJy Pg0KdGhleSBhcmVuJ3QgYXJiaXRyYXJ5IHJhbmdlcyAtIHRoZXkgYXJlIHRoZSByZXNlcnZlZCBB U05zLiZuYnNwOyBXaHkgaXMgaXQ8YnI+DQpkaWZmaWN1bHQgdG8gbWF0Y2ggaWYgKGZpZWxkMSA9 PSAoMHwweGZmZmZ8MHhmZmZmZmZmZikpPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCiZn dDsgVGhhbmtzLDxicj4NCiZndDsgSmFrb2IuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBPbiBP Y3QgMywgMjAxNiwgYXQgOTo1NyBBTSwgSm9iIFNuaWpkZXJzICZsdDs8YSBocmVmPSJtYWlsdG86 am9iQG50dC5uZXQiPmpvYkBudHQubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBPbiBNb24sIE9jdCAwMywgMjAxNiBhdCAwNDo1MzoxNFBNICYjNDM7 MDAwMCwgSmFrb2IgSGVpdHogKGpoZWl0eikgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJIHdy aXRlIGNvZGUuIEkgd2F0Y2ggcGVvcGxlIHdyaXRlIGNvZGUgYW5kIHRlc3QgY29kZS4gSXQgYWRk cyB0bzxicj4NCiZndDsgJmd0OyZndDsgZGV2ZWxvcG1lbnQgdGltZS4gMyByYW5nZXMgaXMgbm90 IG5lY2Vzc2FyeS4gSXQncyBtZXNzeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJvYmxlbSB3 aXRoICpub3QqIHJlc2VydmluZyBhbGwgMyBpcyB0aGlzOiB0aGVyZSBtYXkgYmUsIGluIGZ1dHVy ZSwgYSBuZXcgc2V0IG9mICZxdW90O1dlbGwtS25vd24gTGFyZ2UgQ29tbXVuaXRpZXMmcXVvdDsu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSAoYmVzdCBvciBmZWFzaWJsZSkgY2hvaWNlKHMpIG9mIFdISUNIIG9mIHRoZSAzIHJlc2VydmVk IHZhbHVlcyBzaG91bGQgZ2V0IHVzZWQgYXMgdGhlIHJhbmdlIGNvbnRhaW5pbmcgV0tMQ3MgKGFu ZCBoZXJlIEkgcHJlc3VtZSBvbmUgb2YgdGhlIHRocmVlIE1VU1QgYmUgdGhlIHBsYWNlIGZvciBX S0xDcyksIGNvdWxkIGRlcGVuZCBvbiBzb21lIG51bWJlciBvZiBmYWN0b3JzIG5vdCBrbm93biB0 byB1cyBhdA0KIHRoaXMgdGltZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SWYgd2UgYXR0ZW1wdCB0byBtYWtlIHRoYXQgZGVjaXNpb24gbm93 LCBiYXNlZCBvbiB6ZXJvIGluZm9ybWF0aW9uIGFib3V0IHBvc3NpYmxlIHVuc2VlbiBjb25zZXF1 ZW5jZXMsIG91ciBmdXR1cmUgc2VsdmVzIChvciBvdXIgc3VjY2Vzc29ycykgbWlnaHQgYmUgdmVy eSB1bmhhcHB5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5SZXNlcnZpbmcgYWxsIDMgKGJ1dCBub3QgcmVxdWlyaW5nIGFueSBhY3Rpb24gb24g dGhvc2UgcmVzZXJ2YXRpb25zLCBwZXIgc2UpIGNvc3RzIG5vdGhpbmcsIGFuZCBsZWF2ZXMgYWxs IDMgb3BlbiBmb3IgZnV0dXJlIHVzZSBhcyBXS0xDcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVzZXJ2aW5nIGFsbCAzIGRvZXMsIGhvd2V2 ZXIsIHdhcm4gb2ZmIG9wZXJhdG9ycyBmcm9tIHVzaW5nIGFueSBvZiB0aG9zZSwgc28gdGhleSBk b24ndCBnZXQgc29tZSBsYXRlciBzdXJwcmlzZSB3aGVuIGFuIGltcGxlbWVudGF0aW9uIHN0YXJ0 cyBpbnRlcnByZXRpbmcgV0tMQ3MgdGhhdCBoYXBwZW4gdG8gY29uZmxpY3Qgd2l0aCB3aGF0IHRo ZSBvcGVyYXRvciBoYXMgYmVlbiB1c2luZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgYW50aWNpcGF0b3J5IHByaW5jaXBhbCBvZiBs ZWFzdCBhc3RvbmlzaG1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7ICZndDsgQXMgYW4gaW1w bGVtZW50b3IsIHlvdSBhcmUgbm90IHN1cHBvc2VkIHRvIGRvIGFueXRoaW5nIHdpdGggdGhlc2U8 YnI+DQomZ3Q7ICZndDsgcmFuZ2VzMC4gVGhleSBhcmUganVzdCByZXNlcnZlZCBpbiB0aGUgc2Vu c2UgdGhhdCB0aGV5IGJlbG9uZyB0byBJQU5BLDxicj4NCiZndDsgJmd0OyBub3QgdG8gYSBzaW5n bGUgb3BlcmF0b3IuIEZvciB0aGUgbW9tZW50LCBvcGVyYXRvcnMgc2hvdWxkIGF2b2lkIHVzaW5n PGJyPg0KJmd0OyAmZ3Q7IHZhbHVlcyBmcm9tIHRoZXNlIHJhbmdlcywgYnV0IGltcGxlbWVudGF0 aW9ucyBzaG91bGRuJ3QgcHJvaGliaXQgdGhlbTxicj4NCiZndDsgJmd0OyBmcm9tIGRvaW5nIHNv Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGlzIGlzIG5vIGRpZmZlcmVudCB0aGFu IFJGQzE5OTcgd2hpY2ggcmVzZXJ2ZXMgdGhlIGZvbGxvd2luZyB0d286PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAweDAwMDAwMDAwIC0gMHgwMDAwRkZGRjxicj4N CiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgMHhGRkZGMDAwMCAtIDB4RkZGRkZGRkY8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgQ2FuIHlvdSBlbGFib3JhdGUgb24gd2hldGhlciBJT1MgWFIg dHJlYXRzIFJGQzE5OTcgdmFsdWVzIGZyb20gdGhvc2U8YnI+DQomZ3Q7ICZndDsgcmFuZ2VzIGlu IGEgc3BlY2lhbCB3YXk/IChhc2lkZSBmcm9tIHRoZSB3ZWxsIGtub3duIGNvbW11bml0aWVzPGJy Pg0KJmd0OyAmZ3Q7IG9mIGNvdXJzZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoaXMg aWxsdXN0cmF0ZXMgdGhlIHByb2JsZW0gcXVpdGUgd2VsbC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IG1heSBub3QgYmUgdGhlIGNh c2UgdGhhdCBhbGwgaW1wbGVtZW50YXRpb25zIHByZXZlbnQgc29tZSBvcGVyYXRvciBmcm9tIHVz aW5nIGFuIFJGQzE5OTcgY29tbXVuaXR5IGluIGEgbm9uLWNvbmZvcm1pc3Qgd2F5LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IGlmIHRoZSBv cGVyYXRvciBkb2VzIHVzZSBzdWNoIGEgY29tbXVuaXR5LCBhbmQgdW5leHBlY3RlZCAodG8gdGhh dCBvcGVyYXRvcikgdGhpbmdzIGhhcHBlbiwgd2VsbCwgJnF1b3Q7Y2F2ZWF0IGVtcHRvciZxdW90 Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SXQgd291bGQgYmUgbmljZSBpZiBpbXBsZW1lbnRhdGlvbnMgcHJvdmlkZWQgd2FybmluZ3MsIG9y IGV2ZW4gcHJldmVudGVkIHBlb3BsZSBmcm9tIHNob290aW5nIHRoZW1zZWx2ZXMgaW4gJmx0O2Jv ZHkgcGFydCZndDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JdCBpc24ndCBzdHJpY3RseSBuZWNlc3NhcnksIGFuZCBhcyBsb25nIGFzIHRoZSBS RkNzIHByb3ZpZGUgZW5vdWdoIHdhcm5pbmdzIGFnYWluc3QgZG9pbmcgc28sIHRoYXQncyBwcm9i YWJseSBlbm91Z2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklDQU5OL0lBTkEgb25seSBwcm92aWRlIHRoZSByZWd1bGF0b3J5IGZyYW1ld29y a3MgZm9yIHRoZSBwdWJsaWMgSW50ZXJuZXQ7IHRoZXJlIGFyZSBvdGhlciAmcXVvdDtpbnRlcm5l dHMmcXVvdDsgdGhhdCBleGlzdCwgd2hlcmUgcmUtdXNlIG9mIGFzc2lnbmVkIElQIGFkZHJlc3Nl cyAob3V0c2lkZSBvZiBSRkMxOTE4KSBpcyBhIG5vbi1pc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihBbmQgb25seSBzbyBsb25nIGFzIHRo ZSBuZXR3b3JrcyBpbnZvbHZlZCBkbyBub3QgYXR0ZW1wdCB0byBpbnRlcmNvbm5lY3Qgd2l0aCAm cXVvdDt0aGUgSW50ZXJuZXQmcXVvdDsuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQsIHdoZXJlIHRoZSBpbnRlbnQgaXMgdGhhdCB0aGUg Zmlyc3QgMzItYml0IHZhbHVlIGlzICZxdW90O3RoZSBwdWJsaWMgQVNOJnF1b3Q7IG9mIHRoZSBv cGVyYXRvciAoYW5kIHRoaXMgc2hvdWxkIGJlIHRoZSBjYXNlIGZvciBhbnkgSW50ZXJuZXQtYW5u b3VuY2VkIE5MUklzIHdpdGggdGhpcyBuZXcgYXR0cmlidXRlKSwgd2Ugc2hvdWxkIHdhcm4gb2Zm IGFueSAmcXVvdDtvZmYtbGFiZWwmcXVvdDsgdXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RS5nLiBhZHZpc2Ugb24gdGhlICZxdW90O3ByaXZh dGUgdXNlIEFTTnMmcXVvdDsgYXZhaWxhYmxlLCBhbmQgb24gdGhlICZxdW90O3Jlc2VydmVkIHZh bHVlcyZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhdCdzIG15ICQwLjAyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmlhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_b5de6ce139174bc8a4efbd64c9e0be03XCHALN014ciscocom_-- From nobody Mon Oct 3 15:02:07 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E1D129572; Mon, 3 Oct 2016 15:02:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147553212286.29652.17602398820945558642.idtracker@ietfa.amsl.com> Date: Mon, 03 Oct 2016 15:02:02 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-legacy-rtc-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 22:02:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Automatic Route Target Filtering for legacy PEs Authors : Pradosh Mohapatra Arjun Sreekantiah Keyur Patel Burjiz Pithawala Alton Lo Filename : draft-ietf-idr-legacy-rtc-07.txt Pages : 10 Date : 2016-10-03 Abstract: This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in [RFC4684]. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace [RFC4684]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-legacy-rtc/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-legacy-rtc-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-legacy-rtc-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 5 08:16:16 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4956129703 for ; Wed, 5 Oct 2016 08:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 r8nbeWgTUjbW for ; Wed, 5 Oct 2016 08:16:13 -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 957A01296C2 for ; Wed, 5 Oct 2016 08:16:13 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u95FG8pj035914 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Oct 2016 16:16:09 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <57F51937.70103@foobar.org> Date: Wed, 05 Oct 2016 16:16:07 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.3 (Macintosh/20160930) MIME-Version: 1.0 To: Job Snijders References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> In-Reply-To: <20161003095936.GC20697@Vurt.local> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 15:16:15 -0000 Job Snijders wrote: > On Mon, Oct 03, 2016 at 10:13:02AM +0100, t.petch wrote: >> I think Section 3 needs qualifying; it should allow for there being no >> communities in the routes being aggregated; and what happens if the >> communities are a mix of large and not large? (Something that RFC4360 >> s.6 addresses) > > If we add the following, would that address your concern? > > "A route may carry both the BGP Communities attribute, as defined in > [RFC1997]), and the Extended BGP Communities attribute, as defined > in [RFC4360], and the Large BGP Community attribute. In this case, > the BGP Communities attribute is handled as specified in [RFC1997], > and the Extended BGP Communities attribute is handled as specified > in [RFC4360], and the Large BGP Community is handed as specified in > this document." There are two germane issues when there are multiple types of communities attached to a route: exclusivity and precedence. For exclusivity, the issue is whether you can you attach a large bgp community to a prefix as well as an another type of community. It would be so bizarre an idea to suggest you couldn't do this that it doesn't even need to be mentioned that it's legit. If the document doesn't mention exclusivity, the only possible interpretation is that it must be permitted. TBH it would be rather peculiar to even mention that it's ok, almost as if these new large bgp communities were the new cool kids on the block and they're like totes ok co-existing with other types of communities that have been around for ages. It's faintly ridiculous. Precedence must a locally defined issue because anything else would result in an enormous bunfight about whose BGP Communities rfc was the biggest and most important. Again, it is better not to say anything here, because if nothing is said, then the ietf is not making any judgements about how to interpret community values, which is fully consistent with how communities have always been interpreted in the past. This paragraph should be omitted completely. It adds nothing. Nick From nobody Wed Oct 5 08:46:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154FA12967C for ; Wed, 5 Oct 2016 08:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iD2jwMQWsvqf for ; Wed, 5 Oct 2016 08:46:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B64941295DD for ; Wed, 5 Oct 2016 08:46:08 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id C408A1E337; Wed, 5 Oct 2016 11:47:54 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_8B6D8455-0D85-4130-BD1E-2D669ADB9591" From: Jeffrey Haas In-Reply-To: <57F51937.70103@foobar.org> Date: Wed, 5 Oct 2016 11:46:06 -0400 Message-Id: <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <57F51937.70103@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.2104) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 15:46:10 -0000 --Apple-Mail=_8B6D8455-0D85-4130-BD1E-2D669ADB9591 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 5, 2016, at 11:16 AM, Nick Hilliard wrote: >=20 > This paragraph should be omitted completely. It adds nothing. I agree. To the authors: Other things I note while reading the draft: " Global Administrator: A four-octet namespace identifier. This SHOULD be an Autonomous System Number assigned by IANA." delete "assigned by IANA". That's not usually their business. Similarly, I find the following sentence adds no value: " There are no routing semantics implied by the Global Administrator field." I am also unclear on the semantics of why atomic aggregate impacts = whether merging happens or not. (Please don't make me break out 10+ year old points as to why AA has = been broken from day one.) I'll reiterate my objection to a mandatory representation format, but = other implementations that actually are impacted will make my point for = me. Unless we're doing a yang module, IETF really has no business = specifying UI. With regard to the security considerations, I'd drop the "and BGP = Extended Communities". While the generic ext-comms draft originally = passed through IETF process with its somewhat weak session, I think any = practical security analysis of it would point out that the signaling = information covered by ext-comms is significantly greater than the base = 1997 case these days. Similarly, I'd drop "trust in every other AS in the path" section. If = you're going to dig into that issue, you'll end up in a world of = security considerations hurt. You still will courtesy of the way our = security ADs function with their odd understanding of how protocol work = and operations collide, but you're almost always better off starting = with too little and let them guide you into what they want to see than = give them fodder for confusion early on. -- Jeff --Apple-Mail=_8B6D8455-0D85-4130-BD1E-2D669ADB9591 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 5, 2016, at 11:16 AM, Nick Hilliard <nick@foobar.org> = wrote:

This paragraph should be omitted completely. It = adds nothing.

I = agree.

To the = authors:
Other things I note while reading the = draft:
"   Global =
Administrator:  A four-octet namespace identifier.  This
      SHOULD be an Autonomous System Number assigned by IANA."
delete "assigned by IANA".  That's not usually their = business.

Similarly, I find the following sentence adds no = value:
"   There are no =
routing semantics implied by the Global Administrator
   field."

I am also unclear on the semantics of why atomic aggregate = impacts whether merging happens or not.
(Please = don't make me break out 10+ year old points as to why AA has been broken = from day one.)

I'll reiterate my objection to a mandatory representation = format, but other implementations that actually are impacted will make = my point for me.  Unless we're doing a yang module, IETF really has = no business specifying UI.

With regard to the security considerations, I'd drop the "and = BGP Extended Communities".  While the generic ext-comms draft = originally passed through IETF process with its somewhat weak session, I = think any practical security analysis of it would point out that the = signaling information covered by ext-comms is significantly greater than = the base 1997 case these days.

Similarly, I'd drop "trust in every = other AS in the path" section.  If you're going to dig into that = issue, you'll end up in a world of security considerations hurt. =  You still will courtesy of the way our security ADs function with = their odd understanding of how protocol work and operations collide, but = you're almost always better off starting with too little and let them = guide you into what they want to see than give them fodder for confusion = early on.

-- = Jeff




= --Apple-Mail=_8B6D8455-0D85-4130-BD1E-2D669ADB9591-- From nobody Wed Oct 5 08:48:40 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123A2129792 for ; Wed, 5 Oct 2016 08:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 QDA_4GzMYT27 for ; Wed, 5 Oct 2016 08:48:38 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6D91296FA for ; Wed, 5 Oct 2016 08:48:38 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 86AFB1E337; Wed, 5 Oct 2016 11:50:25 -0400 (EDT) From: Jeffrey Haas Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Oct 2016 11:48:37 -0400 To: IETF IDR WG Message-Id: <0E9469C4-2B72-484A-9C93-BC13401F6889@pfrc.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 15:48:39 -0000 In theory, by adoping draft-ietf-idr-bgp-attribute-announcement, IDR = agreed that attribute scoping was an important issue. As proven by the working group discussion on BGP large communities, the = WG seems unwilling to consider anything that adds any level of = complexity onto certain proposals. Should we simply consider this draft dead? -- Jeff From nobody Wed Oct 5 08:54:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88EB1297A5 for ; Wed, 5 Oct 2016 08:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=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 qOLkiOjrvIf8 for ; Wed, 5 Oct 2016 08:54:47 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980A11297A3 for ; Wed, 5 Oct 2016 08:54:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.177.17; From: "Susan Hares" To: "'Jeffrey Haas'" , "'IETF IDR WG'" References: <0E9469C4-2B72-484A-9C93-BC13401F6889@pfrc.org> In-Reply-To: <0E9469C4-2B72-484A-9C93-BC13401F6889@pfrc.org> Date: Wed, 5 Oct 2016 11:53:15 -0400 Message-ID: <003901d21f20$95ece2f0$c1c6a8d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJqd/5OiARNgmjBwcNLKllywB1Xrp9pT8iw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 15:54:49 -0000 Jeff: My reading of the list that: a) Large communities meets an "urgent/crisis level need" b) Wide communities and bgp-attribute-announcement - meet a longer term need. Did I miss understand the list's comments? Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Wednesday, October 5, 2016 11:49 AM To: IETF IDR WG Subject: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? In theory, by adoping draft-ietf-idr-bgp-attribute-announcement, IDR agreed that attribute scoping was an important issue. As proven by the working group discussion on BGP large communities, the WG seems unwilling to consider anything that adds any level of complexity onto certain proposals. Should we simply consider this draft dead? -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Oct 5 09:17:51 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F381297A3 for ; Wed, 5 Oct 2016 09:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 8Jhen_jukujy for ; Wed, 5 Oct 2016 09:17:48 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 1AA05129550 for ; Wed, 5 Oct 2016 09:17:48 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1brot7-000Cto-K3 (job@us.ntt.net); Wed, 05 Oct 2016 16:17:47 +0000 Date: Wed, 5 Oct 2016 18:17:41 +0200 From: Job Snijders To: Jeffrey Haas Message-ID: <20161005161741.GY20697@Vurt.local> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <57F51937.70103@foobar.org> <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 16:17:50 -0000 On Wed, Oct 05, 2016 at 11:46:06AM -0400, Jeffrey Haas wrote: > > On Oct 5, 2016, at 11:16 AM, Nick Hilliard wrote: > > > > This paragraph should be omitted completely. It adds nothing. > > I agree. Nick, Jeff, thank you for your feedback. I've deleted the section from what will be -02. > To the authors: > Other things I note while reading the draft: > "Global Administrator: A four-octet namespace identifier. This > SHOULD be an Autonomous System Number assigned by IANA." > delete "assigned by IANA". That's not usually their business. agreed. > Similarly, I find the following sentence adds no value: > "There are no routing semantics implied by the Global Administrator > field." This sentence was already deleted following feedback from Tom Petch (https://mailarchive.ietf.org/arch/msg/idr/GF4yLYbWltrj8rKNtdPk1xxexv8) Thanks for seconding the removal. > I am also unclear on the semantics of why atomic aggregate impacts > whether merging happens or not. (Please don't make me break out 10+ > year old points as to why AA has been broken from day one.) I'll leave this for others to comment on. > I'll reiterate my objection to a mandatory representation format, but > other implementations that actually are impacted will make my point > for me. Unless we're doing a yang module, IETF really has no business > specifying UI. There are more examples where the IETF (for better or for worse) has specified canonical representations. For example, I'd be disappointed if a major implementation ends up representing Large BGP Communities as straight uint96_t's in the UI. A challenge here is that there might be two issues at hand: one is the canonical way to represent a Large BGP Community in a phone call, or in technical documentation which is provided by one operator to another operator. The second issue is what is actually typed/inputted into network element configurations. The "Textual Representation" section should provide any implementor with enough freedom to use a prefix, suffix, or a separator of their choosing. Given the current text: https://github.com/large-bgp-communities/large-bgp-communities/blob/master/draft-ietf-idr-large-community.xml#L208-L232 should we change the first three "MUST" to a "SHOULD" to alleviate your concern? Do you consider my concern about a canonical format for inter-operator communication valid? > With regard to the security considerations, I'd drop the "and BGP > Extended Communities". While the generic ext-comms draft originally > passed through IETF process with its somewhat weak session, I think > any practical security analysis of it would point out that the > signaling information covered by ext-comms is significantly greater > than the base 1997 case these days. You make a fair point, I have removed that string (unless someone champions that it should remain part of the draft). > Similarly, I'd drop "trust in every other AS in the path" section. If > you're going to dig into that issue, you'll end up in a world of > security considerations hurt. You still will courtesy of the way our > security ADs function with their odd understanding of how protocol > work and operations collide, but you're almost always better off > starting with too little and let them guide you into what they want to > see than give them fodder for confusion early on. To confirm, you propose to change; "This document does not change any underlying security issues associated with any other BGP Communities mechanism. Specifically, an AS relying on the Large BGP Community attribute carried in BGP must have trust in every other AS in the path, as any intermediate Autonomous System in the path may have added, deleted or altered the Large BGP Community attribute. Specifying the mechanism to provide such trust is beyond the scope of this document." to "This document does not change any underlying security issues associated with any other BGP Communities mechanism." correct? I can agree to this simplification. The text was put in as an attempt to preempt some security review scrutinity. It continues to be a challenge to figure out how far one should go to scope expecations, and when to write down something is out of scope, or not. Feedback from others on this specific topic is most welcome, if case no further feedback offered I'll remove that part of the section as per Jeff's recommendation. Kind regards, Job From nobody Wed Oct 5 09:43:54 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9024B129796 for ; Wed, 5 Oct 2016 09:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jt1tvZgF7zms for ; Wed, 5 Oct 2016 09:43:51 -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 810EB12978A for ; Wed, 5 Oct 2016 09:43:51 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u95Ghm1Z038295 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Oct 2016 17:43:48 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <57F52DC2.40809@foobar.org> Date: Wed, 05 Oct 2016 17:43:46 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.3 (Macintosh/20160930) MIME-Version: 1.0 To: Jeffrey Haas References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <57F51937.70103@foobar.org> <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> In-Reply-To: <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 16:43:53 -0000 Jeffrey Haas wrote: > I'd drop the "and BGP Extended Communities". you're correct on this on the grounds stated, i.e. there is no widespread use of extcomms for inter-as signaling. I added that line in there, and have an item on my todo list to get a couple of lines of text together in the next couple of days to explain in the Introduction section why extcomms are unsuitable for solving the problem at hand. The plan behind this was that when this draft goes through iesg review, the first question that's going to be asked is: "pls explain why extcomms won't work for your use case?", so given that that is likely to precipitate a couple of lines of explanation, the secdir review will then ask, "why didn't you mention extcomms in the security section when you mentioned rfc1997 both here and in the intro?". That, at least, was the rationale. The thing about this draft is that the principal is so easy to understand that a lot of people in the review process are likely to want to bikeshed it. So there are two options open regarding this: 1. omit everything about extcomms and face a likely barrage of nits from post-wglc review, and also don't explain to posterity why they were considered a non-viable solution to the problem at hand, or 2. put in an honorary mention of extcomms and in no more than a tiny number of lines, explain why they are unsuitable. I'd appreciate your input on this though. If you think it's unnecessary or counterproductive, that might save me word-whacking time which could be productively spent tilting at other windmills. Nick From nobody Wed Oct 5 09:50:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315E6129432 for ; Wed, 5 Oct 2016 09:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 IBIeOeZKIOcS for ; Wed, 5 Oct 2016 09:50:08 -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 1571D1293D9 for ; Wed, 5 Oct 2016 09:44:46 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u95Gij0x038339 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Oct 2016 17:44:45 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <57F52DFC.2080408@foobar.org> Date: Wed, 05 Oct 2016 17:44:44 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.3 (Macintosh/20160930) MIME-Version: 1.0 To: Jeffrey Haas References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <57F51937.70103@foobar.org> <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> In-Reply-To: <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 16:50:10 -0000 Jeffrey Haas wrote: > Similarly, I find the following sentence adds no value: > > " There are no routing semantics implied by the Global Administrator > field." +1, for same reason. Nick From nobody Wed Oct 5 10:18:40 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250851293DC for ; Wed, 5 Oct 2016 10:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UbD1pbL44uC6 for ; Wed, 5 Oct 2016 10:18:35 -0700 (PDT) Received: from 12.mo5.mail-out.ovh.net (12.mo5.mail-out.ovh.net [46.105.39.65]) (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 60098120726 for ; Wed, 5 Oct 2016 10:18:34 -0700 (PDT) Received: from player688.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id 1ED56FEC7 for ; Wed, 5 Oct 2016 19:18:32 +0200 (CEST) Received: from dave.pierky.com (dave.pierky.com [37.59.107.119]) (Authenticated sender: pierky@pierky.com) by player688.ha.ovh.net (Postfix) with ESMTPSA id 028A320084 for ; Wed, 5 Oct 2016 19:18:31 +0200 (CEST) Date: Wed, 5 Oct 2016 19:18:24 +0200 From: Pier Carlo Chiodi To: idr@ietf.org Message-ID: <20161005171824.GA6485@dave.pierky.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Ovh-Tracer-Id: 3884354682352481693 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelvddrfedtgddutdekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: [Idr] Large BGP Communities interoperability tests X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 17:18:38 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I ran some tests on OSS implementations using my "playground" [1], here the results: https://github.com/pierky/large-bgp-communities-playground/tree/master/tests They were thought to fill some blanks on the "Implementations of draft-ietf-idr-large-community" wiki page [2]; I also tested some new "Implemented Features" that perhaps may be worth to be added to that page. I'll do the same as soon as new implementations will be made available. Any corrections, suggestions and comments are welcome. 1] https://github.com/pierky/large-bgp-communities-playground 2] https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-large-community= %20implementations --=20 Pier Carlo Chiodi --J/dobhs11T7y2rNN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJX9TXgAAoJEEoF6ysdlltKFcEQAIubry/RCUG1DZaZCyLN4PwJ X2c4FOCxZFKgnlEa3XSHfAVyBkScmiJT+XrgF1wlXrUhTcrVBTztzbKtgTGZZ0LG eTpsRrlBVTDWw/U4PRhB9SXqYqXHPCcE6TzvitW4k8xr3URds3cwpUbDyyUtxMgl a6/7gnzoYWW9ESmeucmRGq3O+fvkZjfWeWeomP31CZajepG5dWdKz8Fy7wAHzV55 XRUgCRB7FfJgbUDMa4pQAVCgklDNyvR4dDY07ANF24kzPe3Yr4wVBKRq8+gg0bzX JkjxtsNFWsyuDv9EzcCrSMV8LsydhZ37JHjCJBXmFIja3sEFrQ/8hZqICuLSzJQy cfGpLyfh2E8ixKIkIB8QBp0fHENpsLq3nZm1iHaw2MUQxbX6Xj7/UPOPT6WrpgHl J25Nnr0FQSVYwalezQFHUoqb6tAMGkjPxkyaGwbjQhp15C4PDU5BF2eCkmj2reHp DQCuyYdSlCIA4vjAkacOO6D6KzuFifs/jQiLspRk34P/Knn27lC7ToXv7NSLzsOT 0Dsa9FkiUFRIklQP9uXdbwqSrhaCSmR4rb8S5/di7Ksq9hmCBKibdUxyF9gsAS4I SpqbzhzZPQbA5I0wmsJ2Mq2D6qNRuUSXF/8b8apl94wEpf2OhSdZmnUEeAf57iFU kDoW56lMKdEXzaSYfZ5W =r9dd -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From nobody Wed Oct 5 11:02:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416711297BD for ; Wed, 5 Oct 2016 11:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 DGtlLMjxQDXG for ; Wed, 5 Oct 2016 11:02:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C4DD01297BE for ; Wed, 5 Oct 2016 11:02:19 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id E8BE31E337; Wed, 5 Oct 2016 14:04:06 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: Jeffrey Haas In-Reply-To: <20161005161741.GY20697@Vurt.local> Date: Wed, 5 Oct 2016 14:02:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8A28CA6B-67F1-4BF9-944D-28BF9AB86360@pfrc.org> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <57F51937.70103@foobar.org> <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> <20161005161741.GY20697@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.2104) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 18:02:22 -0000 > On Oct 5, 2016, at 12:17 PM, Job Snijders wrote: >=20 >> I'll reiterate my objection to a mandatory representation format, but >> other implementations that actually are impacted will make my point >> for me. Unless we're doing a yang module, IETF really has no = business >> specifying UI. >=20 > There are more examples where the IETF (for better or for worse) has > specified canonical representations. For example, I'd be disappointed = if > a major implementation ends up representing Large BGP Communities as > straight uint96_t's in the UI. Some of your operational compatriots are quite happy to do decimal = string character index operations already. It wouldn't surprise me that = at some point someone asks for 4:4:4 to be 4:8 to enable trickery. Note: It's not been asked for. Yet. But I have faith in customers = asking after weird features. >=20 > A challenge here is that there might be two issues at hand: one is the > canonical way to represent a Large BGP Community in a phone call, or = in > technical documentation which is provided by one operator to another > operator. The second issue is what is actually typed/inputted into > network element configurations. I think the critical detail is already handled under section 2 of the = draft: A large community is defined as 3 contiguous four octet values. = You want structure, you have enough of the document defining structure. = More importantly, the structured components have names: Global Admin, = Local Data 1, Local Data 2. Really, I think you're done. >=20 > The "Textual Representation" section should provide any implementor = with > enough freedom to use a prefix, suffix, or a separator of their > choosing. Given the current text: > = https://github.com/large-bgp-communities/large-bgp-communities/blob/master= /draft-ietf-idr-large-community.xml#L208-L232 > should we change the first three "MUST" to a "SHOULD" to alleviate = your > concern? First, you talk about implementations. Again, it'll depend on the = implementation as to whether they find this reasonable or not. We've = already had input on-list from those who do things differently. If your concern is really just to have a useful way to talk about these = things in a portable way: "For documentation purposes, it is RECOMMENDED that BGP Large = Communities be represented as three unsigned decimal numbers separated = by the colon character; ::. E.g. 65551:100:0." > Do you consider my concern about a canonical format for inter-operator > communication valid? For communication, yes. Conveniently, the recommendation also covers = advice for those working on things like yang models. -- Jeff= From nobody Wed Oct 5 11:09:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72C61297CC for ; Wed, 5 Oct 2016 11:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 n4OZ7zH1_bax for ; Wed, 5 Oct 2016 11:09:09 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AEC6C129593 for ; Wed, 5 Oct 2016 11:09:09 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id F246F1E337; Wed, 5 Oct 2016 14:10:56 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: Jeffrey Haas In-Reply-To: <57F52DC2.40809@foobar.org> Date: Wed, 5 Oct 2016 14:09:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4CA1BEF7-B99D-4F86-A658-AE34420B3AB3@pfrc.org> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <57F51937.70103@foobar.org> <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> <57F52DC2.40809@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.2104) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 18:09:11 -0000 > On Oct 5, 2016, at 12:43 PM, Nick Hilliard wrote: >=20 > Jeffrey Haas wrote: >> I'd drop the "and BGP Extended Communities". >=20 > you're correct on this on the grounds stated, i.e. there is no > widespread use of extcomms for inter-as signaling. >=20 > I added that line in there, and have an item on my todo list to get a > couple of lines of text together in the next couple of days to explain > in the Introduction section why extcomms are unsuitable for solving = the > problem at hand. That'd be useful. I mostly restricted my comments on the -01 draft on = editorial corrections rather than reworking the introduction section. =20= In particular, this draft really is mixing up two distinct issues: 1. Expanding to permit 4:4. That case is worth explaining and ties into = the point about why ext-comms are insufficient. 2. Why there's another :4. If parity with 1997 was the only goal... = well,you'd be overreaching. I'm not arguing the Local Data 2 isn't useful. But it's a non-sequitir = in the line of logic presented. >=20 > The plan behind this was that when this draft goes through iesg = review, > the first question that's going to be asked is: "pls explain why > extcomms won't work for your use case?", so given that that is likely = to > precipitate a couple of lines of explanation, the secdir review will > then ask, "why didn't you mention extcomms in the security section = when > you mentioned rfc1997 both here and in the intro?". >=20 > That, at least, was the rationale. The thing about this draft is that > the principal is so easy to understand that a lot of people in the > review process are likely to want to bikeshed it. >=20 > So there are two options open regarding this: >=20 > 1. omit everything about extcomms and face a likely barrage of nits = from > post-wglc review, and also don't explain to posterity why they were > considered a non-viable solution to the problem at hand, or >=20 > 2. put in an honorary mention of extcomms and in no more than a tiny > number of lines, explain why they are unsuitable. >=20 > I'd appreciate your input on this though. If you think it's = unnecessary > or counterproductive, that might save me word-whacking time which = could > be productively spent tilting at other windmills. My opinion is that there will be last minute security considerations = flailing regardless of what we do. Thus, save your sanity for later. But to clarify why a "teaser" pointer to ext-comms is problematic, you = need to be very clear about the syntactic space issues for ext-comms not = being sufficient (it's not big enough!) vs. the semantic ones. Once a = security AD digs into the semantics of defined ext-comms and its impact = on forwarding and thinks (erroneously) that the same blanket = consideration may apply to Large, you'll have lost a week of your life. = Keep it simple (syntax/PDU) and clean. -- Jeff From nobody Wed Oct 5 11:15:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854551293FB for ; Wed, 5 Oct 2016 11:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3ydtp7TODnEa for ; Wed, 5 Oct 2016 11:15:17 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D6C571293E4 for ; Wed, 5 Oct 2016 11:15:16 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 4D9151E337; Wed, 5 Oct 2016 14:17:03 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_71DD2284-13C4-497B-9E8B-82A1BD0C2D5D" From: Jeffrey Haas In-Reply-To: <20161005161741.GY20697@Vurt.local> Date: Wed, 5 Oct 2016 14:15:15 -0400 Message-Id: <87D04902-FD4A-4400-AC9C-4D1CA85AFE6C@pfrc.org> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <57F51937.70103@foobar.org> <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> <20161005161741.GY20697@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.2104) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 18:15:20 -0000 --Apple-Mail=_71DD2284-13C4-497B-9E8B-82A1BD0C2D5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 5, 2016, at 12:17 PM, Job Snijders wrote: >=20 > The "Textual Representation" section should provide any implementor = with > enough freedom to use a prefix, suffix, or a separator of their > choosing. Given the current text: > = https://github.com/large-bgp-communities/large-bgp-communities/blob/master= /draft-ietf-idr-large-community.xml#L208-L232 = > should we change the first three "MUST" to a "SHOULD" to alleviate = your > concern? Minor nit: RFC 1997 never uses colon-format. 1998 does. -- Jeff --Apple-Mail=_71DD2284-13C4-497B-9E8B-82A1BD0C2D5D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 5, 2016, at 12:17 PM, Job Snijders <job@ntt.net> = wrote:

The "Textual Representation" section should = provide any implementor with
enough freedom to use a = prefix, suffix, or a separator of their
choosing. Given the current text:
https://github.com/large-bgp-communities/large-bgp-communities/= blob/master/draft-ietf-idr-large-community.xml#L208-L232
should we change the first three "MUST" to a = "SHOULD" to alleviate your
concern?

Minor nit: RFC 1997 never uses colon-format.  1998 = does.

-- = Jeff

= --Apple-Mail=_71DD2284-13C4-497B-9E8B-82A1BD0C2D5D-- From nobody Wed Oct 5 12:24:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0261297F5 for ; Wed, 5 Oct 2016 12:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Vm9y3VIDKqkU for ; Wed, 5 Oct 2016 12:24:24 -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 07CE212981F for ; Wed, 5 Oct 2016 12:24:23 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u95JOLQM042953 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Oct 2016 20:24:21 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <57F55364.3010302@foobar.org> Date: Wed, 05 Oct 2016 20:24:20 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.3 (Macintosh/20160930) MIME-Version: 1.0 To: Jeffrey Haas References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <57F51937.70103@foobar.org> <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> <57F52DC2.40809@foobar.org> <4CA1BEF7-B99D-4F86-A658-AE34420B3AB3@pfrc.org> In-Reply-To: <4CA1BEF7-B99D-4F86-A658-AE34420B3AB3@pfrc.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 19:24:25 -0000 Jeffrey Haas wrote: > Once a security AD digs into the semantics of defined ext-comms and > its impact on forwarding and thinks (erroneously) that the same > blanket consideration may apply to Large, you'll have lost a week of > your life. Keep it simple (syntax/PDU) and clean. yeah, I had to abandon the first two attempts to get the wording right on this one. Nick From nobody Thu Oct 6 10:27:54 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3BA129504 for ; Thu, 6 Oct 2016 10:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 KTEmq3yPaeVD for ; Thu, 6 Oct 2016 10:27:50 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 AE24A1295CD for ; Thu, 6 Oct 2016 10:27:50 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bsCSQ-000FHt-Va (job@us.ntt.net); Thu, 06 Oct 2016 17:27:49 +0000 Date: Thu, 6 Oct 2016 19:27:38 +0200 From: Job Snijders To: Jeffrey Haas Message-ID: <20161006172738.GN20697@Vurt.local> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <57F51937.70103@foobar.org> <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 17:27:52 -0000 Hi Group, Section 3 currently is as following: """ 3. Aggregation If a range of routes is aggregated and the resulting aggregates attribute section does not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have a Large Communities path attribute which contains all of the large communities from all of the aggregated routes. """ Jeff made the following comment: On Wed, Oct 05, 2016 at 11:46:06AM -0400, Jeffrey Haas wrote: > I am also unclear on the semantics of why atomic aggregate impacts > whether merging happens or not. (Please don't make me break out 10+ > year old points as to why AA has been broken from day one.) Are you asking whether the aggregate is a merge/union of the contributors in case the ATOMIC_AGGREGATE is absent? The text was inspired by RFC4360: """ 6. Operations By default if a range of routes is to be aggregated and the resultant aggregates path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an Extended Communities path attribute that contains the set union of all the Extended Communities from all of the aggregated routes. The default behavior could be overridden via local configuration, in which case handling the Extended Communities attribute in the presence of route aggregation becomes a matter of the local policy of the BGP speaker that performs the aggregation. """ Should a variant of this RFC4360 text be included in the Large BGP Communities specification? Or is ATOMIC_AGGREGATE dead and should section 3 just be removed? Kind regards, Job From nobody Thu Oct 6 11:52:34 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64E31293E9 for ; Thu, 6 Oct 2016 11:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 qMgEndlQtalh for ; Thu, 6 Oct 2016 11:52:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DE2401293D8 for ; Thu, 6 Oct 2016 11:52:31 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id B36091E337; Thu, 6 Oct 2016 14:54:20 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: Jeffrey Haas In-Reply-To: <20161006172738.GN20697@Vurt.local> Date: Thu, 6 Oct 2016 14:52:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <270DFAAE-EE0F-4C29-B64C-546A05FC4D37@pfrc.org> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <57F51937.70103@foobar.org> <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> <20161006172738.GN20697@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.2104) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 18:52:33 -0000 > On Oct 6, 2016, at 1:27 PM, Job Snijders wrote: >=20 > On Wed, Oct 05, 2016 at 11:46:06AM -0400, Jeffrey Haas wrote: >> I am also unclear on the semantics of why atomic aggregate impacts >> whether merging happens or not. (Please don't make me break out 10+ >> year old points as to why AA has been broken from day one.) >=20 > Are you asking whether the aggregate is a merge/union of the > contributors in case the ATOMIC_AGGREGATE is absent? >=20 > The text was inspired by RFC4360: >=20 > """ > 6. Operations > >=20 > By default if a range of routes is to be aggregated and the > resultant aggregates path attributes do not carry the > ATOMIC_AGGREGATE attribute, then the resulting aggregate should = have > an Extended Communities path attribute that contains the set union > of all the Extended Communities from all of the aggregated routes. > The default behavior could be overridden via local configuration, = in > which case handling the Extended Communities attribute in the > presence of route aggregation becomes a matter of the local policy > of the BGP speaker that performs the aggregation. > """ >=20 > Should a variant of this RFC4360 text be included in the Large BGP > Communities specification? Or is ATOMIC_AGGREGATE dead and should > section 3 just be removed? To be clear, the above statement is largely fine modulo the = atomic_aggregate comment. I'm even fine with a simple cut and paste with appropriate substitutions = from 4360, but think that at this point atomic_aggregate is largely just = a dead thing. Considering it just complicates matters unnecessarily. -- Jeff From nobody Thu Oct 6 15:26:15 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E4012955B for ; Thu, 6 Oct 2016 15:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 zcQ9yUKkjcNd for ; Thu, 6 Oct 2016 15:26:10 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38D81294A2 for ; Thu, 6 Oct 2016 15:26:09 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u96MQ4aF013417; Thu, 6 Oct 2016 23:26:04 +0100 Received: from 950129200 (dsl-dp-81-140-96-139.in-addr.broadbandscope.com [81.140.96.139]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u96MQ34P013393 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 6 Oct 2016 23:26:03 +0100 From: "Adrian Farrel" To: "'Jakob Heitz \(jheitz\)'" , "'Mamud Hasan'" , References: <9c6e95b9fd6d4f809cc5734eb124dc6f@XCH-ALN-014.cisco.com> In-Reply-To: <9c6e95b9fd6d4f809cc5734eb124dc6f@XCH-ALN-014.cisco.com> Date: Thu, 6 Oct 2016 23:25:58 +0100 Message-ID: <06aa01d22020$9ce43710$d6aca530$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06AB_01D22028.FEAFF210" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFqRVgUGss81iGLvu0UqNA/n1G8UAH1LVbioVwLacA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22622.003 X-TM-AS-Result: No--19.135-10.0-31-10 X-imss-scan-details: No--19.135-10.0-31-10 X-TMASE-MatchedRID: 0lhM5bBmjEMDJrf2+hNOheYAh37ZsBDCC3HuWcgyQCYCgjr7b0ytGbfc 1MMYXJERHb6AXLODRl87QlE0DAcVy4iXsq96MTZ3rQcmzcV8ovzNbZoHWAcdk1mmz7LVVfOpiir SOkBVAQVAS692nLx0luZ8JvlBwtSZAOZWqwY0KQBor4yxPAz7WVsChor7BLiNIbxYwbCxGTSqM9 21CehQfBQYrVgpDiKvF+Rf1CKzofxKDZlLBSf8q/0peXGEEBlvg3XZcphu4ktXG3yI9k2vbIAuO qciU0p01eMp+in9a9PfCoL1Cy7eF/36sqVF/VZoS3OTftLNfg2U9XpVqqLhsPHFoBcOsKeziPsn ePM42N0lrqsYlHhF+jC6IPNP8UWJUeL68LoXEvwFTi5T7nLXai3S35ohUu37krNbLf4aYG5czil UefYvAz+ZqQbT6/3u3rf2hEEVSR5DSkUa9i2162uj3ZVU+M9wlIvcAfYJnEphn/chy3DQzFQ+CF 9xoc5LnE2RogVHfH2sEFKef8ZUxpcqz3g0A4fyupDIC9422DozH3zWWApNw0vAhd4DVNld+kYX4 FVnQud9xQFIjQfO0oYCheGFuxsgL3m5ejCdaFGdCtkMrsOtOpkShYcLpGH9ZM25ZAWwDYZgEEZ9 y/pY4Y0id0pIhqxT15LlVZSTLD2SjpyB+ma+j3uTVkeYosXtOS0bT53qXdU3Rx11yoeUQtuzY75 ozkkrJXN2dBx41HZcSNmWV/ZuF99faxl/I4mhngIgpj8eDcBpkajQR5gb3tZE3xJMmmXcRRgndE tDQrLNceX0dKgFgXIP2BIs91Ks7JeN3XrK2wcQyh0JKMIYvAkrYwrjkf4Y Archived-At: Subject: Re: [Idr] RFC7752 : Decoding clarification of BGP-LS Link Protection Type TLV (1093) for OSPFv2 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 22:26:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06AB_01D22028.FEAFF210 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry that I lost this in the blizzard of emails on large communities. Thanks for stepping up to answer, Jakob. =20 I agree with Jakob that all the relevant link protection type data from = OSPF fits into the field. The extra reserved bytes are simply padding = and can be ignored (unless you are using them as a covert channel ;-) =20 Cheers, Adrian =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz = (jheitz) Sent: 24 September 2016 22:09 To: Mamud Hasan; idr@ietf.org Subject: Re: [Idr] RFC7752 : Decoding clarification of BGP-LS Link = Protection Type TLV (1093) for OSPFv2 =20 It is formatted according to the ISIS formatting, that is 2 octets. You will need to make OSPF conform by truncating the excess octets. =20 Thanks, Jakob. =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Mamud Hasan Sent: Saturday, September 24, 2016 10:12 AM To: idr@ietf.org Subject: [Idr] RFC7752 : Decoding clarification of BGP-LS Link = Protection Type TLV (1093) for OSPFv2 =20 Hi, This is regarding doubt about decoding of BGP-LS "Link Protection Type = TLV (1093)" for carrying OSPFv2 Link Protection Type value. =20 According to this RFC7752, 3.3.2. Link Attribute TLVs Link Attribute TLVs are TLVs that may be encoded in the BGP-LS attribute with a Link NLRI. Each 'Link Attribute' is a Type/Length/ Value (TLV) triplet formatted as defined in Section 3.1. The format and semantics of the Value fields in some Link Attribute TLVs correspond to the format and semantics of the Value fields in IS-IS Extended IS Reachability sub-TLVs, defined in [RFC5305] and [RFC5307]. Other Link Attribute TLVs are defined in this document. Although the encodings for Link Attribute TLVs were originally defined for IS-IS, the TLVs can carry data sourced by either IS-IS or OSPF. =20 BGP-LS Link Protection Type TLV +++++++++++++++++++++++++++++++++++ = +-----------+---------------------+--------------+-----------------------= -------+ | TLV Code | Description | IS-IS TLV | Reference = | | Point | | /Sub-TLV | = (RFC/Section) | = +-----------+---------------------+--------------+-----------------------= --------+ |1093 | Link Protection | 22/20 | [RFC5307]/1.2 = | | | Type | | = | = -------------------------------------------------------------------------= ----------- We can see above that For BGP-LS Link Protection Type (1093), it follows = references of ISIS (RFC 5307) only. But Link Protection decoding for = ISIS and OSPF is not same (as shown below). For OSPFv2 there are extra 3 = octet reserved field. =20 ISIS Link Protection Type Decoding: (rfc5307) +++++++++++++++++++++++++++++++++++ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protection Cap | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 OSPF Link Protection Type Decoding: (rfc4203) +++++++++++++++++++++++++++++++++++ 0 1 2 = 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protection Cap | Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 So my question is, what could be the coding of BGP-LS Link Protection = Type TLV (1093) for OSPFv2 ? Should it consider the extra 3 octet = reserved field and carry these reserved field value in this TLV ? I will be grateful if receive response.=20 =20 Thanks, Mamud ------=_NextPart_000_06AB_01D22028.FEAFF210 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Sorry that I lost this in the = blizzard of emails on large communities.

Thanks for stepping up to = answer, Jakob.

 

I agree with Jakob that all = the relevant link protection type data from OSPF fits into the field. = The extra reserved bytes are simply padding and can be ignored (unless = you are using them as a covert channel ;-)

 

Cheers,

Adrian

 

From: Idr = [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz = (jheitz)
Sent: 24 September 2016 22:09
To: Mamud = Hasan; idr@ietf.org
Subject: Re: [Idr] RFC7752 : Decoding = clarification of BGP-LS Link Protection Type TLV (1093) for = OSPFv2

 

It is formatted according to = the ISIS formatting, that is 2 octets.

You will need to make OSPF = conform by truncating the excess octets.

 

<= p class=3DMsoNormal>Thanks,=

Jakob.<= /p>

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm = 0cm 4.0pt'>

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of = Mamud Hasan
Sent: Saturday, September 24, 2016 10:12 = AM
To: idr@ietf.org
Subject: [Idr] RFC7752 : = Decoding clarification of BGP-LS Link Protection Type TLV (1093) for = OSPFv2

 

Hi,

This is regarding doubt = about decoding of BGP-LS "Link Protection Type TLV (1093)" for = carrying OSPFv2 Link Protection Type value.

 

=

According to this RFC7752,

3.3.2.  Link Attribute TLVs
   Link Attribute TLVs are TLVs that =
may be encoded in the BGP-LS
   attribute with a Link NLRI.  =
Each 'Link Attribute' is a Type/Length/
   Value (TLV) triplet formatted as =
defined in Section 3.1.  The format
   and semantics of the Value fields =
in some Link Attribute TLVs
   correspond to the format and =
semantics of the Value fields in IS-IS
   Extended IS Reachability sub-TLVs, =
defined in [RFC5305] and
   [RFC5307].  Other Link =
Attribute TLVs are defined in this document.
   Although the encodings for Link =
Attribute TLVs were originally
   defined for IS-IS, the TLVs can =
carry data sourced by either IS-IS or
   OSPF.
 
BGP-LS Link Protection Type TLV
+++++++++++++++++++++++++++++++++++
   =
+-----------+---------------------+--------------+-----------------------=
-------+
   |  TLV Code | =
Description         |  =
IS-IS TLV     | =
Reference        =
    |
   |   =
Point       =
|            =
      =
            &=
nbsp;|   /Sub-TLV   | =
(RFC/Section)      |
   =
+-----------+---------------------+--------------+-----------------------=
--------+
   |1093   =
    | Link Protection     =
|    22/20     | =
[RFC5307]/1.2         =
|
   =
|          =
       | =
Type           &nb=
sp;    =
      |      =
            =
  |          =
       =
            &=
nbsp;      |
   =
-------------------------------------------------------------------------=
-----------
We can see above that For BGP-LS Link =
Protection Type (1093), it follows references of ISIS (RFC 5307) =
only. But Link Protection decoding for ISIS and OSPF is not same (as =
shown below). For OSPFv2 there are extra 3 octet reserved =
field.
 
ISIS Link Protection Type Decoding: =
(rfc5307)
+++++++++++++++++++++++++++++++++++
   =
0            =
       1
       0 1 2 3 4 =
5 6 7 8 9 0 1 2 3 4 5
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Protection Cap =
|    Reserved     |
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 OSPF Link Protection Type Decoding: =
(rfc4203)
+++++++++++++++++++++++++++++++++++
   =
  0          =
             =
1            =
            &=
nbsp;        =
2            =
            &=
nbsp;       3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 =
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
span lang=3DEN-US =
style=3D'mso-ansi-language:EN-US'>
   |Protection Cap =
|            =
        =
Reserved           =
;            =
            &=
nbsp;          |
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
span lang=3DEN-US =
style=3D'mso-ansi-language:EN-US'>
 
So my question is, what could be the coding of =
BGP-LS Link Protection Type TLV (1093) for OSPFv2 ? Should it consider =
the extra 3 octet reserved field and carry these reserved field value in =
this TLV ?
I will be grateful if receive response. =

 
Thanks,
Mamud
------=_NextPart_000_06AB_01D22028.FEAFF210-- From nobody Thu Oct 6 21:11:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8948A1293FE for ; Thu, 6 Oct 2016 21:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3izaSyGHZEab for ; Thu, 6 Oct 2016 21:11:03 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72258127ABE for ; Thu, 6 Oct 2016 21:11:02 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id 197so1445914wmk.1 for ; Thu, 06 Oct 2016 21:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HfcJjQRozVnwSuiRtJwzntASjaCp0uFoe89kVWqrIEg=; b=NZUmM4KSdTKfwV1KaFgl/exSeAfqHp/Ehi+GWgOMEPkx7UtJt5e9NWAfkhoEnxeH36 RdUlHGp0ibqz6lHQx+0dwddv7wu5re96jS8ysgSR4ePOfAXUBctJdO5ip6MqqTs7VrQM XXbCYseAolI/QHCZh0HKopKk2lvNcEx/McysswM0q/rIimBDVTgeOztmEYugMsYoR7kU 3+fJZMUAKeqIvbm7g1rwIslMhD9pnRY6e3NjYeaUDpcAy4ZIx1IfWW5/GUh30KZkataw 9xOi8wr+h9BH4cK/xlcGZdfnLM/abCRc9Bm13TAWykuBs4VeeX78dHsfN6Hd3Q0J+oUF 5Y1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HfcJjQRozVnwSuiRtJwzntASjaCp0uFoe89kVWqrIEg=; b=bsVhsBEomot4ElEDc4zwe2zvt9BZ6auDN7TOQJ1sNf4norm2L1NHaZLS4+EJR058eI z6wVHa5N9ddMhsdCOjOqW1FCDgRxhGpCwuqKS7baSvEs1SBNrBFjpNOUaQu1wEgMDEk8 VD3oSrso0rYnLchch+62K6ywwq3vq2y+/ytKiKnFhPAJbM1mzBaTWWq1avtRib/mDhGt HQ16cP3Dg4s53xmUwzhnzhN3YYS/c3/3F3ZArTP//g/dUZMJIhP2E9N22W1mPnJYgtFU xPvOUt0+71N0A6YQ8iALWKnSq9R133BMommm2e0Lx1GPnwbAMFcF1qjld8ibCkGuRwJj h0YQ== X-Gm-Message-State: AA6/9RnRGoDNnlBrY5gtcdaPXnqHpgip8zerkfS0Q3r6UEQxlEaZHR9Q9DITCpNg3mSBfMntkBN/W63fUodUBg== X-Received: by 10.28.207.204 with SMTP id f195mr7584665wmg.29.1475813460925; Thu, 06 Oct 2016 21:11:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.89.167 with HTTP; Thu, 6 Oct 2016 21:11:00 -0700 (PDT) In-Reply-To: <06aa01d22020$9ce43710$d6aca530$@olddog.co.uk> References: <9c6e95b9fd6d4f809cc5734eb124dc6f@XCH-ALN-014.cisco.com> <06aa01d22020$9ce43710$d6aca530$@olddog.co.uk> From: Mamud Hasan Date: Fri, 7 Oct 2016 09:41:00 +0530 Message-ID: To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=94eb2c0d47a617e1dc053e3e9941 Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] RFC7752 : Decoding clarification of BGP-LS Link Protection Type TLV (1093) for OSPFv2 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 04:11:04 -0000 --94eb2c0d47a617e1dc053e3e9941 Content-Type: text/plain; charset=UTF-8 Thanks Jakob, Adrian for clarification. Thanks, Mamud On Fri, Oct 7, 2016 at 3:55 AM, Adrian Farrel wrote: > Sorry that I lost this in the blizzard of emails on large communities. > > Thanks for stepping up to answer, Jakob. > > > > I agree with Jakob that all the relevant link protection type data from > OSPF fits into the field. The extra reserved bytes are simply padding and > can be ignored (unless you are using them as a covert channel ;-) > > > > Cheers, > > Adrian > > > > *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Jakob Heitz > (jheitz) > *Sent:* 24 September 2016 22:09 > *To:* Mamud Hasan; idr@ietf.org > *Subject:* Re: [Idr] RFC7752 : Decoding clarification of BGP-LS Link > Protection Type TLV (1093) for OSPFv2 > > > > It is formatted according to the ISIS formatting, that is 2 octets. > > You will need to make OSPF conform by truncating the excess octets. > > > > Thanks, > > Jakob. > > > > *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Mamud Hasan > *Sent:* Saturday, September 24, 2016 10:12 AM > *To:* idr@ietf.org > *Subject:* [Idr] RFC7752 : Decoding clarification of BGP-LS Link > Protection Type TLV (1093) for OSPFv2 > > > > Hi, > > This is regarding doubt about decoding of BGP-LS "Link Protection Type > TLV (1093)" for carrying OSPFv2 Link Protection Type value. > > > > *According to this RFC7752,* > > 3.3.2. Link Attribute TLVs > > Link Attribute TLVs are TLVs that may be encoded in the BGP-LS > > attribute with a Link NLRI. Each 'Link Attribute' is a Type/Length/ > > Value (TLV) triplet formatted as defined in Section 3.1. The format > > and semantics of the Value fields in some Link Attribute TLVs > > correspond to the format and semantics of the Value fields in IS-IS > > Extended IS Reachability sub-TLVs, defined in [RFC5305] and > > [RFC5307]. *Other Link Attribute TLVs are defined in this document.* > > * Although the encodings for Link Attribute TLVs were originally* > > * defined for IS-IS, the TLVs can carry data sourced by either IS-IS or* > > * OSPF.* > > > > BGP-LS Link Protection Type TLV > > +++++++++++++++++++++++++++++++++++ > > +-----------+---------------------+--------------+------------------------------+ > > | TLV Code | Description | IS-IS TLV | Reference | > > | Point | | /Sub-TLV | (RFC/Section) | > > +-----------+---------------------+--------------+-------------------------------+ > > |1093 | Link Protection | 22/20 | [RFC5307]/1.2 | > > | | Type | | | > > ------------------------------------------------------------------------------------ > > We can see above that For BGP-LS Link Protection Type (1093), it follows references of *ISIS (RFC 5307) only*. But Link Protection decoding for ISIS and OSPF is not same (as shown below). For OSPFv2 there are extra 3 octet reserved field. > > > > ISIS Link Protection Type Decoding: (rfc5307) > > +++++++++++++++++++++++++++++++++++ > > 0 1 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Protection Cap | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > OSPF Link Protection Type Decoding: (rfc4203) > > +++++++++++++++++++++++++++++++++++ > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Protection Cap | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > So my question is, what could be the coding of BGP-LS Link Protection Type TLV (1093) for OSPFv2 ? Should it consider the extra 3 octet reserved field and carry these reserved field value in this TLV ? > > I will be grateful if receive response. > > > > Thanks, > > Mamud > > --94eb2c0d47a617e1dc053e3e9941 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Jakob, Adrian for clarification.


Thanks,
Mamud


On Fri, Oct 7, 2016 at= 3:55 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Sorry that I lost this in the blizzard of = emails on large communities.

Thanks for stepping up to answer, Jakob.=

= =C2=A0

I= agree with Jakob that all the relevant link protection type data from OSPF= fits into the field. The extra reserved bytes are simply padding and can b= e ignored (unless you are using them as a covert channel ;-)<= /span>

=C2=A0

Cheers,

Ad= rian

=C2=A0

From: Idr [mailto:id= r-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz)
Sent= : 24 September 2016 22:09
To: Mamud Hasan; idr@ietf.org
Subject: Re: [Id= r] RFC7752 : Decoding clarification of BGP-LS Link Protection Type TLV (109= 3) for OSPFv2

=C2=A0

It is for= matted according to the ISIS formatting, that is 2 octets.

You will need to make OSPF conform by truncating the excess oc= tets.

=C2=A0

Thanks,

Jakob.

=C2=A0

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Mamud Hasan
Sent: Saturday, September 24, 2016 10:12 AM
To: idr@ietf.org
Subject: [= Idr] RFC7752 : Decoding clarification of BGP-LS Link Protection Type TLV (1= 093) for OSPFv2

= =C2=A0

Hi,

This is regarding=C2=A0doubt about decoding of BGP-LS "Link Pro= tection Type TLV (1093)" for carrying OSPFv2 Link Protection Type valu= e.

=C2=A0

According to = this RFC7752,

=C2=A0=C2=A0 Link Attribute TLVs are TLVs that may be encode=
d in the BGP-LS
=C2=
=A0=C2=A0 attribute with a Link NLRI.=C2=A0 Each 'Link Attribute' i=
s a Type/Length/
=C2= =A0=C2=A0 Value (TLV) triplet formatted as defined in Section 3.1.=C2=A0 Th= e format
=C2=A0=C2=
=A0 and semantics of the Value fields in some Link Attribute TLVs
=C2=A0=C2=A0 correspond to th=
e format and semantics of the Value fields in IS-IS
=C2=A0=C2=A0 Extended IS Reachability sub-T=
LVs, defined in [RFC5305] and
=C2=A0=C2=A0 [RFC5307].=C2=A0 Other Link Attribute TLVs are de=
fined in this document.
=C2=A0=C2=A0 Although the encodings for Link Attribute TLVs were=
 originally
=
=C2=A0=C2=A0 defined for IS-IS, the TLVs can carry data sourced by either I=
S-IS or
 =C2=
=A0=C2=A0OSPF.
= =C2=A0
BGP-LS Link P=
rotection Type TLV
+= ++++++++++++++++++++++++++++++++++<= u>
=C2=A0=C2=A0 +-----------+---------------------+--=
------------+------------------------------+
=C2=A0=C2=A0 |=C2=A0 TLV Code | Description=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 IS-IS TLV=C2=A0=C2=
=A0=C2=A0=C2=A0 | Reference=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=
=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0 |=C2=A0=C2=A0 Point=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0 /Sub-TLV=C2=A0=C2=A0 | (RFC/=
Section)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=

=C2=A0=C2=A0 +-----------+---------------------+-=
-------------+-------------------------------+
=C2=A0=C2=A0 |1093=C2=A0=C2=A0 =C2=A0=C2=A0=
=C2=A0=C2=A0| Link Protection=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 2=
2/20=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC5307]/1.2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |
=

=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| Type=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0|=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0|=

=C2=A0=C2=A0 ------------------------------------------------------------------------------------
We can see above that For BGP-LS=
 Link Protection Type (1093), it follows references of ISIS (RFC 5307) o=
nly. But Link Protection decoding for ISIS and OSPF is not same (as sho=
wn below). For OSPFv2 there are extra 3 octet reserved field.
=C2=A0
ISIS Link Protection Type Decoding: (rfc5307)=

+++++++++++++++++++=
++++++++++++++++
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 1 =
2 3 4 5 6 7 8 9 0 1 2 3 4 5
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |Protection Cap |=C2=A0=C2=A0=C2=A0 Reserved=C2=A0=C2=A0=C2=
=A0=C2=A0 |
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0
=C2=A0OSPF Link Protection Type Decoding: (r=
fc4203)
++++++++++++=
+++++++++++++++++++++++
=C2=A0=C2=A0 =C2=A0=C2=A00=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 2=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 3
=

=C2=A0=C2=A0=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7=
 8 9 0 1
=C2=A0=C2=
=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+
=C2=A0=C2=A0 |P=
rotection Cap |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reserved=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 |<=
/u>
=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+
=
=C2=A0
So my question is, what could be the coding of B=
GP-LS Link Protection Type TLV (1093) for OSPFv2 ? Should it consider the e=
xtra 3 octet reserved field and carry these reserved field value in this TL=
V ?
I will be gratef=
ul if receive response. 
=C2=A0<=
u>
Thanks,
Mamud
<= /div>

--94eb2c0d47a617e1dc053e3e9941-- From nobody Fri Oct 7 03:29:04 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0B81294E2 for ; Fri, 7 Oct 2016 03:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 FX59bIwKIvTt for ; Fri, 7 Oct 2016 03:29:00 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0097.outbound.protection.outlook.com [104.47.2.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361391294B1 for ; Fri, 7 Oct 2016 03:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pI8LaomWzRQ6Dk+WQbqRpQSq97DcQqUjHnBUHr9q13E=; b=SnuIgL9I63KPUTpuqYsKmWe653fgFMnI6RoPwuZSY1+Qg/2I6jPWCXvUcPTPffSVgD+NcWu7Kfq/NoVhseVQnLUoJKQ/GMf2FnmhVU1evnTOUU4VtJ08TqkLzKi5qqBLjQDDMH76TbOuyvhEMk98/Gw9eebrcOuq3yJ9sTUuLsY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by DB6PR0701MB2999.eurprd07.prod.outlook.com (10.168.84.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Fri, 7 Oct 2016 10:28:57 +0000 Message-ID: <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> From: t.petch To: Nick Hilliard , Job Snijders References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> Date: Fri, 7 Oct 2016 11:26:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: AM4PR0902CA0021.eurprd09.prod.outlook.com (10.171.89.31) To DB6PR0701MB2999.eurprd07.prod.outlook.com (10.168.84.137) X-MS-Office365-Filtering-Correlation-Id: 814bdd5b-6751-4339-9c7a-08d3ee9cbf49 X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 2:bDWEbfzvBA1XE5PaHjKtUwJEc4D1BTJJBx3L9WcQUho7xij0U2Cl+TaEQwY03uUmEpGHi9CXUsGCDeFc4mP8hvxmoiWM8qYHUQzXSnxFAypGef3cZJfhXxMMdtNNxnBIkFog7IHn7z0QG5jH9CaYy3PE5PPiYQGbz2MmPuRQFuTXgVaiO3JkGl55ykz5W28STtZRcGiaGw6biV+6wXcFaw==; 3:ZoF9CwZsJ6hHo9SJ4GpLTpjluL7QHBRbE+JyEhBiQE0GEm8F3Col3ewg81h+6AlI/wucwrF0X9ZMS8MRO5A7xJ1lW4jVxXidlE+30P5uL8U87/JRrs4Cq2dY1G/muQlcIBasliODc6rMgmuElhiQEg==; 25:k0ZlV7q+zDYIYe+MUbvVr21EpPtTcZ2qnwGbYlS4XJ6lp/uuuhho+qFZyQpzeL4/i+IfYYcKmWemi5wJ/u097RFuk63bMAca0DT4tYa3VhGXeArGykE528JCKtMgEn/riZVb2qX8+YM31WglAoYMUGILXVF5J+n+165iCVzW+U+jfppQimK0IP3YkRIKsOvJ8XrqVnaV4MjbQlrUDNYmYSFBanJ31G7O+lbqx4zRE8o51Lrpbxd4DYhV0J24ipK1VScpJxa82ps15GPO3lCducXWPVD71TzCBpOBZyj538t4Qq3oA7QKfu0RvxVUiycfNvt7k9TcBieqwSW3yFLv1Ckwa4CijJ/IgwlZRfujlZQitza7ll337kI2O5Ole55DZQS4/KMNzk4TururTnmxpfgHDku9o6iDApJqd4oCIiL28b92bqzylMygss1mILdf X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0701MB2999; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 31:nWjl8tfG0c2wzfWwhG1y56o1j2mUWjOTvhcyhA4Dao8t1Fpa8EkDUcGOoY5Amaqj3v2MqxIW15WjibOK/xyia8Ar9kYikcu/e7st5QbXSmD73JMmmnekPwaRILTtSY//vQnIMfj8fNpc55BD7joeVuxw8XEzdzeZ9mqM82IOK0ofq0vETBQta3vuSj13C0q95JHYkqqkDaOhx1q/W2IC2eNjBFVRCwjwHCAt6kG7wKw2amXc8JFi8VY0KqP0fYd1AdvXkHug5Xes4CgT2iLyBQ==; 4:I0jL69cmmta1CYu/TTMTf38qkBp9r7N5uS1EAi656fCtZbQZFHWrzak0Sz9rf8Gnrj7Ky48RdgWN/TWXUC1hkZUziJw0H76nXe8vZpcq8n+wrSc5TdOwRHNn4Xzql+QyQaoAdgMvF6DwdoUwSbgQIoGZeTBzifFMf34ZYdCFDot2ebtOap/E3vOMjiBUkUoevW/6chX+3U0GstjDvDLf0f69JhRJe1FOJK+oNxIORogqbUiltuOQN4jQOVno2EPHNrFXNF6X0Vgxv9zYK+DO//IKSoAPBhOpV7amy3tjVxvAkCTiEdb/J2+pUxU+7Dbjtp8Ep82Z7MkuP3Mxo+Zw3mRJVK2Yy+HuMRwR36AdOeGKhl6M9ZcjIAJQ+3Kdg+FjfmTena9l+aMfE8MXvan2k0AXpzHP6LO8DMKQKRuJFpBs1n0BIm74AZRWo3Q4AOeUEdogLtt455f0jUkfJ+8mDA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB6PR0701MB2999; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2999; X-Forefront-PRVS: 0088C92887 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(199003)(377454003)(24454002)(13464003)(50226002)(23676002)(105586002)(5001770100001)(81156014)(81166006)(8676002)(6666003)(66066001)(42186005)(68736007)(101416001)(33646002)(47776003)(62236002)(14496001)(97736004)(44716002)(5660300001)(61296003)(9686002)(1456003)(44736004)(19580395003)(19580405001)(76176999)(7846002)(50986999)(7736002)(6116002)(3846002)(81686999)(81816999)(586003)(305945005)(86362001)(230783001)(92566002)(1556002)(77096005)(230700001)(4720700003)(2906002)(93886004)(116806002)(4326007)(50466002)(84392002)(189998001)(106356001)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2999; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjI5OTk7MjM6UDFxcUk4dGUzVkU5K08yc2FOZmRBSUto?= =?utf-8?B?bUozWFVCMXJUKzRBRkZhUllmeTZyVndUVUZndmVZRzR5aVlnSVptY0VPVyt6?= =?utf-8?B?STdHclU2ai9HU215ZzB3QnlsUENwaGVZc0toU3FNVXVZdWNrdkJmU2FQL3kz?= =?utf-8?B?WEtKZUdaZndRWnhhaGp1RzA3RGR3ekVtcGdudmNNR0dEbmZFZUt2M255T1g0?= =?utf-8?B?R2hkM2Y0TjJiakowaE5qYW5ZdW9wdFJkWDBROUlFNDNWUjBKUDM1ck9ZMjNQ?= =?utf-8?B?WmZQQ3R3YXV0RkhBWGh0Q3JEK2diSVllak03V1VZd1REUzdtTGZDMmVhQmM2?= =?utf-8?B?Yk9UUW00bjB0RGNjVGFna1VMcGY1dFl3a0hITDFiY24wVm55VGpaekhaWEUv?= =?utf-8?B?Y29mekcxdWZlTjdaeUh5VFExb05ES2twV1pVaE9wZnBnYkMyQ1JuTkliNEMz?= =?utf-8?B?YVU2WmxxMXRNSzJyNnh0d1NHcEI3bm05Sks3Ymp4bzZlWEtJaGVRem1SUVVk?= =?utf-8?B?OGo4NUVZa3Y3b2FNdERtQWpvL3RlWGpadVFSQm9hVFJuN2tKUVhWNHFpeTFj?= =?utf-8?B?aEY4SUZ1eWxYS1JRSDZqbjZjOU83dVRXaXFyb0IrRElRWXAzS1d0Njl3aFUy?= =?utf-8?B?MVpZRFBNaHJSZG1iRjU1L0dpbUhjQ3NSWEZZbDcxOEprLzJMdjRiL3BaV2xI?= =?utf-8?B?RkcyYzVyeGdFMmJKa3VLa2tDdHV4bjlaWVFUelZtRDlZbkN0NnlISnVWdU5v?= =?utf-8?B?NVZTVFVwaFM0UDJUQ0xMQWY3YlhsbzFBaUhmKzRSNVUvNEIvSmgwb3ZjUklx?= =?utf-8?B?Njhtbngya0l5bmlwbnNBZExiRGVITmN0UDc4WWkrSVF0Q2RLVjVXSHk1bXQy?= =?utf-8?B?b2RXcGhhdjdHQmwxYnZZbk1RbW05NWpmME95ZExRY0djV1lwMnVpUTY0SE5X?= =?utf-8?B?a1RZQm13YWVtc1pZUjM3dEoxUkVHajcvMVhHRFlncWJCM0swb09qR3dudEZE?= =?utf-8?B?VHY4bkFvb3lRNnFTazBOV3FSREVaci9TSXR5US9iZ3RDbzd1WGNpcnF0VDJt?= =?utf-8?B?K2JUb0V3OWUvOHNGQXQ1MXExUEpkWEdCMXM2K01GL1YwRHo4TU03eDlqOE9Z?= =?utf-8?B?d3EvbVgvdWt5bm0raUFiSy9wU3NPQ1FoM0R1YktrQnFjb0NEcDNuOGZJSVR6?= =?utf-8?B?cldkWWk5VGVCaDhjNGRGUUFMN2drU1ROYzhlUExvTDZONmpreFBOS0lpelBY?= =?utf-8?B?UVRYNlp1WHlJZUNvWFExQVVzUG1NdkdIUlhRY1BtQzhiaVNiSGlUMG0zR29R?= =?utf-8?B?K0llVGFSTWZJRGszRkR4bENCa2w2R1A5V2RFTDZ2djNJa3ZJZ0kxZ2JUL0JG?= =?utf-8?B?RXZGb3JIZGxlUTdQajRPeEpqRWdJUGRESWJwMVpqVXM3Um9tVEZka0hEUklE?= =?utf-8?B?QncxS01ac08vUGo2UVF0MjFsTGJaZ0ZiY3lBME80VXRZcUNvb1A2dTZQSERz?= =?utf-8?B?SXRkdHdjWXVreXo3TVllK3dobFJPMFgzUW5RQ2FJNHdsZkthaUhFOE04ZHg2?= =?utf-8?B?SW55RzZ4ZmdOaWdtWUU1bkxMMWlyV1AzZDlRSnNvczA3RXFJODF4a1BkdVFx?= =?utf-8?B?T0Z0UnVvUWdRNTdQQ3B3TlQvNmREMXJoZjQwMDluSE55ZEtnR1ZmUis1Znha?= =?utf-8?B?SGwydDVyMjlld0xtWW5iaDRoYTVFVEhadis2ZkJUcTVnZDZneVBWSWoxVHVs?= =?utf-8?B?SUc3azd4VHdpeUdxZldISS9nZVV4di9kNE5qcTMxeEI1M3ZKS2p5dnE4UHYw?= =?utf-8?B?djdKSVJHZTlvaURpRDY4TEJhTllKbmY3Q2hvajk4b3ZKeThjTDR5TTlpY21s?= =?utf-8?B?MDN2S0k3dTNadzVlUElhYmRrWFVTTWRja2xLU3hEa3BOR3F1UVpHSlIyTzF0?= =?utf-8?B?V1UyT0s2cmVjRzRKT0F5eUZJR1pmeldGK1BlTHZEL1JLbmxXcDNQaGNUNjg3?= =?utf-8?Q?iHtszdCa?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 6:vXQGFrUmqEoTcDUMnjhO8gU1Yx9LzmGaFSgkK2ycBkgGGawsCKRuW7SdPZDuxBH3JpeuuMY48zo1BaQS9q/Rgnlu/wY/iaF8VKNgU/8J7p/05WwFkO4yccst9TxBVXI/2TSnALn+Gp4gatQ96Iuj0gwyIZSAMUz0wFCMxkTtZni6qD+Dr4hXh0oG3IjHN83HDVb1zIKz6EKP1Ug8RZPecemMGGfviD9metizR6e2OmTcVQMh28d+f7+jSftUwaSZUQAL3YxNi69M9va+0MQ5yWzSzTUXVjynlIE5XPb2zkWR9r5Kt2yIXfxyfNxEanzb; 5:T/701TqolpeVQF9AViJAUY5ffOIuNwQ7XSsuqzy5h0H2BY2odmzCh8aXgt2QHSS4gUrTsIhqyohaTcKOYDw1kznmL6t1zcAmie5CPXW/dUMV/dch+Ttx8RFXUllNLs/B6WouB+HQ8FI7QqbhIoEobMmjavOUaE8TXmJJrVe5Eew=; 24:eDXhmJpF+tlZ6vqLDR9SW/OSUH4zwrz22/waOotoUzlFYfZ1JMOJWZhUalbPtM9aqXBk2bltaS95Up5PaOS5s3ydm57UaN6O3wFTg0OyILs=; 7:XZ0pN89/2/ueSHIyspQeUVT693FP3xhEIzmbkhNFpn0ikTE6ghddX5mOd7SFZ+ZY4zVJp9gD3I5SlBTZjROuiq9Mmsy4uB/m3poxD6ME2N8h1wRFuSQd00mNVlutznRF4evozklCS9APlOx8dJhIQX903ePJn9ovCDvlsTcTjFfTin7tESe3AzPREmdBQ4oXamMlsBIVvP8EWJTUWIl3aFz14TTGecqlZzRKhZwpTvxMCE5pYxJ3zmjUOfIrSN4ajhKQUh/OqMIeFdiNeg1CTdWkgqjbMX84AO84rvloMzBdNWo4bqG1YjNP0X8hPJ/ZYX+SnaSagNmGoWQs4WoqOw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2016 10:28:57.7410 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2999 Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 10:29:03 -0000 ----- Original Message ----- From: "Nick Hilliard" To: "Job Snijders" Cc: "t.petch" ; Sent: Monday, October 03, 2016 4:46 PM > Job Snijders wrote: > > "For Autonomous System numbers which can be encoded as a 2-octet > > value, the two high-order octets of the Global Administrator field > > are set to zero." > > > > Do you have a better suggested sentence? The above feels like a kludge. > > I don't understand why this is necessary. > > This is a global administrator field, i.e. it's not guaranteed that it's > an ASN, so there can be no protocol level assumption that any number > configured to fit in there should be treated any differently to any > other number, even if that number incidentally happens to be the same as > the ASN configured on the device. Nick It is a global administrator field:-) That is, it defines a namespace within which the following data can be interpreted. If the value is not unique, as ASN are, then the following data cannot be reliably interpreted and we are letting loose we do not know what on the Internet. A case study of how not to do this is MPLS which took a very narrow view of its namespace which has led to a lot of subsequent work in order to get round it, for example depending on the bit patterns of IP Version numbers, and other possible first nibbles. If MPLS had thought further ahead, and nailed down its namespaces, then a lot of effort would have been obviated. Communities are not quite as important as MPLS but I still have a concern, that if we allow anything into that first field, then we are creating an untenable situation some time in the future. Note RFC1997 says ' The rest of the community attribute values shall be encoded using an autonomous system number in the first two octets. ' Today, I think we would /shall/MUST/ Here, I would go for 'MUST be an ASN' (or else the community should not be transitive:-) Tom Petch > Secondly, the field is 32 bits wide, so if you have a number between 0 > and 65535, there is exactly one way of fitting that number into a a 32 > bit placeholder in network byte order. This is why big endian encoding > works so well on the wire, and little-endian is terribly broken. > > The text would be better if this were left out completely. > > Nick From nobody Fri Oct 7 04:48:22 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDA412956F for ; Fri, 7 Oct 2016 04:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RyqNLuz-VH5F for ; Fri, 7 Oct 2016 04:48:19 -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 9C1291294D0 for ; Fri, 7 Oct 2016 04:48:19 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u97BmEJa012652 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Oct 2016 12:48:14 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <57F78B7D.609@foobar.org> Date: Fri, 07 Oct 2016 12:48:13 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.3 (Macintosh/20160930) MIME-Version: 1.0 To: "t.petch" References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> In-Reply-To: <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 11:48:21 -0000 Tom, t.petch wrote: > Here, I would go for 'MUST be an ASN' (or else the community should not > be transitive:-) Every 32 bit number is an ASN, so there's an argument to say that this is a tautology. I don't think it's either viable or necessary to narrow down the text to specify that the global administrator field MUST be the ASN of the operator who assigns the community to the prefix. The reason for this is that if large communities are used for inter-as signaling, operators should only act at the edge router when the global administrator field matches the peer-as, and if they need to interpret the community tag further inside the network, they should use a translation layer to map the semantics to a locally significant community (i.e. the same as what we do for rfc1997 communities). For intra-as signaling, it doesn't matter because it's local semantics only. Either way, there is no compelling reason that this should be a MUST and good reasons (e.g. operator discretion) that it shouldn't. Nick From nobody Fri Oct 7 07:00:05 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6CA1295F5 for ; Fri, 7 Oct 2016 06:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.516 X-Spam-Level: X-Spam-Status: No, score=-17.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 FKKdRCHO7RzC for ; Fri, 7 Oct 2016 06:59:53 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3CE1295EB for ; Fri, 7 Oct 2016 06:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=65535; q=dns/txt; s=iport; t=1475848789; x=1477058389; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ngpHwSp/k+tQ/THGGmaR6jbeC2iY+f1g/lG5rb0XTTQ=; b=YtHSMi6WTsaIm59ET5cru8oQUnJy0zbrLioggjjzpgJtGvDCwUbqNP1j xsB+juoLFSk+0+al51AuSum/31iUyptr8o87aTP/I5VuxnbndiE+zui7M A9bzbLSeA2On5IzZbC2A9/i9RXW0BFPuj3gAs8+IbbXD+5uMcTIg913l1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAQABqvdX/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgwc2AQEBAQEeV3wHjSyXAIdYjFSCC4YgAhyBYTgUAQIBAQEBAQE?= =?us-ascii?q?BXieEYQEBAQQjClwCAQgRAwEBASEBBgMCAgIfBQwUCQgCBAERAYg2AxezAIkHD?= =?us-ascii?q?YNeAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYsRgTyBC4IXCRaCToJbBYg7YosIhSU?= =?us-ascii?q?1AYxygwiPdIhjhBSDfgEeNhoxgmgQDxmBOnKHD4EAAQEB?= X-IronPort-AV: E=Sophos;i="5.31,308,1473120000"; d="scan'208,217";a="332935782" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Oct 2016 13:59:48 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u97DxmWR020555 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Oct 2016 13:59:48 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Oct 2016 09:59:47 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 7 Oct 2016 09:59:47 -0400 From: "Acee Lindem (acee)" To: "adrian@olddog.co.uk" , "Jakob Heitz (jheitz)" , "'Mamud Hasan'" , "idr@ietf.org" Thread-Topic: [Idr] RFC7752 : Decoding clarification of BGP-LS Link Protection Type TLV (1093) for OSPFv2 Thread-Index: AQHSFobQofnMASCZJE2PqHSE7pDtN6CJZcaAgBLxcwCAAI+LAA== Date: Fri, 7 Oct 2016 13:59:47 +0000 Message-ID: References: <9c6e95b9fd6d4f809cc5734eb124dc6f@XCH-ALN-014.cisco.com> <06aa01d22020$9ce43710$d6aca530$@olddog.co.uk> In-Reply-To: <06aa01d22020$9ce43710$d6aca530$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.76.45] Content-Type: multipart/alternative; boundary="_000_D41CF7F381D76aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] RFC7752 : Decoding clarification of BGP-LS Link Protection Type TLV (1093) for OSPFv2 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 13:59:55 -0000 --_000_D41CF7F381D76aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIG9mIHRoZSBvYmplY3RpdmVzIG9mIEJHUC1MUyBpcyB0byBwcm92aWRlIGEgbm9ybWFsaXpl ZCByZXByZXNlbnRhdGlvbiBvZiB0aGUgSUdQIGxpbmstc3RhdGUgaW5mb3JtYXRpb24gaW5kZXBl bmRlbnQgb2Ygd2hldGhlciB0aGUgb3JpZ2luIGlzIE9TUEYgb3IgSVMtSVMuIEZvciB0aGUgbW9z dCBwYXJ0LCB3ZeKAmXZlIHN1Y2NlZWRlZC4NClRoYW5rcywNCkFjZWUNCg0KRnJvbTogSWRyIDxp ZHItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhh bGYgb2YgQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9s ZGRvZy5jby51az4+DQpSZXBseS1UbzogQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51 azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4+DQpEYXRlOiBUaHVyc2RheSwgT2N0b2JlciA2 LCAyMDE2IGF0IDM6MjUgUE0NClRvOiAiSmFrb2IgSGVpdHogKGpoZWl0eikiIDxqaGVpdHpAY2lz Y28uY29tPG1haWx0bzpqaGVpdHpAY2lzY28uY29tPj4sICdNYW11ZCBIYXNhbicgPG1hbXVkLmhh c2FuQGdtYWlsLmNvbTxtYWlsdG86bWFtdWQuaGFzYW5AZ21haWwuY29tPj4sIElEUiBMaXN0IDxp ZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0lkcl0gUkZD Nzc1MiA6IERlY29kaW5nIGNsYXJpZmljYXRpb24gb2YgQkdQLUxTIExpbmsgUHJvdGVjdGlvbiBU eXBlIFRMViAoMTA5MykgZm9yIE9TUEZ2Mg0KDQpTb3JyeSB0aGF0IEkgbG9zdCB0aGlzIGluIHRo ZSBibGl6emFyZCBvZiBlbWFpbHMgb24gbGFyZ2UgY29tbXVuaXRpZXMuDQpUaGFua3MgZm9yIHN0 ZXBwaW5nIHVwIHRvIGFuc3dlciwgSmFrb2IuDQoNCkkgYWdyZWUgd2l0aCBKYWtvYiB0aGF0IGFs bCB0aGUgcmVsZXZhbnQgbGluayBwcm90ZWN0aW9uIHR5cGUgZGF0YSBmcm9tIE9TUEYgZml0cyBp bnRvIHRoZSBmaWVsZC4gVGhlIGV4dHJhIHJlc2VydmVkIGJ5dGVzIGFyZSBzaW1wbHkgcGFkZGlu ZyBhbmQgY2FuIGJlIGlnbm9yZWQgKHVubGVzcyB5b3UgYXJlIHVzaW5nIHRoZW0gYXMgYSBjb3Zl cnQgY2hhbm5lbCA7LSkNCg0KQ2hlZXJzLA0KQWRyaWFuDQoNCkZyb206IElkciBbbWFpbHRvOmlk ci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFrb2IgSGVpdHogKGpoZWl0eikNClNl bnQ6IDI0IFNlcHRlbWJlciAyMDE2IDIyOjA5DQpUbzogTWFtdWQgSGFzYW47IGlkckBpZXRmLm9y ZzxtYWlsdG86aWRyQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJZHJdIFJGQzc3NTIgOiBEZWNv ZGluZyBjbGFyaWZpY2F0aW9uIG9mIEJHUC1MUyBMaW5rIFByb3RlY3Rpb24gVHlwZSBUTFYgKDEw OTMpIGZvciBPU1BGdjINCg0KSXQgaXMgZm9ybWF0dGVkIGFjY29yZGluZyB0byB0aGUgSVNJUyBm b3JtYXR0aW5nLCB0aGF0IGlzIDIgb2N0ZXRzLg0KWW91IHdpbGwgbmVlZCB0byBtYWtlIE9TUEYg Y29uZm9ybSBieSB0cnVuY2F0aW5nIHRoZSBleGNlc3Mgb2N0ZXRzLg0KDQpUaGFua3MsDQpKYWtv Yi4NCg0KRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNYW11ZCBIYXNhbg0KU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAyNCwgMjAxNiAxMDoxMiBB TQ0KVG86IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPg0KU3ViamVjdDogW0lkcl0g UkZDNzc1MiA6IERlY29kaW5nIGNsYXJpZmljYXRpb24gb2YgQkdQLUxTIExpbmsgUHJvdGVjdGlv biBUeXBlIFRMViAoMTA5MykgZm9yIE9TUEZ2Mg0KDQpIaSwNClRoaXMgaXMgcmVnYXJkaW5nIGRv dWJ0IGFib3V0IGRlY29kaW5nIG9mIEJHUC1MUyAiTGluayBQcm90ZWN0aW9uIFR5cGUgVExWICgx MDkzKSIgZm9yIGNhcnJ5aW5nIE9TUEZ2MiBMaW5rIFByb3RlY3Rpb24gVHlwZSB2YWx1ZS4NCg0K QWNjb3JkaW5nIHRvIHRoaXMgUkZDNzc1MiwNCg0KMy4zLjIuICBMaW5rIEF0dHJpYnV0ZSBUTFZz DQoNCiAgIExpbmsgQXR0cmlidXRlIFRMVnMgYXJlIFRMVnMgdGhhdCBtYXkgYmUgZW5jb2RlZCBp biB0aGUgQkdQLUxTDQoNCiAgIGF0dHJpYnV0ZSB3aXRoIGEgTGluayBOTFJJLiAgRWFjaCAnTGlu ayBBdHRyaWJ1dGUnIGlzIGEgVHlwZS9MZW5ndGgvDQoNCiAgIFZhbHVlIChUTFYpIHRyaXBsZXQg Zm9ybWF0dGVkIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjEuICBUaGUgZm9ybWF0DQoNCiAgIGFu ZCBzZW1hbnRpY3Mgb2YgdGhlIFZhbHVlIGZpZWxkcyBpbiBzb21lIExpbmsgQXR0cmlidXRlIFRM VnMNCg0KICAgY29ycmVzcG9uZCB0byB0aGUgZm9ybWF0IGFuZCBzZW1hbnRpY3Mgb2YgdGhlIFZh bHVlIGZpZWxkcyBpbiBJUy1JUw0KDQogICBFeHRlbmRlZCBJUyBSZWFjaGFiaWxpdHkgc3ViLVRM VnMsIGRlZmluZWQgaW4gW1JGQzUzMDVdIGFuZA0KDQogICBbUkZDNTMwN10uICBPdGhlciBMaW5r IEF0dHJpYnV0ZSBUTFZzIGFyZSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgIEFsdGhv dWdoIHRoZSBlbmNvZGluZ3MgZm9yIExpbmsgQXR0cmlidXRlIFRMVnMgd2VyZSBvcmlnaW5hbGx5 DQoNCiAgIGRlZmluZWQgZm9yIElTLUlTLCB0aGUgVExWcyBjYW4gY2FycnkgZGF0YSBzb3VyY2Vk IGJ5IGVpdGhlciBJUy1JUyBvcg0KDQogICBPU1BGLg0KDQoNCg0KQkdQLUxTIExpbmsgUHJvdGVj dGlvbiBUeXBlIFRMVg0KDQorKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KDQog ICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgfCAgVExWIENvZGUgfCBEZXNjcmlwdGlv biAgICAgICAgIHwgIElTLUlTIFRMViAgICAgfCBSZWZlcmVuY2UgICAgICAgICAgICB8DQoNCiAg IHwgICBQb2ludCAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAvU3Vi LVRMViAgIHwgKFJGQy9TZWN0aW9uKSAgICAgIHwNCg0KICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KDQogICB8MTA5MyAgICAgICB8IExpbmsgUHJvdGVjdGlvbiAgICAgfCAgICAyMi8yMCAg ICAgfCBbUkZDNTMwN10vMS4yICAgICAgICAgfA0KDQogICB8ICAgICAgICAgICAgICAgICB8IFR5 cGUgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCldlIGNhbiBzZWUgYWJvdmUgdGhhdCBGb3IgQkdQLUxTIExpbmsgUHJvdGVjdGlvbiBU eXBlICgxMDkzKSwgaXQgZm9sbG93cyByZWZlcmVuY2VzIG9mIElTSVMgKFJGQyA1MzA3KSBvbmx5 LiBCdXQgTGluayBQcm90ZWN0aW9uIGRlY29kaW5nIGZvciBJU0lTIGFuZCBPU1BGIGlzIG5vdCBz YW1lIChhcyBzaG93biBiZWxvdykuIEZvciBPU1BGdjIgdGhlcmUgYXJlIGV4dHJhIDMgb2N0ZXQg cmVzZXJ2ZWQgZmllbGQuDQoNCg0KDQpJU0lTIExpbmsgUHJvdGVjdGlvbiBUeXBlIERlY29kaW5n OiAocmZjNTMwNykNCg0KKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCg0KICAg MCAgICAgICAgICAgICAgICAgICAxDQoNCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1DQoNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAg ICB8UHJvdGVjdGlvbiBDYXAgfCAgICBSZXNlcnZlZCAgICAgfA0KDQogICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KDQoNCiBPU1BGIExpbmsgUHJvdGVjdGlvbiBUeXBl IERlY29kaW5nOiAocmZjNDIwMykNCg0KKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysNCg0KICAgICAwICAgICAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMw0KDQogICAgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxDQoNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQoNCiAgIHxQcm90ZWN0aW9uIENhcCB8ICAgICAgICAgICAgICAg ICAgICBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQoNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQoNCg0KDQpTbyBteSBxdWVzdGlvbiBpcywgd2hhdCBjb3VsZCBi ZSB0aGUgY29kaW5nIG9mIEJHUC1MUyBMaW5rIFByb3RlY3Rpb24gVHlwZSBUTFYgKDEwOTMpIGZv ciBPU1BGdjIgPyBTaG91bGQgaXQgY29uc2lkZXIgdGhlIGV4dHJhIDMgb2N0ZXQgcmVzZXJ2ZWQg ZmllbGQgYW5kIGNhcnJ5IHRoZXNlIHJlc2VydmVkIGZpZWxkIHZhbHVlIGluIHRoaXMgVExWID8N Cg0KSSB3aWxsIGJlIGdyYXRlZnVsIGlmIHJlY2VpdmUgcmVzcG9uc2UuDQoNCg0KDQpUaGFua3Ms DQoNCk1hbXVkDQo= --_000_D41CF7F381D76aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <66ED10E86BB49F48BF78EB19453A15CF@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5PbmUgb2YgdGhl IG9iamVjdGl2ZXMgb2YgQkdQLUxTIGlzIHRvIHByb3ZpZGUgYSBub3JtYWxpemVkIHJlcHJlc2Vu dGF0aW9uIG9mIHRoZSBJR1AgbGluay1zdGF0ZSBpbmZvcm1hdGlvbiBpbmRlcGVuZGVudCBvZiB3 aGV0aGVyIHRoZSBvcmlnaW4gaXMgT1NQRiBvciBJUy1JUy4gRm9yIHRoZSBtb3N0IHBhcnQsIHdl 4oCZdmUgc3VjY2VlZGVkLiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFj ZWUmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEx cHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBu b25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJ TkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0 IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+SWRyICZsdDs8YSBocmVm PSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmciPmlkci1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDsgb24gYmVoYWxmIG9mIEFkcmlhbiBGYXJyZWwgJmx0OzxhIGhyZWY9Im1haWx0bzphZHJpYW5A b2xkZG9nLmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+UmVwbHktVG86IDwvc3Bhbj5BZHJpYW4gRmFycmVsICZsdDs8 YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayI+YWRyaWFuQG9sZGRvZy5jby51azwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5U aHVyc2RheSwgT2N0b2JlciA2LCAyMDE2IGF0IDM6MjUgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDtKYWtvYiBIZWl0eiAoamhlaXR6KSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoZWl0ekBjaXNjby5jb20iPmpoZWl0ekBjaXNjby5jb208 L2E+Jmd0OywgJ01hbXVkIEhhc2FuJyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hbXVkLmhhc2FuQGdt YWlsLmNvbSI+bWFtdWQuaGFzYW5AZ21haWwuY29tPC9hPiZndDssIElEUiBMaXN0ICZsdDs8YSBo cmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtJZHJdIFJGQzc3 NTIgOiBEZWNvZGluZyBjbGFyaWZpY2F0aW9uIG9mIEJHUC1MUyBMaW5rIFByb3RlY3Rpb24gVHlw ZSBUTFYgKDEwOTMpIGZvciBPU1BGdjI8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9 IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAg MCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHht bG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0i dXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3 dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJQcm9nSWQiIGNvbnRlbnQ9Ildv cmQuRG9jdW1lbnQiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQg V29yZCAxNCI+DQo8bWV0YSBuYW1lPSJPcmlnaW5hdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29y ZCAxNCI+DQo8bGluayByZWw9IkZpbGUtTGlzdCIgaHJlZj0iY2lkOmZpbGVsaXN0LnhtbEAwMUQy MjAyOC5GM0VDNUM2MCI+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpPZmZpY2VEb2N1bWVu dFNldHRpbmdzPg0KPG86QWxsb3dQTkcvPg0KPC9vOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3OldvcmREb2N1bWVu dD4NCjx3OlNwZWxsaW5nU3RhdGU+Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3OlRyYWNrTW92 ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRl QWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJ bnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVu dD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNl aG9sZGVyVGV4dD4NCjx3OkRvTm90UHJvbW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tR0I8 L3c6TGlkVGhlbWVPdGhlcj4NCjx3OkxpZFRoZW1lQXNpYW4+WC1OT05FPC93OkxpZFRoZW1lQXNp YW4+DQo8dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+WC1OT05FPC93OkxpZFRoZW1lQ29tcGxleFNj cmlwdD4NCjx3OkNvbXBhdGliaWxpdHk+DQo8dzpEb05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCjx3 OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQo8dzpTcGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8dzpF bmFibGVPcGVuVHlwZUtlcm5pbmcvPg0KPC93OkNvbXBhdGliaWxpdHk+DQo8bTptYXRoUHI+DQo8 bTptYXRoRm9udCBtOnZhbD0iQ2FtYnJpYSBNYXRoIi8+DQo8bTpicmtCaW4gbTp2YWw9ImJlZm9y ZSIvPg0KPG06YnJrQmluU3ViIG06dmFsPSImIzQ1Oy0iLz4NCjxtOnNtYWxsRnJhYyBtOnZhbD0i b2ZmIi8+DQo8bTpkaXNwRGVmLz4NCjxtOmxNYXJnaW4gbTp2YWw9IjAiLz4NCjxtOnJNYXJnaW4g bTp2YWw9IjAiLz4NCjxtOmRlZkpjIG06dmFsPSJjZW50ZXJHcm91cCIvPg0KPG06d3JhcEluZGVu dCBtOnZhbD0iMTQ0MCIvPg0KPG06aW50TGltIG06dmFsPSJzdWJTdXAiLz4NCjxtOm5hcnlMaW0g bTp2YWw9InVuZE92ciIvPg0KPC9tOm1hdGhQcj48L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8dzpMYXRlbnRTdHlsZXMgRGVmTG9j a2VkU3RhdGU9ImZhbHNlIiBEZWZVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgRGVmU2VtaUhpZGRlbj0i dHJ1ZSIgRGVmUUZvcm1hdD0iZmFsc2UiIERlZlByaW9yaXR5PSI5OSIgTGF0ZW50U3R5bGVDb3Vu dD0iMjY3Ij4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMCIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iTm9ybWFsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijki IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUi IE5hbWU9ImhlYWRpbmcgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu ZyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3Jt YXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDgiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA5 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM1IiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJjYXB0aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjEwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJUaXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIxIiBOYW1lPSJEZWZhdWx0IFBhcmFncmFwaCBGb250Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjExIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0aXRsZSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMiIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3Ryb25n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIwIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJF bXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1OSIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iVGFibGUgR3Jp ZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJMaWdodCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gU2hhZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gU2hhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g R3JpZCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3Jp ZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlJldmlzaW9uIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJMaXN0IFBhcmFncmFwaCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyOSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iUXVv dGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzAiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9 IkludGVuc2UgUXVvdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBMaXN0IDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2Nl bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGlu ZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQg TGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGln aHQgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQg MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBB Y2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0 IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAx IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g TGlzdCAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gR3JpZCAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNj ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3Qg QWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdy aWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50 IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hh ZGluZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2Nl bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3Qg MiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IEdyaWQgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2Vu dCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA2Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcg QWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVs IExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNv bG9yZnVsIEdyaWQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMTkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFG b3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBFbXBoYXNpcyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIFJl ZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMiIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIg TmFtZT0iSW50ZW5zZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IFFGb3JtYXQ9InRydWUiIE5hbWU9IkJvb2sgVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzciIE5hbWU9IkJpYmxpb2dyYXBoeSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i VE9DIEhlYWRpbmciLz4NCjwvdzpMYXRlbnRTdHlsZXM+DQo8L3htbD48IVtlbmRpZl0tLT48c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0Ow0KCW1zby1mb250LWNo YXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1waXRj aDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxMDczNzg2MTExIDEg MCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMt Zm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQt c2lnbmF0dXJlOi01MjAwODE2NjUgLTEwNzM3MTcxNTcgNDEgMCA2NjA0NyAwO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5Om1vZGVy bjsNCgltc28tZm9udC1waXRjaDpmaXhlZDsNCgltc28tZm9udC1zaWduYXR1cmU6LTUyMDA5Mjky OSAxMDczODA2NTkxIDkgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJMdWNp ZGEgQ29uc29sZSI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNCA1IDQgMiAyIDQ7DQoJbXNvLWZvbnQt Y2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5Om1vZGVybjsNCgltc28tZm9udC1w aXRjaDpmaXhlZDsNCgltc28tZm9udC1zaWduYXR1cmU6LTIxNDc0ODI5OTMgNjE0NCAwIDAgMzEg MDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0 OnllczsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2 M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xl O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtbm9z aG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxl LWxvY2tlZDp5ZXM7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNv LWhhbnNpLWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNvbnNv bGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCW1z by1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglt c28taGFuc2ktZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWls eToiQ291cmllciBOZXciOw0KCWNvbG9yOiM3MDMwQTA7DQoJbXNvLXRleHQtYW5pbWF0aW9uOm5v bmU7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVj b3JhdGlvbjpub25lOw0KCXRleHQtdW5kZXJsaW5lOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5v bmU7DQoJdGV4dC1saW5lLXRocm91Z2g6bm9uZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28t c3R5bGUtdW5oaWRlOm5vOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJbXNvLWJpZGkt Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlNwZWxs RQ0KCXttc28tc3R5bGUtbmFtZToiIjsNCgltc28tc3BsLWU6eWVzO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsN Cglmb250LXNpemU6MTAuMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJbXNvLWJp ZGktZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDsNCgltc28taGVh ZGVyLW1hcmdpbjozNi4wcHQ7DQoJbXNvLWZvb3Rlci1tYXJnaW46MzYuMHB0Ow0KCW1zby1wYXBl ci1zb3VyY2U6MDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDEwXT48c3R5bGU+LyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwi Ow0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6 MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGNtIDUuNHB0IDBjbSA1LjRwdDsN Cgltc28tcGFyYS1tYXJnaW46MGNtOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgbGFu Zz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0idGFiLWludGVy dmFsOjM2LjBwdCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+U29ycnkgdGhhdCBJIGxvc3Qg dGhpcyBpbiB0aGUgYmxpenphcmQgb2YgZW1haWxzIG9uIGxhcmdlIGNvbW11bml0aWVzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiPlRoYW5rcyBmb3Igc3RlcHBpbmcgdXAgdG8gYW5zd2VyLCBKYWtvYi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5JIGFncmVlIHdp dGggSmFrb2IgdGhhdCBhbGwgdGhlIHJlbGV2YW50IGxpbmsgcHJvdGVjdGlvbiB0eXBlIGRhdGEg ZnJvbSBPU1BGIGZpdHMgaW50byB0aGUgZmllbGQuIFRoZSBleHRyYSByZXNlcnZlZCBieXRlcyBh cmUgc2ltcGx5IHBhZGRpbmcgYW5kDQogY2FuIGJlIGlnbm9yZWQgKHVubGVzcyB5b3UgYXJlIHVz aW5nIHRoZW0gYXMgYSBjb3ZlcnQgY2hhbm5lbCA7LSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+QWRyaWFu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRh aG9tYSwgc2Fucy1zZXJpZjsiPiBJZHIgWzxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRm Lm9yZyI+bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+SmFrb2IgSGVpdHogKGpoZWl0eik8YnI+DQo8Yj5TZW50OjwvYj4gMjQgU2VwdGVtYmVyIDIw MTYgMjI6MDk8YnI+DQo8Yj5Ubzo8L2I+IE1hbXVkIEhhc2FuOyA8YSBocmVmPSJtYWlsdG86aWRy QGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWRy XSBSRkM3NzUyIDogRGVjb2RpbmcgY2xhcmlmaWNhdGlvbiBvZiBCR1AtTFMgTGluayBQcm90ZWN0 aW9uIFR5cGUgVExWICgxMDkzKSBmb3IgT1NQRnYyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMDttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+SXQgaXMg Zm9ybWF0dGVkIGFjY29yZGluZyB0byB0aGUgSVNJUyBmb3JtYXR0aW5nLCB0aGF0IGlzIDIgb2N0 ZXRzLjwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTA7bXNvLWFu c2ktbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwO21zby1hbnNpLWxhbmd1 YWdlOkVOLVVTIj5Zb3Ugd2lsbCBuZWVkIHRvIG1ha2UgT1NQRiBjb25mb3JtIGJ5IHRydW5jYXRp bmcgdGhlIGV4Y2VzcyBvY3RldHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTA7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOiM3MDMwQTA7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjojNzAzMEEwO21zby1hbnNpLWxh bmd1YWdlOkVOLVVTIj5KYWtvYi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMDttc28tYW5zaS1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyI+IElkciBbPGEgaHJlZj0ibWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnIj5t YWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYW11 ZCBIYXNhbjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgU2VwdGVtYmVyIDI0LCAyMDE2IDEw OjEyIEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtJZHJdIFJGQzc3NTIgOiBEZWNvZGlu ZyBjbGFyaWZpY2F0aW9uIG9mIEJHUC1MUyBMaW5rIFByb3RlY3Rpb24gVHlwZSBUTFYgKDEwOTMp IGZvciBPU1BGdjI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4t VVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj5UaGlz IGlzIHJlZ2FyZGluZyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdDttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+ZG91YnQgYWJvdXQgZGVjb2Rpbmcg b2YgQkdQLUxTICZxdW90O0xpbmsgUHJvdGVjdGlvbiBUeXBlIFRMViAoMTA5MykmcXVvdDsgZm9y IGNhcnJ5aW5nIE9TUEZ2MiBMaW5rIFByb3RlY3Rpb24NCiBUeXBlIHZhbHVlLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5BY2NvcmRpbmcgdG8gdGhpcyBSRkM3NzUyLDwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpw cmUtd3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4zLjMuMi4mbmJzcDsg TGluayBBdHRyaWJ1dGUgVExWczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1h bnNpLWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsi PiZuYnNwOyZuYnNwOyBMaW5rIEF0dHJpYnV0ZSBUTFZzIGFyZSBUTFZzIHRoYXQgbWF5IGJlIGVu Y29kZWQgaW4gdGhlIEJHUC1MUzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1h bnNpLWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsi PiZuYnNwOyZuYnNwOyBhdHRyaWJ1dGUgd2l0aCBhIExpbmsgTkxSSS4mbmJzcDsgRWFjaCAnTGlu ayBBdHRyaWJ1dGUnIGlzIGEgVHlwZS9MZW5ndGgvPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IGJsYWNrOyI+Jm5ic3A7Jm5ic3A7IFZhbHVlIChUTFYpIHRyaXBsZXQgZm9ybWF0dGVkIGFz IGRlZmluZWQgaW4gU2VjdGlvbiAzLjEuJm5ic3A7IFRoZSBmb3JtYXQ8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDsmbmJzcDsgYW5kIHNlbWFudGljcyBvZiB0aGUg VmFsdWUgZmllbGRzIGluIHNvbWUgTGluayBBdHRyaWJ1dGUgVExWczwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiBibGFjazsiPiZuYnNwOyZuYnNwOyBjb3JyZXNwb25kIHRvIHRoZSBmb3Jt YXQgYW5kIHNlbWFudGljcyBvZiB0aGUgVmFsdWUgZmllbGRzIGluIElTLUlTPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7Jm5ic3A7IEV4dGVuZGVkIElTIFJlYWNo YWJpbGl0eSBzdWItVExWcywgZGVmaW5lZCBpbiBbUkZDNTMwNV0gYW5kPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7Jm5ic3A7IFtSRkM1MzA3XS4mbmJzcDsgPGI+ T3RoZXIgTGluayBBdHRyaWJ1dGUgVExWcyBhcmUgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Ljwv Yj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUt d3JhcCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDsmbmJzcDsg QWx0aG91Z2ggdGhlIGVuY29kaW5ncyBmb3IgTGluayBBdHRyaWJ1dGUgVExWcyB3ZXJlIG9yaWdp bmFsbHk8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3Bh Y2U6cHJlLXdyYXAiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7 Jm5ic3A7IGRlZmluZWQgZm9yIElTLUlTLCB0aGUgVExWcyBjYW4gY2FycnkgZGF0YSBzb3VyY2Vk IGJ5IGVpdGhlciBJUy1JUyBvcjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog YmxhY2s7Ij4gJm5ic3A7Jm5ic3A7T1NQRi48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IGJsYWNrOyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWFu c2ktbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+ QkdQLUxTIExpbmsgUHJvdGVjdGlvbiBUeXBlIFRMVjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiBibGFjazsiPiYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQz OyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0Mzsm IzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0 MzsmIzQzOyYjNDM7JiM0Mzs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5z aS1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3 aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4m bmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0 MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3Jh cCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDsmbmJzcDsgfCZuYnNw OyBUTFYgQ29kZSB8IERlc2NyaXB0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgSVMtSVMgVExWJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgUmVmZXJlbmNlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxh Y2s7Ij4mbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyBQb2ludCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsgL1N1Yi1UTFYmbmJzcDsm bmJzcDsgfCAoUkZDL1NlY3Rpb24pJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDsmbmJzcDsgJiM0MzstLS0t LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7Jm5ic3A7IHwxMDkzJm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3wgTGluayBQcm90ZWN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsgMjIvMjAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBbUkZD NTMwN10vMS4yJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUt d3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8IFR5cGUmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7fCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7fDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiBibGFjazsiPiZuYnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3Jh cCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5XZSBjYW4gc2VlIGFib3ZlIHRo YXQgRm9yIEJHUC1MUyBMaW5rIFByb3RlY3Rpb24gVHlwZSAoMTA5MyksIGl0IGZvbGxvd3MgcmVm ZXJlbmNlcyBvZiA8Yj5JU0lTIChSRkMgNTMwNykgb25seTwvYj4uIEJ1dCBMaW5rIFByb3RlY3Rp b24gZGVjb2RpbmcgZm9yIElTSVMgYW5kIE9TUEYgaXMgbm90IHNhbWUgKGFzIHNob3duIGJlbG93 KS4gRm9yIE9TUEZ2MiB0aGVyZSBhcmUgZXh0cmEgMyBvY3RldCByZXNlcnZlZCBmaWVsZC48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5JU0lTIExpbmsgUHJvdGVjdGlvbiBUeXBlIERlY29kaW5n OiAocmZjNTMwNyk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5n dWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1z cGFjZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mIzQzOyYj NDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQz OyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0Mzsm IzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7Jm5ic3A7IDAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxQcm90 ZWN0aW9uIENhcCB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlc2VydmVkJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFj ZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0Mzs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFj ZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDtPU1BGIExpbmsgUHJvdGVj dGlvbiBUeXBlIERlY29kaW5nOiAocmZjNDIwMyk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogYmxhY2s7Ij4mIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0Mzsm IzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0 MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7JiM0MzsmIzQzOyYjNDM7 JiM0MzsmIzQzOyYjNDM7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0id2hp dGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOzAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1hbnNp LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Indo aXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZu YnNwOyZuYnNwOyZuYnNwOyAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxh Y2s7Ij4mbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDsmbmJzcDsgfFByb3RlY3Rpb24gQ2FwIHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg UmVzZXJ2ZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7IHw8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0Mzs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5n dWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1z cGFjZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0 ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5TbyBt eSBxdWVzdGlvbiBpcywgd2hhdCBjb3VsZCBiZSB0aGUgY29kaW5nIG9mIEJHUC1MUyBMaW5rIFBy b3RlY3Rpb24gVHlwZSBUTFYgKDEwOTMpIGZvciBPU1BGdjIgPyBTaG91bGQgaXQgY29uc2lkZXIg dGhlIGV4dHJhIDMgb2N0ZXQgcmVzZXJ2ZWQgZmllbGQgYW5kIGNhcnJ5IHRoZXNlIHJlc2VydmVk IGZpZWxkIHZhbHVlIGluIHRoaXMgVExWID88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog YmxhY2s7Ij5JIHdpbGwgYmUgZ3JhdGVmdWwgaWYgcmVjZWl2ZSByZXNwb25zZS4gPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+VGhhbmtzLDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiBibGFjazsiPk1hbXVkPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D41CF7F381D76aceeciscocom_-- From nobody Fri Oct 7 09:24:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AD2129503 for ; Fri, 7 Oct 2016 09:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 BBeHgOhsHbYT for ; Fri, 7 Oct 2016 09:24:18 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD8212966D for ; Fri, 7 Oct 2016 09:24:13 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 921007BCEF; Fri, 7 Oct 2016 16:24:12 +0000 (UTC) Date: Fri, 7 Oct 2016 16:24:12 +0000 From: heasley To: Nick Hilliard Message-ID: <20161007162412.GB97455@shrubbery.net> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57F78B7D.609@foobar.org> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 16:24:20 -0000 Fri, Oct 07, 2016 at 12:48:13PM +0100, Nick Hilliard: > Tom, > > t.petch wrote: > > Here, I would go for 'MUST be an ASN' (or else the community should not > > be transitive:-) > > Every 32 bit number is an ASN, so there's an argument to say that this > is a tautology. > > I don't think it's either viable or necessary to narrow down the text to > specify that the global administrator field MUST be the ASN of the > operator who assigns the community to the prefix. Agreed. From nobody Fri Oct 7 12:12:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448601293DA for ; Fri, 7 Oct 2016 12:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 gXyyswhXpOfp for ; Fri, 7 Oct 2016 12:12:47 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC319120726 for ; Fri, 7 Oct 2016 12:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2313; q=dns/txt; s=iport; t=1475867567; x=1477077167; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JNz372C4CubzNlr7pvA84GcORG5NeMhviOFwqYytgzo=; b=SZvRjlizxl4/4Beb3g+PvrNiWa+quJ0d13Z/JRUhW1BAs1C2GAtX0Trc 06fh5Dd5ySAjnqvHcQsZfSa1PsBKT0Gj8seasxdYPKSeA4xk8iDalaupb JY+MzAMW2Ye86Dk39AUZ0S4Sid084wiqr+jZ/TZYEtdRQdWSExamPyuKY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQCy8vdX/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz0BAQEBAR5XfI0zln+PbIRAggsbC4V6AoF/OBQBAgEBAQEBAQF?= =?us-ascii?q?eJ4RhAQEBAwEBAQE3NAsFCwIBCA4KHhAnCyUCBA4FFIg0CA7AEQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhjyBfQiCUIRHgzCCLwWZfwGPeoFuhGeJH0mMLoN+AR4?= =?us-ascii?q?2S4RacogPAQEB?= X-IronPort-AV: E=Sophos;i="5.31,456,1473120000"; d="scan'208";a="332302591" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Oct 2016 19:12:46 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u97JCksp015113 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Oct 2016 19:12:47 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Oct 2016 14:12:46 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 7 Oct 2016 14:12:46 -0500 From: "Jakob Heitz (jheitz)" To: Jeffrey Haas Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt: ATOMIC_AGGREGATE Thread-Index: AQHSIM7JN5p85q2qcUWkgR/CNwQ73w== Date: Fri, 7 Oct 2016 19:12:46 +0000 Message-ID: <50F55580-2892-485F-9369-E7F2DF23E1C2@cisco.com> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <57F51937.70103@foobar.org> <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> <20161006172738.GN20697@Vurt.local>, <270DFAAE-EE0F-4C29-B64C-546A05FC4D37@pfrc.org> In-Reply-To: <270DFAAE-EE0F-4C29-B64C-546A05FC4D37@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt: ATOMIC_AGGREGATE X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 19:12:49 -0000 I took the ATOMIC_AGGREGATE text from RFC1997. ATOMIC_AGGREGATE means that = information was lost. In that case, you are free to put whatever communitie= s you want. I can remove the ATOMIC_AGGREGATE text, such that the aggregati= on SHOULD be done in the specified way even when ATOMIC_AGGREGATE is presen= t. Any objections? Thanks, Jakob. > On Oct 6, 2016, at 11:52 AM, Jeffrey Haas wrote: >=20 >=20 >> On Oct 6, 2016, at 1:27 PM, Job Snijders wrote: >>=20 >> On Wed, Oct 05, 2016 at 11:46:06AM -0400, Jeffrey Haas wrote: >>> I am also unclear on the semantics of why atomic aggregate impacts >>> whether merging happens or not. (Please don't make me break out 10+ >>> year old points as to why AA has been broken from day one.) >>=20 >> Are you asking whether the aggregate is a merge/union of the >> contributors in case the ATOMIC_AGGREGATE is absent? >>=20 >> The text was inspired by RFC4360: >>=20 >> """ >> 6. Operations >> >>=20 >> By default if a range of routes is to be aggregated and the >> resultant aggregates path attributes do not carry the >> ATOMIC_AGGREGATE attribute, then the resulting aggregate should have >> an Extended Communities path attribute that contains the set union >> of all the Extended Communities from all of the aggregated routes. >> The default behavior could be overridden via local configuration, in >> which case handling the Extended Communities attribute in the >> presence of route aggregation becomes a matter of the local policy >> of the BGP speaker that performs the aggregation. >> """ >>=20 >> Should a variant of this RFC4360 text be included in the Large BGP >> Communities specification? Or is ATOMIC_AGGREGATE dead and should >> section 3 just be removed? >=20 > To be clear, the above statement is largely fine modulo the atomic_aggreg= ate comment. >=20 > I'm even fine with a simple cut and paste with appropriate substitutions = from 4360, but think that at this point atomic_aggregate is largely just a = dead thing. Considering it just complicates matters unnecessarily. >=20 > -- Jeff >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Oct 7 14:37:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C764D129430 for ; Fri, 7 Oct 2016 14:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WGyvEj5SmA2h for ; Fri, 7 Oct 2016 14:37:04 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1C7128B37 for ; Fri, 7 Oct 2016 14:37:03 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id qn10so23682790pac.2 for ; Fri, 07 Oct 2016 14:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7iog1G4RzBuFFuTENe2dPfjf57j5/JGUHSZHW/408OI=; b=UHAPJnlhe/9vlobxJ8IHTZFlDYEmpWUDEMm7YLbTIxvljduucGp/b7D8SCoChlGmxj YJTg2DyFx7R5XNDgHucuj9kcEOcG/04h/uVG6jKPYtom5EQpSMRMipdswyhNag9nILOo H9Xj/xSbYN05uMZygrS2tSAH2fN9T9LI3enWPUYT/BNeRGvLB3b7Vf+GdX+fC70dlM9A EiTNP5XKCsOsU8QkPeonglEWl14K0dw/CBp0GyJa9L46TzYRrkMeYPXErTheITnUHDvu TD8Tb4DNO95SgAHUt6cX3W/xI0mPVXYzqrCI3gNhoBoO0/LQ1oTXsYvOOG8paq56aKFc xc0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7iog1G4RzBuFFuTENe2dPfjf57j5/JGUHSZHW/408OI=; b=NLy2IOyjhIQ1X49lCwh3dhqwr2PYs/Im44ViG9l4BLCRF6pjX/1Fhh1PovFryyz9FB 3Yqn9ts35YMZFMciXNQmODMUB2JcI1VMXMOEkJZhcxn74tWU30Eu3gqOmD2IObF8N3ma 3S6+luKWG8I8ys2Lcy7AWHyBAl12hMGM3ev+nLBSEjbuurY0Dw27jjxaHF3kBIP1o4NZ w2HCdyGGTntmkjr6XwXBh/9jOZ/yLH+crgGUUOdYVEPJt3pxuEny+h7EWno0CHeuc7aB Xbmo8vvJwahrBiP7s0rrkljTiJ0q/Zph7+KIVZ908DlxJcP7ZDX+y66umAFKk3SG3/J2 +xxw== X-Gm-Message-State: AA6/9RnxLFtnMmXL13jFtXpaxnHQuPQFfcxHioL9ipWoldz0d+NmkGYJ7SWiZ+ITIvgWnQ== X-Received: by 10.66.72.103 with SMTP id c7mr33189178pav.15.1475876222853; Fri, 07 Oct 2016 14:37:02 -0700 (PDT) Received: from ?IPv6:2001:569:72b9:1f00:3088:faf:b0af:5d3b? (node-1w7jr9qj3jdopj7r2x2bo16wr.ipv6.telus.net. [2001:569:72b9:1f00:3088:faf:b0af:5d3b]) by smtp.gmail.com with ESMTPSA id b129sm16296034pfg.36.2016.10.07.14.37.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Oct 2016 14:37:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (14A456) In-Reply-To: <57F78B7D.609@foobar.org> Date: Fri, 7 Oct 2016 14:37:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> To: Nick Hilliard Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 21:37:06 -0000 Sent from my iPhone > On Oct 7, 2016, at 4:48 AM, Nick Hilliard wrote: >=20 > Tom, >=20 > t.petch wrote: >> Here, I would go for 'MUST be an ASN' (or else the community should not >> be transitive:-) >=20 > Every 32 bit number is an ASN, so there's an argument to say that this > is a tautology. Let us leave the straw man alone, please. :-) >=20 > I don't think it's either viable or necessary to narrow down the text to > specify that the global administrator field MUST be the ASN of the > operator who assigns the community to the prefix. >=20 > The reason for this is that if large communities are used for inter-as > signaling, operators should only act at the edge router when the global > administrator field matches the peer-as, and if they need to interpret > the community tag further inside the network, they should use a > translation layer to map the semantics to a locally significant > community (i.e. the same as what we do for rfc1997 communities). No. You are making the erroneous assertion that the way you think these communit= ies should be used, is the only correct way or the only common way they shou= ld be (or will be) used. For 1997 communities (both the year as well as the RFC), inter-as was not li= mited to adjacent ASNs. This is why large needs to be transitive as well as globally unique for the g= lobal administrator - i.e. ASN. > For > intra-as signaling, it doesn't matter because it's local semantics only. > Either way, there is no compelling reason that this should be a MUST > and good reasons (e.g. operator discretion) that it shouldn't. Local semantics are fully supported by use of (agreed upon) private ASNs. Those are also consistent with the strong assertion of MUST, as well as both= the letter and intent of what is meant by ASN. Is there anything you envision in use of large communities that cannot be su= pported by use of ASNs and private ASNs? I can't see anything that would not= fit into those two use cases. Brian= From nobody Sat Oct 8 02:25:02 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68561296C2 for ; Sat, 8 Oct 2016 02:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 t-zzaQiTogds for ; Sat, 8 Oct 2016 02:24:59 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21C61296C6 for ; Sat, 8 Oct 2016 02:24:58 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id k125so70377072wma.1 for ; Sat, 08 Oct 2016 02:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Qr2RHaofFWg6jSm06zQPxItvddoTptdJR0oAmXUm9yg=; b=x2HhHZfdIc2+8OJCCluVLTvrpBkeM64Oww+KpquwqhWRnl3fqhKy9ywlrj0ABq19lH Ez+Ti6XZwL64EZlcAj4Y0csf4Sy3Oqoq+5d/7vBf/FADbVHha1iuplB3ni+cuu1ALv/M 6fLN0I5yKvExJf3EDaGwI+Q2FSPLd7qtndeh066ZSBk57z/V3TKnEVCRCqPuXwVP+ye2 2hMvLFZDI/gl1pNEsIdLm2I22wFn5OOy0XEkhPWIK5ZyuBMv6aNcmes5VskRnt5mjpoe bSyOY6THz56SIJ/JG1B+yLprOcUiQw52/+ooeNovpF5OVp+TDSyzDzWPYRAdyGhplyys 0qMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Qr2RHaofFWg6jSm06zQPxItvddoTptdJR0oAmXUm9yg=; b=eTXVHlbpM7f7g8R2rOHHHnzY8i3rFFLaOqZTBURp8yqsI9rGRDk9vHzCy5PbnBXS7Q y3zkYnD+cHAMkAXvLXerQAeCWTzgwD0KzBhtsxd6AvuluNaftlvZA08y2nJ0aUx/kyug FoNF7hCC6fmpX3KbH/TRiDCe2a2j3+G6P/xwKgG5LscHN4Q6arqHi3fhswVsASH6A62F G/tuups+bxw2yRLxJZuy5THOgJV686SZWdvDS9JOIcsxUBo0bOhhoIvTecySL6+OKXQB TA21pHwjBs2HHuBnwZyAvMF4h6oQP9qPrOII2FboOFZCyGKov0WFi9QdYlgHy/v2cp3U ZMcA== X-Gm-Message-State: AA6/9Rk28GiAcnS1Moj1z3r3WSFhfcImIvDb2NXaFQzaA8rofTbO7oYSEC4ajuTpN16iig== X-Received: by 10.28.148.18 with SMTP id w18mr2618712wmd.108.1475918697194; Sat, 08 Oct 2016 02:24:57 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:558c:fd3f:dad9:a30a]) by smtp.gmail.com with ESMTPSA id vh6sm24155651wjb.0.2016.10.08.02.24.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Oct 2016 02:24:53 -0700 (PDT) Date: Sat, 8 Oct 2016 11:24:53 +0200 From: Job Snijders To: Jeffrey Haas Message-ID: <20161008092453.GL89179@Vurt.local> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <57F51937.70103@foobar.org> <4C5E4C28-E26F-44C3-A661-514328180F6E@pfrc.org> <20161005161741.GY20697@Vurt.local> <87D04902-FD4A-4400-AC9C-4D1CA85AFE6C@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87D04902-FD4A-4400-AC9C-4D1CA85AFE6C@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 09:25:00 -0000 On Wed, Oct 05, 2016 at 02:15:15PM -0400, Jeffrey Haas wrote: > > On Oct 5, 2016, at 12:17 PM, Job Snijders wrote: > > The "Textual Representation" section should provide any implementor > > with enough freedom to use a prefix, suffix, or a separator of their > > choosing. > > Minor nit: RFC 1997 never uses colon-format. 1998 does. Hi Jeff, RFC 1997 defines BGP Communities, which is the intended reference here. Kind regards, Job From nobody Sat Oct 8 09:35:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D55E1294FD for ; Sat, 8 Oct 2016 09:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bNAPm4uzyeDC for ; Sat, 8 Oct 2016 09:35:20 -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 2C86D1288B8 for ; Sat, 8 Oct 2016 09:35:19 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u98GZGTC065189 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Oct 2016 17:35:16 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <57F92043.20301@foobar.org> Date: Sat, 08 Oct 2016 17:35:15 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.3 (Macintosh/20160930) MIME-Version: 1.0 To: Brian Dickson References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> In-Reply-To: <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 16:35:22 -0000 Brian Dickson wrote: > Is there anything you envision in use of large communities that > cannot be supported by use of ASNs and private ASNs? I can't see > anything that would not fit into those two use cases. There are plenty of situations where the semantics of what you're suggesting would be troublesome to define, for example, confederations, asn translation or asn migration, leading to cases where there would be multiple asns being legitimate on a single router. And even if these cases could be cleared up easily, what happens when someone injects a prefix tagged with a community which isn't the same as their ASN? You're then stuck with the situation where you're defining one thing as a MUST in the semantic specification section of the rfc, while down in the Security Considerations section, it's going to need to be admitted that there's no guarantee whatsoever that the global administrator field in the large community was actually set by the ASN which announced the prefix. Worse still, once it's been changed, there is no practical way for a neighbor to detect this change, as s-bgp isn't a thing. Realistically, vendors are going to implement ways of modifying the field in exactly the same way as rfc1997 communities can be set to anything at all at any policy specification point in a bgp-enabled network. Nick From nobody Sat Oct 8 10:38:24 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415B4129466 for ; Sat, 8 Oct 2016 10:38:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 k2ZyC9-oxPH4 for ; Sat, 8 Oct 2016 10:38:19 -0700 (PDT) Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83DF61295EB for ; Sat, 8 Oct 2016 10:38:17 -0700 (PDT) X-Footer: aTNkLm5s Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for idr@ietf.org; Sat, 8 Oct 2016 19:38:11 +0200 To: idr@ietf.org References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> From: "i3D.net - Martijn Schmidt" X-Enigmail-Draft-Status: N1110 Message-ID: <57F92EF4.1000308@i3d.net> Date: Sat, 8 Oct 2016 19:37:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <57F92043.20301@foobar.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 17:38:22 -0000 Let's say I am AS49544 and I need to transmit a prepend instruction to AS2914, I would add 2914:3320:2 or 2914:2:3320 or similar on my prefix. Why is it important to allow me to specify any value in the Global Administrator field? Well, 1) If we did REQUIRE people to use their own ASN when adding a new community on a prefix, we'd essentially be back to the same amount of opaque space as in RFC1997 (e.g. two fields, not three). This also brings back the collision problem which we were trying to tackle, both AS2914 and AS3356 might decide to act on a community tag like 49544:2:3320. 2) The actor ASN already knows who could have set the community tag thanks to the AS_PATH, using a field in the large community tag to make it aware of that might be considered as redundant information. 3) Using the first field to specify the ASN which needs to take the action makes it quite easy for an operator to ignore any large community tags which are intended to signal something to a 3rd party. This allows for transitive instructions in cases where one doesn't have a direct adjacency with the target ASN; quite useful for downstream customers of a tier-2 network which are trying to trigger an action in that network's upstream provider. Informational communities are another matter - that's where an operator SHOULD use their own ASN in the Global Administrator field. However there is no (technical) difference between an informational and an action community - just semantics - so we can't really specify such restrictions in the draft. Best regards, Martijn On 10/08/2016 06:35 PM, Nick Hilliard wrote: > Brian Dickson wrote: >> Is there anything you envision in use of large communities that >> cannot be supported by use of ASNs and private ASNs? I can't see >> anything that would not fit into those two use cases. > There are plenty of situations where the semantics of what you're > suggesting would be troublesome to define, for example, confederations, > asn translation or asn migration, leading to cases where there would be > multiple asns being legitimate on a single router. > > And even if these cases could be cleared up easily, what happens when > someone injects a prefix tagged with a community which isn't the same as > their ASN? You're then stuck with the situation where you're defining > one thing as a MUST in the semantic specification section of the rfc, > while down in the Security Considerations section, it's going to need to > be admitted that there's no guarantee whatsoever that the global > administrator field in the large community was actually set by the ASN > which announced the prefix. Worse still, once it's been changed, there > is no practical way for a neighbor to detect this change, as s-bgp isn't > a thing. > > Realistically, vendors are going to implement ways of modifying the > field in exactly the same way as rfc1997 communities can be set to > anything at all at any policy specification point in a bgp-enabled network. > > Nick > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sat Oct 8 10:45:42 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB74C129466; Sat, 8 Oct 2016 10:45:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147594873969.28908.11158283743945295574.idtracker@ietfa.amsl.com> Date: Sat, 08 Oct 2016 10:45:39 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-large-community-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 17:45:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Large BGP Communities Authors : Jakob Heitz Keyur Patel Job Snijders Ignas Bagdonas Adam Simpson Filename : draft-ietf-idr-large-community-02.txt Pages : 8 Date : 2016-10-08 Abstract: This document describes the Large BGP Community attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use in 4-octet ASNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-large-community-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 8 10:52:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBA11295EB for ; Sat, 8 Oct 2016 10:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 NUEUt4QjpOGa for ; Sat, 8 Oct 2016 10:52:30 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 1B58B12954F for ; Sat, 8 Oct 2016 10:52:30 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bsvnQ-0000Za-P2 (job@us.ntt.net); Sat, 08 Oct 2016 17:52:29 +0000 Date: Sat, 8 Oct 2016 19:52:25 +0200 From: Job Snijders To: idr@ietf.org Message-ID: <20161008175225.GF4365@Vurt.local> References: <147594873969.28908.11158283743945295574.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147594873969.28908.11158283743945295574.idtracker@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 17:52:32 -0000 Dear working group, Changes to draft-ietf-idr-large-community-02.txt o Update implementation status (added fifth implementation: OpenBGPD) o 'byte' -> 'octet' in abstract (Jakob) o Remove RFC references from abstract (Petch) o Change wording IANA recommendations (Petch) o Clarify duplicate value handling (Ignas, Adam) o Improve 'Global Administrator' definition in section 2 (Nick, Haas, Petch) o Remove extended communities from security section (Haas) o Change RFC1997 xref to RFC1998 in "Textual Representation" (Haas) Thank you all for your contributions! Kind regards, Job On Sat, Oct 08, 2016 at 10:45:39AM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing of the IETF. > > Title : Large BGP Communities > Authors : Jakob Heitz > Keyur Patel > Job Snijders > Ignas Bagdonas > Adam Simpson > Filename : draft-ietf-idr-large-community-02.txt > Pages : 8 > Date : 2016-10-08 > > Abstract: > This document describes the Large BGP Community attribute, an > extension to BGP-4. This attribute provides a mechanism to signal > opaque information within separate namespaces to aid in routing > management. The attribute is suitable for use in 4-octet ASNs. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-large-community-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sat Oct 8 13:14:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6017129532 for ; Sat, 8 Oct 2016 13:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NatKmh-o_Tsp for ; Sat, 8 Oct 2016 13:14:16 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DAF126FDC for ; Sat, 8 Oct 2016 13:14:16 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id rz1so35464852pab.1 for ; Sat, 08 Oct 2016 13:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gVA1B161Ag2mKex0fVyOErzP0BQZJJQFb3H+Dt2D5IY=; b=aYziLQF5+mPVy/lo1kCmYcmVYIF36BrGiOjT80mfiAl5f035+XYUTWAvxQbr9rmoFV cIbBDohg5umQqK/Uvz9HSpWnMxdxvYpw1PuP4xrtq1uWNK9GmFKDXTmMQX0FplRFY+ek bGIyyZH9o/biCD9cU8YnoN6VJiT5+YkVHPPbzf0WObspAeByzNN8peHI7ojxGuFod/Im Eu1I/WZ/zyG3lB9rXkWTsiB4osEZqvyPTGy7QlPompSeyddGSf661YnumpAQx0TqSfyc 8l9IbyWHGaSSH+iYmPr+eFZOGgZCvHz0kGQDoyhWga16NFEiXSzlUYtT+2pSilsExuGr vI3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gVA1B161Ag2mKex0fVyOErzP0BQZJJQFb3H+Dt2D5IY=; b=FQIFOdkAmWEir6c9aqnsjaA+EdqGNbshkTriHzBvmyB7CWuHm80JKGvmQCryaxZ05U rkQHn1LDkbcKTI91eMdsP/q3OE4O+WF/4ZPpP5cJ/+WCOl+NmjNU4A4xtfcvj7gHvz6E 03C14moinhroGvaps2nKSeR2UMZ+475x7zxjb0w1oKrdibNH9BwStUjdg7OjsE6SfScC i8s2GNONgW7DDC0kTmBMh3nELVDL6/JOmv/JaY98mbnkc1J5z68KpMgZie3JvFb05Rox OQQtuK7lWMAZwwM+P5gejLRngb5G7an0G5m59y/wQk6b5rmF18A/qTT5/42c7Ap9C1Rt xAgQ== X-Gm-Message-State: AA6/9Rl0hyChlXhZuHnjmQqzQeOiqsYiqchB5qZzdBL/cYPoH2bhzTHjT8cX5/eOH1YhNA== X-Received: by 10.66.230.199 with SMTP id ta7mr32789968pac.86.1475957655460; Sat, 08 Oct 2016 13:14:15 -0700 (PDT) Received: from ?IPv6:2001:569:72b9:1f00:2845:91ab:4ad0:9234? (node-1w7jr9qj3jdopeoyqeg712r04.ipv6.telus.net. [2001:569:72b9:1f00:2845:91ab:4ad0:9234]) by smtp.gmail.com with ESMTPSA id sa1sm40236970pac.34.2016.10.08.13.14.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 08 Oct 2016 13:14:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (14A456) In-Reply-To: <57F92043.20301@foobar.org> Date: Sat, 8 Oct 2016 13:14:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> To: Nick Hilliard Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 20:14:18 -0000 Sent from my iPhone > On Oct 8, 2016, at 9:35 AM, Nick Hilliard wrote: >=20 > Brian Dickson wrote: >> Is there anything you envision in use of large communities that >> cannot be supported by use of ASNs and private ASNs? I can't see >> anything that would not fit into those two use cases. >=20 > There are plenty of situations where the semantics of what you're > suggesting would be troublesome to define, for example, confederations, > asn translation or asn migration, leading to cases where there would be > multiple asns being legitimate on a single router. >=20 The operator setting the community would need to know the intended semantics= . The other operator would need to establish what acceptable communities cou= ld be used and the corresponding semantics. The operator doing anything complicated will already need to understand the A= SN gymnastics; the corresponding communities follow those same gymnastics. > And even if these cases could be cleared up easily, what happens when > someone injects a prefix tagged with a community which isn't the same as > their ASN? =20 I said ASN. I didn't say THEIR ASN. That is the apparent disconnect. Nothing should enforce what ASN value is used. > You're then stuck with the situation where you're defining > one thing as a MUST in the semantic specification section of the rfc, > while down in the Security Considerations section, it's going to need to > be admitted that there's no guarantee whatsoever that the global > administrator field in the large community was actually set by the ASN > which announced the prefix. Correct. That is the intended behavior. The ASN value will rarely be the ASN setting the community. The cases where t= he sender uses its own ASN can already be handled with extended communities.= > Worse still, once it's been changed, there > is no practical way for a neighbor to detect this change, as s-bgp isn't > a thing. >=20 > Realistically, vendors are going to implement ways of modifying the > field in exactly the same way as rfc1997 communities can be set to > anything at all at any policy specification point in a bgp-enabled network= . Yes, and this is the desired state of affairs. Complete parity with 1997. Brian= From nobody Sun Oct 9 03:07:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93FE1294A0 for ; Sun, 9 Oct 2016 03:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 Yt3o5S4i5eUt for ; Sun, 9 Oct 2016 03:07:44 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0094.outbound.protection.outlook.com [104.47.2.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E246129473 for ; Sun, 9 Oct 2016 03:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AgLziJQawQXXGcM4lLM9WKtDeL6EhdcHJAlWEMiOz9g=; b=TZUpOMEspZr7fo1pg6huueObLvrpnKkB50RMSnDu8zlX5+ZMqj3ny1C27LIgYlcowqNs08N4Jo4gaoVvBu3nYLkJxlsIPq3Q8544kK1uMIhgCHYbuvFimykL2CTLXiq2yvhqlbeVutfr6V7pf9gKWJIJpRovfmLvDmBNlWHohpw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Sun, 9 Oct 2016 10:07:41 +0000 Message-ID: <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> From: t.petch To: Brian Dickson , Nick Hilliard References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> Date: Sun, 9 Oct 2016 10:55:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: DB3PR08CA0026.eurprd08.prod.outlook.com (10.161.51.164) To HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) X-MS-Office365-Filtering-Correlation-Id: 2376a31e-6864-42b9-c6fe-08d3f02c1b51 X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 2:00VNsXneTaY8UkR3ZP//mzpSkLbqeo1Pb/Yi/MvS3MyFqWNWtuwb4Q4+AeHfq0OAhdZZiP1u0tUDOR6swWc3Pma+ee4ECY/nOD2hM7OBCzMO+PNLRy88h56gLjGRwJDPNXrWtNtI4s9xKIV0aqMRVhnOgFAZ7Tu8buF6pD2bfnkvomZYQ4Ge2vnqhuxnwI3pkj5PvkvmcdE4iWpLVrvf5Q==; 3:EY89rkhw7iA6POWfRIZb0ykkYgIqL608rFIzqYEFlD5Q2AvCbyx2dVFBpMBW1ugH+5YWxZ35fWzV/IRFJQv7UTeMH44G6JFC1/Ao87+ZgdZH0o+6Roc45s0bdccvFewWtTZHT2tp4WpJzm9JUZjDTQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 25:VZ7iVabsaFpIakosPxXL8hLpeZG5sUw9oggHoUZ2pgGoxyKzFtYut4UYqKiuQeulxTNd6WUPvQRghhndriLivMYt81foPitNtl0NapuVlLxZD3Yoc417tubINX9m8cXy4SSe4ti6Vr/Yt+SJzRaadaEDK5Ar3ctdCT1pcfrgIpVHHXUyki1iRmjhE70CW7L8S/PoBy4CZzUW1zPbXzB350nJ3sX4LfdjZSalCdLVZeTqWEAjtdkoBmJOkDU/0Maf1lhBwI9QbTO6zWpQLZE9qlSHa52i2Ab7jkaLd2IESLsPqjiLbfd7VyMyD15PcU3mIIzwywDivleM9bDF+AoAfoq0BuFENxqD0D3pOA2QI9e8I8ICAH14VPRkzCoySdGDOPmogxq1pq3Nuc8eIOHf2Z42k4GVG2AGa87PiCalK9LW39Szt+9/T/EBv+eWCHb1taFO6Cnar1qN0MTCB96idAI1dENcn0qEakvkZM1lJ+EsDbLNdZNBiRoG6z0tc05Jd6ebqJR/9xhPG/KQ8hDnaa8Gap8pzUVd64XGeBipB3PCU0hmuerdRQOZokc/BojclqhlMH+bgRYUO+wuww8ZdXvRh8sgeOY4+ifvGZLe1P8SFasTe8BIRGKf1mIV/Jmur1HTABD+4HBC83vr+H1d7n5JJEIEzBI9ik3oEaPtdI6mvJTO5We0zKYIzjm5bVeO42rSGPUWsItG6lljzez2DdmMp7U1F78hCBK/oh6PrPZph+NvgPH3yyUcSEDtbDofiV7/X1+gjGQppHPMKcSstBroLPD56PZyzPu1PxSlSNu9e2h3sXUVLmhdGZPx9pvQdWpexJRrpADahLnWkCHX/w== X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 31:mBtWhqsr24gxy/LEltdoRm/lKUd9vI0SVw7/uKhkwKbGLr5jRIJfu+tPFf1WskemRj/qCrH9zQ2Z94VhBbN298kbi8b9rL7YbV/L1e35LFwc9ZU1QNOYI2f+O62vSPnFhm9ChSxnOivN9jEhk+B8NOEAI80lGVs8wW6p5QXSPKSSvHdh8dYxZC1v4HXPfulucjwpkWnGMD9l8kuD9OF1xMez9T6gV1VyF1TwxuzUHfMuvpsWAre+nZDpWaavSlh/fbSgqVpyReKIws5deTftpQ==; 4:0hXA7MmQUNheqaunwkwAMpDFX9Mxdndun5y3NZiiOwMUyZzIBCUklTQIfZQxy5Uq3/Z/2OtPQVn3u4f1HK0oKsjO1cSPhx4AZAAUuiSmAGOpkGB9a86uduoVzci3fZYJPtLOXvJ6YiMrZg45muse4LwkbuZAOOcF6XTqWdgNH/b3ZWrTSsXfvC4K0maHe0n2C47sjNiSoNk5kF4WtBdknsmsVwFEznmGH5Wgpcav74Hs6xQTdDLXu4ytVaOqSg9/w2KxlHElBkUJzDe33mC1y7Q+7G4vBzYMvWenwmCxB3QnWx2CfN2zDOvfvCPKVQJ12W5pSiqrMg4MLdmeN4DJbBI3yZdUNcG4oz1dw77WB8Vwh+ifpYIUg2R7vKrZcXxtvsWrIVvkEPGKk5toP+Y7cqra8B6y9g/KZ3vwflLgCihiQPreIakC7sJj9aR7O8Masbhu18cym44l9pSRSrfPIQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3002; X-Forefront-PRVS: 00909363D5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(377454003)(24454002)(13464003)(189002)(199003)(7846002)(44736004)(14496001)(15975445007)(23756003)(7736002)(6666003)(50466002)(101416001)(68736007)(66066001)(93886004)(230700001)(47776003)(50986999)(76176999)(81686999)(81816999)(81156014)(81166006)(189998001)(97736004)(5660300001)(5001770100001)(1456003)(305945005)(42186005)(77096005)(33646002)(61296003)(50226002)(105586002)(106356001)(6116002)(3846002)(8676002)(86362001)(586003)(19580395003)(19580405001)(62236002)(44716002)(92566002)(4720700003)(1556002)(9686002)(4326007)(230783001)(2906002)(116806002)(84392002)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3002; 23:BIyJwqNCmWtQTnbJ7LRbo1C0vlKOcJ6o7fkjK?= =?iso-8859-1?Q?qkWMilyWK5ikZ1Utm4W43kqtLwkF75JebpbOqeb50PtaaYkAlVgphMnl3S?= =?iso-8859-1?Q?ZRChaMmcty3t+rL8ve4sF9LvDLnOqW3qg82I3z5WWL+AtNrCPK9s8JBaYK?= =?iso-8859-1?Q?PuV+edmJucDEI//BwmB/F1OHSlD+LNVGxu6BXtxhdiTYNTrD4dSCn/sCNx?= =?iso-8859-1?Q?4vjlJpzLO8ZiEw88Ws05/9PD5KW2TgBGPidRJL7ZuKX74rmb8g13OR4vUt?= =?iso-8859-1?Q?kqnd6wQbql4Qp8yNvx3j1XFmLGCnalv13zIe2qSB5w6KkdVCAirVA/+jjk?= =?iso-8859-1?Q?MdCXzEo27sc7ehhbnPLJM4LwyCb6LXA+h6IFq0QmA0Z5FA8xbY8YyA5BON?= =?iso-8859-1?Q?SkJGfOOXvOF8nGikOMi9Qvc6H9cTAiugt6v8+RKYrFdf+Zt+P6cHLN3Z0e?= =?iso-8859-1?Q?GsZtZbrjYeQDBGVKvYP/kMonZRs9jAunno4PyfEjxLPp9qOGEAwBObze50?= =?iso-8859-1?Q?sXMPK5swPJ32OWv71R+mFg0diyxuhiwRLLbhuxeuqrypcR2bS6BBmBiPlC?= =?iso-8859-1?Q?hS6UGpME6zXLDXvryTaYpYXWyoE+luQ0T9BJLXjbJ0t8DAxI/91VPtqFm8?= =?iso-8859-1?Q?w/YwgZsamRXZJ0ad6xjJoqzLXo22JW023bk0EofKAlvZX6acjA/NCleg44?= =?iso-8859-1?Q?XZU8OfSEtoFYplq+ikhhSG1ank13+RJRxLN1+Ayh95BVlvkJar3NO+lJzS?= =?iso-8859-1?Q?slDaBlV8IlKMEfufZsND3/u2XLVgUnFbt2c3zSVi7zhGPjasNZ595V8HzQ?= =?iso-8859-1?Q?WqKdTluj33bOWauZT07UhNo35vSXwGs7UR7UaJojatWGiuEtzoXIBBJqgt?= =?iso-8859-1?Q?GsLTWzdkd+YIyVXpq1CsBqYPsvy653xRCtsMqUoe1K78RFfoFrlzK0uPAy?= =?iso-8859-1?Q?RpE4puIXXmWxGqt6swifau64LVDYarXnEu+sV7sDYNiH5CABaKyZqED6po?= =?iso-8859-1?Q?hjL0idUgNwK/t0yc6+Cwmthdpqb6fb4BQU2kn4kxV3wzm+Q4r46kQvfqfU?= =?iso-8859-1?Q?4q4Wg5mLZgnTmki+vhOiYoJ0rrlHV7TXhYkG/WKMo/m24lUN3Hnly84vpO?= =?iso-8859-1?Q?v5YkhSbHKJW1V4rgq9ZbVkRG1fRcNx6iFYeUdQQ3BcX9/xgoluLkAAhP8M?= =?iso-8859-1?Q?GeBiVAm8q9fMPMQhz8KbQjGwuL5XN1905Y8m6FSnjWN3URGT+IJdsJgiEV?= =?iso-8859-1?Q?4zOCzcwBqCXpKsg1z6g1ZXkuvCFJAgoImc3D8r3h6l2TQMCoX/4VvpfFxG?= =?iso-8859-1?Q?/9tney3E41Qt3o4zA3mTHuQ6quVMdNXGAejdwDLe57ob44u+hzAGkY+rVB?= =?iso-8859-1?Q?fIY0+nbskKjG6ahLnqB5tiHnzvIekHo99Iva40Pe6YPaGEsKy958q6QLCc?= =?iso-8859-1?Q?Wx/THhO4tngQf0lAnnumV7QQL32AF4ltghOg/9aPpBLPrab87wG4YokAU0?= =?iso-8859-1?Q?Hfn07oUCjPgKFvvawB8J7Un79+ks79k2LTECr1lcF3mFWFL+duCypvY1Td?= =?iso-8859-1?Q?Tx+mQoA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:oJR8WZYV4SKlY25bndY+aeWmvjKTNGGWCTb9wSRK5sKFif4+1drpQqtj8bVJ4aQYkF13jX+ds3/ZlCM4G8ZLxRSPIGeYg2Z+v3NGsoKqRdfymXdBhhY5JEfYQdvj8XfMhwTP+8SkhXSI8eL1Fa4SwKhZFMIm98ZtxRkEH00XmC3zR4J64NNDQmpYzyWjuRYwOr5g0rGFro8+5voUFWrKF9D56uf9BbHLA9Mkx2YG0jfEZzk2ssA8DJeEal1h8dmo5VRGiEHkD6AsRjRKaOKeknU0lm5VrHrDvxqxm6lT4vqhWUvLshqbZU36kk8RPpCc; 5:jvSow6xuetrdq/2o8caTBqRDiaxM0RIuDawn0bY1jDCsK8/DU7AXWYrIvRo+4ozfUS7vxRerwkkQ5xRnwFxKH6HaS5itwNnYh7Iz0elzTDJNwHCPjTDQSpfTnxKkzAI3dje05/ymNWwLYRajsco7cmVwK3sYnPX2wzGmj/W3OEM=; 24:QoqYjVj368MoJRKhhPop1DgFEVKC/75PpHfUcjDk6h71fdBDP3My3aiHO4Dw7Ry0vY3nB8DP64JVVOIGTVzsx1qqRCVeadXg2AOdA7DPYws=; 7:ZewZKtIU7R8+LWkyYMsVYpAayQM6k9VnoHt8dNAXLKIyN2i26/GUfY8YuYgMySOu/kzWC2itv0Bo/qjKZ5uigjW5gLRGt/u4LyrpFABLx3huwg196msEKMyV/6pdqRImig0E2KGPxSd4IelKb6M4EywmApMqukW/pINXxrT4amfyeP3uWvS3NODaOfSBHonim/ku5dkbHdPscVHBpRODK/kH4yBxLs31cFjb79y1jtq7XWf4gW6JIBlITP/cZ5wBNrNlJZRfVLghSvz4B+1H7MstSkp03MSmqH+S6aAu1CXw0R0OU+I5deoEW6J7hU6wH/MOJmF8CubYy86wIbGGDg== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2016 10:07:41.1668 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 10:07:49 -0000 --- Original Message ----- From: "Brian Dickson" To: "Nick Hilliard" Cc: Sent: Saturday, October 08, 2016 9:14 PM > > > On Oct 8, 2016, at 9:35 AM, Nick Hilliard wrote: > > > > Brian Dickson wrote: > >> Is there anything you envision in use of large communities that > >> cannot be supported by use of ASNs and private ASNs? I can't see > >> anything that would not fit into those two use cases. > > > > There are plenty of situations where the semantics of what you're > > suggesting would be troublesome to define, for example, confederations, > > asn translation or asn migration, leading to cases where there would be > > multiple asns being legitimate on a single router. > > > > The operator setting the community would need to know the intended semantics. The other operator would need to establish what acceptable communities could be used and the corresponding semantics. > > The operator doing anything complicated will already need to understand the ASN gymnastics; the corresponding communities follow those same gymnastics. > > > And even if these cases could be cleared up easily, what happens when > > someone injects a prefix tagged with a community which isn't the same as > > their ASN? > > I said ASN. I didn't say THEIR ASN. That is what I intended, although it has not been construed as such. There is nothing IMHO in ' Global Administrator: A four-octet namespace identifier. This MUST be an Autonomous System Number assigned by IANA.' which says whose ASN it is, just that it must be an ASN; if you allow IPv4 addresses, Router ID, IGP Area numbers and so on, anything else that fits into 32 bit, then it all breaks down so it MUST be an ASN. At a stretch, that wording includes private ASN since those values are assigned by IANA although we might want to point that out explicitly. And as Brian says, security is something else. Anyone can forge anyone else's ASN in there, but that is possible with other BGP data (in the absence of SIDR or some such) so the security needs careful consideration. Tom Petch > That is the apparent disconnect. > > Nothing should enforce what ASN value is used. > > > You're then stuck with the situation where you're defining > > one thing as a MUST in the semantic specification section of the rfc, > > while down in the Security Considerations section, it's going to need to > > be admitted that there's no guarantee whatsoever that the global > > administrator field in the large community was actually set by the ASN > > which announced the prefix. > > Correct. That is the intended behavior. > > The ASN value will rarely be the ASN setting the community. The cases where the sender uses its own ASN can already be handled with extended communities. > > > Worse still, once it's been changed, there > > is no practical way for a neighbor to detect this change, as s-bgp isn't > > a thing. > > > > Realistically, vendors are going to implement ways of modifying the > > field in exactly the same way as rfc1997 communities can be set to > > anything at all at any policy specification point in a bgp-enabled network. > > Yes, and this is the desired state of affairs. Complete parity with 1997. > > Brian > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sun Oct 9 14:55:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9131295B4 for ; Sun, 9 Oct 2016 14:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 RQwVqXAfSMc3 for ; Sun, 9 Oct 2016 14:55:47 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A97129491 for ; Sun, 9 Oct 2016 14:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4909; q=dns/txt; s=iport; t=1476050147; x=1477259747; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=S804GXIdrFzXQmYbDBhmNKgRohxhLXpbR7iBV7LGZHQ=; b=KDEHYjiMLfSemrZaHbLsnNWbvAJ+EDD0dLRUxBdjrgx4ftkUK2BMHcoP 6gWJpIV2HozukH4ZIla8Ipj1INEJnkvr2XWXEDUvfOIkqjzE+nKApHjyM oX5sfZ0mv4ktaVr3SdKt/n5yATC4WB8flq3229Ndyr18Ek1OrM/usH51i k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAQCmvPpX/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAR1XfAeNLJcCh1uMVoILGwuCRIM2AoF6OBQBAgEBAQE?= =?us-ascii?q?BAQFeJ4RhAQEBBAEBATc0CwwEAgEIEQQBAQEeCQchBgsUCQgCBAENBQgMiCIDF?= =?us-ascii?q?w69HA2DZAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhj2EVYJHh18FmUo1AYxxgwS?= =?us-ascii?q?BdY4Ghw+BVIQUg34BHjZLgmYFHIFTcgGHAIEAAQEB?= X-IronPort-AV: E=Sophos;i="5.31,468,1473120000"; d="scan'208";a="156141882" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2016 21:55:33 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u99LtXYS006850 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 9 Oct 2016 21:55:33 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 9 Oct 2016 16:55:32 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Sun, 9 Oct 2016 16:55:32 -0500 From: "Jakob Heitz (jheitz)" To: "t.petch" , Brian Dickson , Nick Hilliard Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt Thread-Index: AQHSG79TGAvzbRTYaUOLNdatGR0q+6CTny8AgALbUg+AAFuDAP//w9BUgABdGYCAAD/ogIAFnPnpgABp4oCAAKSCAIABPgaAgAA9LACAAJUrsoAAug9w Date: Sun, 9 Oct 2016 21:55:32 +0000 Message-ID: References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> In-Reply-To: <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.21.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 21:55:49 -0000 Router software will not treat an UPDATE message as malformed if the Global Administrator field of a Large Community does not contain an = ASN. It doesn't even know that it's an ASN. It's just 32 bits. I don't think we can or should specify anything stronger than: A receiving BGP speaker is permitted to remove unexpected Large Communities from received routes. A Large Community that is intended to be sent to multiple ASes SHOULD contain an ASN in the Global Administrator field. The ASN SHOULD be one that is assigned to the entity that defines the meaning of the rest of the Large Community. This allows a route to carry multiple Large Commuinties, the meaning of each being defined by different independent entities. Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch > Sent: Sunday, October 09, 2016 2:55 AM > To: Brian Dickson ; Nick Hilliard > Cc: idr@ietf.org > Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt >=20 > --- Original Message ----- > From: "Brian Dickson" > To: "Nick Hilliard" > Cc: > Sent: Saturday, October 08, 2016 9:14 PM > > > > > On Oct 8, 2016, at 9:35 AM, Nick Hilliard wrote: > > > > > > Brian Dickson wrote: > > >> Is there anything you envision in use of large communities that > > >> cannot be supported by use of ASNs and private ASNs? I can't see > > >> anything that would not fit into those two use cases. > > > > > > There are plenty of situations where the semantics of what you're > > > suggesting would be troublesome to define, for example, > confederations, > > > asn translation or asn migration, leading to cases where there would > be > > > multiple asns being legitimate on a single router. > > > > > > > The operator setting the community would need to know the intended > semantics. The other operator would need to establish what acceptable > communities could be used and the corresponding semantics. > > > > The operator doing anything complicated will already need to > understand the ASN gymnastics; the corresponding communities follow > those same gymnastics. > > > > > And even if these cases could be cleared up easily, what happens > when > > > someone injects a prefix tagged with a community which isn't the > same as > > > their ASN? > > > > I said ASN. I didn't say THEIR ASN. >=20 > That is what I intended, although it has not been construed as such. >=20 > There is nothing IMHO in > ' Global Administrator: A four-octet namespace identifier. This > MUST be an Autonomous System Number assigned by IANA.' > which says whose ASN it is, just that it must be an ASN; if you allow > IPv4 addresses, Router ID, IGP Area numbers and so on, anything else > that fits into 32 bit, then it all breaks down so it MUST be an ASN. At > a stretch, that wording includes private ASN since those values are > assigned by IANA although we might want to point that out explicitly. >=20 > And as Brian says, security is something else. Anyone can forge anyone > else's ASN in there, but that is possible with other BGP data (in the > absence of SIDR or some such) so the security needs careful > consideration. >=20 > Tom Petch >=20 > > That is the apparent disconnect. > > > > Nothing should enforce what ASN value is used. > > > > > You're then stuck with the situation where you're defining > > > one thing as a MUST in the semantic specification section of the > rfc, > > > while down in the Security Considerations section, it's going to > need to > > > be admitted that there's no guarantee whatsoever that the global > > > administrator field in the large community was actually set by the > ASN > > > which announced the prefix. > > > > Correct. That is the intended behavior. > > > > The ASN value will rarely be the ASN setting the community. The cases > where the sender uses its own ASN can already be handled with extended > communities. > > > > > Worse still, once it's been changed, there > > > is no practical way for a neighbor to detect this change, as s-bgp > isn't > > > a thing. > > > > > > Realistically, vendors are going to implement ways of modifying the > > > field in exactly the same way as rfc1997 communities can be set to > > > anything at all at any policy specification point in a bgp-enabled > network. > > > > Yes, and this is the desired state of affairs. Complete parity with > 1997. > > > > Brian > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sun Oct 9 16:34:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47445129417 for ; Sun, 9 Oct 2016 16:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4aBg6xk731qO for ; Sun, 9 Oct 2016 16:34:10 -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 3D0BF124281 for ; Sun, 9 Oct 2016 16:34:09 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u99NY4uq020332 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Oct 2016 00:34:05 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local Message-ID: <57FAD3EA.6070800@foobar.org> Date: Mon, 10 Oct 2016 00:34:02 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.4 (Macintosh/20161007) MIME-Version: 1.0 To: "t.petch" References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> In-Reply-To: <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 23:34:12 -0000 t.petch wrote: > There is nothing IMHO in > ' Global Administrator: A four-octet namespace identifier. This > MUST be an Autonomous System Number assigned by IANA.' > which says whose ASN it is, just that it must be an ASN; if you allow > IPv4 addresses, Router ID, IGP Area numbers and so on, anything else > that fits into 32 bit, then it all breaks down so it MUST be an ASN. At > a stretch, that wording includes private ASN since those values are > assigned by IANA although we might want to point that out explicitly. There's something I'm not getting here in this discussion. Let's step back a bit and start with a principal: "if a policy cannot be enforced, it is bad policy". There is no way a priori for a router to have knowledge of what ASNs have or have not been assigned, either by IANA or any other assignment body. If a standards track document is created which mandates that a specific identifier field "MUST" contain a ASN assigned by IANA, there is no practical way for another router to check this. Because the MUST cannot be checked or enforced in any meaningful way, a formal requirement of this form automatically falls into the realm of bad policy. The best option here is - as Brian noted - to align with 1997 semantics and make a recommendation to operators that the global administrator field should be an ASN, and to stay well clear of attempting to define what an ASN is, or is not. Operators are adults and will do what works for them; there's no need to be over-prescriptive. Nick From nobody Sun Oct 9 23:18:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766E31295BB for ; Sun, 9 Oct 2016 23:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 isL8l1M-MyGd for ; Sun, 9 Oct 2016 23:18:33 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84942129560 for ; Sun, 9 Oct 2016 23:18:33 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id x79so109106072lff.0 for ; Sun, 09 Oct 2016 23:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yEAyr8gwFX29dacOuW0VQZ9J27lZa105mBO+OYiay7o=; b=P8r85Na0a3MdmbllZDJktNR1xhwSyVxuOw7QYPsBh5a098pZ4oSWmRkQVYccNsnR0I ZOYeG1+mkbVyRMwSc7t4Kxmr17icF7Zt5ZjMG5r1RsDh734KJRF52AOIEmU5+J8n/N1A ddx3XSiHkyMAYOMMO9RKN/OIuIGZ/duTsNOdk6gm0V3QbjRDnZ96CiDtGwo+57GmyyX8 jEj/P8WtC0fyNUp7oEbBFnuTNRCyzFzopzEcunrhaGmdySuk08yaNfRP+77HaJ9p8S+g x+h2LeYImkA6uPKJARf//4S2zTaA8lEnM748i4V4t/1eRA3KNEcCsN/CE4xwoAORDmz5 oMZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yEAyr8gwFX29dacOuW0VQZ9J27lZa105mBO+OYiay7o=; b=ReGE/rYgK3nxxI8IR2kM+Oh4u3eJV0Lmqm6er4FIFpVVHKgfK9SQ5eXJ/wJcCQ3c4h s8t9PXidwjz3XJE6N9zraWVf8H05nXOApQTINSzKVRjMozJhQUj8kYd/StTr3Rb9c1rn TopEePPTeFU4DaIUuNh1RCStb5jOndTltuZBJExG52zYY7q/umFkr8DKF990BgfWzUsu 1Wdj6BXeWkuFXNtMtdXr4tX6cIZuXT4iehYQvxKkc9/WLUkRGTGkd1SxaRUXkHdP5HQ7 PrcWKJRS/v7lby5LEwkfcALANbBIXzvWy81IUGqzfeRA9tgYjWowFTeKt5ehh/NVXI8Y nQQA== X-Gm-Message-State: AA6/9RkX4G9SXKkl/oJ4z/FdpnN27wGPOiQdrP9hy5H+i2ju8KK3qREundfoqPNPFrkn6hVBUFYxE0yxK7iLvw== X-Received: by 10.194.97.69 with SMTP id dy5mr26204288wjb.53.1476080311517; Sun, 09 Oct 2016 23:18:31 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Sun, 9 Oct 2016 23:18:30 -0700 (PDT) Received: by 10.80.182.155 with HTTP; Sun, 9 Oct 2016 23:18:30 -0700 (PDT) In-Reply-To: References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> From: Robert Raszuk Date: Mon, 10 Oct 2016 08:18:30 +0200 X-Google-Sender-Auth: NjVHjF20DL5c6bW9fuhVXTsEctc Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=089e0103e2f6a0c975053e7cbab8 Archived-At: Cc: idr wg Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 06:18:36 -0000 --089e0103e2f6a0c975053e7cbab8 Content-Type: text/plain; charset=UTF-8 Hi Nick, It is not true ... Bgp origin validation shipping for a long time does contain both assigned AS numbers as well as mappings to the prefixes which should be originated with such AS numbers. So technically there is an easy way to enforce it in any place in the network. Now should it be enforced or not it's a different debate. Personally I do not think so. As discussed previously any field can be overloaded so locking any field of large comms to any specific semantics of the value it is to carry would be limiting its flexibility. Thx R. On Oct 10, 2016 01:34, "Nick Hilliard" wrote: t.petch wrote: > There is nothing IMHO in > ' Global Administrator: A four-octet namespace identifier. This > MUST be an Autonomous System Number assigned by IANA.' > which says whose ASN it is, just that it must be an ASN; if you allow > IPv4 addresses, Router ID, IGP Area numbers and so on, anything else > that fits into 32 bit, then it all breaks down so it MUST be an ASN. At > a stretch, that wording includes private ASN since those values are > assigned by IANA although we might want to point that out explicitly. There's something I'm not getting here in this discussion. Let's step back a bit and start with a principal: "if a policy cannot be enforced, it is bad policy". There is no way a priori for a router to have knowledge of what ASNs have or have not been assigned, either by IANA or any other assignment body. If a standards track document is created which mandates that a specific identifier field "MUST" contain a ASN assigned by IANA, there is no practical way for another router to check this. Because the MUST cannot be checked or enforced in any meaningful way, a formal requirement of this form automatically falls into the realm of bad policy. The best option here is - as Brian noted - to align with 1997 semantics and make a recommendation to operators that the global administrator field should be an ASN, and to stay well clear of attempting to define what an ASN is, or is not. Operators are adults and will do what works for them; there's no need to be over-prescriptive. Nick _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --089e0103e2f6a0c975053e7cbab8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Nick,

It is not true ...

Bgp origin validation shipping for a long time does contain = both assigned AS numbers as well as mappings to the prefixes which should b= e originated with such AS numbers.

So technically there is an easy way to enforce it in any pla= ce in the network.

Now should it be enforced or not it's a different debate= .

Personally I do not think so. As discussed previously any fi= eld can be overloaded so locking any field of large comms to any specific s= emantics of the value it is to carry would be limiting its flexibility.

Thx
R.


On Oct 10, 2016 0= 1:34, "Nick Hilliard" <nick= @foobar.org> wrote:
t.petch wrote:
> There is nothing IMHO in
> '=C2=A0 =C2=A0Global Administrator:=C2=A0 A four-octet namespace i= dentifier.=C2=A0 This
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be an Autonomous System Number assigned= by IANA.'
> which says whose ASN it is, just that it must be an ASN; if you allow<= br> > IPv4 addresses, Router ID, IGP Area numbers and so on, anything else > that fits into 32 bit, then it all breaks down so it MUST be an ASN.= =C2=A0 At
> a stretch, that wording includes private ASN since those values are > assigned by IANA although we might want to point that out explicitly.<= br>
There's something I'm not getting here in this discussion.
Let's step back a bit and start with a principal:=C2=A0 "if a poli= cy cannot
be enforced, it is bad policy".

There is no way a priori for a router to have knowledge of what ASNs
have or have not been assigned, either by IANA or any other assignment body= .

If a standards track document is created which mandates that a specific
identifier field "MUST" contain a ASN assigned by IANA, there is = no
practical way for another router to check this.=C2=A0 Because the MUST cann= ot
be checked or enforced in any meaningful way, a formal requirement of
this form automatically falls into the realm of bad policy.

The best option here is - as Brian noted - to align with 1997 semantics
and make a recommendation to operators that the global administrator
field should be an ASN, and to stay well clear of attempting to define
what an ASN is, or is not. Operators are adults and will do what works
for them; there's no need to be over-prescriptive.

Nick

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--089e0103e2f6a0c975053e7cbab8-- From nobody Sun Oct 9 23:52:46 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3075312949B for ; Sun, 9 Oct 2016 23:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=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 9BjxzGB9SgOW for ; Sun, 9 Oct 2016 23:52:44 -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 3B168128E18 for ; Sun, 9 Oct 2016 23:52:43 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3031F606E8 for ; Mon, 10 Oct 2016 08:52:41 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id C98B56012B; Mon, 10 Oct 2016 08:52:40 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id C5E0C3676F; Mon, 10 Oct 2016 08:52:40 +0200 (CEST) Date: Mon, 10 Oct 2016 08:52:40 +0200 From: Gert Doering To: "Jakob Heitz (jheitz)" Message-ID: <20161010065240.GF79185@Space.Net> References: <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> 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.6.1 (2016-04-27) Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 06:52:46 -0000 Hi, On Sun, Oct 09, 2016 at 09:55:32PM +0000, Jakob Heitz (jheitz) wrote: > A receiving BGP speaker is permitted to remove unexpected > Large Communities from received routes. A Large Community that > is intended to be sent to multiple ASes SHOULD contain an ASN > in the Global Administrator field. The ASN SHOULD be one that > is assigned to the entity > that defines the meaning of the rest of the Large Community. > This allows a route to carry multiple Large Commuinties, the meaning > of each being defined by different independent entities. This matches how I understand people's intention to use these. So, works for me. 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 Sun Oct 9 23:53:22 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9481294A4 for ; Sun, 9 Oct 2016 23:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=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 nxHs76S-6NPE for ; Sun, 9 Oct 2016 23:53:20 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 D061D128E18 for ; Sun, 9 Oct 2016 23:53:19 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 26D8260662 for ; Mon, 10 Oct 2016 08:53:18 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id C6144606D0; Mon, 10 Oct 2016 08:53:17 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id C243F3677E; Mon, 10 Oct 2016 08:53:17 +0200 (CEST) Date: Mon, 10 Oct 2016 08:53:17 +0200 From: Gert Doering To: Robert Raszuk Message-ID: <20161010065317.GG79185@Space.Net> References: <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> 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.6.1 (2016-04-27) Archived-At: Cc: idr wg Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 06:53:21 -0000 Hi, On Mon, Oct 10, 2016 at 08:18:30AM +0200, Robert Raszuk wrote: > Bgp origin validation shipping for a long time does contain both assigned > AS numbers as well as mappings to the prefixes which should be originated > with such AS numbers. It could, but it doesn't. Out there, in the real world. 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 Mon Oct 10 05:18:02 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8EC1294FF for ; Mon, 10 Oct 2016 05:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 uGru24_mriwJ for ; Mon, 10 Oct 2016 05:17:59 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 815DF129412 for ; Mon, 10 Oct 2016 05:17:59 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1btZWk-0008sv-EX (job@us.ntt.net); Mon, 10 Oct 2016 12:17:55 +0000 Date: Mon, 10 Oct 2016 14:17:48 +0200 From: Job Snijders To: "Jakob Heitz (jheitz)" Message-ID: <20161010121748.GI57491@Vurt.local> References: <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 12:18:01 -0000 Hi all, On Sun, Oct 09, 2016 at 09:55:32PM +0000, Jakob Heitz (jheitz) wrote: > Router software will not treat an UPDATE message as malformed if the > Global Administrator field of a Large Community does not contain an > ASN. It doesn't even know that it's an ASN. It's just 32 bits. ^^ exactly. It is just 32 bits. This discussion is taking a strange turn. > I don't think we can or should specify anything stronger than: > > """A receiving BGP speaker is permitted to remove unexpected Large > Communities from received routes. A Large Community that is intended > to be sent to multiple ASes SHOULD contain an ASN in the Global > Administrator field. The ASN SHOULD be one that is assigned to the > entity that defines the meaning of the rest of the Large Community. > This allows a route to carry multiple Large Commuinties, the meaning > of each being defined by different independent entities.""" I think this text introduces more problems then it solves. What defines an 'unexpected' community? If Large communities can be deleted, does that mean that other types of communities cannot be deleted? We've had 20 years of communities and to me it is entirely redundant to specify that you can delete a community. The term "Global Administrator" is well understood through years of use and precedent, I dont understand why this suddenly is a problem. We should just stick with the current text. Kind regards, Job From nobody Mon Oct 10 05:21:59 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A7A12946E for ; Mon, 10 Oct 2016 05:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 PNcR7JfRpIWI for ; Mon, 10 Oct 2016 05:21:55 -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 4A226129412 for ; Mon, 10 Oct 2016 05:21:54 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u9ACLnlI046797 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Oct 2016 13:21:49 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <57FB87DC.7030009@foobar.org> Date: Mon, 10 Oct 2016 13:21:48 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.4 (Macintosh/20161007) MIME-Version: 1.0 To: "Jakob Heitz (jheitz)" References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 12:21:57 -0000 Jakob Heitz (jheitz) wrote: > Router software will not treat an UPDATE message as malformed > if the Global Administrator field of a Large Community does not contain an ASN. > It doesn't even know that it's an ASN. It's just 32 bits. > > I don't think we can or should specify anything stronger than: > > A receiving BGP speaker is permitted to remove unexpected > Large Communities from received routes. A Large Community that > is intended to be sent to multiple ASes SHOULD contain an ASN > in the Global Administrator field. The ASN SHOULD be one that > is assigned to the entity > that defines the meaning of the rest of the Large Community. > This allows a route to carry multiple Large Commuinties, the meaning > of each being defined by different independent entities. This is all redundant text. Reality demands that we should be able to add or remove communities. Common sense demands that if we intend a community value to be interpreted by multiple external ASNs, then it should be set to an ASN that we have some claim to because if it isn't, then it is likely to be be stripped off at the ASN border. The protocol specification already states that "the attribute consists of one or more 12-octet values". The document currently says: 1. "Global Administrator: A four-octet namespace identifier. This SHOULD be an Autonomous System Number" 2. "Implementations MUST allow the operator to specify any value for the Global Administrator field" We don't need anything more than this. Less is more. Nick From nobody Tue Oct 11 02:31:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065A11294D4 for ; Tue, 11 Oct 2016 02:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 vBQzIKTdOU57 for ; Tue, 11 Oct 2016 02:31:37 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20118.outbound.protection.outlook.com [40.107.2.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31103128874 for ; Tue, 11 Oct 2016 02:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PxHJn6q2tEAx6huBPOieZN7VEXCn3LQ+ZdBo4BsNPWA=; b=inaZk5hQ3xwYHF9R8KwWdAhfb/rco81Yv/86efpihdfrzsKh/7GoN7sjllk4i7b1V1v2AnBIg6ydCSDAe8Pb8807VPkv78UmVf0wxwTqv+NTr6zPlowqies65mtx2sQzV1HU/hOCxmQsCYeyzxbZMlq2v1kZUG+8irsX4S/A8PM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by VI1PR0701MB3006.eurprd07.prod.outlook.com (10.173.72.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Tue, 11 Oct 2016 09:31:34 +0000 Message-ID: <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> From: t.petch To: Nick Hilliard References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> Date: Tue, 11 Oct 2016 10:29:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: DB6P18901CA0012.EURP189.PROD.OUTLOOK.COM (10.169.208.150) To VI1PR0701MB3006.eurprd07.prod.outlook.com (10.173.72.148) X-MS-Office365-Filtering-Correlation-Id: 2999eb77-f82f-480f-84ec-08d3f1b964a3 X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 2:5bGDSwPuxERa2Q/ZuLMU9CmR5B+YMZJj+M9FDIQj9MdlHRD+t1HJwhkn1RsZ/CINWUyS2R48n1FaQI2eo0zpGAGAYFBnnG3EDqIDitHlZgBxfJEIIW0Sz46fQFItR2I86SQmwyZNuNh/3ilpDmBFPgGHICP71+fVeOggNkCF9mSA4kVziT5Z6Ofkt5CquoDRD1GcZYg0hGiy5MZfaYilfg==; 3:CcQOjdiwwMvEDkSdzQLntHSeNGltSFT+Q+NvurLD4dPK+75NEu0AyQNMAtLU4LWPvbGeJtRWWQXh15K4gTND1KmpQqUC6jWpjrB42kGnNeOtN8AXHriI13xqH6GUUev6f1NP0mviTf8pYkNmsr1ZmQ==; 25:9NQMss4VtLozRVdCKlwsh2mpuP/KXSaiG46WRlDSDnKU7mXCypA6yQ1QwRRmVbGWWRBQWtgGdJcVneqnjC8vXwziA/9R4n6isnq6pWoW05y7L6ZlznS8s0oMZGC1aAfNwQFDe5L9I5NilrE9S+Et/aO+XART3mgxNbaXy2PKW7TMg0kw/0wJoz3FqwWoTMwDI4Ab1FTl7EjhDds+4TI2h1pjLmnCHHMj/6NV8Ez73f68srrVPzCzkL02a2OUIrswS0OlM4cNpHRg098S3Gf/9gGEfGi/7Tzp9BxQ93YnPkfMbaUsPXW9myZSakOcHEb/7V72uxRn9rsHfboJahc9Yfbdy0uOUMBDT1+uauO5/aI2lXRJHwKVGMU3e1Pyv3qThmi/GSNYned4fPS3LzAz9er6RJawAUUbu8plO9oSEYGeTjfMn/B3FBaM9cQvx6zJ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0701MB3006; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 31:FdP8QTALeiD5q08eoTk/dDnB805caBWPGhI7oe5hLR/4i2E2Qi+IP1JxSQ9MrpKLg/ao/Alwd0CEnJRKAJIsmFve550kgpWuozMiB70WUsa7CYv5KNH/duSAS6nQsYRWMzHCgGtjBJqKhXyYRHtXAVSs9ruhzwrA6wpglEZ22Drfd12WY0QPvF07HIUO2JydDVzNARDSe3Uss60mjsc2+JD9+9455YDACeXrzBCtJaoqGhEgxIHuNVevBgNiDUVaGKnqlmwTc/Nfuel81wNvYw==; 4:zkSFtYXW84olC8U7owdoK0jTfqNTQNpC7QNhis98iZQFdmkS5MU+9avHT+7KDyNqg8t76p+qDkQd1aw1VEW2FY6A7u0DWAO0nTJg4ufhXnVCbSLYZ9r2JyCzsbe6H7vCZ9ZjL8DBk9fEIc9zxD5WwX3vaFBNdNvsAb/kVWIuA2PtiQ1a+76SoothliF/Sw+swsKAozcs18TX9mbH7L/nwHl7tbaJIv2FUUuhi8HYCJd42tujVwQnTX/OUT/XWjAWWUJvOAMa/ZxE0K39yRjaYZEKzKL9oADvo/vx/u7Td0zKny1EUZWCnVZYZdPRMCXihXKUV3qVGXa/lMMm4b2jT+wP0AR0duBlpz92KSnZ4+B2FAgqgyWVp/+Ccu5D1hMoZBCADOWx5LsBSNBc+yRYzg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR0701MB3006; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3006; X-Forefront-PRVS: 00922518D8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(377454003)(51444003)(199003)(13464003)(24454002)(42186005)(14496001)(19580395003)(97736004)(68736007)(76176999)(586003)(81686999)(81816999)(106356001)(101416001)(105586002)(6116002)(3846002)(61296003)(44716002)(62236002)(1456003)(66066001)(189998001)(50986999)(305945005)(19580405001)(92566002)(47776003)(44736004)(116806002)(110136003)(7846002)(7736002)(50466002)(5660300001)(230700001)(81166006)(50226002)(81156014)(77096005)(4326007)(6916009)(9686002)(23756003)(93886004)(84392002)(86362001)(230783001)(1556002)(6666003)(4720700003)(8676002)(33646002)(2906002)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3006; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB3006; 23:OAScFxji/JxWJB0PG33u9mp5Cco79GCb9HFrx?= =?iso-8859-1?Q?BZ4/ke8vn9yC01GiTLsmDfv2lmhylmF9+sxWP9Mr/VUIGU1yNF6c2oLrfv?= =?iso-8859-1?Q?yC+hU+iZgW6MsgqgT4zv1DcQKskEui1/WpNYyzhBHwk7cgQdvmUygWI+Fs?= =?iso-8859-1?Q?UvKixFqbKIb+2HB8XO+YF7rESWkmrQi+248HciQmMr3D7+iyvYykSp5AIF?= =?iso-8859-1?Q?jPrJBZJQtUnkl0HNg1rvfDwoXH1MStx1+7yPK31ScO/iLrXTxzoYMsdFwP?= =?iso-8859-1?Q?Gf5YtahrB3j3n6UJzGMe4vtwV7V4t9U0wiTyEbhFlD8qYl3/LBJsWWwhj6?= =?iso-8859-1?Q?9yQGLrYCqJjGc509utpmMgxI/A2ACS4hRYdwNp17EyJ1KIhurxFmtgVDVw?= =?iso-8859-1?Q?mxHNNhJ6DvxbSG6KOVxWiZL/aUtRIWwY3QA/PEshXepcjwfNsCGrx6oZ1Y?= =?iso-8859-1?Q?6L4KsoEKJMw0Amphr9p9VVu+EZUKtGb8agxltJH1jRmivj7cL/LEdS4H8Y?= =?iso-8859-1?Q?TZFSwhl6uFDGquOfdjRthULr6m6tDJfjSwyN1GBfE3sXtCCT2Mbg9ZmFxT?= =?iso-8859-1?Q?gEPZOGDNodi4oot5Bxe7pc2xn4DlvymVhVgU5HcEz7roA7JvywZYST2gXf?= =?iso-8859-1?Q?UoP9F/mtVmlrnmd+QRLpzqobwJAOf/5yw5evJZ2CsZUYEus++TZRzMZOrV?= =?iso-8859-1?Q?TSepCh/t/XihbsmY9Keze4CmguPMEzpyXjTjYhuE82ynCaaxcj3EoCdQQy?= =?iso-8859-1?Q?jRo4KRVVBtUTW4jlIlAbMglqjMafzhpBes1aZEgt9dqpNmAUEspv1YL0M8?= =?iso-8859-1?Q?hN3EcF5inwIB4ktHmS3Pj38xkuJ0GqZ4UwBRprH1ldYeUDmV1KpGJ+BR1a?= =?iso-8859-1?Q?wlsRYsBcPemA8QW4EAFIZtm99E3xyCaP0dEnIRhXBdV3L/7WSb9sWZlIFa?= =?iso-8859-1?Q?tcENnQB1DyjkvylhDGOoTaKoeUmwtxdB4JAycmETlpg3Wbru9mOlqUMFab?= =?iso-8859-1?Q?8l9bm90EX+Vd+P7opOFa/fLpDy/2c0cdvU9UOdNFntd7wvH9ybpQ26/lcM?= =?iso-8859-1?Q?UI6ZyaV8xN9ivJyxmrgFnxc+k2TXjTNFcwqPC60VIFW3BrdyETFzfMoYz3?= =?iso-8859-1?Q?l/8LuaE0tBpjb9L8zffCZ3AvUSbbTaFUaIhkIuoAgnGXrwBrkBCn5NQN1o?= =?iso-8859-1?Q?u0nhO/oYffO78cVjBNoTdKbAqXOI9kRRYBopocakIvt4ne1qCptHVKdflK?= =?iso-8859-1?Q?JWZTxOOmHlH7yBZsEwRlEh9dYiR2s300kDpAw/Jwzg0HAyrb64oLUeFEN3?= =?iso-8859-1?Q?3LyxXjxOJ5MtzonFpawwMs/pODGZESy+vu44hCAJ0OZoTGP/Ny63wGAziv?= =?iso-8859-1?Q?KtX5GZMGg4NTk4078h+RkoF19qRk9Xs/x+fKKhwfoVsJI5UvOa8vvJCXm8?= =?iso-8859-1?Q?kDBiCbrMKLq5RcHKMeYJ2mKdXxSuEAH81Kvfq3lx7C2bDiXPl7i2cmXYf6?= =?iso-8859-1?Q?Y71kJJ5MHdjVilcpULmB3Kjeo+P/Fg2F4HN03QQ7T2dr82Fq5W7F6tuW5h?= =?iso-8859-1?Q?hZAZwSouEWHrq8Z/u1D0P+I0qhC0=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 6:uj3yv8Fv/ST1xqQkh41TK8puHSY6a+KqK14M0UkdL0VhLzDpKQgHy5UFNxGh28wMNwBaFKhnpmzCUSCzcHDWD/x2Ved6pNjTzIQKx4I2dxyufHUGLwaoHSlBcgQULMj3ZClv2Zu9CntaImz6ZpWI/R6lR0OVyFKxu4o6x03rfC0lD1xIOzdjV1wYwN36AwIimSb+nZXqNbfTajvweSCJxrqx0BcmYF/e8bzAd2dZSxUSY5CLL2WLGqbJBrmdvQ2WB5a7Zes5iNsvr5kcf20MsSGVnVj3UlREgGBnXhdVkm4PhO2Q7cGEJwWJuJWw6XN5; 5:wS7uXH7CWzoJn6g9z3nxvahhUZ/FKwDwyfgYZ2l2hVcIsCF6TVHru09igAYmAS31kdB+JEX1Ru/JBP6BT/xP/TTJcLWlJbwgeqP/Cer+dbfCjLJ3LDE8LpvCX6pGtcfGYcuV4mZ+7DvrXCqjaZmSjA==; 24:9W0c1SiqfRAQgEp5I5aX6TacarnRltRxDY7Q+F+qA/JLiStntfPum1JurF/YdNzJYTFTKG/UMKs2fIBUA4U31/1DFvA3hs6Wiw9nIXn1Auk=; 7:9MEEvILlQyheX/q9cmXBUvF5cKh4wBme279SbDWIq9CYx5nthzDfTUnGfT0tLdel7Rf7cf7Jvo8UA59RMfPfavpIYc7cKse9lnMH5bfd+jO5YVmLUp6Zirpxjwsyi9wQ+AKg0V187ZMIDWOpPQ1L9IV+qrresAaGynmbmXFn014p9Pnv5KvaMPFeMJ5s3hJ+bJbUJpVlfhgARw+OGv2yWD6rZ6fYcRqIEIYi0Ab77tEXT7/JZDMd28YG3yVr53cIGM2hca6nq9k1pIGtWlmFVQTlRUgzbw60IMRSPekoYv2SSduw1ICDLZj/KqZlZF7aSgZkoaV1P2rD1v+a2GdzxLTjhyCLYyYqkM6kKJsL+/0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2016 09:31:34.4369 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3006 Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 09:31:42 -0000 ----- Original Message ----- From: "Nick Hilliard" Sent: Monday, October 10, 2016 12:34 AM > t.petch wrote: > > There is nothing IMHO in > > ' Global Administrator: A four-octet namespace identifier. This > > MUST be an Autonomous System Number assigned by IANA.' > > which says whose ASN it is, just that it must be an ASN; if you allow > > IPv4 addresses, Router ID, IGP Area numbers and so on, anything else > > that fits into 32 bit, then it all breaks down so it MUST be an ASN. At > > a stretch, that wording includes private ASN since those values are > > assigned by IANA although we might want to point that out explicitly. > > There's something I'm not getting here in this discussion. > > Let's step back a bit and start with a principal: "if a policy cannot > be enforced, it is bad policy". > > There is no way a priori for a router to have knowledge of what ASNs > have or have not been assigned, either by IANA or any other assignment body. > > If a standards track document is created which mandates that a specific > identifier field "MUST" contain a ASN assigned by IANA, there is no > practical way for another router to check this. Because the MUST cannot > be checked or enforced in any meaningful way, a formal requirement of > this form automatically falls into the realm of bad policy. > > The best option here is - as Brian noted - to align with 1997 semantics > and make a recommendation to operators that the global administrator > field should be an ASN, and to stay well clear of attempting to define > what an ASN is, or is not. Operators are adults and will do what works > for them; there's no need to be over-prescriptive. Nick I am probably still not being clear. I think that 'assigned by IANA' is a distraction. My concern is with 'SHOULD be an ASN' 'SHOULD' means it need not be so some router manufacturer in response to some customers' requests at some time in the future sees a completely different use for it and puts in a 32-bit value from a different namespace which may well have the same bit pattern as the ASN of one of your peers. You receive such a community and cannot tell, from the protocol, how to interpret this 32 bit value, whether or not it is an ASN. And if you cannot do that, you cannot interpret the rest of the field safely. The only thing you can do is see where it came from, which, being a transitive attribute, you again cannot reliably do from the protocol. So you have to start ringing around your peers, who created this community, is that an ASN or not? Um. I want a MUST in there so if anyone does otherwise, we can say No!, not allowed. I take your point about the lack of enforcement but that is true of everything the IETF does. We have no Internet police; if there is a bad actor, then it is up to peer pressure to get them to change. (And if the bad actor dominates the market, then may be it is the IETF that changes:-( Tom Petch > Nick From nobody Tue Oct 11 02:54:24 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E7612942F for ; Tue, 11 Oct 2016 02:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 QheocuUgKRjz for ; Tue, 11 Oct 2016 02:54:21 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:470:1f0b:8b2::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232D7126D74 for ; Tue, 11 Oct 2016 02:54:21 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 1D3947892E; Tue, 11 Oct 2016 11:54:19 +0200 (CEST) Date: Tue, 11 Oct 2016 11:54:17 +0200 From: Peter Hessler To: "t.petch" Message-ID: <20161011095417.GL19434@gir.theapt.org> References: <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 09:54:23 -0000 On 2016 Oct 11 (Tue) at 10:29:09 +0100 (+0100), t.petch wrote: :----- Original Message ----- :From: "Nick Hilliard" :Sent: Monday, October 10, 2016 12:34 AM : :> t.petch wrote: :> > There is nothing IMHO in :> > ' Global Administrator: A four-octet namespace identifier. This :> > MUST be an Autonomous System Number assigned by IANA.' :> > which says whose ASN it is, just that it must be an ASN; if you :allow :> > IPv4 addresses, Router ID, IGP Area numbers and so on, anything else :> > that fits into 32 bit, then it all breaks down so it MUST be an ASN. :At :> > a stretch, that wording includes private ASN since those values are :> > assigned by IANA although we might want to point that out :explicitly. :> :> There's something I'm not getting here in this discussion. :> :> Let's step back a bit and start with a principal: "if a policy cannot :> be enforced, it is bad policy". :> :> There is no way a priori for a router to have knowledge of what ASNs :> have or have not been assigned, either by IANA or any other assignment :body. :> :> If a standards track document is created which mandates that a :specific :> identifier field "MUST" contain a ASN assigned by IANA, there is no :> practical way for another router to check this. Because the MUST :cannot :> be checked or enforced in any meaningful way, a formal requirement of :> this form automatically falls into the realm of bad policy. :> :> The best option here is - as Brian noted - to align with 1997 :semantics :> and make a recommendation to operators that the global administrator :> field should be an ASN, and to stay well clear of attempting to define :> what an ASN is, or is not. Operators are adults and will do what works :> for them; there's no need to be over-prescriptive. : :Nick : :I am probably still not being clear. I think that 'assigned by IANA' is :a distraction. My concern is with :'SHOULD be an ASN' : :'SHOULD' means it need not be so some router manufacturer in response to :some customers' requests at some time in the future sees a completely :different use for it and puts in a 32-bit value from a different :namespace which may well have the same bit pattern as the ASN of one of :your peers. : :You receive such a community and cannot tell, from the protocol, how to :interpret this 32 bit value, whether or not it is an ASN. And if you :cannot do that, you cannot interpret the rest of the field safely. : That's correct! and by design. Section 1: To address these shortcomings, this document defines a Large Community BGP Attribute encoded as one or more 12-octet values, each consisting of a four-octet ASN and two four-octet operator-defined values, each of which can be used to denote properties or actions significant to that ASN. Section 2: The Global Administrator field is intended to allow different Autonomous Systems to define Large Communities without collision. Implementations MUST allow the operator to specify any value for the Global Administrator field. The vendor is NOT allowed to squat on the GA field. :The only thing you can do is see where it came from, which, being a :transitive attribute, you again cannot reliably do from the protocol. :So :you have to start ringing around your peers, who created this community, :is that an ASN or not? : The entire large-community attribute is opaque, and only has meaning to the entity that created it. Inferring your own meaning from it can't work. :Um. : :I want a MUST in there so if anyone does otherwise, we can say No!, not :allowed. : As an implementor, we MUST NOT use a MUST here. ;) Putting my own ASN, or the ASN of my peer that I wish to control, will be the main uses; I agree. But there is a difference between SHOULD and MUST. Since I MUST allow users to change the value there, I am happy. -- In specifications, Murphy's Law supersedes Ohm's. From nobody Tue Oct 11 04:09:56 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C9D1294E5 for ; Tue, 11 Oct 2016 04:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 OlWxAepXIgep for ; Tue, 11 Oct 2016 04:09:53 -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 1C2341296DC for ; Tue, 11 Oct 2016 04:09:48 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u9BB9hNq086170 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2016 12:09:44 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <57FCC876.5090109@foobar.org> Date: Tue, 11 Oct 2016 12:09:42 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.4 (Macintosh/20161007) MIME-Version: 1.0 To: "t.petch" References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> In-Reply-To: <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 11:09:55 -0000 t.petch wrote: > I want a MUST in there so if anyone does otherwise, we can say No!, not > allowed. If an operator in the far depths of inner Kaboodlestan uses an IPv4 address instead of an ASN, the IETF can disapprove all it wants, and it will make no difference to anyone. For inter-as signaling, no-one is going to accept anything other than an ASN, but even if they do, it doesn't matter that much. Communities are not redistributed by default on ebgp sessions, and when they are, the normal operation is to strip off anything not related to the next-hop ASN. So in practice, the distribution radius for most communities mappings tends to be quite small. Nick From nobody Tue Oct 11 04:30:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CB4129473 for ; Tue, 11 Oct 2016 04:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 FrAbdaFoad4E for ; Tue, 11 Oct 2016 04:30:46 -0700 (PDT) Received: from ex1.workonline.co.za (ex1.workonline.co.za [197.157.92.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A401294AC for ; Tue, 11 Oct 2016 04:30:39 -0700 (PDT) Received: from EX2.workonline.co.za ([fe80::8572:d946:2c81:17bb]) by ex1.workonline.co.za ([fe80::f84f:93b7:a923:f286%14]) with mapi id 14.02.0387.000; Tue, 11 Oct 2016 13:30:35 +0200 From: Ben Maddison To: Nick Hilliard , t.petch Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt Thread-Index: AQHSG79f4gLPfLBG50exCsj8QwL4bKCTKdYAgANQzs3//+YHAIAAOUPw///npoCAAD/ogIAGEmvK///0cYAAFJAmAAAnwL+AAAelkQAAIVOd/gAX8aMAAEtfbkr///m3AP//3YuQ Date: Tue, 11 Oct 2016 11:30:34 +0000 Message-ID: <874E439F335FD742B8D1565730E537E0011C10EA21@ex2.workonline.co.za> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> In-Reply-To: <57FCC876.5090109@foobar.org> Accept-Language: en-ZA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2c0f:fa90:2000:204:8567:ee20:86a4:b5a3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 11:30:49 -0000 Hi all, I'm rather struggling to see the point of this debate. There is a thing abo= ut ducks that comes to mind ("if it walks like an ASN..."). Surely what we're really concerned with is on the receiving/interpreting en= d, where (in the inter-AS scenario) the authority responsible of assigning = meaning to a large-comm of the form 64500:X:Y is expected to be the operato= r of AS64500. This is already clear to me from section 2: "The Global Administrator field is intended to allow different Autonomous Systems to define Large Communities without collision" Nick is entirely correct that this intention is not enforceable in any mean= ingful way, so I really don't think it is worth spending additional time an= d energy defining it more narrowly. Cheers, Ben Maddison Director Workonline Communications (Pty) Ltd Office:=A0=A0=A0=A0 +27 (0) 21 200 9000 Mobile:=A0=A0 +27 (0) 82=A0415 5545 Email:=A0=A0=A0=A0=A0 benm@workonline.co.za SIP:=A0=A0=A0=A0=A0=A0=A0=A0=A0 benm@workonline.co.za -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Nick Hilliard Sent: Tuesday, October 11, 2016 1:10 PM To: t.petch Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt t.petch wrote: > I want a MUST in there so if anyone does otherwise, we can say No!,=20 > not allowed. If an operator in the far depths of inner Kaboodlestan uses an IPv4 address= instead of an ASN, the IETF can disapprove all it wants, and it will make = no difference to anyone. For inter-as signaling, no-one is going to accept anything other than an AS= N, but even if they do, it doesn't matter that much. Communities are not r= edistributed by default on ebgp sessions, and when they are, the normal ope= ration is to strip off anything not related to the next-hop ASN. So in pra= ctice, the distribution radius for most communities mappings tends to be qu= ite small. Nick _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Tue Oct 11 07:07:59 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E1B129548 for ; Tue, 11 Oct 2016 07:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 G1nEzGQJf6Ma for ; Tue, 11 Oct 2016 07:07:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E49091294C5 for ; Tue, 11 Oct 2016 07:07:52 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 919021E1F0; Tue, 11 Oct 2016 10:09:49 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: Jeffrey Haas In-Reply-To: <57FCC876.5090109@foobar.org> Date: Tue, 11 Oct 2016 10:07:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.2104) Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 14:07:57 -0000 > On Oct 11, 2016, at 7:09 AM, Nick Hilliard wrote: >=20 > t.petch wrote: >> I want a MUST in there so if anyone does otherwise, we can say No!, = not >> allowed. >=20 > If an operator in the far depths of inner Kaboodlestan uses an IPv4 > address instead of an ASN, the IETF can disapprove all it wants, and = it > will make no difference to anyone. Somewhat relevant example in other extensions: Many implementations treat an add-paths path-id as an integer and you = tend to see them showing up as a int in show commands. At least one implementation chose to use a BGP identifier/IP address in = theirs. The spec treats the value opaquely. Both use cases make sense in their = own context. End of the day, the protocol cares that it's a 4 byte value. Users may = want a given representational syntax because it makes their life easier = in their particular scenario. Neither is solely the Right Thing. -- Jeff From nobody Tue Oct 11 08:29:59 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B66B129602 for ; Tue, 11 Oct 2016 08:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 7MleDTe3H6D3 for ; Tue, 11 Oct 2016 08:29:56 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 16A7B12962E for ; Tue, 11 Oct 2016 08:29:56 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1btz06-00059G-J7 (job@us.ntt.net); Tue, 11 Oct 2016 15:29:55 +0000 Date: Tue, 11 Oct 2016 17:29:50 +0200 From: Job Snijders To: idr@ietf.org Message-ID: <20161011152950.GY57491@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Subject: [Idr] FW: Large BGP Communities beacon in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 15:29:58 -0000 This message was posted to various operational mailing lists. TL;DR - there are now two beacons carrying a Large BGP Community in the DFZ. On IPv4 we observe full coverage from the NLNOG RING LG - on IPv6 not so much. Kind regards, Job ----- Forwarded message from Job Snijders ----- Date: Tue, 11 Oct 2016 17:01:56 +0200 From: Job Snijders To: nanog@nanog.org, routing-wg@ripe.net, Jared Mauch Subject: [routing-wg] Large BGP Communities beacon in the wild Dear all, Large BGP Communities are a novel way to signal information between networks. An example of a Large BGP Communities is: 2914:4056024901:80. Large BGP Communities are composed of three 4-octet integers, separated by something like a colon. This is easy to remember and accommodates advanced routing policies in relation to 4-Byte ASNs. It is the tool that has been missing since 4-octet ASNs were introduced. IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) in the "BGP Path Attributes" registry under the "Border Gateway Protocol (BGP) Parameters" group. The draft can be read here: https://tools.ietf.org/html/draft-ietf-idr-large-community Additional information about Large BGP Communities can be found here: http://largebgpcommunities.net/ Starting today (2016.10.11), the following two BGP beacons are available to the general public, with AS_PATH 2914_15562$ Both these prefixes have a Large BGP Community attached: 2001:67c:208c::/48 192.147.168.0/24 Large BGP Community - 15562:1:1 The NLNOG RING BGP Looking Glass is running the latest version of BIRD which understands the Large BGP Community Path Attribute. IPv4 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.147.168.0/24 IPv6 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:67c:208c::/48 In theory, since this is an optional transitive BGP Path Attribute, all the Looking Glass' peers should boomerang the Large Community back to the LG. However we currently observe that 50 out of 75 peers propagate the Large BGP Community to the LG. Relevant Router commands to see if you receive the attribute, or whether one of intermediate networks has stripped the attribute from the route: IOS: show ip bgp path-attribute unknown shows all prefixes with unknown path attributes. IOS #2 - like on route views: route-views>sh ip bgp 192.147.168.0 BGP routing table entry for 192.147.168.0/24, version 98399100 Paths: (39 available, best #30, table default) Not advertised to any peer Refresh Epoch 1 701 2914 15562 137.39.3.55 from 137.39.3.55 (137.39.3.55) Origin IGP, localpref 100, valid, external unknown transitive attribute: flag 0xE0 type 0x1E length 0xC value 0000 3CCA 0000 0001 0000 0001 rx pathid: 0, tx pathid: 0 IOS-XR: (you must look at specific prefixes) RP/0/RSP0/CPU0:Router#show bgp ipv6 unicast 2001:67c:208c::/48 unknown-attributes BGP routing table entry for 2001:67c:208c::/48 Community: 2914:370 2914:1206 2914:2203 2914:3200 Unknown attributes have size 15 Raw value: e0 1e 0c 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ JunOS: user@JunOS-re6> show route 2001:67c:208c::/48 detail 2001:67c:208c::/48 (1 entry, 1 announced) AS path: 15562 I Unrecognized Attributes: 15 bytes Attr flags e0 code 1e: 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A note about router Configurations: Ensure you are not fitlering the path attributes, eg: JunOS: [edit protocols bgp] user@junos# delete drop-path-attributes 30 XR: configure router bgp YourASN attribute-filter group ReallyBadIdea ! avoid creating bogons no attribute 30 ! ! Contact persons: myself or Jared Mauch or NTT NOC. BGP Session identifier 83.231.213.230 / 2001:728:0:5000::a92 AS 15562. Kind regards, Job ----- End forwarded message ----- From nobody Tue Oct 11 11:51:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63B9129671 for ; Tue, 11 Oct 2016 11:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 kLsT6cp4xx3n for ; Tue, 11 Oct 2016 11:51:33 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 95BD6129586 for ; Tue, 11 Oct 2016 11:51:33 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bu29E-0006rI-E8 (job@us.ntt.net); Tue, 11 Oct 2016 18:51:33 +0000 Date: Tue, 11 Oct 2016 20:51:29 +0200 From: Job Snijders To: idr@ietf.org Message-ID: <20161011185129.GB57491@Vurt.local> References: <20161011152950.GY57491@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161011152950.GY57491@Vurt.local> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Subject: Re: [Idr] FW: Large BGP Communities beacon in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 18:51:35 -0000 On Tue, Oct 11, 2016 at 05:29:50PM +0200, Job Snijders wrote: > This message was posted to various operational mailing lists. > > TL;DR - there are now two beacons carrying a Large BGP Community in the > DFZ. On IPv4 we observe full coverage from the NLNOG RING LG - on IPv6 > not so much. We tracked down the IPv6 discrepency: All the looking glass peers that don't propagate the Large Community to the Looking Glass are Cisco IOS boxes. These IOS boxes won't send attribute 30 (and possibly other unknown attributes) over IPv6 BGP sessions which are _not_ configured with 'send-community'. Kind regards, Job From nobody Tue Oct 11 15:03:05 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4C61295BA for ; Tue, 11 Oct 2016 15:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hOt_IQxC3gAk for ; Tue, 11 Oct 2016 15:03:01 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B786A12946C for ; Tue, 11 Oct 2016 15:03:01 -0700 (PDT) Received: by mail-pa0-x22f.google.com with SMTP id vu5so21544072pab.0 for ; Tue, 11 Oct 2016 15:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JtVijxeXd//+HWPsVIr01sNG/2krRbcoZkvC3PqqiJw=; b=gpu0KamnB8zMwx2vQw+/KL6RMCeAuqrK/XjQGxukdOHW1WUOHqmErrD9cgPB5dvLVI eITgrOIc2R+jarXfe7O6BZD0K2eR4Wd3v8Exhqojnlf//aaN7vkovomSDJLgBLKlepbd qdTt0YQfc/NYjE+fDDwc4dtnhD+AaAwJvktuYE/TBqUVFqHebavRtZXdqWTIYlDhEhHg 5DvQNTiRgR5dq7BISfbUuSMlCtlWaWV47mDAGrWLOSQqlshhTx5ug8uAR0CRDVCEPjCq glEIv7IHPhjFTyFTVmcQ2QxGIPHTYkTjiz4pot6NTHz3OvMAn46AbRv23APIEZiCoro4 WJhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JtVijxeXd//+HWPsVIr01sNG/2krRbcoZkvC3PqqiJw=; b=iUgDzSKvYXN/3qS67WaC4vomH+3S2GBCLG2d2909d1Ues/tUZP4X32UfI/t5QlKgY/ 0UChnoTnNLi5ztTMzUhPZfZpub849/C6QQcg1g1EZzw76u+AuNI1IMCB/msg/uDK62sn Z64XDRY/I2wFyTdeGewqhewZ00Ll69NXLgLcs5Jv/6rXP6p5OhPYMi0GN0fr6nIfMPbE kPf9ln+alqiu3lthDlbF/sl/kwhHzsXv+JlIV3lA4qPEqNszqrjTZpRCBiBoZ3zgeWVh V+Vcldm2YOmKCy7ZQCp/2bw3cNZPiKV1DcgMAmYc6DVIEEzrU3jY5c5GDzJ/t5fPBJ/y 7RKg== X-Gm-Message-State: AA6/9RmSVj1PDwBNayJcG7cOvjC26ufJve2zy/2cXEOvwDePeYuulPCZGOmhxnDWJf205A== X-Received: by 10.66.2.101 with SMTP id 5mr10364253pat.118.1476223381027; Tue, 11 Oct 2016 15:03:01 -0700 (PDT) Received: from [192.168.5.105] (c-73-92-109-167.hsd1.ca.comcast.net. [73.92.109.167]) by smtp.gmail.com with ESMTPSA id h130sm6616026pfe.35.2016.10.11.15.02.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Oct 2016 15:02:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (14A456) In-Reply-To: <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> Date: Tue, 11 Oct 2016 15:02:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> To: Jeffrey Haas Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 22:03:04 -0000 Top-reply for clarity. Apologies if doing so offends anyone. Here's the rationale for MUST (vs SHOULD): - there is NO difference in what implementations need to do - there IS a difference in what operators are able to do if/when collisions o= ccur=20 What I believe Tom was trying to articulate is this: If some sends Large communities which start with HIS_ASN, he needs this MUST= to use as a clue-by-four in communicating with the offending party. If it is only a SHOULD, it removes the only tool available with which to app= ly pressure.=20 (Do the math on the odds of unsigned 32-bit integers above 132K from differe= nt number spaces colliding, if those number spaces are not sparsely populate= d, and assigned in a sequential manner. The odds are "1, eventually".) Squatting on assigned number resources is a horrible thing to deal with. I p= ersonally have had an IPv4 prefix squatted on, and that was something where t= hings were significantly impacted. It is not likely to happen, and if it does, it is very likely not malicious.= However, without this MUST, the usefulness of Large communities are potenti= ally impacted. Please, let us have the MUST. It has no impact to implementers, and a huge benefit to operators. Brian Sent from my iPhone > On Oct 11, 2016, at 7:07 AM, Jeffrey Haas wrote: >=20 >=20 >> On Oct 11, 2016, at 7:09 AM, Nick Hilliard wrote: >>=20 >> t.petch wrote: >>> I want a MUST in there so if anyone does otherwise, we can say No!, not >>> allowed. >>=20 >> If an operator in the far depths of inner Kaboodlestan uses an IPv4 >> address instead of an ASN, the IETF can disapprove all it wants, and it >> will make no difference to anyone. >=20 > Somewhat relevant example in other extensions: > Many implementations treat an add-paths path-id as an integer and you tend= to see them showing up as a int in show commands. >=20 > At least one implementation chose to use a BGP identifier/IP address in th= eirs. >=20 > The spec treats the value opaquely. Both use cases make sense in their ow= n context. >=20 > End of the day, the protocol cares that it's a 4 byte value. Users may wa= nt a given representational syntax because it makes their life easier in the= ir particular scenario. >=20 > Neither is solely the Right Thing. >=20 > -- Jeff >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Oct 11 15:15:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859CE129550 for ; Tue, 11 Oct 2016 15:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 zCMG0ZZkO74K for ; Tue, 11 Oct 2016 15:15:45 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47ED61293D9 for ; Tue, 11 Oct 2016 15:15:45 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 08CD07B9A7; Tue, 11 Oct 2016 22:15:44 +0000 (UTC) Date: Tue, 11 Oct 2016 22:15:44 +0000 From: heasley To: Brian Dickson Message-ID: <20161011221544.GG12806@shrubbery.net> References: <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 22:15:46 -0000 Tue, Oct 11, 2016 at 03:02:57PM -0700, Brian Dickson: > - there IS a difference in what operators are able to do if/when collisions occur which is nothing. there is no enforcement. leave it alone. From nobody Tue Oct 11 18:57:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B02129436 for ; Tue, 11 Oct 2016 18:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rob-sh.20150623.gappssmtp.com 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 6MPcbQ-7JQj7 for ; Tue, 11 Oct 2016 18:57:52 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA48129445 for ; Tue, 11 Oct 2016 18:57:50 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id o19so41170881ito.1 for ; Tue, 11 Oct 2016 18:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rob-sh.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=aEeLBExJ3tqJHIiPZCrPSXk0aMvnBHcM4i0Ug9kthwg=; b=QR7EEOFe9YKO96RwVcmHxFAjuxJx9Zc+LmiPacfqDYMzjXNaFmpx1CZzszlYiyu7AZ JqNePMposnkhmjifjUerfyPlIWQBJmb21UMOp0kjKlku658jRJ5ZnxvCxzO72EqgNY4P v/b9xR5/EC30HWXx4ffL1xVLkYzHTedGVvTu95gL/mobyb/6aNUsbeKZtgYUUVj0nfJl S44R4LyKgPN4g8I/IzmJijOYmkO/BtC1/m1SUZNiKGocVuleUHCTJzlOI4GavtsoJs2t WE/6t487bTeLRSZsPD/37fZK3VntcMekrTN+Veb4s6ZDMdjJuT1gsdAk7jg8j2kenM8F sdBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=aEeLBExJ3tqJHIiPZCrPSXk0aMvnBHcM4i0Ug9kthwg=; b=YYLa8jCMilWbU1RmDLlb8P2/o+fj87ttP3609y4gsaaJCbUUX8YP6pxYoORBa4FCQP 5CCcWyybV4YqwNmZ8hGKr/w8h7sj32CvV4pvWGQr7ArkUDsBvHkY3eOuZxC8Vg8CxJ7E Xf7A+vSZq8qF/xNX34GfwU3HLwa8tZ1mfkGmtqV1/sm0GldCxubYy1ADhGAEVuQK907S L3t2MLXHK7IF00mnvEoqgqfKDHEyW9nvq/ZgvhFo8fZzurhwEmBW3FvmQ7bec/6AlFkK 7uau8C1foFL1Qjy4FvirSaQpzAwdA+Su07qTBUWpwuEBYLYxJJLdXoxx0AmSZTK/EJ0j ZOnw== X-Gm-Message-State: AA6/9Rnb5jLWyt1g/lduOQGolKXHPIinrJeTosfAXS63Hz5ZSmH2QJEiTJ8ROyj3xo5EdHKiYRz6HQzJi4h3mg== X-Received: by 10.107.51.140 with SMTP id z134mr1049717ioz.23.1476237469536; Tue, 11 Oct 2016 18:57:49 -0700 (PDT) MIME-Version: 1.0 References: <0E9469C4-2B72-484A-9C93-BC13401F6889@pfrc.org> <003901d21f20$95ece2f0$c1c6a8d0$@ndzh.com> In-Reply-To: <003901d21f20$95ece2f0$c1c6a8d0$@ndzh.com> From: Rob Shakir Date: Wed, 12 Oct 2016 01:57:39 +0000 Message-ID: To: Susan Hares , Jeffrey Haas , IETF IDR WG Content-Type: multipart/alternative; boundary=001a113f0a10fa0f6a053ea15144 Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 01:57:54 -0000 --001a113f0a10fa0f6a053ea15144 Content-Type: text/plain; charset=UTF-8 Jeff, I am interested in the working group pursuing this draft. The pressure behind large community seems (to me) to be very short-term focused [0]. Operationally, I understand the requirement, but we should also be improving the infrastructure that we have in BGP. There are numerous use cases for BGP, many of which are not Internet DFZ focused. As part of this infrastructure, I believe that in the longer term, we need the ability to do attribute scoping in a more robust way. The current definitions of non-transitive and transitive are overly coarse for today's heterogeneous networks. It is particularly important to me that we look beyond confederations as the only means of grouping autonomous systems. Cheers, r. [0]: This isn't to say that isn't required, I don't want to debate that any further as I am pretty sure the horse that we're beating is little more than a skeleton at this point. See https://www.ietf.org/mail-archive/web/idr/current/msg16051.html On Wed, Oct 5, 2016 at 8:54 AM Susan Hares wrote: Jeff: My reading of the list that: a) Large communities meets an "urgent/crisis level need" b) Wide communities and bgp-attribute-announcement - meet a longer term need. Did I miss understand the list's comments? Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Wednesday, October 5, 2016 11:49 AM To: IETF IDR WG Subject: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? In theory, by adoping draft-ietf-idr-bgp-attribute-announcement, IDR agreed that attribute scoping was an important issue. As proven by the working group discussion on BGP large communities, the WG seems unwilling to consider anything that adds any level of complexity onto certain proposals. Should we simply consider this draft dead? -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --001a113f0a10fa0f6a053ea15144 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeff,

I am intere= sted in the working group pursuing this draft. The pressure behind large co= mmunity seems (to me) to be very short-term focused [0]. Operationally, I u= nderstand the requirement, but we should also be improving the infrastructu= re that we have in BGP. There are numerous use cases for BGP, many of which= are not Internet DFZ focused. As part of this infrastructure, I believe th= at in the longer term, we need the ability to do attribute scoping in a mor= e robust way.

<= div class=3D"gmail_msg">The current definitions of non-transitive and trans= itive are overly coarse for today's heterogeneous networks. It is parti= cularly important to me that we look beyond confederations as the only mean= s of grouping autonomous systems.

Cheers,
r.

[0]: This isn't to say that isn't required, I= don't want to debate that any further as I am pretty sure the horse th= at we're beating is little more than a skeleton at this point. See=C2= =A0https://www.ietf.org/mail-archive/web/idr/current/msg16051.html


On Wed, Oct 5, 2016 at 8:54 AM Susan Hares <shares@ndzh.com= > wrote:
Jeff:

<individual contributor hat on&g= t;



My reading of the= list that:

a) Large communities meets an "= urgent/crisis level need"

b) Wide communiti= es and bgp-attribute-announcement - meet a longer term

need.



Did I m= iss understand the list's comments?



Sue

-----Original Message---= --

From: Idr [mailto:idr-bounces@ietf.org= ] On Behalf Of Jeffrey Haas

Sent: Wednesday, Oct= ober 5, 2016 11:49 AM

To: IETF IDR WG

Subject: [Idr] draft-ietf-idr-bgp-attribute-announcement= dead on arrival?



In= theory, by adoping draft-ietf-idr-bgp-attribute-announcement, IDR agreed
that attribute scoping was an important issue.


As proven by the worki= ng group discussion on BGP large communities, the WG

seems unwilling to consider anything that adds any level of complexity= onto

certain proposals.
=


Should we simply consider this draft dead?<= br class=3D"gmail_msg">


-- Jeff



________________________________= _______________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr



_____________________________________= __________

Idr mailing list

Idr@ietf.org

https://www.ietf.org/mailman/listinfo/idr

--001a113f0a10fa0f6a053ea15144-- From nobody Wed Oct 12 02:05:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC841294A9 for ; Wed, 12 Oct 2016 02:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=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 s0erm0Q8UCDM for ; Wed, 12 Oct 2016 02:05:55 -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 D3C26129486 for ; Wed, 12 Oct 2016 02:05:54 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B2FCB6067E for ; Wed, 12 Oct 2016 11:05:51 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id D35116010B; Wed, 12 Oct 2016 11:05:50 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id C2B3A43179; Wed, 12 Oct 2016 11:05:50 +0200 (CEST) Date: Wed, 12 Oct 2016 11:05:50 +0200 From: Gert Doering To: Brian Dickson Message-ID: <20161012090550.GW79185@Space.Net> References: <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 09:05:57 -0000 Hi, On Tue, Oct 11, 2016 at 03:02:57PM -0700, Brian Dickson wrote: > What I believe Tom was trying to articulate is this: > > If some sends Large communities which start with HIS_ASN, he needs this MUST to use as a clue-by-four in communicating with the offending party. But that is easily solved today by a) commercial arrangements, and b) filters. If someone tags a community with 5539:xxx today, which might or might not have any meaning inside my AS, 5539, I will only accept this community from BGP peers that have a corresponding commercial relationship (typically, customers, that are allowed to influence "announce-here", "prepend-there", etc.). >From anyone else, I will not accept 5539:x communities. Should I care if anyone else out there (40000+ networks) is using 5539:xx for something else? Should I act? Why? > Squatting on assigned number resources is a horrible thing to deal with. I personally have had an IPv4 prefix squatted on, and that was something where things were significantly impacted. IPv4 prefixes have global significance. Communities have not. 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 Wed Oct 12 02:12:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C4512948B for ; Wed, 12 Oct 2016 02:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 5dUIyWrinTdE for ; Wed, 12 Oct 2016 02:12:00 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40135.outbound.protection.outlook.com [40.107.4.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF4C129445 for ; Wed, 12 Oct 2016 02:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Bx8VV9+O2ieV0+5Vdk8HHi3zNCvEmJ7r7bkWoRedULo=; b=iM9Uc/3RUUAMk3lMTXzA3+oVeSiF/JnCV6Xhq0mkyR/mfZtYeW1jbZibSyjJt27RO6TsEdUyg4nOPIqOgnTQ41ZPtNyX64tluKzIL66v3ZzjsvSs5jowCtM94eIpIubYx01so7fWA5daT6uOSoUKSywG6J67DwwMDc0vgT8qs10= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by DB6PR0701MB2999.eurprd07.prod.outlook.com (10.168.84.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Wed, 12 Oct 2016 09:11:57 +0000 Message-ID: <012301d22468$5d4271c0$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> Date: Wed, 12 Oct 2016 09:49:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: HE1PR10CA0040.EURPRD10.PROD.OUTLOOK.COM (10.167.243.178) To DB6PR0701MB2999.eurprd07.prod.outlook.com (10.168.84.137) X-MS-Office365-Filtering-Correlation-Id: b399c414-da58-4e97-eabd-08d3f27fd1bd X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 2:TbGm5N+h0aUFMtjz8Qnry28P4VAwQqq3YM0Y2TelOVF40EzPVekIVB6NAiRNs9MX83UGfYWOVup9E6u5iIHeaZ9IlAdb2FGQGoTjwiNd3QB0Kk0HH3FoS0FN3Ofq3C6DN4qLzisluMXmtt6V4XqZYIF5uRISe2aMsWlz8UK6K+Yll8GYS+cmsekbp20YtqqJph+VJSFiCxAkoTnI6vPSFA==; 3:TJ/wlDOxTySA5QWuf6ulLYT+EfP98abH/jAxT34Rp9Q57FPPwiNtCDmOw0TJUrCfXvTIGjnTvK4+6rEVLcWAWxKpqtMAvolbFbheEDJLFnTNA6DNstJvmkExXKPRtNf4E/7k6PVM2UdQiC8+FB/m3A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0701MB2999; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 25:ugavHhr9chox2Hn39ZFvzEPUhmPDSl+SVUi0BgWDLmxhrhC2ZvgBvBwYZhcmeEEH/cIMAlsy9EcufbiQwKDababFePHsgCi0LDc45XOZ8HOpi9iqVVZcN9sw734IC2YI93LfTeUJj3eNKOPmOlBqMKtMYIuBI4Ke9js3M5c1Bdf/ycuSUUTaTI/Fi8VUffHm+QI7WFmDQumDE3ymndrMNYNrYIALMSj8OkuD3atvVJTzWtExgu54Zn7MuOFwQ31kD9+T/wk2NF8Q7e5F3Hvyy4l3J160+3BfNDbsWvC95NtQewjy0XNriwwGLuAS4Xt4ar4CI38aP1fwqOV004vB4DbshDyfXJ3R/CatEjZp9SDUManGl572hqxQ+4IZ71a2VMpPOagvPM4lb04gWuOrvz3VE8gu9Gt2xUcacAPE2aOQy3DBtbMxSoA09a9Y5R/vOiZG3id285wTZWYqH6Rla/UWOgIww66899M1gHE0IeIACiwFEraobU8P23j5Pk/OjTyY4knVQ1TkrVS8TzJvdwi4HfO2jvmTNIpGSlKX0OSKJ+zknCyzPA/bLNr5jGe4QN+IxpJP4/omPaUZdxNlHMqQdpk5IJK0iqah4TrdiJSS18hzghSAec95QkBL1xN2CD4fBF7wCs5xkPmOiKpwQJ9xwuC6HRz9qTLWwcc5m/7Zb2fn5W+Vo5WVd/aXhb3FtpfPm6lldxzBlyGIk4ONiA== X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 31:mqoeZbsyrTc2HsM8Cdn+fG4B4K4ZagCA3K2EpDreqWbnbnx+/vPpYBGt/FfQML85UMgi/w04/rCc6XQggZJtcElQ55XH964B8yPWLC3SPC5oQyL/BiW/5/5/FlDI6WU2hGD4FtIxJptYFtvjvTaCSgn69/X4TWj6xuPinszvFZvPUmCkzlXdnij7Ou7Ld+dOKS5ANXLGNQrfVyTYW0GnC3Z+eIlTvVQUweNUnmljhumULfbTVpKuaAZ0LGixjJ6l; 4:I90Yp//6CO94QIWhb9HyH3TSuHOAl02Wo1XsRorx3qIoVgRvCh70JM5RVvhxIfIolevTMFV3xl4Z/UDurkfrdIheM0oFu9DUy8PwG88zs29+GQRCbB8VqyQVT8oTaAItryrWhEt8AGug6vzs3igCOKD18lLKvcPRSdD2u+6c7FRTQaHZqC+S5bnsYftaKxu3xC9n3IzPS1pr52kgRPxd94TFzWVkoKZDEsjcJvI05zJPaLHyyxOKjulgoUOHdixG76NE7CbEnAtOSlVuNm6HWCiuz9KL24MCfJsrgFzTW1Y1hSfuBK7dPJQTZDNtDB9f++FfF4LZRjTCOucXlBSAql8T4RfYOcbbbVIcXVdTwoHA9itRlSUGsMIqzF927Y5vn3t0X5RHAcsoJ745vCq9VQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB6PR0701MB2999; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2999; X-Forefront-PRVS: 0093C80C01 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(199003)(24454002)(377454003)(13464003)(66066001)(33646002)(7846002)(47776003)(305945005)(84392002)(7736002)(4326007)(50986999)(81686999)(81816999)(76176999)(97736004)(3846002)(19580395003)(19580405001)(6116002)(586003)(44716002)(62236002)(101416001)(50226002)(68736007)(6666003)(6916009)(9686002)(14496001)(92566002)(61296003)(116806002)(93886004)(81156014)(81166006)(2906002)(42186005)(105586002)(230783001)(230700001)(8676002)(106356001)(23756003)(5660300001)(189998001)(110136003)(1556002)(1456003)(77096005)(86362001)(50466002)(4720700003)(44736004)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2999; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB2999; 23:4IHsqajVQf9gBaixxhIJjC4LXxV+8n7csoarj?= =?iso-8859-1?Q?QYtsG+l5dZGhgCSMhXO+Zf9Sx4a3d3F1NG3FyMHrSZvpvxs6mOotk4/OE3?= =?iso-8859-1?Q?y+kKRf5Dh+DmwOJH1oCadZmkNbsbd+rW1tuxYPKkGgjPqn7dPtxikuRjMe?= =?iso-8859-1?Q?9jDTVpOo2ZZGP+0+4T+n3D7ZDjY58wNtRfKIf+rwF9XgXMaIuVG7p1GqQG?= =?iso-8859-1?Q?ApgnaI0zy6/DmR4pZTZXlsGkcirgCBIJiZisaQlLDIm1GG7xsKLvCV/713?= =?iso-8859-1?Q?49CZdrLHFSpTKX1UGtx8BJYXhvhR4gkoVc179MaFHIFFnYc3gViH0hXpMN?= =?iso-8859-1?Q?KLdhsSr//CDMsHttkQi8yy94WLmdSh/3YgWdmTgGG3GLwEeJubwVX+27Lr?= =?iso-8859-1?Q?lytx9BPtexgSKrvkyKnCqo+IgYBj1q4VhBya4H55O9rUhq2fee5+ZVSspH?= =?iso-8859-1?Q?G/mAJXdZCHWq0SJGWCsFrfwleBZlueBdI+Opzx60hguANAQqNv8rMLnQqg?= =?iso-8859-1?Q?7dLKce0T654G81SdRAcWdRcHoyuTc5deB65tcO6LbvIRM5dJdbM7tKG0JY?= =?iso-8859-1?Q?/jbbGK5TOHprSRtze99fIxGPYtjBRiHr2Ab8z1RdzfTwRKzGX15ytxFqhK?= =?iso-8859-1?Q?BHzBJ5VE4gq2SDvJ+N2hyuGmMUYbTYNknuDkS7my1Hn7HuUUdBcGHRmnsw?= =?iso-8859-1?Q?IBuuMosW+jwWTKsiMgwksWUjGpUwyqWLrcGt0Y0QaiyGOHr+1cwmc/CehQ?= =?iso-8859-1?Q?MkQVMlHnuX5TeDalNANehgCE2IY1nIEUR2uEa64N5WYxAui+Mva8d3XPhA?= =?iso-8859-1?Q?Y32gztVGsUKiwXGoJWIXbY+kFPxXcbukHJfOfpaAOw4hG0geIz9XyhvNyv?= =?iso-8859-1?Q?21amm/V6Ms2bsVcVfNwDvkW8QcMhmifrFKOFBf0rQH+AjTeFb3XCn+/IQG?= =?iso-8859-1?Q?pddo0FjiOWVPBQBlAW8u/pmzWzcJoQ6WRKVk81bRFBUTFEcc7U9+MkTQzh?= =?iso-8859-1?Q?pBBpJBKvNkcu/qYtvyWhfZ96F9swcvErtPUlyQCeOONijd8uupPE/COf9p?= =?iso-8859-1?Q?O9hDwm0C9vU1CtlHXSVY+05qE89+NnwQ3knB/+235tr8zXT1CBIK67LaVD?= =?iso-8859-1?Q?BuW1zQC9Bj22yvmVv94N4iicQxKXTB6dx/YqDI4JSjpm8ynN+ldnkM0nUc?= =?iso-8859-1?Q?rHTev90ARko017ObdKP0hPNsjK1ynsbco0T6dqPHimLzK85phLRvaheY1h?= =?iso-8859-1?Q?EIOvjxeKdn8CNMaCiqHQ3Td/iX4pE8OcNs9BgbIVRqOIK1xhVmNkSYjXui?= =?iso-8859-1?Q?IO22nd33sGWb9YWKXAtO3HtvfrFTQZHqL6avH2JWUV4gBlwbRZcIqoGZRm?= =?iso-8859-1?Q?E1cBP5pP9cUJhM0sYSuAl/REghewzM5H+S7LoKobHMIuO8HjYEZB4Aj+zb?= =?iso-8859-1?Q?ou6aoqF0d9pG18TAyAPohM98YELPffWskKRmrnXD7I6GyWnC0cLWWO0Br3?= =?iso-8859-1?Q?DV/jPX9aBYRFIvJngerQw2ugVCoE7QU0gSlav1Loa+ssyg4tPZXmLAV61w?= =?iso-8859-1?Q?8QmNkcA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 6:AezezvV2K6+1fojl4ywrWZMNPlt+mVGFEjZ79X29U+WjmwWmTg2RiGvja0Xm+KMM+MLG7Vg1G1FWpMCqYzvL1NDWiFebi4JRhfb9+J9uoilEzW8z6Kas8mz12gsqi10+3x7gjHs+i01deWTVIIfadMeeEV7VuWu94YMcQKgpmyf+qzpI4NUS6EcBPm6H0DPjkcuhZHiIsOBtABOGS9eUrSh/eESpMPfhBXSuhfy1P85OjJjmgK6GKY/ivfjusAh/0gW2+pbGv1vy6T198VPPho+pv58kKsUR8WPqGUUZjnUJMFu0cmC2yFjXu25KOTKr; 5:gFuwUa7tNM/B7vCrDF48MpqSss5JfBjLRYZmjDJl3Wwq3RzDoFAVikOnChiBwXeXECDW+XMGveL/bqBDF+QU8y3A/u0GtAAuim1Bo+2F740PqBj4TBghXANMK1VMGzennOWy/aW4RSAZBNIMsNsCLf85Z9E+gScs8Tuy0z7vVOY=; 24:P2AXxZdNK+rGBnnxCg5v3nDfNR9LcmXokBOHFFQybwQgb6W2QH2TGjMYFi9RDhFOEYJlXE3PpkUJ7KE+9FhvJrjhqJ6yZ62gEUEDOkOOT/I= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 7:hTiot433nFV96sy0waTB7idj1GXRi9wJFqhSLbMOKUWcKjUSmcnXqfEuRdzNhX/kVXABH73zQX2aTk3PKdI8N1iiMzn55/eQdUgtDtdazBaAPOUUXGfWPkb8bKmEuJ/7t8QJ0uYvv7o6fvqteVJ+bOhcW0PiGlfGmy9Zo45QIdT8lWxNL4ULQhUx6+8LlXIWPw8hKMcSQ96nAGYVhlLswJM8MwD2G/ruSCDeqw8EVSP5k2priwBKZy8c0G9OFYNByxJ9AtUZplw+UuQrqjYsuSook862zAQGn/UQjMz2sGncuwCyzs0S3YwkAKWe/iEY0ate5nJHJ9IxbXl4ONY2gvq0YCBogK2nHIaPlRdKgNA= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2016 09:11:57.7550 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2999 Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 09:12:02 -0000 ----- Original Message ----- From: "Jeffrey Haas" Sent: Tuesday, October 11, 2016 3:07 PM > On Oct 11, 2016, at 7:09 AM, Nick Hilliard wrote: > > t.petch wrote: >> I want a MUST in there so if anyone does otherwise, we can say No!, not >> allowed. > > If an operator in the far depths of inner Kaboodlestan uses an IPv4 > address instead of an ASN, the IETF can disapprove all it wants, and it > will make no difference to anyone. Somewhat relevant example in other extensions: Many implementations treat an add-paths path-id as an integer and you tend to see them showing up as a int in show commands. At least one implementation chose to use a BGP identifier/IP address in theirs. The spec treats the value opaquely. Both use cases make sense in their own context. End of the day, the protocol cares that it's a 4 byte value. Users may want a given representational syntax because it makes their life easier in their particular scenario. Neither is solely the Right Thing. Jeff True but not really germane to the point I keep making:-) Your point is about representation, about how implementations may or may not go beyond the RFC in what a user sees which is an interesting point but not one that the relevant RFC says anything about (some RFC do prescribe a display format). On the other hand, the relevant RFC does contain a specific warning about the local significance of the path identifier. For large-community, we are using a transitive attribute which, by definition, has global significance, hence my concern. Tom Petch -- Jeff From nobody Wed Oct 12 02:12:15 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFAE129445 for ; Wed, 12 Oct 2016 02:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 x0p_X9pIZh8c for ; Wed, 12 Oct 2016 02:12:01 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40135.outbound.protection.outlook.com [40.107.4.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB651294A9 for ; Wed, 12 Oct 2016 02:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=G/Cw6si5+GgCLZaVBNIpAb2TthhE9DmHRyFhTJR0Q6M=; b=dL71G9/ei/dGEBsRUmgfKZpSDI+JA4kJs1IkdCgzqLbx9GGKJNjbIobHhSncGZbgNIpkBDFEGwENi1WSPUgOPdJdaaEozgKXr8LOH1gUr1CpwPOipUpC2/xH4EsTCpCQjmP2McmZ/lydp60R8SZlRW3jm7tK9Euk8HilE4wW/tY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by DB6PR0701MB2999.eurprd07.prod.outlook.com (10.168.84.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Wed, 12 Oct 2016 09:11:58 +0000 Message-ID: <012401d22468$5e0bdc40$4001a8c0@gateway.2wire.net> From: t.petch To: Rob Shakir , Susan Hares , Jeffrey Haas , IETF IDR WG References: <0E9469C4-2B72-484A-9C93-BC13401F6889@pfrc.org> <003901d21f20$95ece2f0$c1c6a8d0$@ndzh.com> Date: Wed, 12 Oct 2016 09:54:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: HE1PR10CA0040.EURPRD10.PROD.OUTLOOK.COM (10.167.243.178) To DB6PR0701MB2999.eurprd07.prod.outlook.com (10.168.84.137) X-MS-Office365-Filtering-Correlation-Id: fb2210a8-6424-42c0-95ec-08d3f27fd286 X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 2:VKMfbLxl7hCaD/S2JesLzfvjo2TohrlpKIGpzi2EjF0wsexDvmANe49wPDdp2n0RoJrN7BuxPqtP+Pf9TdJuL1wBIYn9dF0MACfSka1Yi0rYRHidiiwtkf7GboefoNSqoAvpMWIVAYVJlrHAUvSYSq6Vn1ZPBYTBUij2wG1VuBIa/I80nbDicZwyHx4OKJnhk+G5rfQ6R7zxl4U7/c6Dxw==; 3:+dxjf9MxZh548TeS3zuJ0iyCjJNuSU9l1R2CYPS3GBLwPXO/2DK8hssiQzg9TIefYCt8R4HQUHRdd2hfK6Ru64n/9R9T65dttAC3Wh502Ka5MKf/ejTtYDFajmJssLoD8PcBJO40BrFcca/naHi00A==; 25:l8N9OcBeB3T5c1TSNJPvh1MDGCNuYa8+LeFFawR8ssr08IVkJmlBwQnBjI2KNcptreXVPeuS/RlcBN3ACiwt3UQV+H0ygO5kXgbiygLOKQ+9DIa+M5b55vgJXaGSAWB2Z/b2j3SeDsfvOnOS2rIUK6ehXamXuqv8Io7c14ywRggruWWgIGfzuV5DNWa+Tqrb/A6nIkXK9BR5CKkPdBpr9Qh4Auc0AULLzCKjKTtTVeBXvRHtGUgmCQ+XbGoXudwlyPFLPmrLRVE3I1DBFZPy2wnaJAo1fGAjCeJSIMcUVFVll6qJfF3I6zpls9Wtp6h61zz1gMrczchgEIh37yX3WU+86fVA37/LVbnZxylxYWieKdv8vIsHV/wg9VRC5TvE0Q9OZgQrk4Y6iXtzoAPKI5iXVxDWxTLBWlnHE6d5ZLx8ThuLkAdhwLI81spN9FR7 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0701MB2999; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 31:Gkg5X1AljAOdcgSWx4wfMOm5fuGM4FF440+4xm/YF8ZKLSsmzrIrSkeZx0I/YqNwRLMwkeU9L6mGNaMyO4upslhbxgav6eQ4phpAbHZ7OGFTNLCkQqJMCl0TOfY3oU8gj7ojsiXHJSvEW+ZpQQq1O7ZEkObupcPapN/fRaN/oB52DcQLG/1HxWYjCvBCP/DdoKtnzG3v2kHk+RQaAFquTK2XMSjGvy90xYpWXrKSy9b39rWWLRviup5Twai3DY+3; 4:TJXe9iNNyLE3jFY/8lTVbVMuDETKcujwfp4Uxeu4fXXgZ+IwGOPDljpM6qavX520/96P1ldTCJ0PjujBhD95/qKEZr6huxMyObU10G8hDp69RqjEJQKrz79WEklYMEpzikGFC6nYA8T/03x4MXxuNa7b2JtPkzSaZ83JWr5AQxhKuV0QKnEHcy3KgjpWBm2e/nSxMikhFr+eZuqjfuP4lkx2fRBahF8erJjNhjjjgDCVbwOkSMG5RGM5/St48SCT8Ly9PLsakHfvnv2ISj8PEFFd2qftoUl8bDoeXkikBnwod5GvakyRRntlngodpo/5h7xX8XgWYMt6RN1xwPGIOTDwtXT/xf/D6lekw1TGXS7OcY4CMDCsgp11VaXXk/nY1R/fgBGU1m3i+3YE6pUM+1ZrDOp1VZQTBsL8ECVgHJxMzAGypaUkKNMmeFYkAASg93bCWenWejv29IjaFAKXjQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB6PR0701MB2999; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2999; X-Forefront-PRVS: 0093C80C01 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(199003)(24454002)(377454003)(13464003)(66066001)(33646002)(7846002)(47776003)(305945005)(84392002)(7736002)(50986999)(81686999)(81816999)(76176999)(97736004)(5001770100001)(3846002)(19580395003)(19580405001)(6116002)(586003)(44716002)(62236002)(101416001)(50226002)(23676002)(68736007)(6666003)(9686002)(14496001)(92566002)(61296003)(116806002)(81156014)(81166006)(2906002)(42186005)(105586002)(230783001)(230700001)(8676002)(106356001)(107886002)(5660300001)(15975445007)(189998001)(1556002)(1456003)(77096005)(86362001)(50466002)(4720700003)(44736004)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2999; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjI5OTk7MjM6dnB4T05aaysxVEZCZnFkOEoremsvenIw?= =?utf-8?B?Zm1XQkNZOWp6eGdQYmtUTkN5QW1NS1JCSkVJdndoZGU1b1RSdW5OOXZuZkNV?= =?utf-8?B?Y1ExalJGbE5PU1FzZ2MvT0NlWTBhSTR3ZUQrVi9XTGRzUEttbG9lR1lJTGEz?= =?utf-8?B?Rk5VK2p6YlV6NVMxVVRPNGlaY0M5bXFKVjJyditxWktJV0ZhdkRHZ2Nic1lM?= =?utf-8?B?Nzd1Yko5M0c1eVpQYzVhRklsSUxJZUdSWDY5MldMUG1meHRVME1KMTVCNWFT?= =?utf-8?B?cVpoc1Jvb2RRdjRISERLbC96NUh2RUpUWm84ZHpybjVnQTVpMEY2cm5hWXlk?= =?utf-8?B?TU5MaTkzbFlqSTdCUVNEM3RCWEhtdUtncUZhSUh0UmhkYUVza2ZtaE9oL3Jl?= =?utf-8?B?ZkVGZWl4cGlZcm1qaDkyWTBobWtuMUdJczhqSEhVNTB0SzFUWE1XWHpMOXZZ?= =?utf-8?B?QzZZa1FnMlVqZUV2NGlCbUFmeTJBT1c1dXpQUVl6QlpQSzJ4cVpURitmTXdi?= =?utf-8?B?NGdNRTRBakUvK2RuR202TUhDSUJodUpUUGhsNjR4enQ5UXRPN1NnR1ZlZk9j?= =?utf-8?B?aFJGZSs1YUYzR1g2eGhNMkZHL0VFWjRCcEY2NE41ekdUSERpaGE1VEdNbXQ4?= =?utf-8?B?WEZjOTdKVWVESVFEL1hadSsrbFhtZW1QWUNCM3QrVDVBQVJ3TElZSnpWc1dz?= =?utf-8?B?bERhMkVDNlh4bmwrRS9UYU5aODVmNjNxc3ZCNlNwWnJneWQ2bU90QW9pcGN6?= =?utf-8?B?M0JYSDF0NEVIZzBUZlhvSGtBVFlaRFFlSWluU1o2UzlUNTZHeDJuNHUrWVNW?= =?utf-8?B?eXd0RGdTUnVuckQxYzBBVW5DUWNLSjNleTF6VHpHbExhcitmYThLU1dHR3Ba?= =?utf-8?B?eW5IV1o1VWhTNVhKZnUzOXZSVUVQem9qQnc2LzBZVGVWMWNvLzdSSkRlZXNp?= =?utf-8?B?WDFLdTV1S2lRSG9jQmVqcnRJTXFNMFJYZFRhaHBiNkNHT2xyeE9DMjJFU2dy?= =?utf-8?B?WHp6eXdaZGlkYllEbUJVQ3Vha0J0ZTV2bXBnd2RhTVZ6OWRmZDgzcVZmL1J2?= =?utf-8?B?SkFSUUxKb2pVdjdFT2gwQ0ZubkFQZE0wWmkxbzFYNUt3K2k3bm4xcVNZUHNZ?= =?utf-8?B?bitCVCs5d0NvUllpTjlBVmZISXFKUm9IRjEvclhPREdOdHJMYktxRkozMHVG?= =?utf-8?B?aFp5YjFYb1BtVnNjNlhJQWZUR0dCelgyV1gzRUtPQ1drbnh1bmN1ZitQb2RC?= =?utf-8?B?WWJobDk2QnRpUEwvTUx5cm5UdzluV1JxR2JKN200bUhIczVPLy9ZZjh1Umty?= =?utf-8?B?N0g3b0RHaHRCbnY3Q1RnY2VJV2dnOVdMcWQrTWw0WTRqcnBwdGdxOFNkWFBo?= =?utf-8?B?Y3RHaGc5RFh0d25SYVp3SktGc3lnS3VwK2d3eDVoWC9tYkcxdzl5Q2w3VU9q?= =?utf-8?B?TStreVVOcUJwL0VwWXZQVTBLL1ZMYUlnMDZQZDBFNTRKbVd6dDd4aXNNWXBJ?= =?utf-8?B?cWZOUWxEREZaK2tubEhCamFwUWJlY0I0N2t5U3phakg3OEY5SVVBYmZsYVpx?= =?utf-8?B?OGUzb2duTFJjazQwdmxQTE5CVUI4MlJJQ21pVC9lYVQvbjREOWRIR3BSTDZx?= =?utf-8?B?UlVjV0RXbERUOE5EaGpyU1VKTXhoTDNhRkVXQVRvemxCb0YrVXFYN09iSmZy?= =?utf-8?B?Rm5rOFRoMWNEd3BlbHB1SjdSYW5UbE1pemxKTkYxcm55WUNPKzVENCtlUnhk?= =?utf-8?B?QUxTM3ozY2hnTHhVMjB0Q1RET2psZThwZFdHQ25FSXpuZFpMMG0vR1JyUlFV?= =?utf-8?B?ZFBSOEVlNTJjd3J1SHBDMWlWL2c1ZDVxRlQ2NDFyaGJoWCtidkpZemI1VHY2?= =?utf-8?B?R1ZqZUJvZ0FsMjR0Vm5WNG5kVTFoQ2xnUUQ4NmVLRWdaSmRqaWk5ajhKT1hW?= =?utf-8?B?b3I4YXFuME5wTGdpbG1OM2dkSHRJd3JOd3Nna1Zya1JtK01nK0RTUG94WTVt?= =?utf-8?B?ZStWUzU2Z1R6RUYvOTRTd2RSNkVsM3Jka3h3OVdBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 6:ucGn+nuEogwTpbue34c1SZ0JU7N6UXjEpsUnICphQXt41/V/frl57UH8X1fie7b6PexZo5ESus1H20jgGjYk2zJEBxuOhwRvSyWem1xsxgajWgRXWWOUy5Bc1BLEHrGPkD9+KFu3Z9dNUUVhQGblyArgA+Bakyy0FjgIr40Z+WGMDZad0ZiWgFUsNk/vSi6+f0UsF9jwPHcslwnEthhKNcuzeqEVH97kwruoOMNF4sXIOS0sHYm3lL8AXMu6td8jAJKgT3tBh38SJFbFp8XESWiyOsGmvJ9wDQruwhg3l5At8tiok27ajowCA2Bb3giC; 5:RpWqTfhsWkRTB0ebG477cx2wkU0XQ949boRKgGzlnnfqyQvhHfjNwi101d2uZOGdOGsSF0vbvWmR2ASt3LmkadoMydNdy0CUD0lJ6B4SJbzpQCTSLXcdDSAwroeLdqQZp1ajVkH7Vb17SwcIxrw4jHlsDJFtS014XFc9sLUgXBs=; 24:DQPaXzdVY+tF8qwPxfEpoeVp8Ryp8OLgiSkpbnkWqym0Gmg48SnFkOgQtyKN75m08fpAUj4Z1hODezlDA/7tlg7L1a0NLhH/C70KhIfPvs0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 7:eXEADBbkSHthL6EakMeXbfLrf99zjV4SssopaumukIOoCfaaTstSTJPtW3lrKVHC92Lltr2WO60allK04d8xrM/SUz3/RmN9Na4krxG1CHqHTTuxOnqU9eGWhAf6CSN7QL9rRGSuEQqojaafr582Ll5nwpkHvD6JCsz0EeaNKgtrrCCf1pah5zqUo8NECOOp3bEopHPdJz/Gy5gjziIVeEWazRCajvxHa77V+LnAOY6l1npWpW+iVwwD7xibj3J1lD2ZPdqWRrIN6JNSIFsl1d7IwXvJOVPJK95eI1RRbvOCbVe9LN8ZrF7SwRzaB2C4hszs8kVpEAYnZOOFDGyya4lmuoA8lslT0pCLmjxS/ZU= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2016 09:11:58.8559 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2999 Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 09:12:03 -0000 ----- Original Message ----- From: "Rob Shakir" Sent: Wednesday, October 12, 2016 2:57 AM > Jeff, > > I am interested in the working group pursuing this draft. The pressure > behind large community seems (to me) to be very short-term focused [0]. > Operationally, I understand the requirement, but we should also be > improving the infrastructure that we have in BGP. There are numerous use > cases for BGP, many of which are not Internet DFZ focused. As part of this > infrastructure, I believe that in the longer term, we need the ability to > do attribute scoping in a more robust way. > > The current definitions of non-transitive and transitive are overly coarse > for today's heterogeneous networks. It is particularly important to me that > we look beyond confederations as the only means of grouping autonomous > systems. I agree; if we had a more flexible definition, something between transitive and non-transitive, then that could be an option for 'large'. I also agree that 'large', while having strong consensus, is short-term and that we could be looking for something more in a year or two. (Which is a theme that recurs in the work of the IETF:-( Tom Petch > Cheers, > r. > > [0]: This isn't to say that isn't required, I don't want to debate that any > further as I am pretty sure the horse that we're beating is little more > than a skeleton at this point. See > https://www.ietf.org/mail-archive/web/idr/current/msg16051.html > > > On Wed, Oct 5, 2016 at 8:54 AM Susan Hares wrote: > > Jeff: > > > > > > My reading of the list that: > > a) Large communities meets an "urgent/crisis level need" > > b) Wide communities and bgp-attribute-announcement - meet a longer term > > need. > > > > Did I miss understand the list's comments? > > > > Sue > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas > > Sent: Wednesday, October 5, 2016 11:49 AM > > To: IETF IDR WG > > Subject: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? > > > > In theory, by adoping draft-ietf-idr-bgp-attribute-announcement, IDR agreed > > that attribute scoping was an important issue. > > > > As proven by the working group discussion on BGP large communities, the WG > > seems unwilling to consider anything that adds any level of complexity onto > > certain proposals. > > > > Should we simply consider this draft dead? > > > > -- Jeff > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > ------------------------------------------------------------------------ -------- > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nobody Wed Oct 12 04:11:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C9E1294CA for ; Wed, 12 Oct 2016 04:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.516 X-Spam-Level: X-Spam-Status: No, score=-17.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 td_8ZFLZjwQq for ; Wed, 12 Oct 2016 04:11:40 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5207F1294C8 for ; Wed, 12 Oct 2016 04:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13241; q=dns/txt; s=iport; t=1476270700; x=1477480300; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=BpYNfYqfEWy9Pnpl0VL6dM8tVUjiX0g5pdLucmmLoVQ=; b=bea4Ob7GqmMHBYoSHDYDfrxO+w8X0kU+lFCmFS7lV3IFBQt2L7Q38wY8 H7ULmbyDnX7N7uwI2+qD1Iz5JcUsyoERRBCadVz1mCdbm2g/2E2BsUk0Y FDOKvYTS7kcV/T8H2fn9bzIDHHl2+4r5gKQEg7lrldaZXdxh/had/vqvv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAQAlGf5X/5pdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgwc1AQEBAQEdV3wHjSyXBY8ghRSCDBsBCoV6AhqBfTgUAQIBAQE?= =?us-ascii?q?BAQEBXieEYQEBAQQBAQEgSxcEAgEIDgMDAQEBKAMCAgIlCxQJCAIEARIUB4g1D?= =?us-ascii?q?rYijQYBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYsShCoBATuCZIJbBZQohVoBj3y?= =?us-ascii?q?PdYx5g34BHjZOgnMcgVNyAYZDgSCBAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,333,1473120000"; d="scan'208,217";a="161113672" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2016 11:11:39 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u9CBBcaF015727 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Oct 2016 11:11:39 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Oct 2016 07:11:38 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 12 Oct 2016 07:11:38 -0400 From: "Acee Lindem (acee)" To: Rob Shakir , Susan Hares , Jeffrey Haas , IETF IDR WG Thread-Topic: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? Thread-Index: AQHSHx/3C4MhuBw1H0iZDgaAwvyZqqCkGeTLgACapwA= Date: Wed, 12 Oct 2016 11:11:38 +0000 Message-ID: References: <0E9469C4-2B72-484A-9C93-BC13401F6889@pfrc.org> <003901d21f20$95ece2f0$c1c6a8d0$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.200] Content-Type: multipart/alternative; boundary="_000_D423912E825A6aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 11:11:42 -0000 --_000_D423912E825A6aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmVmZiwgUm9iLA0KDQpJIGFncmVlIHdpdGggUm9iIHRoYXQgV0cgYWRvcHRpb24gb2YgbGFy Z2UgY29tbXVuaXRpZXMgaW4gbm8gd2F5IGltcGxpZXMgdGhhdCBhdHRyaWJ1dGUgc2NvcGluZyBp cyBub3QgYSByZXF1aXJlbWVudCBhbmQgc2hvdWxkIG5vdCBhbHNvIGJlIHB1cnN1ZWQuDQoNCklu IGZhY3QsIHRoZXJlIG1heSBldmVuIGJlIGhvcGUgZm9yIHdpZGUgY29tbXVuaXRpZXMgdG8gZXZv bHZlIGludG8gdGhlIGxvbmcgdGVybSBzb2x1dGlvbi4NCg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9t OiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZz4+ IG9uIGJlaGFsZiBvZiBSb2IgU2hha2lyIDxyanNAcm9iLnNoPG1haWx0bzpyanNAcm9iLnNoPj4N CkRhdGU6IFR1ZXNkYXksIE9jdG9iZXIgMTEsIDIwMTYgYXQgOTo1NyBQTQ0KVG86IFN1c2FuIEhh cmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+LCBKZWZmIEhhYXMg PGpoYWFzQHBmcmMub3JnPG1haWx0bzpqaGFhc0BwZnJjLm9yZz4+LCBJRFIgTGlzdCA8aWRyQGll dGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZHJdIGRyYWZ0LWll dGYtaWRyLWJncC1hdHRyaWJ1dGUtYW5ub3VuY2VtZW50IGRlYWQgb24gYXJyaXZhbD8NCg0KSmVm ZiwNCg0KSSBhbSBpbnRlcmVzdGVkIGluIHRoZSB3b3JraW5nIGdyb3VwIHB1cnN1aW5nIHRoaXMg ZHJhZnQuIFRoZSBwcmVzc3VyZSBiZWhpbmQgbGFyZ2UgY29tbXVuaXR5IHNlZW1zICh0byBtZSkg dG8gYmUgdmVyeSBzaG9ydC10ZXJtIGZvY3VzZWQgWzBdLiBPcGVyYXRpb25hbGx5LCBJIHVuZGVy c3RhbmQgdGhlIHJlcXVpcmVtZW50LCBidXQgd2Ugc2hvdWxkIGFsc28gYmUgaW1wcm92aW5nIHRo ZSBpbmZyYXN0cnVjdHVyZSB0aGF0IHdlIGhhdmUgaW4gQkdQLiBUaGVyZSBhcmUgbnVtZXJvdXMg dXNlIGNhc2VzIGZvciBCR1AsIG1hbnkgb2Ygd2hpY2ggYXJlIG5vdCBJbnRlcm5ldCBERlogZm9j dXNlZC4gQXMgcGFydCBvZiB0aGlzIGluZnJhc3RydWN0dXJlLCBJIGJlbGlldmUgdGhhdCBpbiB0 aGUgbG9uZ2VyIHRlcm0sIHdlIG5lZWQgdGhlIGFiaWxpdHkgdG8gZG8gYXR0cmlidXRlIHNjb3Bp bmcgaW4gYSBtb3JlIHJvYnVzdCB3YXkuDQoNClRoZSBjdXJyZW50IGRlZmluaXRpb25zIG9mIG5v bi10cmFuc2l0aXZlIGFuZCB0cmFuc2l0aXZlIGFyZSBvdmVybHkgY29hcnNlIGZvciB0b2RheSdz IGhldGVyb2dlbmVvdXMgbmV0d29ya3MuIEl0IGlzIHBhcnRpY3VsYXJseSBpbXBvcnRhbnQgdG8g bWUgdGhhdCB3ZSBsb29rIGJleW9uZCBjb25mZWRlcmF0aW9ucyBhcyB0aGUgb25seSBtZWFucyBv ZiBncm91cGluZyBhdXRvbm9tb3VzIHN5c3RlbXMuDQoNCkNoZWVycywNCnIuDQoNClswXTogVGhp cyBpc24ndCB0byBzYXkgdGhhdCBpc24ndCByZXF1aXJlZCwgSSBkb24ndCB3YW50IHRvIGRlYmF0 ZSB0aGF0IGFueSBmdXJ0aGVyIGFzIEkgYW0gcHJldHR5IHN1cmUgdGhlIGhvcnNlIHRoYXQgd2Un cmUgYmVhdGluZyBpcyBsaXR0bGUgbW9yZSB0aGFuIGEgc2tlbGV0b24gYXQgdGhpcyBwb2ludC4g U2VlIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWRyL2N1cnJlbnQvbXNn MTYwNTEuaHRtbA0KDQoNCk9uIFdlZCwgT2N0IDUsIDIwMTYgYXQgODo1NCBBTSBTdXNhbiBIYXJl cyA8c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+PiB3cm90ZToNCkplZmY6 DQoNCjxpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yIGhhdCBvbj4NCg0KDQoNCk15IHJlYWRpbmcgb2Yg dGhlIGxpc3QgdGhhdDoNCg0KYSkgTGFyZ2UgY29tbXVuaXRpZXMgbWVldHMgYW4gInVyZ2VudC9j cmlzaXMgbGV2ZWwgbmVlZCINCg0KYikgV2lkZSBjb21tdW5pdGllcyBhbmQgYmdwLWF0dHJpYnV0 ZS1hbm5vdW5jZW1lbnQgLSBtZWV0IGEgbG9uZ2VyIHRlcm0NCg0KbmVlZC4NCg0KDQoNCkRpZCBJ IG1pc3MgdW5kZXJzdGFuZCB0aGUgbGlzdCdzIGNvbW1lbnRzPw0KDQoNCg0KU3VlDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGll dGYub3JnPG1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKZWZmcmV5 IEhhYXMNCg0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDUsIDIwMTYgMTE6NDkgQU0NCg0KVG86 IElFVEYgSURSIFdHDQoNClN1YmplY3Q6IFtJZHJdIGRyYWZ0LWlldGYtaWRyLWJncC1hdHRyaWJ1 dGUtYW5ub3VuY2VtZW50IGRlYWQgb24gYXJyaXZhbD8NCg0KDQoNCkluIHRoZW9yeSwgYnkgYWRv cGluZyBkcmFmdC1pZXRmLWlkci1iZ3AtYXR0cmlidXRlLWFubm91bmNlbWVudCwgSURSIGFncmVl ZA0KDQp0aGF0IGF0dHJpYnV0ZSBzY29waW5nIHdhcyBhbiBpbXBvcnRhbnQgaXNzdWUuDQoNCg0K DQpBcyBwcm92ZW4gYnkgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzY3Vzc2lvbiBvbiBCR1AgbGFyZ2Ug Y29tbXVuaXRpZXMsIHRoZSBXRw0KDQpzZWVtcyB1bndpbGxpbmcgdG8gY29uc2lkZXIgYW55dGhp bmcgdGhhdCBhZGRzIGFueSBsZXZlbCBvZiBjb21wbGV4aXR5IG9udG8NCg0KY2VydGFpbiBwcm9w b3NhbHMuDQoNCg0KDQpTaG91bGQgd2Ugc2ltcGx5IGNvbnNpZGVyIHRoaXMgZHJhZnQgZGVhZD8N Cg0KDQoNCi0tIEplZmYNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCklkciBtYWlsaW5nIGxpc3QNCg0KSWRyQGlldGYub3JnPG1haWx0bzpJ ZHJAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRy DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpJZHIgbWFpbGluZyBsaXN0DQoNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0K DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQo= --_000_D423912E825A6aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4FEB059B79F28F47894AE7D22E3287A1@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBKZWZmLCBS b2IsJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGFncmVlIHdpdGggUm9i IHRoYXQgV0cgYWRvcHRpb24gb2YgbGFyZ2UgY29tbXVuaXRpZXMgaW4gbm8gd2F5IGltcGxpZXMg dGhhdCBhdHRyaWJ1dGUgc2NvcGluZyBpcyBub3QgYSByZXF1aXJlbWVudCBhbmQgc2hvdWxkIG5v dCBhbHNvIGJlIHB1cnN1ZWQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5J biBmYWN0LCB0aGVyZSBtYXkgZXZlbiBiZSBob3BlIGZvciB3aWRlIGNvbW11bml0aWVzIHRvIGV2 b2x2ZSBpbnRvIHRoZSBsb25nIHRlcm0gc29sdXRpb24uJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFjZWU8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6 YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5v bmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hU OiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1 bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5Gcm9tOiA8L3NwYW4+SWRyICZsdDs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5v cmciPmlkci1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIFJvYiBTaGFraXIg Jmx0OzxhIGhyZWY9Im1haWx0bzpyanNAcm9iLnNoIj5yanNAcm9iLnNoPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlR1ZXNkYXksIE9jdG9i ZXIgMTEsIDIwMTYgYXQgOTo1NyBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5UbzogPC9zcGFuPlN1c2FuIEhhcmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemgu Y29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0OywgSmVmZiBIYWFzICZsdDs8YSBocmVmPSJtYWls dG86amhhYXNAcGZyYy5vcmciPmpoYWFzQHBmcmMub3JnPC9hPiZndDssIElEUiBMaXN0ICZsdDs8 YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtJZHJdIGRy YWZ0LWlldGYtaWRyLWJncC1hdHRyaWJ1dGUtYW5ub3VuY2VtZW50IGRlYWQgb24gYXJyaXZhbD88 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfbXNnIj5KZWZmLA0K PGRpdiBjbGFzcz0iZ21haWxfbXNnIj48YnIgY2xhc3M9ImdtYWlsX21zZyI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX21zZyI+SSBhbSBpbnRlcmVzdGVkIGluIHRoZSB3b3JraW5nIGdyb3Vw IHB1cnN1aW5nIHRoaXMgZHJhZnQuIFRoZSBwcmVzc3VyZSBiZWhpbmQgbGFyZ2UgY29tbXVuaXR5 IHNlZW1zICh0byBtZSkgdG8gYmUgdmVyeSBzaG9ydC10ZXJtIGZvY3VzZWQgWzBdLiBPcGVyYXRp b25hbGx5LCBJIHVuZGVyc3RhbmQgdGhlIHJlcXVpcmVtZW50LCBidXQgd2Ugc2hvdWxkIGFsc28g YmUgaW1wcm92aW5nIHRoZSBpbmZyYXN0cnVjdHVyZQ0KIHRoYXQgd2UgaGF2ZSBpbiBCR1AuIFRo ZXJlIGFyZSBudW1lcm91cyB1c2UgY2FzZXMgZm9yIEJHUCwgbWFueSBvZiB3aGljaCBhcmUgbm90 IEludGVybmV0IERGWiBmb2N1c2VkLiBBcyBwYXJ0IG9mIHRoaXMgaW5mcmFzdHJ1Y3R1cmUsIEkg YmVsaWV2ZSB0aGF0IGluIHRoZSBsb25nZXIgdGVybSwgd2UgbmVlZCB0aGUgYWJpbGl0eSB0byBk byBhdHRyaWJ1dGUgc2NvcGluZyBpbiBhIG1vcmUgcm9idXN0IHdheS48L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX21zZyI+PGJyIGNsYXNzPSJnbWFpbF9tc2ciPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSJnbWFpbF9tc2ciPlRoZSBjdXJyZW50IGRlZmluaXRpb25zIG9mIG5vbi10cmFuc2l0aXZlIGFu ZCB0cmFuc2l0aXZlIGFyZSBvdmVybHkgY29hcnNlIGZvciB0b2RheSdzIGhldGVyb2dlbmVvdXMg bmV0d29ya3MuIEl0IGlzIHBhcnRpY3VsYXJseSBpbXBvcnRhbnQgdG8gbWUgdGhhdCB3ZSBsb29r IGJleW9uZCBjb25mZWRlcmF0aW9ucyBhcyB0aGUgb25seSBtZWFucyBvZiBncm91cGluZyBhdXRv bm9tb3VzIHN5c3RlbXMuPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9tc2ciPjxiciBjbGFzcz0i Z21haWxfbXNnIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfbXNnIj5DaGVlcnMsPC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9tc2ciPnIuPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9tc2ci PjxiciBjbGFzcz0iZ21haWxfbXNnIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfbXNnIj5b MF06IFRoaXMgaXNuJ3QgdG8gc2F5IHRoYXQgaXNuJ3QgcmVxdWlyZWQsIEkgZG9uJ3Qgd2FudCB0 byBkZWJhdGUgdGhhdCBhbnkgZnVydGhlciBhcyBJIGFtIHByZXR0eSBzdXJlIHRoZSBob3JzZSB0 aGF0IHdlJ3JlIGJlYXRpbmcgaXMgbGl0dGxlIG1vcmUgdGhhbiBhIHNrZWxldG9uIGF0IHRoaXMg cG9pbnQuIFNlZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvaWRyL2N1cnJlbnQvbXNnMTYwNTEuaHRtbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9pZHIvY3VycmVudC9tc2cxNjA1MS5odG1sPC9hPjwvZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfbXNnIj48YnIgY2xhc3M9ImdtYWlsX21zZyI+DQo8L2Rpdj4NCjwvZGl2Pg0K PGJyIGNsYXNzPSJnbWFpbF9tc2ciPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUgZ21haWxfbXNn Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9tc2ciPk9uIFdlZCwgT2N0IDUsIDIwMTYg YXQgODo1NCBBTSBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNv bSIgY2xhc3M9ImdtYWlsX21zZyIgdGFyZ2V0PSJfYmxhbmsiPnNoYXJlc0BuZHpoLmNvbTwvYT4m Z3Q7IHdyb3RlOjxiciBjbGFzcz0iZ21haWxfbXNnIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIGdtYWlsX21zZyIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRl ci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KSmVmZjo8YnIgY2xhc3M9 ImdtYWlsX21zZyI+DQo8YnI+DQombHQ7aW5kaXZpZHVhbCBjb250cmlidXRvciBoYXQgb24mZ3Q7 PGJyIGNsYXNzPSJnbWFpbF9tc2ciPg0KPGJyPg0KPGJyIGNsYXNzPSJnbWFpbF9tc2ciPg0KPGJy Pg0KTXkgcmVhZGluZyBvZiB0aGUgbGlzdCB0aGF0OjxiciBjbGFzcz0iZ21haWxfbXNnIj4NCjxi cj4NCmEpIExhcmdlIGNvbW11bml0aWVzIG1lZXRzIGFuICZxdW90O3VyZ2VudC9jcmlzaXMgbGV2 ZWwgbmVlZCZxdW90OzxiciBjbGFzcz0iZ21haWxfbXNnIj4NCjxicj4NCmIpIFdpZGUgY29tbXVu aXRpZXMgYW5kIGJncC1hdHRyaWJ1dGUtYW5ub3VuY2VtZW50IC0gbWVldCBhIGxvbmdlciB0ZXJt PGJyIGNsYXNzPSJnbWFpbF9tc2ciPg0KPGJyPg0KbmVlZC48YnIgY2xhc3M9ImdtYWlsX21zZyI+ DQo8YnI+DQo8YnIgY2xhc3M9ImdtYWlsX21zZyI+DQo8YnI+DQpEaWQgSSBtaXNzIHVuZGVyc3Rh bmQgdGhlIGxpc3QncyBjb21tZW50cz88YnIgY2xhc3M9ImdtYWlsX21zZyI+DQo8YnI+DQo8YnIg Y2xhc3M9ImdtYWlsX21zZyI+DQo8YnI+DQpTdWU8YnIgY2xhc3M9ImdtYWlsX21zZyI+DQo8YnI+ DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBjbGFzcz0iZ21haWxfbXNnIj4NCjxicj4N CkZyb206IElkciBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyIg Y2xhc3M9ImdtYWlsX21zZyIgdGFyZ2V0PSJfYmxhbmsiPmlkci1ib3VuY2VzQGlldGYub3JnPC9h Pl0gT24gQmVoYWxmIE9mIEplZmZyZXkgSGFhczxiciBjbGFzcz0iZ21haWxfbXNnIj4NCjxicj4N ClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciA1LCAyMDE2IDExOjQ5IEFNPGJyIGNsYXNzPSJnbWFp bF9tc2ciPg0KPGJyPg0KVG86IElFVEYgSURSIFdHPGJyIGNsYXNzPSJnbWFpbF9tc2ciPg0KPGJy Pg0KU3ViamVjdDogW0lkcl0gZHJhZnQtaWV0Zi1pZHItYmdwLWF0dHJpYnV0ZS1hbm5vdW5jZW1l bnQgZGVhZCBvbiBhcnJpdmFsPzxiciBjbGFzcz0iZ21haWxfbXNnIj4NCjxicj4NCjxiciBjbGFz cz0iZ21haWxfbXNnIj4NCjxicj4NCkluIHRoZW9yeSwgYnkgYWRvcGluZyBkcmFmdC1pZXRmLWlk ci1iZ3AtYXR0cmlidXRlLWFubm91bmNlbWVudCwgSURSIGFncmVlZDxiciBjbGFzcz0iZ21haWxf bXNnIj4NCjxicj4NCnRoYXQgYXR0cmlidXRlIHNjb3Bpbmcgd2FzIGFuIGltcG9ydGFudCBpc3N1 ZS48YnIgY2xhc3M9ImdtYWlsX21zZyI+DQo8YnI+DQo8YnIgY2xhc3M9ImdtYWlsX21zZyI+DQo8 YnI+DQpBcyBwcm92ZW4gYnkgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzY3Vzc2lvbiBvbiBCR1AgbGFy Z2UgY29tbXVuaXRpZXMsIHRoZSBXRzxiciBjbGFzcz0iZ21haWxfbXNnIj4NCjxicj4NCnNlZW1z IHVud2lsbGluZyB0byBjb25zaWRlciBhbnl0aGluZyB0aGF0IGFkZHMgYW55IGxldmVsIG9mIGNv bXBsZXhpdHkgb250bzxiciBjbGFzcz0iZ21haWxfbXNnIj4NCjxicj4NCmNlcnRhaW4gcHJvcG9z YWxzLjxiciBjbGFzcz0iZ21haWxfbXNnIj4NCjxicj4NCjxiciBjbGFzcz0iZ21haWxfbXNnIj4N Cjxicj4NClNob3VsZCB3ZSBzaW1wbHkgY29uc2lkZXIgdGhpcyBkcmFmdCBkZWFkPzxiciBjbGFz cz0iZ21haWxfbXNnIj4NCjxicj4NCjxiciBjbGFzcz0iZ21haWxfbXNnIj4NCjxicj4NCi0tIEpl ZmY8YnIgY2xhc3M9ImdtYWlsX21zZyI+DQo8YnI+DQo8YnIgY2xhc3M9ImdtYWlsX21zZyI+DQo8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBj bGFzcz0iZ21haWxfbXNnIj4NCjxicj4NCklkciBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9ImdtYWls X21zZyI+DQo8YnI+DQo8YSBocmVmPSJtYWlsdG86SWRyQGlldGYub3JnIiBjbGFzcz0iZ21haWxf bXNnIiB0YXJnZXQ9Il9ibGFuayI+SWRyQGlldGYub3JnPC9hPjxiciBjbGFzcz0iZ21haWxfbXNn Ij4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWRyIiByZWw9Im5vcmVmZXJyZXIiIGNsYXNzPSJnbWFpbF9tc2ciIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcjwvYT48YnIgY2xhc3M9Imdt YWlsX21zZyI+DQo8YnI+DQo8YnIgY2xhc3M9ImdtYWlsX21zZyI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iZ21haWxfbXNn Ij4NCjxicj4NCklkciBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9ImdtYWlsX21zZyI+DQo8YnI+DQo8 YSBocmVmPSJtYWlsdG86SWRyQGlldGYub3JnIiBjbGFzcz0iZ21haWxfbXNnIiB0YXJnZXQ9Il9i bGFuayI+SWRyQGlldGYub3JnPC9hPjxiciBjbGFzcz0iZ21haWxfbXNnIj4NCjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyIiByZWw9Im5vcmVm ZXJyZXIiIGNsYXNzPSJnbWFpbF9tc2ciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcjwvYT48YnIgY2xhc3M9ImdtYWlsX21zZyI+DQo8YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D423912E825A6aceeciscocom_-- From nobody Wed Oct 12 04:14:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0AB129787 for ; Wed, 12 Oct 2016 04:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 JNtpLifTWUx5 for ; Wed, 12 Oct 2016 04:14:22 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 B76BD129786 for ; Wed, 12 Oct 2016 04:14:22 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1buHUK-0006qS-Te (job@us.ntt.net); Wed, 12 Oct 2016 11:14:22 +0000 Date: Wed, 12 Oct 2016 13:14:17 +0200 From: Job Snijders To: idr@ietf.org Message-ID: <20161012111417.GN57491@Vurt.local> References: <0E9469C4-2B72-484A-9C93-BC13401F6889@pfrc.org> <003901d21f20$95ece2f0$c1c6a8d0$@ndzh.com> <012401d22468$5e0bdc40$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012401d22468$5e0bdc40$4001a8c0@gateway.2wire.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Subject: Re: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 11:14:24 -0000 Dear working group, On Wed, Oct 12, 2016 at 09:54:24AM +0100, t.petch wrote: > ----- Original Message ----- > From: "Rob Shakir" > Sent: Wednesday, October 12, 2016 2:57 AM > > > I am interested in the working group pursuing this draft. The > > pressure behind large community seems (to me) to be very short-term > > focused [0]. Operationally, I understand the requirement, but we > > should also be improving the infrastructure that we have in BGP. > > There are numerous use cases for BGP, many of which are not Internet > > DFZ focused. As part of this infrastructure, I believe that in the > > longer term, we need the ability to do attribute scoping in a more > > robust way. > > > > The current definitions of non-transitive and transitive are overly > > coarse for today's heterogeneous networks. It is particularly > > important to me that we look beyond confederations as the only means > > of grouping autonomous systems. > > I agree; if we had a more flexible definition, something between > transitive and non-transitive, then that could be an option for > 'large'. Tom, I disagree with your remark about 'large'. Large BGP Communities, by design and definition, are transitive. Put differently: A 96 bit opaque entity which is not transitive, is not a Large BGP Community. I am sure there are some usecases for such a non-transitive tool, but call it has to be called something different. Rob makes an excellent observation in "we should be improving the infrastructure", an example is that during the standardisation of the BGP BLACKHOLE community, not everyone appreciated the transitivity of the well known community, but non-transitive didn't cut it either for the use case. No tools were readily available to do any better, so a choice between the two coarse approaches had to be made. I am interested in having non-confed-based grouping of ASNs. Regarding draft-ietf-idr-bgp-attribute-announcement itself, I wonder if there actually is a need to be able to define an optional transitive extended path attribute. We already have a method to do optional transitive attributes today, maybe there is no need to provide a new way to perform that function. > I also agree that 'large', while having strong consensus, is > short-term and that we could be looking for something more in a year > or two. (Which is a theme that recurs in the work of the IETF:-( I am not sure if the 'short term' or 'long term' distinctions do justice to any of the efforts. In fact, I find it somewhat insidious to call any effort in IDR "short term". (Apologies if my interpretation is an artifact of a language barrier) For all of these efforts, we're often looking at multi-year projects: huge periods of time between "draft"-phase and "widely deployed code"-phase. Then comes the popularising phase and education phase in which people have to be trained in how to use the new technology, etc. Entire ecosystems need to be upgraded, this is like turning a supertanker around. Large is not "short-term", it exists to address a narrow use case. draft-ietf-idr-bgp-attribute-announcement can exist to address other use cases. Kind regards, Job From nobody Wed Oct 12 06:43:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C3212950B for ; Wed, 12 Oct 2016 06:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Xf9qhcly1yQl for ; Wed, 12 Oct 2016 06:43:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 648E312950D for ; Wed, 12 Oct 2016 06:43:54 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DDF3B1E32B; Wed, 12 Oct 2016 09:45:52 -0400 (EDT) Date: Wed, 12 Oct 2016 09:45:52 -0400 From: Jeffrey Haas To: heasley Message-ID: <20161012134552.GE22695@pfrc.org> References: <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> <20161011221544.GG12806@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161011221544.GG12806@shrubbery.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 13:43:56 -0000 On Tue, Oct 11, 2016 at 10:15:44PM +0000, heasley wrote: > Tue, Oct 11, 2016 at 03:02:57PM -0700, Brian Dickson: > > - there IS a difference in what operators are able to do if/when collisions occur > > which is nothing. there is no enforcement. > > leave it alone. This is one I have to agree with. With respect, Brian, this is a point where your desire is to encode operational (if not contractual) practice in the protocol RFC. I don't think that helps anyone. Somewhat to Gert D.'s point later in-thread, part of the issue with communities is that that are in-practice heavily scrubbed and tend not to be transitive. Part of this is the difficulty in determining who may have injected something more than a single AS-hop away. Arguably this was one of the motivations for doing scoping of attributes or communities themselves: If the effective operational behavior is almost always going to be AS-non-transitive, it'd be nice if the cleanup just happens automagically. Unfortunately people are rather enamored with their existing cleanup mechanisms. -- Jeff From nobody Wed Oct 12 06:50:00 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A2012950B for ; Wed, 12 Oct 2016 06:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uwrIp7UTIVwn for ; Wed, 12 Oct 2016 06:49:57 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 652E9129480 for ; Wed, 12 Oct 2016 06:49:57 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CED3D1E32B; Wed, 12 Oct 2016 09:51:55 -0400 (EDT) Date: Wed, 12 Oct 2016 09:51:55 -0400 From: Jeffrey Haas To: "Acee Lindem (acee)" Message-ID: <20161012135155.GF22695@pfrc.org> References: <0E9469C4-2B72-484A-9C93-BC13401F6889@pfrc.org> <003901d21f20$95ece2f0$c1c6a8d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF IDR WG , Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 13:49:58 -0000 Acee (and Sue earlier) On Wed, Oct 12, 2016 at 11:11:38AM +0000, Acee Lindem (acee) wrote: > I agree with Rob that WG adoption of large communities in no way implies that attribute scoping is not a requirement and should not also be pursued. > > In fact, there may even be hope for wide communities to evolve into the long term solution. I would honestly prefer this conversation pretends the wide community draft doesn't exist. People keep getting hung up on it. This is more the general long term question. My intention a day after Sue's response had been to scrub the list of pending path attribute features in IDR, BESS, etc., but I've not found the time to do that yet. WRT large communities, the main reason I cite that conversation is not an attempt to "beat the dead horse", but to point out what was brought up as technical objections to such header mechanisms. If the WG simply wants to declare what was raised as technical objections as non-technical objections (i.e. "we simply didn't want to") - so be it. But that's not how the narrative ran. -- Jeff From nobody Wed Oct 12 07:15:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D6B12944D for ; Wed, 12 Oct 2016 07:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 kGKzNo1-Mrcq for ; Wed, 12 Oct 2016 07:15:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D128412946E for ; Wed, 12 Oct 2016 07:07:00 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 620E11E32B; Wed, 12 Oct 2016 10:08:59 -0400 (EDT) Date: Wed, 12 Oct 2016 10:08:59 -0400 From: Jeffrey Haas To: Job Snijders Message-ID: <20161012140859.GG22695@pfrc.org> References: <0E9469C4-2B72-484A-9C93-BC13401F6889@pfrc.org> <003901d21f20$95ece2f0$c1c6a8d0$@ndzh.com> <012401d22468$5e0bdc40$4001a8c0@gateway.2wire.net> <20161012111417.GN57491@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161012111417.GN57491@Vurt.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:15:09 -0000 Job, On Wed, Oct 12, 2016 at 01:14:17PM +0200, Job Snijders wrote: > Regarding draft-ietf-idr-bgp-attribute-announcement itself, I wonder if > there actually is a need to be able to define an optional transitive > extended path attribute. We already have a method to do optional > transitive attributes today, maybe there is no need to provide a new way > to perform that function. The base BGP extension mechanism gives us two ways to add new path attributes: - Optional-non-transitive: If you don't understand it, you drop it; it doesn't get propagated. - Optional-transitive: It gets propagated, even if you don't understand it. The partial bit gets set if you do. That bit is unfortunately protocol noise. Effectively for most features that need some domain-wide deployment, optional-transitive is the only real game in town. For example, your route reflectors need not understand the attribute if it's only important to your edges. This is a generally good property. What's been problematic is when attributes leave the scope of interest, probably shouldn't but there's no way to halt them. The usual example worth bringing up is attr-128 (RFC 6368). It's a useful feature in some deployments, but it's unfortunately also a cautionary tale about the hazards of deploying code for features that haven't fully gone through the standards process. We tend to see the need for attribute scoping more from providers that provide other BGP enabled services, and also are starting to see some of this conversation happening in the BGP as a data center control plane protocol. Where this conversation tends to hit core service providers the most is in the perennial issues of "optional transitive nonsense" that takes down some bit of the Internet. The BGP error handling RFC significantly mitigates such issues, but I don't think it totally eliminates it. It's understood the current proposal is overly coarse, but it was the easy least-common denominator to start the conversation: - Scope at confederation boundaries. - Scope at AS boundaries. Two additional cases that are somewhat clear from recurring conversations elsewhere are: - Scope at AS domain boundary. Effectively, a confederation of cooperating ASes, just not using the confederation feature. See prior conversations about the impact of eBGP AS checks for RFC 4684 (rt-constrain). - Scope at arbitrary "group" boundaries. The draft-ietf-idr-flowspec-interfaceset work is effectively a form of this, but not an exact use-case match. Arguably, many MPLS VPN control communities such as route-target, etc. also should have similar scoping considerations since their cleanup when sending routes from the PE context to the CE context is not automatic in some implementations. This conversation is certainly less clear when you restrict yourself to features wherein an implementation understands the feature. At that point, it's a matter of filtering. But once you change the conversation to "the implementation doesn't know and thus can at best pass things on", I think we're at the relevant discussion topics. -- Jeff From nobody Wed Oct 12 07:17:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA33112944D for ; Wed, 12 Oct 2016 07:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 uhg4Gldcn6QV for ; Wed, 12 Oct 2016 07:17:49 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD9312946E for ; Wed, 12 Oct 2016 07:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1988; q=dns/txt; s=iport; t=1476281869; x=1477491469; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8fKEi99ylP6oNK4KXKbZpMRGASqWa7f2oFHVV5nq2Ls=; b=DnYWc27oEnYW0oriyE2mArTmpNEedP/61vTqiRSVvChGcka1xM9WGjgU 1JJoLHjmKSgbVM6W7sdQhAwDGuy20zm+X6AvrBwmMO/DY5FSkCV2utBuD 4NIq+pUeIhdfu237szpaNSpsR9VYYfaBMSr7vI/ZaRdZXH7c62X9p3iaX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAQByRf5X/51dJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzwBAQEBAR2BUweNLJcFlDSCDIYgAhqCCTgUAQIBAQEBAQEBXieEYgE?= =?us-ascii?q?BBCMRRRACAQgOCgICJgICAjAVEAIEDgUUB4g1tkyNBAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEfgQeKC4dLglsBBJoCAY98j3WMeYN+AR42ToRicodkgQABAQE?= X-IronPort-AV: E=Sophos;i="5.31,482,1473120000"; d="scan'208";a="161908382" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2016 14:17:48 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u9CEHm3v009887 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Oct 2016 14:17:48 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Oct 2016 10:17:47 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 12 Oct 2016 10:17:47 -0400 From: "Acee Lindem (acee)" To: Jeffrey Haas Thread-Topic: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? Thread-Index: AQHSHx/3C4MhuBw1H0iZDgaAwvyZqqCkGeTLgACapwCAAG/YgP//xCkA Date: Wed, 12 Oct 2016 14:17:47 +0000 Message-ID: References: <0E9469C4-2B72-484A-9C93-BC13401F6889@pfrc.org> <003901d21f20$95ece2f0$c1c6a8d0$@ndzh.com> <20161012135155.GF22695@pfrc.org> In-Reply-To: <20161012135155.GF22695@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.200] Content-Type: text/plain; charset="utf-8" Content-ID: <7C5A19A21AFFBB4D81BC38F1F4744770@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IETF IDR WG , Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:17:51 -0000 SGkgSmVmZiwgDQoNCk9uIDEwLzEyLzE2LCA5OjUxIEFNLCAiSmVmZnJleSBIYWFzIiA8amhhYXNA cGZyYy5vcmc+IHdyb3RlOg0KDQo+QWNlZSAoYW5kIFN1ZSBlYXJsaWVyKQ0KPg0KPk9uIFdlZCwg T2N0IDEyLCAyMDE2IGF0IDExOjExOjM4QU0gKzAwMDAsIEFjZWUgTGluZGVtIChhY2VlKSB3cm90 ZToNCj4+IEkgYWdyZWUgd2l0aCBSb2IgdGhhdCBXRyBhZG9wdGlvbiBvZiBsYXJnZSBjb21tdW5p dGllcyBpbiBubyB3YXkNCj4+aW1wbGllcyB0aGF0IGF0dHJpYnV0ZSBzY29waW5nIGlzIG5vdCBh IHJlcXVpcmVtZW50IGFuZCBzaG91bGQgbm90IGFsc28NCj4+YmUgcHVyc3VlZC4NCj4+IA0KPj4g SW4gZmFjdCwgdGhlcmUgbWF5IGV2ZW4gYmUgaG9wZSBmb3Igd2lkZSBjb21tdW5pdGllcyB0byBl dm9sdmUgaW50byB0aGUNCj4+bG9uZyB0ZXJtIHNvbHV0aW9uLg0KPg0KPkkgd291bGQgaG9uZXN0 bHkgcHJlZmVyIHRoaXMgY29udmVyc2F0aW9uIHByZXRlbmRzIHRoZSB3aWRlIGNvbW11bml0eQ0K PmRyYWZ0DQo+ZG9lc24ndCBleGlzdC4gIFBlb3BsZSBrZWVwIGdldHRpbmcgaHVuZyB1cCBvbiBp dC4NCj4NCj5UaGlzIGlzIG1vcmUgdGhlIGdlbmVyYWwgbG9uZyB0ZXJtIHF1ZXN0aW9uLg0KPg0K Pk15IGludGVudGlvbiBhIGRheSBhZnRlciBTdWUncyByZXNwb25zZSBoYWQgYmVlbiB0byBzY3J1 YiB0aGUgbGlzdCBvZg0KPnBlbmRpbmcgcGF0aCBhdHRyaWJ1dGUgZmVhdHVyZXMgaW4gSURSLCBC RVNTLCBldGMuLCBidXQgSSd2ZSBub3QgZm91bmQgdGhlDQo+dGltZSB0byBkbyB0aGF0IHlldC4N Cj4NCj5XUlQgbGFyZ2UgY29tbXVuaXRpZXMsIHRoZSBtYWluIHJlYXNvbiBJIGNpdGUgdGhhdCBj b252ZXJzYXRpb24gaXMgbm90IGFuDQo+YXR0ZW1wdCB0byAiYmVhdCB0aGUgZGVhZCBob3JzZSIs IGJ1dCB0byBwb2ludCBvdXQgd2hhdCB3YXMgYnJvdWdodCB1cCBhcw0KPnRlY2huaWNhbCBvYmpl Y3Rpb25zIHRvIHN1Y2ggaGVhZGVyIG1lY2hhbmlzbXMuICBJZiB0aGUgV0cgc2ltcGx5IHdhbnRz IHRvDQo+ZGVjbGFyZSB3aGF0IHdhcyByYWlzZWQgYXMgdGVjaG5pY2FsIG9iamVjdGlvbnMgYXMg bm9uLXRlY2huaWNhbA0KPm9iamVjdGlvbnMNCj4oaS5lLiAid2Ugc2ltcGx5IGRpZG4ndCB3YW50 IHRvIikgLSBzbyBiZSBpdC4gIEJ1dCB0aGF0J3Mgbm90IGhvdyB0aGUNCj5uYXJyYXRpdmUgcmFu Lg0KDQpPayAtIHNvIHRoZSBkZWFkLW9uLWFycml2YWwgY29tbWVudCB3YXMgaW4gdGhlIGNvbnRl eHQgb2YgdGhlIGdlbmVyaWMNCmNvbW11bml0eSBoZWFkZXIgKHdoaWNoIHdvdWxkIGJlIGEgbG9n aWNhbCBwbGFjZSBmb3Igc2NvcGluZykgbm90IGJlaW5nDQppbmNsdWRlZCBpbiB0aGUgbGFyZ2Ug Y29tbXVuaXRpZXMgZHJhZnQuIEkgaG9wZSBJIHVuZGVyc3RhbmQgbm93Lg0KDQoNClRoYW5rcywN CkFjZWUgDQoNCg0KPg0KPi0tIEplZmYNCg0K From nobody Wed Oct 12 13:59:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E71129525 for ; Wed, 12 Oct 2016 13:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 bH55l7mlb8YX for ; Wed, 12 Oct 2016 13:59:24 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 A030D12959C for ; Wed, 12 Oct 2016 13:59:24 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1buQcV-0002uD-AY (job@us.ntt.net); Wed, 12 Oct 2016 20:59:24 +0000 Date: Wed, 12 Oct 2016 22:59:20 +0200 From: Job Snijders To: idr@ietf.org Message-ID: <20161012205920.GZ57491@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Subject: [Idr] Large BGP Communities debugging tools (tcpdump, wireshark) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 20:59:26 -0000 Dear implementers, working group. To ease debugging your implementation of Large BGP Communities, the toolchain has now been upgraded. For various flavours of tcpdump and wireshark patches have been made available. tcpdump.org is the upstream vendor for some of the Linux and BSD distributions out there, they have committed support for decoding Large BGP Communities into their master branch: https://github.com/the-tcpdump-group/tcpdump/issues/543 (this this thread contains PCAP data suitable for tool testing, kindly provided by Pier Carlo Chiodi) https://github.com/the-tcpdump-group/tcpdump/commit/bc700c426251f8d93049d71fd4c007d22b2a2aa0 Wireshark is a populair and detailed packet tracer (also famous for their CLI tool 'tshark'). Arjen Zonneveld submitted a patch to the wireshark project: https://code.wireshark.org/review/#/c/18172/ A patch for FreeBSD's tcpdump is available: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213423 A patch for OpenBSD's tcpdump is available: http://marc.info/?l=openbsd-tech&m=147629067413734&w=2 Please note: not all of these patches have (yet) been accepted into the projects respective main branches or releases. For instance, the patch might not be compliant with the project's style guide. However, for development or early adaptor debugging purposes, these tools beat reading the wire and decoding it in your head. Kind regards, Job From nobody Wed Oct 12 14:56:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A122F12961D for ; Wed, 12 Oct 2016 14:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5Xos4xSKK6Ub for ; Wed, 12 Oct 2016 14:56:24 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CAC12959A for ; Wed, 12 Oct 2016 14:56:24 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id D90FB7C829; Wed, 12 Oct 2016 21:56:23 +0000 (UTC) Date: Wed, 12 Oct 2016 21:56:23 +0000 From: heasley To: Jeffrey Haas Message-ID: <20161012215623.GH45879@shrubbery.net> References: <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> <20161011221544.GG12806@shrubbery.net> <20161012134552.GE22695@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161012134552.GE22695@pfrc.org> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 21:56:25 -0000 Wed, Oct 12, 2016 at 09:45:52AM -0400, Jeffrey Haas: > Arguably this was one of the motivations for doing scoping of attributes or > communities themselves: If the effective operational behavior is almost > always going to be AS-non-transitive, it'd be nice if the cleanup just > happens automagically. Unfortunately people are rather enamored with their > existing cleanup mechanisms. Please, no automatic clean-up. A community may be 100% legitimately used to affect a decision 2 or 3 AS-hops away and it is extremely useful. Operators already know how to alter communities. From nobody Wed Oct 12 15:08:51 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73276129561 for ; Wed, 12 Oct 2016 15:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wIB66VW3MsVy for ; Wed, 12 Oct 2016 15:08:48 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CACEA129490 for ; Wed, 12 Oct 2016 15:08:47 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id b81so96888750lfe.1 for ; Wed, 12 Oct 2016 15:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=30t/Lysg64HhV8MvDL1nd9oz1/YPxFW/9bUbGm7MQEI=; b=l0GqHpq60nuk+o6asXmi1vZP5L1VkYgfAQBznHKdMCB0LP9t40MCEFEfrFvEEyUrer TZYyhWseDhU9AILkAK1l7WBekRrrQM5HLQ6gD1RmVLXXzbGQesbReTR7mWB9eh8Mdq9A dVyZYehxj2t+gcZ6Q3lpjVksy3vM2bJmI5aP4/0gwPCq2Wlg0LDG60Aceg9CbiaRAWXB MGHC3wKZh/aJ4xlOvJaG1kPfPiaACXYd1EigScxD4ucqeMNPAj/gm6hAXUwQItTzRdYx w4vy9ufagXgU+2D2nYLr1ZmeI6z4GmEPnAAHo8dB1UTNHO5qwKF3XueQXIMyxOh13E3/ r9kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=30t/Lysg64HhV8MvDL1nd9oz1/YPxFW/9bUbGm7MQEI=; b=D5wbsmOcPWkndCP1SUEpF7rk3fHP+ot3g8KL9IhB+gUyol70FRAxzhx4ZBGIgbN+Ww fgMEFEzdTaAew+WmRYTX69q5WlqqvGT7iiqKalyQFd1K86vBPAyokG4NliPF3aE4/pa6 kc/ruB/bD4S6Iqdm7vTwWjGoCIHDCIk7IZxQOEuCz6uTYMD8+/3AWj+G4t83nlIF5CJd qQyECqtQpUkkj8q6iXFRatAdQNecG+4Lqu3olZ6tt9qzQU23x4B8FsPwDTwydEwS2O8l Tp+r3VespypuCVe0HXmgWskbJYbgfGmMv5ZuApokX0lJkvMMhmFwcP3iJoopW15AVWYL MX9w== X-Gm-Message-State: AA6/9RmdpVhFoLW+TxxWk8KwVJjK5+SKMvWZxGOpOi+eekOUjdjRdQ6soYT8qdp7PmRVQu26yI3fwloQ5KPKwA== X-Received: by 10.194.178.130 with SMTP id cy2mr4327943wjc.138.1476310125919; Wed, 12 Oct 2016 15:08:45 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Wed, 12 Oct 2016 15:08:44 -0700 (PDT) In-Reply-To: <20161012215623.GH45879@shrubbery.net> References: <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> <20161011221544.GG12806@shrubbery.net> <20161012134552.GE22695@pfrc.org> <20161012215623.GH45879@shrubbery.net> From: Robert Raszuk Date: Thu, 13 Oct 2016 00:08:44 +0200 X-Google-Sender-Auth: cTyNevFKqTkrvRfQnIpLMiZKXSo Message-ID: To: heasley Content-Type: multipart/alternative; boundary=089e01419ce8a244fd053eb23cd4 Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 22:08:50 -0000 --089e01419ce8a244fd053eb23cd4 Content-Type: text/plain; charset=UTF-8 I believe Jeff was talking about intelligent cleanup with sufficient information embedded into community itself such that forwarding BGP speaker can decide what to pass and what to drop ... not an unconditional blind drop. However as I see the folks here - some say do not send anything over eBGP unless explicitely permitted (and sorry but "send-community all" knob is not at that level of granularity needed), some say send everything everywhere. To me this is a bit a conflict of interests which I am really not going to be in the middle of. Some say that standardizing, deployment, education of large communities will take years. And in fact they are very correct. It will take that much indeed. That is why I believe the delta to add few more lines of code which Jakob refused should be smashed by IDR WG in the interest of BGP as protocol and we should all together as a WG produce a solution which scales to the current needs as well as leaves some room for future extensions. That would mean that the overall effort which vastly exceeds few lines of C would gain much more value. Acee stating that may be even wide comms could be progressed in the future is very interesting in the light of his BGP IOS team mate stating in the other thread that he will never implement those :) Kind regards, R. On Wed, Oct 12, 2016 at 11:56 PM, heasley wrote: > Wed, Oct 12, 2016 at 09:45:52AM -0400, Jeffrey Haas: > > Arguably this was one of the motivations for doing scoping of attributes > or > > communities themselves: If the effective operational behavior is almost > > always going to be AS-non-transitive, it'd be nice if the cleanup just > > happens automagically. Unfortunately people are rather enamored with > their > > existing cleanup mechanisms. > > Please, no automatic clean-up. A community may be 100% legitimately used > to affect a decision 2 or 3 AS-hops away and it is extremely useful. > Operators already know how to alter communities. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --089e01419ce8a244fd053eb23cd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I believe = Jeff was talking about intelligent cleanup with sufficient information embe= dded into community itself such that forwarding BGP speaker can decide what= to pass and what to drop
... not an unconditional = blind drop.=C2=A0

Howe= ver as I see the folks here - some say do not send anything over eBGP unles= s explicitely permitted (and sorry but "send-community all" knob = is not at that level of granularity needed), some say send everything every= where.=C2=A0

To me thi= s is a bit a conflict of interests which I am really not going to be in the= middle of.=C2=A0

Some= say that standardizing, deployment, education of large communities will ta= ke years. And in fact they are very correct. It will take that much indeed.= =C2=A0

That is why I b= elieve the delta to add few more lines of code which Jakob refused should b= e smashed by IDR WG in the interest of BGP as protocol and we should all to= gether as a WG produce a solution which scales to the current needs as well= as leaves some room for future extensions. That would mean that the overal= l effort which vastly exceeds few lines of C would gain much more value.=C2= =A0

Acee stating that = may be even wide comms could be progressed in the future is very interestin= g in the light of his BGP IOS team mate stating in the other thread that he= will never implement those :)=C2=A0

Kind regards,
R.

On Wed, Oct 12, 2016 at 1= 1:56 PM, heasley <heas@shrubbery.net> wrote:
Wed, Oct 12, 2016 at 09:45:52AM -0400, Jeffrey Haas: > Arguably this was one of the motivations for doing sc= oping of attributes or
> communities themselves: If the effective operational behavior is almos= t
> always going to be AS-non-transitive, it'd be nice if the cleanup = just
> happens automagically.=C2=A0 Unfortunately people are rather enamored = with their
> existing cleanup mechanisms.

Please, no automatic clean-up.=C2=A0 A community may be 100% legitim= ately used
to affect a decision 2 or 3 AS-hops away and it is extremely useful.
Operators already know how to alter communities.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--089e01419ce8a244fd053eb23cd4-- From nobody Wed Oct 12 15:34:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2922129438 for ; Wed, 12 Oct 2016 15:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Ucb8uBLki9Ij for ; Wed, 12 Oct 2016 15:34:55 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493D81293FE for ; Wed, 12 Oct 2016 15:34:55 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id CFA297C9AC; Wed, 12 Oct 2016 22:34:54 +0000 (UTC) Date: Wed, 12 Oct 2016 22:34:54 +0000 From: heasley To: Robert Raszuk Message-ID: <20161012223454.GR45879@shrubbery.net> References: <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> <20161011221544.GG12806@shrubbery.net> <20161012134552.GE22695@pfrc.org> <20161012215623.GH45879@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 22:34:56 -0000 Thu, Oct 13, 2016 at 12:08:44AM +0200, Robert Raszuk: > I believe Jeff was talking about intelligent cleanup with sufficient > information embedded into community itself such that forwarding BGP speaker > can decide what to pass and what to drop > ... not an unconditional blind drop. I (we, I believe) do not want vendors to do anything automatic about dropping/altering communities. But, provide us all the tools to manipulate them. > Some say that standardizing, deployment, education of large communities > will take years. And in fact they are very correct. It will take that much > indeed. I think you are speculating to push your drafts; you are certainly persistent. I do not expect education to take much time at all. I hope that standardizing is swift - EOY. And, I expect that we will see rapid adoption (deployment) in some specific places; particularly exchanges with RSes. From nobody Wed Oct 12 15:46:18 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8F3129440 for ; Wed, 12 Oct 2016 15:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 f_T6jdkswikm for ; Wed, 12 Oct 2016 15:46:16 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 10E7C1293FE for ; Wed, 12 Oct 2016 15:46:15 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u9CMiwhm000835; Wed, 12 Oct 2016 18:46:15 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 261wyk8gb9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Oct 2016 18:46:14 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9CMkEeJ001272; Wed, 12 Oct 2016 18:46:14 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9CMkAk7001266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Oct 2016 18:46:10 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 12 Oct 2016 22:45:50 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9CMjniA029733; Wed, 12 Oct 2016 18:45:50 -0400 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9CMjlLh029621; Wed, 12 Oct 2016 18:45:48 -0400 Received: by oz.mt.att.com (Postfix, from userid 1000) id BDBECA40E91; Wed, 12 Oct 2016 18:45:46 -0400 (EDT) X-Mailer: emacs 24.3.1 (via feedmail 11-beta-1 I); VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22526.48408.762893.63854@oz.mt.att.com> Date: Wed, 12 Oct 2016 18:45:44 -0400 From: Jay Borkenhagen To: heasley In-Reply-To: <20161012223454.GR45879@shrubbery.net> References: <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> <20161011221544.GG12806@shrubbery.net> <20161012134552.GE22695@pfrc.org> <20161012215623.GH45879@shrubbery.net> <20161012223454.GR45879@shrubbery.net> X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-12_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1034 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610120379 Archived-At: Cc: idr , Robert Raszuk Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Jay Borkenhagen List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 22:46:17 -0000 heasley writes: > Thu, Oct 13, 2016 at 12:08:44AM +0200, Robert Raszuk: > > I believe Jeff was talking about intelligent cleanup with sufficient > > information embedded into community itself such that forwarding BGP speaker > > can decide what to pass and what to drop > > ... not an unconditional blind drop. > > I (we, I believe) do not want vendors to do anything automatic about > dropping/altering communities. But, provide us all the tools to manipulate > them. > I want the same thing that heas wants. So yes: "we" is correct. Jay B. From nobody Wed Oct 12 15:46:38 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF48129583 for ; Wed, 12 Oct 2016 15:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 noYIcqZ3vEqM for ; Wed, 12 Oct 2016 15:46:32 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCEC11293FE for ; Wed, 12 Oct 2016 15:46:31 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id l131so64909417lfl.2 for ; Wed, 12 Oct 2016 15:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=B1SNYT00oMHhDsdE+ea8hT9njri9prVyZVYz+hgtmwE=; b=Eo1u0GF+V63WFta31AeurmdZXKx1V79ZuHu6ZH5FBnxttTjdXLx45cQkEXEftyX8lg +zpwkrMU/GziTHYbg/Ty4ngIhps0iVTdHV5tTP9ivTQmbWrdMwpsS3Q9bjYor70yjMF2 ptC/l2vamyXEzF1ZhpvhyQlT+VVur8kZZmEFSPs10SRqfxEtrATODewUvRswcY1E6hWw SEyFmNBBaHboicyAJ5JW2Np4FzXjXG6w/kYiLv/gFuql3sNg8imWIcOXv05v6I/71Eix VDikS6kLdLxSd/023XtIF6mq++/m5gkiYBrwsZ+tfWbvyS5fTSV8M8Q5JiAobDWSN69A HGJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=B1SNYT00oMHhDsdE+ea8hT9njri9prVyZVYz+hgtmwE=; b=SonNRk/Rk9eoCe1Cby957XIHJW57pW2ZAO9rW/sXY4DA+eGC2w03ikerBr3diuOWUp zhSvQV2Qw4TKAwBQRE+TlABgjtCAoNAHU0XYUrAC/W7Tdv02F304oc1hsTyQlpz0jdis +vV8joeGc9/c1SeQ6V2Tnca/FukpZZJmbo0x3NLHoiu57WgNgTD82JIP/jWNptP40lB4 uJyceDyVCUqj3Q+RHVdWagQlAtpn2RCGIa8BSSBw/qEQxtuZPDwxZGQEaHnUJMyWF3yj cCMY6PtsM1MDqj3lJhOi0YE59cevLVpt2EjxYikjtpnnkjsQi6m7Urw9TN1KXSL1Xfvn WYVA== X-Gm-Message-State: AA6/9RnlRUm/YNCh4czgCbTQDyHdjwNNlZlOKQoaN+Y0HHhBU+aZEW2k8/gr9LwYCQVMIguCGmWROM4UmAVZ6Q== X-Received: by 10.194.94.232 with SMTP id df8mr4552265wjb.227.1476312389888; Wed, 12 Oct 2016 15:46:29 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Wed, 12 Oct 2016 15:46:28 -0700 (PDT) In-Reply-To: <20161012223454.GR45879@shrubbery.net> References: <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> <20161011221544.GG12806@shrubbery.net> <20161012134552.GE22695@pfrc.org> <20161012215623.GH45879@shrubbery.net> <20161012223454.GR45879@shrubbery.net> From: Robert Raszuk Date: Thu, 13 Oct 2016 00:46:28 +0200 X-Google-Sender-Auth: ED3ZrTm5ZQp-SlrWMim9Ilew1i4 Message-ID: To: heasley Content-Type: multipart/alternative; boundary=047d7bb03aae93b29e053eb2c35b Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 22:46:35 -0000 --047d7bb03aae93b29e053eb2c35b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Thu, Oct 13, 2016 at 12:08:44AM +0200, Robert Raszuk: > > I believe Jeff was talking about intelligent cleanup with sufficient > > information embedded into community itself such that forwarding BGP > speaker > > can decide what to pass and what to drop > > ... not an unconditional blind drop. > > I (we, I believe) do not want vendors to do anything automatic about > dropping/altering communities. But, provide us all the tools to manipula= te > them. > =E2=80=8BIt's like asking vendors .. Dear vendor pls give me tools to unloc= k rounded by design metal nut :) =E2=80=8B > > Some say that standardizing, deployment, education of large communities > > will take years. And in fact they are very correct. It will take that > much > > indeed. > > I think you are speculating to push your drafts; you are certainly > persistent. > No .. not at all. I currently gave up on pushing wide or even common header idea if you have not already noticed since large was accepted as WG doc. = =E2=80=8B > I do not expect education to take much time at all. =E2=80=8BWell I value your expectations however the personal experience edu= cating network community in Nanog, RIPE, APRICOT and many *NOGs proves me otherwise. I think Job was right on the spot in his recent mail on the estimate of the effort. > I hope that standardizing > =E2=80=8B =E2=80=8B > is swift - EOY. =E2=80=8BSure.=E2=80=8B > And, I expect that we will see rapid adoption (deployment) in > some specific places; particularly exchanges with RSes. > =E2=80=8BIf you need large community for IXes then it is fine. To me real u= se of BGP as protocol is a bit more then that. Best, R. --047d7bb03aae93b29e053eb2c35b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thu, Oct 13, 2016 at 12:08:44AM +0200, Robert Ra= szuk:
> I believe Jeff was talking about intelligent cleanup = with sufficient
> information embedded into community itself such that forwarding BGP sp= eaker
> can decide what to pass and what to drop
> ... not an unconditional blind drop.

I (we, I believe) do not want vendors to do anything automatic about=
dropping/altering communities.=C2=A0 But, provide us all the tools to manip= ulate
them.

=E2=80=8BIt= 9;s like asking vendors .. Dear vendor pls give me tools to unlock rounded = by design metal nut :) =E2=80=8B
=C2=A0
> Some say that standardizing, dep= loyment, education of large communities
> will take years. And in fact they are very correct. It will take that = much
> indeed.

I think you are speculating to push your drafts; you are certainly p= ersistent.

No .. not= at all. I currently gave up on pushing wide or even common header idea if = you have not already noticed since large was accepted as WG doc. =E2=80=8B<= /div>
= =C2=A0
I do not expect educa= tion to take much time at all.=C2=A0

=E2=80=8BWell I value your expectations however the personal = experience educating network community in Nanog, RIPE, APRICOT and many *NO= Gs proves me otherwise. I think Job was right on the spot in his recent mai= l on the estimate of the effort.=C2=A0
=C2=A0
I hope that standardizing
=E2=80=8B =E2=80=8B
is swift - EOY.=C2=A0
=E2=80=8BSure.=E2=80=8B
= =C2=A0
And, I expect that we will s= ee rapid adoption (deployment) in
some specific places; particularly exchanges with RSes.

=E2=80=8BIf you need large community fo= r IXes then it is fine. To me real use of BGP as protocol is a bit more the= n that.=C2=A0

Best,
R.

--047d7bb03aae93b29e053eb2c35b-- From nobody Wed Oct 12 16:34:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874F5129652 for ; Wed, 12 Oct 2016 16:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HGmkhhG2X_TK for ; Wed, 12 Oct 2016 16:34:46 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4CF129632 for ; Wed, 12 Oct 2016 16:34:45 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id A74667CB55; Wed, 12 Oct 2016 23:34:45 +0000 (UTC) Date: Wed, 12 Oct 2016 23:34:45 +0000 From: heasley To: Robert Raszuk Message-ID: <20161012233445.GY45879@shrubbery.net> References: <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> <20161011221544.GG12806@shrubbery.net> <20161012134552.GE22695@pfrc.org> <20161012215623.GH45879@shrubbery.net> <20161012223454.GR45879@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: heasley , idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 23:34:47 -0000 Thu, Oct 13, 2016 at 12:46:28AM +0200, Robert Raszuk: > > > > Thu, Oct 13, 2016 at 12:08:44AM +0200, Robert Raszuk: > > > I believe Jeff was talking about intelligent cleanup with sufficient > > > information embedded into community itself such that forwarding BGP > > speaker > > > can decide what to pass and what to drop > > > ... not an unconditional blind drop. > > > > I (we, I believe) do not want vendors to do anything automatic about > > dropping/altering communities. But, provide us all the tools to manipulate > > them. > > > > ​It's like asking vendors .. Dear vendor pls give me tools to unlock > rounded by design metal nut :) ​ I do not understand that analogy. Automatic dropping is like giving me the toolbox full of tools but no key to unlock it. /) btw, tools exist to remove rounded nuts. > > > Some say that standardizing, deployment, education of large communities > > > will take years. And in fact they are very correct. It will take that > > much > > > indeed. > > > > I think you are speculating to push your drafts; you are certainly > > persistent. > > No .. not at all. I currently gave up on pushing wide or even common header > idea if you have not already noticed since large was accepted as WG doc. ​ yes, you've stopped trying to block -large- for -wide-, but no operator suggested that you stop pushing -wide- for the sake of -wide-. I think -wide- is a good idea. > > I do not expect education to take much time at all. > > ​Well I value your expectations however the personal experience educating > network community in Nanog, RIPE, APRICOT and many *NOGs proves me > otherwise. I think Job was right on the spot in his recent mail on the > estimate of the effort. they know rfc1997; this is rfc1997+. unless their vendor does something silly with RPL features, where is the difficulty? > > And, I expect that we will see rapid adoption (deployment) in > > some specific places; particularly exchanges with RSes. > > ​If you need large community for IXes then it is fine. To me real use of > BGP as protocol is a bit more then that. I'm suggesting that there is a need there, a clear one with great benefit to them (ie: incentive), and RSes have more flexibility to alter their code and upgrade than others. From nobody Wed Oct 12 16:44:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F874129630 for ; Wed, 12 Oct 2016 16:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 U8sB4hCw5cad for ; Wed, 12 Oct 2016 16:44:52 -0700 (PDT) Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com [209.85.216.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDF4120726 for ; Wed, 12 Oct 2016 16:44:51 -0700 (PDT) Received: by mail-qt0-f175.google.com with SMTP id s49so28000924qta.0 for ; Wed, 12 Oct 2016 16:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dNvHKKXxYdxHCWOS2YxF/cauhXEbXOzzzopJcg4qHsk=; b=vseB5Prus+skp7h/GHWmkLjWhjZOzvv1dsBN+ffRiZfK/2FYEePsqpfvkPMkFK7iZ1 d3lwlmjd1fN26StzzXzzNUZatbqwzExyA+9lw1KuhVnnJH82PDa4HKcEDLjsJpA5s4a6 O5Cx65YfHALyJ0UphO2Qs9fDPUjBu7raMlByUnwql6rxpCLppACeLWkX7XGaNAywbLxb YTORS/oYTfr2AfaUkzkKr+JRLMeYY08VZYhtcBrXwxNSdL+bo+HPox2Y2r54M+6wqquI /AvfMt3MZjFbYcolEhQxZCYH4fU8YdZepS0ORVVDY1MFynhK0JIwcAvDTrwLSJQcsiXg OMTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dNvHKKXxYdxHCWOS2YxF/cauhXEbXOzzzopJcg4qHsk=; b=TFganVaaecrDSrljia9RAN83N1XNn0bj7whT+lfdlPxg15n375tQHAcH4iNCOdFA2W tfO5qAqrRAp1Srn5GQ93MknBPQ0z12kr+ETce91DGEkuHomf05SFsoyKEM3esRdelxs1 s/7a/0dkRt9QxPecvUxvEQQmlWrSKzE4efz40wpJPOafWlV2vbQlL2JdzbmRXzxV0agK 5sLeUFWqxP9vaMk0huq57Fbj8O7IeXdPu38JcKTpoC/pow4eAk4J0PmFRmElTfUD83DJ ISTmBT/3N5elV5dBX9kpt0elKf8EI7TxBbXcKfods6dcymojSfhCH3CpKpp8a99bt9m+ 0N0A== X-Gm-Message-State: AA6/9RmwpG3PHn958Tt720250OUP03aoD0wpthQZI8CAolplBTlKt/E0BRqxPB5zneH6A1jqpgrJQ2/zrGEzpA== X-Received: by 10.237.58.161 with SMTP id o30mr3956297qte.3.1476315830939; Wed, 12 Oct 2016 16:43:50 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.105.244 with HTTP; Wed, 12 Oct 2016 16:43:49 -0700 (PDT) In-Reply-To: <20161012233445.GY45879@shrubbery.net> References: <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> <20161011221544.GG12806@shrubbery.net> <20161012134552.GE22695@pfrc.org> <20161012215623.GH45879@shrubbery.net> <20161012223454.GR45879@shrubbery.net> <20161012233445.GY45879@shrubbery.net> From: Christopher Morrow Date: Wed, 12 Oct 2016 19:43:49 -0400 X-Google-Sender-Auth: GuglG2_b38fdrhMHgdUY32xE1DA Message-ID: To: heasley Content-Type: multipart/alternative; boundary=001a11404abeae068a053eb3905b Archived-At: Cc: idr , Robert Raszuk Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 23:44:54 -0000 --001a11404abeae068a053eb3905b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2016 at 7:34 PM, heasley wrote: > > =E2=80=8BIf you need large community for IXes then it is fine. To me re= al use of > > BGP as protocol is a bit more then that. > > I'm suggesting that there is a need there, a clear one with great benefit > to them (ie: incentive), and RSes have more flexibility to alter their > code and upgrade than others. I think once -large- is in code from vendors it's easy to see rollout happen where that sort of function is required... quickly. People will pick up the code for their gear as they need this feature. --001a11404abeae068a053eb3905b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Oct 12, 2016 at 7:34 PM, heasley <heas@shrubbery.net> wrote:
> =E2=80=8B= If you need large community for IXes then it is fine. To me real use of
> BGP as protocol is a bit more then that.

I'm suggesting that there is a need there, a clear one with grea= t benefit
to them (ie: incentive), and RSes have more flexibility to alter their
code and upgrade than others.

I think once -large- is= in code from vendors it's easy to see rollout happen where that sort o= f function is required... quickly. People will pick up the code for their g= ear as they need this feature.
--001a11404abeae068a053eb3905b-- From nobody Wed Oct 12 17:11:00 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BD2129401 for ; Wed, 12 Oct 2016 17:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Hh2rQTFtIm2i for ; Wed, 12 Oct 2016 17:10:58 -0700 (PDT) Received: from relay.dacor.de (relay.dacor.de [217.24.56.24]) by ietfa.amsl.com (Postfix) with ESMTP id 338D2127735 for ; Wed, 12 Oct 2016 17:10:58 -0700 (PDT) Received: from exchange.dacor.de (astaro1.dacor.de [217.24.48.66]) by relay.dacor.de (Postfix) with ESMTPS id 801D4E3019; Thu, 13 Oct 2016 02:10:56 +0200 (CEST) Received: from ex02.suecdacor.local (192.168.1.16) by ex02.suecdacor.local (192.168.1.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 13 Oct 2016 02:10:56 +0200 Received: from ex02.suecdacor.local ([::1]) by ex02.suecdacor.local ([::1]) with mapi id 15.00.1210.000; Thu, 13 Oct 2016 02:10:56 +0200 From: Julian Seifert To: Peter Hessler , t.petch Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt Thread-Index: AQHSG79ZgAsifiK0skyf/LayHf2VVaCTKdYAgANQsh7//+YjAIAAOTQi///ntYCAAD/ogIAGElhC///0hIAAFJAnAAAnwMCAAAelkAAAIVEWdQAX9CsAAEtc/Zb//+S4gIACnkc1 Date: Thu, 13 Oct 2016 00:10:55 +0000 Message-ID: <1476317462333.82977@dacor.de> References: <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net>, <20161011095417.GL19434@gir.theapt.org> In-Reply-To: <20161011095417.GL19434@gir.theapt.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [88.133.178.43] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 00:11:00 -0000 Hi, =0A= =0A= On 2016 Oct 11 phessler wrote:=0A= > Putting my own ASN, or the ASN of my peer that I wish to control, will=0A= > be the main uses; I agree. But there is a difference between SHOULD and= =0A= > MUST. Since I MUST allow users to change the value there, I am happy.=0A= =0A= I totally agree and want to give support to the current wording in the draf= t.=0A= " Global Administrator: A four-octet namespace identifier. This=0A= SHOULD be an Autonomous System Number assigned by IANA."=0A= =0A= "Implementations MUST allow the operator to specify any value for the=0A= Global Administrator field."=0A= =0A= The semantics of the value configured in the community is up to the operato= r and must not be =0A= enforced/assumed by the implementation. It makes sense to reserve certain v= alues/prohibit their=0A= use to prevent compatibility issues, keep special values for tests/document= ation/checking and for well known communities=0A= that might be defined later on, but don't force operators to only be allowe= d to configure iana assigned =0A= ASN values or force implementations to only allow configuration of an ASN = in the GA that is a configured ASN on=0A= the specific router etc. =0A= =0A= Communities are great because of the ambiguity(sorry of not the correct ter= m for what I want to express)=0A= The vast number of values I can configure with meaning only for me and part= ies I interact with) =0A= being too strict will greatly diminish the value they represent as a tool i= n operating networks. =0A= And would be contradictory to the operational need from which the draft aro= se. =0A= =0A= kind regards,=0A= =0A= Julian=0A= From nobody Thu Oct 13 01:57:07 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E130F1294A5 for ; Thu, 13 Oct 2016 01:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 wkCrpI2JjLeC for ; Thu, 13 Oct 2016 01:57:03 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40105.outbound.protection.outlook.com [40.107.4.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E621293EE for ; Thu, 13 Oct 2016 01:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2NnofAG99S1xNjxJC34oBYJEp9Vq2nyVBLT9wP6gPtY=; b=OHR3zsICbh1gFZe+IWlpJE3GAWKvttN8dsuh4OOaPkJ5nnuKoAaxkZxxsLIfrtsI9uNCATuoiqDQA7z1aQGWisNAjoZTEQ5BMe1oqoFFwc8Aw0MkJncxAtJjjbYHIuInwiH1vViITVtw3iVPasN5aArsD5DwdHS0Eyz/iKv7gAw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by HE1PR0701MB3004.eurprd07.prod.outlook.com (10.168.93.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Thu, 13 Oct 2016 08:57:00 +0000 Message-ID: <00fb01d2252f$700c2360$4001a8c0@gateway.2wire.net> From: t.petch To: Julian Seifert , Peter Hessler References: <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net>, <20161011095417.GL19434@gir.theapt.org> <1476317462333.82977@dacor.de> Date: Thu, 13 Oct 2016 09:54:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: AM4PR0902CA0023.eurprd09.prod.outlook.com (10.171.89.33) To HE1PR0701MB3004.eurprd07.prod.outlook.com (10.168.93.138) X-MS-Office365-Filtering-Correlation-Id: 47408346-f32e-4d3e-3da0-08d3f346e565 X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 2:hozXEEzZ7w3jpUcxLfs3aug1APpmkojCVqi85cn/v9GBy6xXyCfMFPIBSEXkJKx+PfIZdBvXkSQiugQzZA/34slFSpfrmhs+XvJqbqiRlLtVl0AzqLsFpKXqrRNu2Bo2FXuPrYrNSlhihw5O/rf8enpGTdueLc1eytAY4FTq++1oGttBNHD9MBvN+60JMEq5eq1U8R1jngVBxhEzhGXO8g==; 3:ztmvuu7eMVcxFRLKZtCS5J1yk+5Vq5bJgtglwLuvek4FbDxKoPeJY8/C/7u7CPL+K+QjEyt9DDOALnWBQo08x15XUTuw/1QR9YW+LcJKmjG7iwHPD8nhpbPCjDHCGJTbNqR60pTgReyQxQi3eXXz9A==; 25:Rjl4FRpD1wnLMvz53pjuvcAymcZIX0wOiirpNQcpLA04rBJsF4MKhyCsc6Vo0ZP4qgTZ9xS2xVe/V+7BEiIe4VBwvD+OxPBenPrxX1goPjAnvTGVpxK1miUHHUNacnimkYRFT4ekr9GhLtKJdUPwlODzGE/vlulC+poEXPUaxIEfnPIgv5KvWCWO7xGjsk8x4ArXtHf7bzvqceIBD6hUPIu75vFEj6LTUVDTIsz3mOXnnOIv+aaUXgGRsaLdYEusmlcf2SH7v8/fMxO6iC3NNg2gJoqAv6cFMtd7FaptrgEVn1f1a3qopUMDNSbWv+ww6MjY0n7FKV8JrTm7o36YFflYOGi1oaZVjbY9GQ4pvo2rMmrhyGTIgdleirdILpQJBBER5G9uZlZ6fKNzXPm79VAiVb9yz2Xts77dyeRNYQzeM40sAGTTphC0xxqZNoaL X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3004; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 31:xLqq6QOCzd6VSQ8PaeX8Kuopi9kRZB0XJG0LqY4GGFdZKN4GmSQzp7SJIa6+b30nCPsfsyHTC9lz9jjDIJNa1ECiR5WXM9pEeKDm4m/sCpmQVrRFs4bztxVFWsWvGU63RhiEkGR/OiWwWk7E/hNAyT0sbEcmRuka+BtfzGYy04XxCMvC6Kh1xs1NLzZfBJQlFn71FqEVqNkq8QpAr88wnch19kIAna3exlvMCxpVGLj9fjpNegrD8ETsXVpMyY+NZdYAc7oaVMBq4wMd0s3Icg==; 4:5rELtMXN6UwJAxA/pg375Mpsj+ji00rxsk2Qt4TA78gTOYwQyZrHiGfnaf24e+hI3+XPiPQ0f5/NI/gt7magSklFY9wnZsylwaaPbrwsTORmzfp54KBpQ/qgI2KBT35rmWqNZKpfV/YJfXnWW7Fzzk/Ojc0CqkMnz+ZzyIOt/nGdJDRGJCU6BjeiVKOwfwjXw4XBxHOJNruUkgpT12UzT7aI1oGOuqGoBJBs6wMk3IG/+sSzUbzhgWwb2cbTdrFLPHDu9DvlgBHxQ99eIE55ao0wcPI5vLayGRRc55PqTOySmPcyugFRkuq1ivuHLppv1asZ7moxZB96ntncyBQrTnIdlDjHB37oiCfwqtBzyXEIobyMaGQ0atP1ryPxnJTFkM1mB4bJDd+IuaNX2STplQ6krpZ/gBN2X32n2Zr2tusq+2xI9v9fZHDFQ2fqRLfg X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(35073007944872); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR0701MB3004; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3004; X-Forefront-PRVS: 0094E3478A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(24454002)(13464003)(189002)(199003)(377454003)(105586002)(6116002)(68736007)(586003)(97736004)(14496001)(3846002)(5001770100001)(116806002)(9686002)(81156014)(8676002)(81166006)(4326007)(50226002)(86362001)(44716002)(19580405001)(47776003)(1556002)(44736004)(62236002)(66066001)(19580395003)(81816999)(23756003)(61296003)(42186005)(7736002)(84392002)(93886004)(81686999)(76176999)(106356001)(50986999)(7846002)(5660300001)(6666003)(230700001)(1456003)(33646002)(305945005)(4720700003)(189998001)(101416001)(2906002)(92566002)(77096005)(230783001)(50466002)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3004; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3004; 23:KIJK0hvs0OH1NnKOfg0mkV5Ujcdjrqp8igF/T?= =?iso-8859-1?Q?4YgpEPdPTTNAe2bpaFonW5Ek1pUpvHXPcZO/4gHC04MD8n4RFWGGS88whI?= =?iso-8859-1?Q?PGks/qxkyoJ2Dx/ZOlIcC3HuLw0dvPg2NrcbPwPOQES9alhdkO1EM/JTqV?= =?iso-8859-1?Q?H4Ao8CCn09cOo32tIBltGZq8XRwC+FHePKd+neT+iLhN8HggJCJr1TyW2S?= =?iso-8859-1?Q?gD9vQjswcPz1B4zUPKeAqTTXOfrvJSsTSn37IFBV7aoL/0bQvypT1EOBZY?= =?iso-8859-1?Q?8LZBxxz9a03iJKuLeFmz3+V6PLpvV1jNP/w63oDM1soKYqsiE+am6VQl/z?= =?iso-8859-1?Q?RLERUZ7idStZxO3ysnSd64NuJSKN9TfEMWsuz2aHNbk50znFM67BJ+QzNu?= =?iso-8859-1?Q?ua9Ep7O2vGFlPFS5Z+P4oHhnydOz0qETN0wIqy89XBXwYdeNrjy3agWfrJ?= =?iso-8859-1?Q?bMTM72iww+ssopQ9d0pydFFP/FBIolkF8sFRG2jDM/clt89IE7gjnBh7HH?= =?iso-8859-1?Q?iuT36BU5I8b/Qhheen5ceANPT9d1u5psk41l4TNLrZQrY+3giCjI2Tuzji?= =?iso-8859-1?Q?wTY4Hxo7oVO4wb4pqKqVVQ2MLlIsgKPjlYkHfgGbAxFxTStGDcrgz7nH6c?= =?iso-8859-1?Q?rwBvZcvsT592T/9l3YBpeiAD8x4Pa1i6t5zunZ858A4YxUPza5ODpm6SaJ?= =?iso-8859-1?Q?7KI+a7esG91j+eU8gl9G49PWZ0tYIWthuX2VadwajNucUMTs4a8kb9WOa/?= =?iso-8859-1?Q?JiUr+nG9KZ8bGpUO+J6OfO5dolUe34aRloHN8OxiVHTZ5oKqlBW6RzHGqp?= =?iso-8859-1?Q?AWo3a2i9UstvGJZhtcdjfTB3gdgSzetwbBzv36f0RWcA/zUov5t4sxdR0N?= =?iso-8859-1?Q?PZBS9yB1oaJ0RAfX+qkMPse8p3WuZvJRNvaqM2d8t3EY/zyQS4IsIx/6ol?= =?iso-8859-1?Q?LEQ5QUva1i1Zowft8PhZUoXLEU0EmZ7G4TGyw0WpRPFAAHdn6m6F+MRDJu?= =?iso-8859-1?Q?vNk9lwnq9cdu3lpPYVDn6jhNC9SgCQ8QIxTmEE150IyenYwOkekwuPoJad?= =?iso-8859-1?Q?YC9irJCEdpCG+3dvHH8sDJIe8zKAesEOAIJq9q6oAyZq9GByu1ynuAXTqJ?= =?iso-8859-1?Q?QpgrszwUyCP9/v1lydEhvubq0qaxmQHpXyLc9SFDkd+/yj90EQA/4UaAPN?= =?iso-8859-1?Q?za+vvehCZgH+aj6KQ7gy2kEz9cUPD01wvJdwHAFukQf6BTF2xA7sMMiCBW?= =?iso-8859-1?Q?7alewTA3p7HRfVzrxh01JUg1051IFFteJhbnh6qtR8UCcmz3+3uRoeTR5Q?= =?iso-8859-1?Q?5TJoyTTUKl1xPvEgr5ulMtq363Tom8cKNK+Bay+iXprcOqa4lRLApYmArD?= =?iso-8859-1?Q?EhXL4jYdUgQq/ni4BwWhDWmpF5f4/7cskxTy5F0clq9RRuA7wTYfiAf6v8?= =?iso-8859-1?Q?slscdeOl+HDGhZnD/eOLGur3uYL6VUaHGbwC4cRBavnMtG0UL9FAEmxAYX?= =?iso-8859-1?Q?VJnzqUehsu+aRF6y63BaHz/E4hC19710Ax2i2hAjr+z?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 6:p1484xCXz4Zqv8KYGKbXF7Meu6dj2bSzsyyxnbTgyWn94bmQ3bgy9KPDjjJ3shD35lM5Ycz4VtAM+lxwnS6ehwyWAOwx68GyCpbbRVgKCrSyYY56ImFouxn446r1zUrjjsRR6DOgS0nlLn4oCVomInYLJvXS/vVVv6CV+NEcPAqK9ZIHabO8lfr2jyF7hUNzVmbFwcoks+KYhUuPSoz03nfEn9GO9F7rVPdL4pqk1W1oAR3L3CD/QHTMy9O1i2LVz2Govn2+DB4g9i0hi9ztPxPUUeqC02/YIkzsGhJvFQZhHzP7QSZNZYKpI1nlpfep; 5:WGT4ftOr/BweA3Um8BsjYgVV7mlQxWImJegoSR4jUmgrZhI64BFTvhbBvL0CwlGVQXElvQ6d1jTfzPGPy2Wm2r9ssX9iePQjv+gDNEECVxw+KslsxEAvJRa0mE2aMQPEbjfbP+YFc+dLwTYEUInA8g==; 24:8eI0FS+RwGqQXlZDPGFSt3tUzhojLm2yFVd29/JkV0ABLBtH96dfED/VyLUrAPzPLApQ3KvkLy9YtfAej9vAKdzCGGAXGZxh99x20wxPdOs=; 7:0QXRSedrr2nEMtbZnAkaKksOJy3mT2c5fjg3A5QiUss9ZSRqvps0yWcaBAqPoxu1CAAOUVOmL+YTE8SxSaGsZlZAtjJMpQRsoKkUoS38NsjzQM6fv3QE6mKa71N4JBSE4n0uHKvHKbIfsVGuGHIGbgIBVBY01ppSN7rUpCm0zbGUWN76HcMeS0tyHkSlr5K3LUe6E863UAlXz8mH5C8pWWKndpdshxm6cdOzYTnZXhn4jZhU5kIUMxJ2+jdrDqmxnudmrntSq3eLO0VCVsVF/9dVlS8YfTHKaKz43CUYpoQ5bvRZreaCFdrJ2RtnhAVPPQe1Vq9I7TfrUsg7zNpkicetC7DUmeBM/SiPcBO2MFg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2016 08:57:00.7136 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3004 Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 08:57:06 -0000 ----- Original Message ----- From: "Julian Seifert" Sent: Thursday, October 13, 2016 1:10 AM Hi, On 2016 Oct 11 phessler wrote: > Putting my own ASN, or the ASN of my peer that I wish to control, will > be the main uses; I agree. But there is a difference between SHOULD and > MUST. Since I MUST allow users to change the value there, I am happy. I totally agree and want to give support to the current wording in the draft. " Global Administrator: A four-octet namespace identifier. This SHOULD be an Autonomous System Number assigned by IANA." "Implementations MUST allow the operator to specify any value for the Global Administrator field." The semantics of the value configured in the community is up to the operator and must not be enforced/assumed by the implementation. It makes sense to reserve certain values/prohibit their use to prevent compatibility issues, keep special values for tests/documentation/checking and for well known communities that might be defined later on, but don't force operators to only be allowed to configure iana assigned ASN values or force implementations to only allow configuration of an ASN in the GA that is a configured ASN on the specific router etc. Communities are great because of the ambiguity(sorry of not the correct term for what I want to express) The vast number of values I can configure with meaning only for me and parties I interact with) being too strict will greatly diminish the value they represent as a tool in operating networks. And would be contradictory to the operational need from which the draft arose. Julian I believe I understand the need that you express but the BGP protocol does not have the mechanics to express it! You say 'configure with meaning only for me and parties I interact with' but BGP has no such mechanism. As Jeff has already explained, an optional attribute either gets dropped, which is unlikely to work with route reflectors, or it gets passed on and this I-D chooses the option that it gets passed on. So a community that only you and your fellow parties understand is let loose on the whole Internet where it is open to misinterpretation by everyone else because, e.g., they are expecting an ASN and are getting something else that is private to you. And the remit of the IETF is to make the Internet as a whole work better so in updating the specification of BGP, the IETF has to consider the trade off of something that benefits you and the parties you interact with versus the risk of causing some level of damage to the Internet. Obviously, I hope, I am concerned about the damage; you gain, but somewhere else across the globe, someone else's connectivity may fail. Of course it is possible to define a more sophisticated system that allows communities to go so far and no further but that is not the BGP we have. Tom Petch kind regards, Julian = From nobody Thu Oct 13 03:08:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33ED212972B for ; Thu, 13 Oct 2016 03:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 yvCeoJ2nDizk for ; Thu, 13 Oct 2016 03:08:29 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 E6714129727 for ; Thu, 13 Oct 2016 03:08:28 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bucw5-0000NL-Fq (job@us.ntt.net); Thu, 13 Oct 2016 10:08:28 +0000 Date: Thu, 13 Oct 2016 12:08:22 +0200 From: Job Snijders To: idr@ietf.org Message-ID: <20161013100822.GD57491@Vurt.local> References: <20161011152950.GY57491@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161011152950.GY57491@Vurt.local> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Subject: Re: [Idr] FW: Large BGP Communities beacon in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 10:08:32 -0000 Hi all, Can anyone from Huawei help debug an issue? It appears that some Huawei routers (at least NE40E with VRP 8.100) are entirely ignoring route announcements which have a Large BGP Community path attribute attached. For testing, pingable beacon IPs: 192.147.168.255 / 2001:67c:208c::1 Not propagating an unknown optional transitive path attribute is one thing, but outright dropping the entire route is a whole other level :) Kind regards, Job On Tue, Oct 11, 2016 at 05:29:50PM +0200, Job Snijders wrote: > This message was posted to various operational mailing lists. > > TL;DR - there are now two beacons carrying a Large BGP Community in the > DFZ. On IPv4 we observe full coverage from the NLNOG RING LG - on IPv6 > not so much. > > Kind regards, > > Job > > ----- Forwarded message from Job Snijders ----- > > Date: Tue, 11 Oct 2016 17:01:56 +0200 > From: Job Snijders > To: nanog@nanog.org, routing-wg@ripe.net, Jared Mauch > Subject: [routing-wg] Large BGP Communities beacon in the wild > > Dear all, > > Large BGP Communities are a novel way to signal information between > networks. An example of a Large BGP Communities is: 2914:4056024901:80. > > Large BGP Communities are composed of three 4-octet integers, separated > by something like a colon. This is easy to remember and accommodates > advanced routing policies in relation to 4-Byte ASNs. It is the tool that has > been missing since 4-octet ASNs were introduced. > > IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) in > the "BGP Path Attributes" registry under the "Border Gateway Protocol > (BGP) Parameters" group. > > The draft can be read here: https://tools.ietf.org/html/draft-ietf-idr-large-community > > Additional information about Large BGP Communities can be found here: > http://largebgpcommunities.net/ > > Starting today (2016.10.11), the following two BGP beacons are available > to the general public, with AS_PATH 2914_15562$ > > Both these prefixes have a Large BGP Community attached: > > 2001:67c:208c::/48 > 192.147.168.0/24 > > Large BGP Community - 15562:1:1 > > The NLNOG RING BGP Looking Glass is running the latest version of BIRD > which understands the Large BGP Community Path Attribute. > > IPv4 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.147.168.0/24 > IPv6 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:67c:208c::/48 > > In theory, since this is an optional transitive BGP Path Attribute, all > the Looking Glass' peers should boomerang the Large Community back to > the LG. However we currently observe that 50 out of 75 peers propagate > the Large BGP Community to the LG. > > Relevant Router commands to see if you receive the attribute, or whether > one of intermediate networks has stripped the attribute from the route: > > IOS: show ip bgp path-attribute unknown > shows all prefixes with unknown path attributes. > > IOS #2 - like on route views: > route-views>sh ip bgp 192.147.168.0 > BGP routing table entry for 192.147.168.0/24, version 98399100 > Paths: (39 available, best #30, table default) > Not advertised to any peer > Refresh Epoch 1 > 701 2914 15562 > 137.39.3.55 from 137.39.3.55 (137.39.3.55) > Origin IGP, localpref 100, valid, external > unknown transitive attribute: flag 0xE0 type 0x1E length 0xC > value 0000 3CCA 0000 0001 0000 0001 > rx pathid: 0, tx pathid: 0 > > IOS-XR: (you must look at specific prefixes) > RP/0/RSP0/CPU0:Router#show bgp ipv6 unicast 2001:67c:208c::/48 unknown-attributes > BGP routing table entry for 2001:67c:208c::/48 > Community: 2914:370 2914:1206 2914:2203 2914:3200 > Unknown attributes have size 15 > Raw value: > e0 1e 0c 00 00 3c ca 00 00 00 01 00 00 00 01 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > JunOS: > user@JunOS-re6> show route 2001:67c:208c::/48 detail > 2001:67c:208c::/48 (1 entry, 1 announced) > AS path: 15562 I > Unrecognized Attributes: 15 bytes > Attr flags e0 code 1e: 00 00 3c ca 00 00 00 01 00 00 00 01 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > A note about router Configurations: > > Ensure you are not fitlering the path attributes, eg: > > JunOS: > [edit protocols bgp] > user@junos# delete drop-path-attributes 30 > > XR: > configure > router bgp YourASN > attribute-filter group ReallyBadIdea ! avoid creating bogons > no attribute 30 > ! > ! > > Contact persons: myself or Jared Mauch or NTT NOC. BGP Session > identifier 83.231.213.230 / 2001:728:0:5000::a92 AS 15562. > > Kind regards, > > Job > > > ----- End forwarded message ----- > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Oct 13 05:11:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3451294D6 for ; Thu, 13 Oct 2016 05:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=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 3CAAyrLqBH8S for ; Thu, 13 Oct 2016 05:11:21 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B786A1294BE for ; Thu, 13 Oct 2016 05:11:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.182; From: "Susan Hares" To: "'IETF IDR WG'" Date: Thu, 13 Oct 2016 08:09:32 -0400 Message-ID: <00b201d2254a$a83f8b30$f8bea190$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B3_01D22529.212E3950" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdIlSg4FwWXFq1J3SgK4KWGp0vYusw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: cl@tix.at Subject: [Idr] WG Adoption of draft-loibl-bacher-idr-flowspec-clarification-00.txt (10/13/2016-10/27/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 12:11:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B3_01D22529.212E3950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG adoption call for draft-loibl-bacher-idr-flowspec-clarification-00.txt from 10/13/2016 to 10/27/2016. This draft provides a list of clarifications needed for RFC5575 discovered at a large interoperability test. Please consider if this draft will help us in the creation of RFC5575bis. Sue Hares and John Scudder ------=_NextPart_000_00B3_01D22529.212E3950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG adoption call for = draft-loibl-bacher-idr-flowspec-clarification-00.txt from 10/13/2016 to = 10/27/2016.  

 

This draft = provides a list of clarifications needed for RFC5575 discovered at a = large interoperability test.   Please consider if this draft = will help us in the creation of RFC5575bis. =   

 

Sue Hares and John Scudder =

------=_NextPart_000_00B3_01D22529.212E3950-- From nobody Thu Oct 13 07:11:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E271298D6 for ; Thu, 13 Oct 2016 07:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9q0NF5SI06LX for ; Thu, 13 Oct 2016 07:11:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E2D711298E9 for ; Thu, 13 Oct 2016 07:11:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C9F901E32B; Thu, 13 Oct 2016 10:13:43 -0400 (EDT) Date: Thu, 13 Oct 2016 10:13:43 -0400 From: Jeffrey Haas To: heasley Message-ID: <20161013141343.GH22695@pfrc.org> References: <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> <20161011221544.GG12806@shrubbery.net> <20161012134552.GE22695@pfrc.org> <20161012215623.GH45879@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161012215623.GH45879@shrubbery.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 14:11:49 -0000 On Wed, Oct 12, 2016 at 09:56:23PM +0000, heasley wrote: > Wed, Oct 12, 2016 at 09:45:52AM -0400, Jeffrey Haas: > > Arguably this was one of the motivations for doing scoping of attributes or > > communities themselves: If the effective operational behavior is almost > > always going to be AS-non-transitive, it'd be nice if the cleanup just > > happens automagically. Unfortunately people are rather enamored with their > > existing cleanup mechanisms. > > Please, no automatic clean-up. A community may be 100% legitimately used > to affect a decision 2 or 3 AS-hops away and it is extremely useful. > Operators already know how to alter communities. Experience has shown that a lot of people are simply bad about cleaning up their trash. (And also how it was found that some particular bit of code had a hash table poorly sized...) This is really more an issue in the scope of VPN related (extended) communities, but the analogy generally holds. What I think is being missed in the conversation is just because something has a scoping bit (i.e. AS-non-transitive), nothing stops you from using policy to say "don't enforce it for *this* thing". However, I think that use case is a bit weaker once you move into the federated AS scoping case. ----- I do want to make one partially orthogonal comment here: A number of the highly opinionated operational folk that are participating on IDR follow or set current best operational practices for dealing with communities. However, you're not the only set of users of these features. Forcing protocol feature sets to stay to your current strictures because you've rigorously instrumented their behavior may not be the right answer. But whether "doing better" comes via protocol changes, or getting better common practices embedded in running (policy) code is a longer conversation. -- Jeff From nobody Thu Oct 13 07:17:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBCC1298F7 for ; Thu, 13 Oct 2016 07:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Ofqym4LGiRDM for ; Thu, 13 Oct 2016 07:17:21 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9FD12990D for ; Thu, 13 Oct 2016 07:17:12 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 84FB91E32B; Thu, 13 Oct 2016 10:19:12 -0400 (EDT) Date: Thu, 13 Oct 2016 10:19:12 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20161013141912.GI22695@pfrc.org> References: <00b201d2254a$a83f8b30$f8bea190$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b201d2254a$a83f8b30$f8bea190$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: 'IETF IDR WG' , cl@tix.at Subject: Re: [Idr] WG Adoption of draft-loibl-bacher-idr-flowspec-clarification-00.txt (10/13/2016-10/27/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 14:17:23 -0000 On Thu, Oct 13, 2016 at 08:09:32AM -0400, Susan Hares wrote: > This begins a 2 week WG adoption call for > draft-loibl-bacher-idr-flowspec-clarification-00.txt from 10/13/2016 to > 10/27/2016. I support adoption. It's all good stuff, although much of it could simply be filed as errata. Comment to the authors: Your IANA actions do involve changes to the semantics of existing communities in terms of documentation in IANA registries. You need to list those here. Please pay attention Eric Rosen's registry reorg RFC. -- Jeff From nobody Thu Oct 13 07:26:40 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955BC12990D for ; Thu, 13 Oct 2016 07:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LARfASIvokxu for ; Thu, 13 Oct 2016 07:26:37 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711FD1298EB for ; Thu, 13 Oct 2016 07:26:37 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id q7so46570141qtq.1 for ; Thu, 13 Oct 2016 07:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=K5KGRDsN5AaS1zK0NK7ouBF2xZ00QG7ZyJJVQUzaX/k=; b=DCxRiFcYxpL8UNPdX2cDTb24skC3Dh3s496V2KXcL9uC4XVFGGkQL7VSpby0+vXtzm c3vgHJ+90SIsEYbq0GGr6zvjvxsu8As3NPYHnhJQb9pwHz1BQzdi/ox0eqBUc5u8eu+4 tu1j7qgjMvsF9wrWTnGsm+wlu6paN0QsxNlCQ5PBs4YPPS/N1r6tFFnYPlUpQ5gv6Fr2 9Sk9k+zaTVyps3I1XlE7EQ1PwSRWBBvngdKGOG41uCuT2AbmS9gF89Q1UieCioabKkx6 3oqm89A2wxWMQ5J8wU/yk0DluqLnI5Ccm/TXyMYfDPba+Ff20rHy21v1n2AmA/bxzL7K m8wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=K5KGRDsN5AaS1zK0NK7ouBF2xZ00QG7ZyJJVQUzaX/k=; b=hhT6i6dVn/lOmOz8omKAF6kAmCKVxUFvSq+DmaEJQSi+Qj+FUqwOJVHQUWovw669Im 2oJfPtlkMqg6z2UkRtC1tecgeiabxD1Jt3ZTNw/4os2TkPkn8d+CvqBGsXN5Mzsx6gu8 NxlgrcfODv8Qf/PRy/2uai7DzxDKNsI2t5zb0DPGNB1JZjzFbz/3vOw/7ZUQQPt9hZ3Y yI4iW5qZRU6CH+bxT3Xw6HcKtJNsGDQyiiSBiG2aeKJYBs7mJSE7ubzgELsPpR9F9PqP kafaAfHZ1tbNPQdM8b5x9IHSChIib2o/qGcErDpWELp0R2vb9InexWSp5cY/vh8rKCXc AJCQ== X-Gm-Message-State: AA6/9RnM902WEg6w29A76ktbDZCSXaqsk8FSuPRqobcfpt3aZNPuYlzb5hxvkZPB9P5zzY5nBa2NaBcmysgDfw== X-Received: by 10.28.21.198 with SMTP id 189mr2360271wmv.15.1476368796101; Thu, 13 Oct 2016 07:26:36 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Thu, 13 Oct 2016 07:26:35 -0700 (PDT) In-Reply-To: <00b201d2254a$a83f8b30$f8bea190$@ndzh.com> References: <00b201d2254a$a83f8b30$f8bea190$@ndzh.com> From: Robert Raszuk Date: Thu, 13 Oct 2016 16:26:35 +0200 X-Google-Sender-Auth: oK4HIPMGJcpi9LS6QeutJsxIAww Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a1145b436a632c9053ebfe513 Archived-At: Cc: IETF IDR WG , cl@tix.at Subject: Re: [Idr] WG Adoption of draft-loibl-bacher-idr-flowspec-clarification-00.txt (10/13/2016-10/27/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 14:26:39 -0000 --001a1145b436a632c9053ebfe513 Content-Type: text/plain; charset=UTF-8 I support the adoption. As discussed already with authors there are few subtle choices (for example regarding enforcing re-validation) to be made, but more to WG to decide once this becomes a WG doc. Thx, R. On Thu, Oct 13, 2016 at 2:09 PM, Susan Hares wrote: > This begins a 2 week WG adoption call for draft-loibl-bacher-idr-flowspec-clarification-00.txt > from 10/13/2016 to 10/27/2016. > > > > This draft provides a list of clarifications needed for RFC5575 discovered > at a large interoperability test. Please consider if this draft will help > us in the creation of RFC5575bis. > > > > Sue Hares and John Scudder > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a1145b436a632c9053ebfe513 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the adoption.=C2=A0

As discussed already with autho= rs there are few subtle choices (for example regarding enforcing re-validat= ion) to be made, but more to WG to decide once this becomes a WG doc.=C2=A0=

Thx,
R.

On Thu, Oct 13, 2016 at 2:09 PM, Susan Hares <shares@ndzh.com><= /span> wrote:
<= p class=3D"MsoNormal">This begins a 2 week WG adoption call for draft-loibl= -bacher-idr-flowspec-clarification-00.txt from 10/13/2016 to 10/27/201= 6. =C2=A0

=C2=A0

<= p class=3D"MsoNormal">This draft provides a list of clarifications needed f= or RFC5575 discovered at a large interoperability test.=C2=A0 =C2=A0Please = consider if this draft will help us in the creation of RFC5575bis. =C2=A0= =C2=A0

=C2=A0

Sue Hares and John Scudder


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--001a1145b436a632c9053ebfe513-- From nobody Thu Oct 13 16:07:34 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E42129551 for ; Thu, 13 Oct 2016 16:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dt7CaopsauXP for ; Thu, 13 Oct 2016 16:07:30 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4E812946C for ; Thu, 13 Oct 2016 16:07:30 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id n189so120325096qke.0 for ; Thu, 13 Oct 2016 16:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AnJGIAgm4aAkW8LPwG2b2a6s5D9pnnJqhPuZhhG7UxY=; b=dzWbEjOScQbNJ3Z1wklkl+1k3xZLsh1kuDCkRht/Vj/zdnqkvggwRo/OXkgbzXCyT+ BjpcQEEO3sPqBpqyX0fo4yE0XVqZPYhqZLUF3jfECt2bqzVrAMVJez2+a8dYNwfE3BHH KeNXIXz4Z2+RUY4pBUrsjFT2sbrLpdVHo3dbiNdAt2H+NLHkjGK7MC0puBR0gEgkDUrK Rfo/CvMTzkCMv/tXz5622CMlwKHkcIjcwHeL5tsCFWyc17299jWIcXG7/8x/Ay68QCVH fM3tWeq9wCVhCNfup3uaJ4Ne2q+IsrtJ3izz57q2l6X7aDYqXg/ruIdoWMtfEWbz3hKC QJWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AnJGIAgm4aAkW8LPwG2b2a6s5D9pnnJqhPuZhhG7UxY=; b=gXaoFE9ExTtrzpI29ExpHtB2HArRO2/MyXmbLZRgYqIyqq+rae+p4KzhJ78n2YSvja j1UkoJmEqwHU8yyRBl2HcE33or3w8dpdG1jkJuto8Y2RjyLNKO1gSfpYdGe+bpl9hp4u t8Hw9RH4mmLroZsyyZox2GF6JyBEtXdN+aJbuAmQeovQAY3/CPPIA0kH73vjUMhJMKtn GHltp2AL//eHAgwOJN0W/L34SMgGG+b3yovbo8DQaRjM1OOqRu2LTLREjfKM0LFZIkCw ngK8xXnv9t8uq54PWNmsjWsibnaHSMlfEsr0dDh15OSn56QEkHbxnvmn25F0Fsd4OqC5 dfVA== X-Gm-Message-State: AA6/9Rlx44SsHFXDy5qD48jVYgAIgbz9FWEcWCOOfdnu5TS/nVvD65h3i4fKxirrAHWX8fpSQEs4WATehAJT5w== X-Received: by 10.194.93.234 with SMTP id cx10mr81252wjb.140.1476400049244; Thu, 13 Oct 2016 16:07:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.207 with HTTP; Thu, 13 Oct 2016 16:07:27 -0700 (PDT) In-Reply-To: <1476317462333.82977@dacor.de> References: <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <20161011095417.GL19434@gir.theapt.org> <1476317462333.82977@dacor.de> From: Brian Dickson Date: Thu, 13 Oct 2016 16:07:27 -0700 Message-ID: To: Julian Seifert Content-Type: multipart/alternative; boundary=047d7beb93407b526e053ec72cc2 Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 23:07:33 -0000 --047d7beb93407b526e053ec72cc2 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 12, 2016 at 5:10 PM, Julian Seifert wrote: > Hi, > > On 2016 Oct 11 phessler wrote: > > Putting my own ASN, or the ASN of my peer that I wish to control, will > > be the main uses; I agree. But there is a difference between SHOULD and > > MUST. Since I MUST allow users to change the value there, I am happy. > > Close, but not quite. The "MUST" for changing the values, IMHO, is something we all agree on, myself included, and is directed at implementers. The distinction is *to whom* the "MUST (be an ASN)" is directed at: operators. The "why" of the (global administrator) MUST is as follows: - The Large community that the operator sets, may not involve the operator's own ASN, nor any of the operator's peers' ASNs. -- This is desired, allowable behavior, acknowledged by operators, and in parity with RFC-1997 - Thus, the implementation CANNOT have enough local information to enforce the "ASN-ness" of the 32-bit value -- This is also as desired, acknowledged by operators, and in parity with RFC-1997 - HOWEVER, it is not acceptable for the operator to use some other 32-bit value in place of an ASN -- By definition, any other 32-bit number will collide with the values of 32-bit ASNs (they are integers between 0 and 2^32-1) -- There are plenty of private-use ASN values (between 4,000,000,000 and 2^32-2) for anyone who wants to do things "between consenting adults" Private use ASNs are not guaranteed to be unique, so anyone using them need to protect against collision. Non-private-use ASNs are guaranteed to be unique, and adopting "MUST" gives operators exactly what they need to influence those who behave badly, e.g. out of ignorance. Enforcement of this ASN-ness is something that needs to be exclusively handled in meat-space. I don't think anyone (from an operator background) has any issues with anything outside of "large" (in idr) doing smarter/better things. Please let us have large, with this "MUST", without interfering in this consensus, particularly from the operator community. > > The semantics of the value configured in the community is up to the > operator and must not be > enforced/assumed by the implementation. It makes sense to reserve certain > values/prohibit their > use to prevent compatibility issues, keep special values for > tests/documentation/checking and for well known communities > that might be defined later on, but don't force operators to only be > allowed to configure iana assigned > ASN values or force implementations to only allow configuration of an ASN > in the GA that is a configured ASN on > the specific router etc. > > Communities are great because of the ambiguity(sorry of not the correct > term for what I want to express) > The vast number of values I can configure with meaning only for me and > parties I interact with) > being too strict will greatly diminish the value they represent as a tool > in operating networks. > And would be contradictory to the operational need from which the draft > arose. > > Agreed (modulo "SHOULD vs MUST" language). Maybe putting a prefacing statement to clarify the Global Administrator definition, so that the restriction is guidance for operators, not implementors, would get us to consensus? Brian --047d7beb93407b526e053ec72cc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 12, 2016 at 5:10 PM, Julian Seifert <<= a href=3D"mailto:js@dacor.de" target=3D"_blank">js@dacor.de> = wrote:
Hi,

On 2016 Oct 11 phessler wrote:
> Putting my own ASN, or the ASN of my peer that I wish to control, will=
> be the main uses; I agree.=C2=A0 But there is a difference between SHO= ULD and
> MUST.=C2=A0 Since I MUST allow users to change the value there, I am h= appy.


Close, but not quite.

The "MUST" for changing the values, IMHO, is some= thing we all agree on, myself included, and is directed at implementers.

The distinction is *to whom* the "MUST (be = an ASN)" is directed at: operators.


The "why" of the (global administrator) MUST is as follows:=
- The Large community that the operator sets, may not involve th= e operator's own ASN, nor any of the operator's peers' ASNs.
-- This is desired, allowable behavior, acknowledged by operators, = and in parity with RFC-1997
- Thus, the implementation CANNOT hav= e enough local information to enforce the "ASN-ness" of the 32-bi= t value
-- This is also as desired, acknowledged by operators, an= d in parity with RFC-1997
- HOWEVER, it is not acceptable for the= operator to use some other 32-bit value in place of an ASN
-- By= definition, any other 32-bit number will collide with the values of 32-bit= ASNs (they are integers between 0 and 2^32-1)
-- There are plent= y of private-use ASN values (between 4,000,000,000 and 2^32-2) for anyone w= ho wants to do things "between consenting adults"

<= /div>
Private use ASNs are not guaranteed to be unique, so anyone using= them need to protect against collision.

Non-p= rivate-use ASNs are guaranteed to be unique, and adopting "MUST" = gives operators exactly what they need to influence those who behave badly,= e.g. out of ignorance.

Enforcement of this ASN-ne= ss is something that needs to be exclusively =C2=A0handled in meat-space.

I don't think anyone (from an operator backgrou= nd) has any issues with anything outside of "large" (in idr) doin= g smarter/better things.

Please let us have large,= with this "MUST", without interfering in this consensus, particu= larly from the operator community.

The semantics of the value configured in the community is up to the = operator and must not be
enforced/assumed by the implementation. It makes sense to reserve certain v= alues/prohibit their
use to prevent compatibility issues, keep special values for tests/document= ation/checking and for well known communities
that might be defined later on, but don't force operators to only be al= lowed to configure iana assigned
ASN values or force implementations to only allow configuration of=C2=A0 an= ASN in the GA that is a configured ASN on
the specific router etc.

Communities are great because of the ambiguity(sorry of not the correct ter= m for what I want to=C2=A0 express)
The vast number of values I can configure with meaning only for me and part= ies I interact with)
being too strict will greatly diminish the value they represent as a tool i= n operating networks.
And would be contradictory to the operational need from which the draft aro= se.


Agreed (modulo "SHOULD vs = MUST" language).

Maybe putting a prefacing st= atement to clarify the Global Administrator definition, so that the restric= tion is guidance for operators, not implementors, would get us to consensus= ?

Brian=C2=A0

--047d7beb93407b526e053ec72cc2-- From nobody Thu Oct 13 16:15:56 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C979812956A for ; Thu, 13 Oct 2016 16:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HQgAk6czFmS5 for ; Thu, 13 Oct 2016 16:15:52 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65124129471 for ; Thu, 13 Oct 2016 16:15:52 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id b75so160402927lfg.3 for ; Thu, 13 Oct 2016 16:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ii09ni5J9eIF/vLbuIrYXUtLyGxAcGeecbTP597hzrI=; b=hHT5mjEyghKYOUGJhCIo7kyiD8B6xvcETjFxPoOTAXcaB/puG3QTfZ5SDSo7RaeF8A mMSLBHxRUmoi0gZZRl+1y0/ZglzRCqptQGlqIogcVFWyqWlvmXvAFZoXDPiFo7dyqNk6 atS/I4GLzPDVqB20FSieDV7bbbm8jyl0oNrPeCkYwBUb7ehdLq1iMZc086b0zOQDmxfe OnpcL7VOzrnVC3kLTMnkcEIknWcx/5DaSW1POQNNBk9Dw2pSgPl7yp9ZqMr1mnTNt0D0 Ku7lK7fw2yEA+XPLEeMeyXYnlOhHdfcCXnrvur59fH9xce8AWIEtno1oI8Sr331qtQjh IKEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ii09ni5J9eIF/vLbuIrYXUtLyGxAcGeecbTP597hzrI=; b=Mf/utboDa0zzQnMxbK/zAD9xpP5bubb1mnYd1ZJka+SzqV06wO/0neYEqdWPtbrEiv XO6EeL8aVh1bzIcKZMNzXr2VCWLLbqGAwiG9Xu8ViKSaR3kRzn5Oa1LCa+XK/mlEIcTf E6V6v+fwzQcT7UfjIp+trZbKrtpN2A6hos/Ex6iZTMTxQqMSzVjfgG8cUWCrh+tAI6fr Uwm8fxoMSuTxP7VpTlWCnwQXf0xNWTGwLydRWBdYZ6r+RMpKxkGJDpBTYKfGRgdf04Am r/KEQWUH0gibWYHkzgINaove6cc/3FcihRl7+ztkdMNzi+MVCcm+pyvn6xFPYLwGCQjc Opyg== X-Gm-Message-State: AA6/9RmyvuFy0ilt8BGsliY11LC/Fs1wrtuDDItBwwiqY0cpSkgcpAUvVd21AyMS8hdcBr3JdVqKFeMwTQs9rw== X-Received: by 10.194.93.234 with SMTP id cx10mr95899wjb.140.1476400550618; Thu, 13 Oct 2016 16:15:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.207 with HTTP; Thu, 13 Oct 2016 16:15:49 -0700 (PDT) In-Reply-To: <20161013141343.GH22695@pfrc.org> References: <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> <20161011221544.GG12806@shrubbery.net> <20161012134552.GE22695@pfrc.org> <20161012215623.GH45879@shrubbery.net> <20161013141343.GH22695@pfrc.org> From: Brian Dickson Date: Thu, 13 Oct 2016 16:15:49 -0700 Message-ID: To: Jeffrey Haas Content-Type: multipart/alternative; boundary=047d7beb93405daf1f053ec74a9c Archived-At: Cc: heasley , idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 23:15:55 -0000 --047d7beb93405daf1f053ec74a9c Content-Type: text/plain; charset=UTF-8 On Thu, Oct 13, 2016 at 7:13 AM, Jeffrey Haas wrote: > On Wed, Oct 12, 2016 at 09:56:23PM +0000, heasley wrote: > > Wed, Oct 12, 2016 at 09:45:52AM -0400, Jeffrey Haas: > > > Arguably this was one of the motivations for doing scoping of > attributes or > > > communities themselves: If the effective operational behavior is almost > > > always going to be AS-non-transitive, it'd be nice if the cleanup just > > > happens automagically. Unfortunately people are rather enamored with > their > > > existing cleanup mechanisms. > > > > Please, no automatic clean-up. A community may be 100% legitimately used > > to affect a decision 2 or 3 AS-hops away and it is extremely useful. > > Operators already know how to alter communities. > > Experience has shown that a lot of people are simply bad about cleaning up > their trash. (And also how it was found that some particular bit of code > had a hash table poorly sized...) > I think we actually need a straw-man here, upon which to hang the argument (pro vs con on clean-up). IMHO, any ASN that falls outside of the ranges that are "Reserved" or "Private Use", should be excluded from clean-up. The flip side to that is having "MUST" to give operators the ability to protect their ASN-space from accidental or deliberate collisions. However, I am willing to concede that Private ASN values should only be propagated one AS-hop (where an entire Federation is one AS-hop). Is it the case that the implementors in this discussion were specifically thinking of applying the "intelligent clean-up" to ONLY the Private ASN ranges? (A simple Yes or No would be extremely helpful for bringing this discussion to a close, IMNSHO.) > But whether "doing better" comes via protocol changes, or getting better > common practices embedded in running (policy) code is a longer > conversation. > I think articulating the specific values of "better" would help move the conversation in a productive direction. I am as much to blame here as anyone :-). Brian --047d7beb93405daf1f053ec74a9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 13, 2016 at 7:13 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
On Wed, Oct 12, 2016 at 09:56:23PM +0000, heasley wrote:
> Wed, Oct 12, 2016 at 09:45:52AM -0400, Jeffrey Haas:
> > Arguably this was one of the motivations for doing scoping of att= ributes or
> > communities themselves: If the effective operational behavior is = almost
> > always going to be AS-non-transitive, it'd be nice if the cle= anup just
> > happens automagically.=C2=A0 Unfortunately people are rather enam= ored with their
> > existing cleanup mechanisms.
>
> Please, no automatic clean-up.=C2=A0 A community may be 100% legitimat= ely used
> to affect a decision 2 or 3 AS-hops away and it is extremely useful. > Operators already know how to alter communities.

Experience has shown that a lot of people are simply bad about = cleaning up
their trash.=C2=A0 (And also how it was found that some particular bit of c= ode
had a hash table poorly sized...)

I thi= nk we actually need a straw-man here, upon which to hang the argument (pro = vs con on clean-up).

IMHO, any ASN that falls outs= ide of the ranges that are "Reserved" or "Private Use",= should be excluded from clean-up.

The flip side t= o that is having "MUST" to give operators the ability to protect = their ASN-space from accidental or deliberate collisions.

However, I am willing to concede that Private ASN values should onl= y be propagated one AS-hop (where an entire Federation is one AS-hop).

Is it the case that the implementors in this discussio= n were specifically thinking of applying the "intelligent clean-up&quo= t; to ONLY the Private ASN ranges?

(A simple Yes o= r No would be extremely helpful for bringing this discussion to a close, IM= NSHO.)

=C2=A0
But whether "doing better" comes via protocol changes, or getting= better
common practices embedded in running (policy) code is a longer conversation= .

I think articulating the specific val= ues of "better" would help move the conversation in a productive = direction. I am as much to blame here as anyone :-).

Brian=C2=A0
--047d7beb93405daf1f053ec74a9c-- From nobody Thu Oct 13 16:22:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5FE129471 for ; Thu, 13 Oct 2016 16:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 gSXE4eb93boQ for ; Thu, 13 Oct 2016 16:22:02 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D7C124281 for ; Thu, 13 Oct 2016 16:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2485; q=dns/txt; s=iport; t=1476400922; x=1477610522; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e+mKcHf7ExFBV/7o9lHdvieo01mvyft86toogQHn14E=; b=Dz+dReOznl/F4nGEfUJbETxNNf7Fb3eK5xXXnvrzFPplBFAvdBA/7zHX /tAsJ/ErE80ThPCKptqvhQGtuquJbGwVnXoUqgA85LoyqbVHhl93HAQBC EcMOZIfRzGYXF2uNx0hK9+56AmVua5bLSEsTuHN3FJzTxD+6i+9yVlV5N 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQBAFgBY/4YNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzwBAQEBAR2BUweNLZcFlDSCCIYiAoIMOBQBAgEBAQEBAQFeJ4RhAQE?= =?us-ascii?q?BBDoyCgMMBAIBCBUBIAkHMhQRAgQBDQUIDIg+w2EBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEdhj2EVYomBZoCAY91gXWEZ4kgjHmDfgEeNlCEZHKHBIEAAQEB?= X-IronPort-AV: E=Sophos;i="5.31,490,1473120000"; d="scan'208";a="333638410" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Oct 2016 23:22:01 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u9DNM1MJ005092 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Oct 2016 23:22:01 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 13 Oct 2016 18:22:00 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 13 Oct 2016 18:22:00 -0500 From: "Jakob Heitz (jheitz)" To: "t.petch" , Julian Seifert , Peter Hessler Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt Thread-Index: AQHSG79TGAvzbRTYaUOLNdatGR0q+6CTny8AgALbUg+AAFuDAP//w9BUgABdGYCAAD/ogIAFnPnpgABp4oCAAKSCAIABPgaAgAA9LACAAJUrsoABNP8AgAHlkWKAAFoQgIACgayAgAA/PvOAAOqp8A== Date: Thu, 13 Oct 2016 23:22:00 +0000 Message-ID: <370dd06bff7c425db78dc82c5bce8907@XCH-ALN-014.cisco.com> References: <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net>, <20161011095417.GL19434@gir.theapt.org> <1476317462333.82977@dacor.de> <00fb01d2252f$700c2360$4001a8c0@gateway.2wire.net> In-Reply-To: <00fb01d2252f$700c2360$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.162.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 23:22:04 -0000 Tom I understand your issue and I believe every major router vendor does too. What to do about it? The router cannot check if the first word is a valid ASN or if the ASN is the intended one. Even if the ASN is correct, The rest of the community could still be junk. A router vendor can provide tools to make it easier for operators to be safe with communities, large or regular. For example, there is a knob 'send-community' that must be configured before a router will send communities on an ebgp session. Therefore, an operator who is unaware of the problem will not spray junk. Another tool is the 'peeras' keyword that allows you to match the peer's ASN in any field of the community. This makes it easier to write generic filters in RPL. Excuse me if I'm tooting my own horn, but I do not believe that this funcionality is unique to Cisco. You can match private ASN and your own ASN too. If anyone can suggest more tools, please do. Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch > Sent: Thursday, October 13, 2016 1:55 AM > Julian >=20 > I believe I understand the need that you express but the BGP protocol > does not have the mechanics to express it! >=20 > You say > 'configure with meaning only for me and parties I interact with' > but BGP has no such mechanism. As Jeff has already explained, an > optional attribute either gets dropped, which is unlikely to work with > route reflectors, or it gets passed on and this I-D chooses the option > that it gets passed on. So a community that only you and your fellow > parties understand is let loose on the whole Internet where it is open > to misinterpretation by everyone else because, e.g., they are expecting > an ASN and are getting something else that is private to you. >=20 > And the remit of the IETF is to make the Internet as a whole work better > so in updating the specification of BGP, the IETF has to consider the > trade off of something that benefits you and the parties you interact > with versus the risk of causing some level of damage to the Internet. >=20 > Obviously, I hope, I am concerned about the damage; you gain, but > somewhere else across the globe, someone else's connectivity may fail. >=20 > Of course it is possible to define a more sophisticated system that > allows communities to go so far and no further but that is not the BGP > we have. >=20 > Tom Petch From nobody Fri Oct 14 09:34:41 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A819112984F for ; Fri, 14 Oct 2016 09:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 FYrOuEqufgBi for ; Fri, 14 Oct 2016 09:34:37 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id D6E05129516 for ; Fri, 14 Oct 2016 09:34:36 -0700 (PDT) Received: from www.lamehost.it (unknown [80.76.80.23]) (Authenticated sender: marco@lamehost.it) by seele.lamehost.it (Postfix) with ESMTPSA id BFF36746D0 for ; Fri, 14 Oct 2016 18:34:30 +0200 (CEST) Mime-Version: 1.0 Date: Fri, 14 Oct 2016 16:34:30 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <0d36bd4a0b98a813dfa632673560bed7@www.lamehost.it> X-Mailer: RainLoop/1.10.3.151 From: marco@lamehost.it To: Idr@ietf.org In-Reply-To: <147553212286.29652.17602398820945558642.idtracker@ietfa.amsl.com> References: <147553212286.29652.17602398820945558642.idtracker@ietfa.amsl.com> X-Originating-IP: 176.57.126.2 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Fri, 14 Oct 2016 18:34:30 +0200 (CEST) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Fri, 14 Oct 2016 18:34:30 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.99.2 at seele X-Virus-Status: Clean Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-legacy-rtc-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 16:34:40 -0000 October 4, 2016 12:02 AM, internet-drafts@ietf.org wrote:=0A> A New Inter= net-Draft is available from the on-line Internet-Drafts directories.=0A> = This draft is a work item of the Inter-Domain Routing of the IETF.=0A> = =0A> Title : Automatic Route Target Filtering for legacy PEs =0A> Authors= : Pradosh Mohapatra=0A> Arjun Sreekantiah=0A> Keyur Patel=0A> Burjiz Pit= hawala=0A> Alton Lo=0A> Filename : draft-ietf-idr-legacy-rtc-07.txt=0A> P= ages : 10=0A> Date : 2016-10-03=0A> =0A> Abstract:=0A> This document desc= ribes a simple procedure that allows "legacy" BGP=0A> speakers to exchang= e route target membership information in BGP=0A> without using mechanisms= specified in [RFC4684]. The intention of=0A> the proposed technique is t= o help in partial deployment scenarios and=0A> is not meant to replace [R= FC4684].=0A> =0A> The IETF datatracker status page for this draft is:=0A>= https://datatracker.ietf.org/doc/draft-ietf-idr-legacy-rtc=0A> =0A> Ther= e's also a htmlized version available at:=0A> https://tools.ietf.org/html= /draft-ietf-idr-legacy-rtc-07=0A> =0A> A diff from the previous version i= s available at:=0A> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-le= gacy-rtc-07=0A> =0A> Please note that it may take a couple of minutes fro= m the time of submission=0A> until the htmlized version and diff are avai= lable at tools.ietf.org.=0A> =0A> Internet-Drafts are also available by a= nonymous FTP at:=0A> ftp://ftp.ietf.org/internet-drafts/=0A> =0A> _______= ________________________________________=0A> Idr mailing list=0A> Idr@iet= f.org=0A> https://www.ietf.org/mailman/listinfo/idr=0A=0A=0ADear Authors,= =0A=0AAt bullet 3.2.1 your draft says:=0A=0A The RR MAY also translate t= he received extended communities from=0A legacy clients into route targe= t membership NLRIs as if it had=0A received those NLRIs from the client = itself. =0A=0AI'd suggest to turn that MAY to MUST as it would help to ke= ep consistent behavior in the AS with the BGP speakers that support RFC46= 84.=0A=0A=0ALast i wonder why we need different communities.=0AWouldn't b= e simpler to reuse the same AFI/SAFI of the prefix?=0A=0AThank you From nobody Sat Oct 15 04:52:02 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6BD129651 for ; Sat, 15 Oct 2016 04:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 3fs2mPe5AFbi for ; Sat, 15 Oct 2016 04:51:58 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0114.outbound.protection.outlook.com [104.47.1.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8C6126FDC for ; Sat, 15 Oct 2016 04:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2YYC8itiXBu+pd/ZMy+vDpwW2WjmdL1Ej/NpAYfWpTM=; b=ju/YOdgITluwfDauM0mA/zutimSGAD1smbE6t8ewRI3Ear5q62eeYu7Mrce1w/PTUULkXzEPN2gyo6EbpTMQ0r31ltf8LUrJf4aSIK8z/G+m4LmNXwbTpFyG+hNEHw94+YFhRAl31KR0ML6UpfvzATDXTaeiL+ys+upNDdIm3lI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Sat, 15 Oct 2016 11:51:55 +0000 Message-ID: <015001d226da$32df80c0$4001a8c0@gateway.2wire.net> From: t.petch To: "Jakob Heitz (jheitz)" , Julian Seifert , Peter Hessler References: <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net>, <20161011095417.GL19434@gir.theapt.org> <1476317462333.82977@dacor.de> <00fb01d2252f$700c2360$4001a8c0@gateway.2wire.net> <370dd06bff7c425db78dc82c5bce8907@XCH-ALN-014.cisco.com> Date: Sat, 15 Oct 2016 12:49:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: AM4PR0101CA0033.eurprd01.prod.exchangelabs.com (10.167.254.43) To HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) X-MS-Office365-Filtering-Correlation-Id: bbebfc1b-e126-45f4-1979-08d3f4f1a962 X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 2:f/NfcPiJU/Jaizw038DuTBKVCbBHPwox5jGDTf1p0yxUyq64k7PsosoLcgx9cnQZSo/uq+rKWISBBOxPZEcD4Gxi1JUqXV2n4Rt8ShXzrnUGGZ6Og8cXbpbw3umMbmpYT9LRsAK5rsXPbZJ+hAlANOfgmpfQ3TmFd28HcA3JcqUn5/h7KMCdJu3xgqk2aZ2vX001Z/j43dMFUnk6JRYZyw==; 3:y4gy0wgef2WOK6po6wL6SaoUF3Ubah7FnLRHgzhZWGZZsw6uk6g18zaiC6WNvH9r4Vnq2qYIPYZgSMPBXrAJTusQ0ZvIIQFbnhwE/nue+tMLlSd6/XDhVmnH1ZHummgn98nJXuthjQPxSACkck4QBw==; 25:nX7nvQgOvgJ12xU6jhUfMCZtPCQmCXLx40yyRbAl9R+hdcXPggNDtXpc8O/mqxjeWcVUgfzMe+Ffj4WsEsLHV38/UXIjNJFfeMzvSmLyYPfNON6Z4Tq/pXYr1jCn1CDIvIRoRXe/jShC5QtZYbHT7II0LvDiPNLxvhDITm4Jz+dRonkCkTG0OsI7Ln8YkgBEw8cMngakZR7w+lM2KraZTqdxroZfBUk1Imi9GZ4zmM7GVuePdAfw4ksVKJi/6E902vumWpOkaBkH4HYEebgvke9jFU6O3VSIDKwTHj6hMIrO1E1nJvZYbpitz7Cc0Yv7/7MkRFgi5ModbvP9Zh34Z+Q5BIrS9ZVVAq0Txh6ctod3ugHy10HB2Lr1c7FdiMSjU6K+tw/1zqHybRyatEDYzbSgs5oNTGU8rdSug/8OLAuczjHdlS8ZkgjS55gkU/1X X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 31:/ha2IBiza7yOJyo0TekLpwoHVsQY1o/cUcIFyU70dkCjVxx+q8HtAbcTgbXVTUZ6/r9X/PEZLbyq9MXunYZg+cT6jToXHf/SGkFB01Vl0PSg2SPNotpVgvi8bMnX/xi9IDowZ5PBhatopuSen+NuiJJVFh2sDcqYthYzBMyowIBCWhf8h0tmZ426J60hgAc6b2FQn+uHCA62lKS90y6DD6aeoK0H5M2RRFgS6A2c7D0ZS338sfzSzDfZlQUaojBE; 4:70Ciom44nLird/R4+jEvh+6cjYyfDuzj5kjjXVLMI6EPxy/KsRpmwLJZQYbjXHBuhnNPcBzeomAoxTLMbKz+D4eRqZa9YvVSZ58z+kG7Ok5SIWA+YwpXGyTPTjtyVTcRxKMeW06yRqwP3IQLkCWatSBaifZ5K2c7X/QqODVn9VeCp2j/SfWFl+ZIlrX1uqT0s5zeM/4JveKGC8kqpHwxPs8gPuH/L0ZBn3zvqZFChbOt/UbhN3o2PGcHnrqziO5QF+GM0b6qKWPcXzt+VGgNNyXJ95Ff+/k6vr0/4a+lZ5bhVsrYQikWq2kez6ZXPBFQ72ecO2pVOR01j4OpCIRctCECNTZPWTdqd9LqJWizUK3m28zM+PvLVnRoFURG70mnjiQRPPoWHqoWGRrI5LrtAshlGw1PfkdBMO0PSIH6UuOfY1Kc9aO0yrpl/ueqmVCdPTeAgqKe48jlf0e78ESGccwh7UIS0dIv+nYutbc7peDH4jS29ac/IqGf+Cj0nXF/C5rINw+hbARnht/VKeU6QA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(35073007944872)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3002; X-Forefront-PRVS: 00963989E5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(51444003)(199003)(377454003)(189002)(13464003)(116806002)(101416001)(93886004)(44736004)(44716002)(62236002)(230700001)(50466002)(6116002)(3846002)(586003)(77096005)(1456003)(86362001)(2906002)(84392002)(6666003)(19580395003)(4720700003)(50226002)(9686002)(68736007)(66066001)(14496001)(47776003)(92566002)(4326007)(19580405001)(61296003)(5001770100001)(5660300001)(23756003)(106356001)(42186005)(76176999)(81166006)(81156014)(8676002)(230783001)(1556002)(81816999)(50986999)(81686999)(7736002)(97736004)(7846002)(189998001)(33646002)(305945005)(105586002)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3002; 23:SBFRskPC1Mqv16v4RFF1NzwTbd605tP3y79YJ?= =?iso-8859-1?Q?cPZTgxHs0TM+gsVweIG2QEU6F76U3yLNjQ+UbQJLFg4HQzb+iPWX/ODXXP?= =?iso-8859-1?Q?dyonEgobXPQBkSj1p2ZPLBpfOLG70mSZZU1oeI1hVQcm9H0STMQt9KzqRW?= =?iso-8859-1?Q?3RhwE3tLKghN9jmvQF2/F9uotrMOe/6EDjZnyvdd2zk3I/6iYwns5NH8Br?= =?iso-8859-1?Q?KzJixxHVpkehiAvEuW/fGfFsr+UHKKuL+H5aunLbc66zjGwsctYnN8l7vQ?= =?iso-8859-1?Q?fGmGprfxV11laTF2dlqwqd7vCUdOQhBa++BRgRNu7HGaGdR56Ltwbi8s2f?= =?iso-8859-1?Q?brymds6GN5n5F5VIFfBUrr5pmn9vO/5q+1lrOpFj21b8sYkm/eLpC1VTGP?= =?iso-8859-1?Q?SyioVZeWt0B5YZCiT03yEpTV8NbCAcGNTOukSoNEEOFVyMBc/9Ss8DF79l?= =?iso-8859-1?Q?gJW8gelLTxqzFx9Vq8fv3a9Uj5/tzqSjhAu33MR9rjO6eWnCGpynYY7x2u?= =?iso-8859-1?Q?fRXuWur5Sbrli7dDSOcPyrN+EzYcqSPdSgzuNMwk5o2HwLjXToyIbg7TxA?= =?iso-8859-1?Q?CeJSorAGPjPo4FewEcRhNuMwZnsULJKZK0pLrbo8ekAnUn/QqVSKPlZjjh?= =?iso-8859-1?Q?z1esmwNnCvATKETjprqp5dnnrb3Gd91875ktZ5MJVqu4S6hxJPF2CaC0to?= =?iso-8859-1?Q?W6F8ARu7lMtN2NovLg/vt9Dzz7rOjobuYH4YzVFROzARFyCAFhy8fIhWn3?= =?iso-8859-1?Q?da58mstwNy3HQ39L4zQeUbqnl7CjHywUK2LfBw7UHxL42HOGiDynb7MSgf?= =?iso-8859-1?Q?PUEq3xFce2+tsHPcAjleGA/hijZTNzoMcOkep3I3RbtK5Lu7ylcaGdwocq?= =?iso-8859-1?Q?vgVunwC7+MkOu6EXbfZx5Y1XEbzvSCaupBwjSTUykfVFfJ/mbVIe6thDB2?= =?iso-8859-1?Q?1nLgCGuXUuds9Sbc8LWEN9iiTKpMY/vVHLa+gpBLgegE60J02jkb7skTV/?= =?iso-8859-1?Q?y1gY9Wopab2A5NXoYMCn2o6acsBbbL1ixAF9HLxOxR6v2hecGNhKhz2Vur?= =?iso-8859-1?Q?PS0tLmwo6RUJAhaJktgmtdO7rMDpV0j6Q6APGKdwe/eWXL0wcf4Qi/52qu?= =?iso-8859-1?Q?BsrbYO/mMMoUwmwIJsQtixI20B7alrvUxBoxwn/tnkP2mQ9OOkW1OTeR4V?= =?iso-8859-1?Q?S+axnNzMmbJHxt/SQEq3WgLIaQN59ujv+8fTonPiQP0GgRz+zaCNAn2taS?= =?iso-8859-1?Q?CfsQXCdqjIesBy506f0kuh22nnAHRVT76D5vuq/Qki9+m61NCCO0gEQ8V1?= =?iso-8859-1?Q?XVYN5+BC8X+DcoA8ADYi12paotHLjSXXeEYh60YFtADq2VAoPrOKgASb/r?= =?iso-8859-1?Q?JXjWum+7nH5h/k80aNgbFGKoOEKHEOwSl7RTrdOeX4sAZLxO3VC4BvP/W/?= =?iso-8859-1?Q?RRmdmajQ/UljuolfgiaIyIKzlphOF85QNRCyw46qkVv+yqGkO0g++I3vP+?= =?iso-8859-1?Q?tWGvyFIY0DHfmxSmuXsBTmJPBVKFmWsK1eLL+X6AT30?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:7D99OpTrWjdKbrfSW3Kw+DFXvUpl82Dp4wkT6Jxux1oA23J0JYlf7brl75ZTkqjo0uVPmBEwviYW9g+DFhz4i9FDfpH2Oqu8s6+T9Bmv1+J/TODYtKLwtWKQyrN9IyGpfZ1NuWaIG3D8UcQ1pi72SZmCw7Y8PTkgbaRv/kwtPxHTnp+rpL5SCrbOib6CudsrzrDBEzsqO18L5TspjEOmNYkogOhnQJ2UlCZsL5KG/q+L1jBAOIrfCixEsWDaPNlaVm5Bx/HeiwG/79jnp46tsMrkk9h3H40QMMBNLt+uW2ELObn1dR/wMrRTu9ibrZEM; 5:wv6fT3+AuhzAQ1ABrTxMZ0FJzhc7Mr9p21BpKHjDYDPPdpjkhjas0QwZAQG++aPkUimPIDyU8Y3FniMJBMJmJl/k/YSLOvaWcbl3uMEf+9v+xFAwkYRsaq8rZN/xvO7YnEy16k1rzvd1+5/cWigua6/qe2M+ITH/k+Jb/O7AzaM=; 24:fiMjZxXYW06wKRafjUbPPRLgEG25V01/SVkS6MB+6/d1PbGb3wdhTKHNAQgu7T/qbyfeXmfK+2q78+amiucMgI+KZAqxjid+Vi5uCsThzCg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 7:Y6k7/fWHJ86YVDgyDVdIl8Hd01Tb4doHP0aLIxSxogsUh0KWumI+vn6DmkGPAUeYvfuXPfUH/Je/vqiMQ8KKMX02/UUwkfJAsba6agMxstruAf3cIFQ18M3O4/fC34nzo8gJyqys5+qg6a7Ruc6hvNMoo0hjBAQS1TgCfw2Tkc7Wp05kL1sQZjIpFR7DM0Ak00nPkYwILekoiHNaIl2WLi7sQsTphNpHTmask65ASuWHZpJiQg6SrODhkS3kOzb4yQ+zOntYATKmbMifA5g55uM2VxczFVZ/NtJyS7ZC9MlHVj2WBR2XfRSI0XSBXMmuVUktSusx02lO3dSoCSqi53GiOW8WbiTvPpcArGdFCFk= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2016 11:51:55.0291 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 11:52:01 -0000 ----- Original Message ----- From: "Jakob Heitz (jheitz)" Sent: Friday, October 14, 2016 12:22 AM Tom I understand your issue and I believe every major router vendor does too. What to do about it? The router cannot check if the first word is a valid ASN or if the ASN is the intended one. Even if the ASN is correct, The rest of the community could still be junk. A router vendor can provide tools to make it easier for operators to be safe with communities, large or regular. For example, there is a knob 'send-community' that must be configured before a router will send communities on an ebgp session. Therefore, an operator who is unaware of the problem will not spray junk. Another tool is the 'peeras' keyword that allows you to match the peer's ASN in any field of the community. This makes it easier to write generic filters in RPL. Excuse me if I'm tooting my own horn, but I do not believe that this funcionality is unique to Cisco. You can match private ASN and your own ASN too. If anyone can suggest more tools, please do. Jakob I think that Brian well expressed the issue in a post 15 minutes before yours. My concern starts with the protocol rather than the implementation, seeing getting the protocol right as the first step, even if it does not seem possible at present for a router to enforce the protocol rigidly. I see BGP as a whole as somewhat weak on security, on authentication and data integrity, and these things only getting fixed after a disaster or two. So I am content to specify a protocol which implementations may or may not catch up with at a later date. I agree the vendors can make it easier for an operator to get right and that they should do so, and this in turn can influence the decision as to whose products to use but do not want to see that as feeding back into decisions as to what the protocol should be. Tom Petch Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch > Sent: Thursday, October 13, 2016 1:55 AM > Julian > > I believe I understand the need that you express but the BGP protocol > does not have the mechanics to express it! > > You say > 'configure with meaning only for me and parties I interact with' > but BGP has no such mechanism. As Jeff has already explained, an > optional attribute either gets dropped, which is unlikely to work with > route reflectors, or it gets passed on and this I-D chooses the option > that it gets passed on. So a community that only you and your fellow > parties understand is let loose on the whole Internet where it is open > to misinterpretation by everyone else because, e.g., they are expecting > an ASN and are getting something else that is private to you. > > And the remit of the IETF is to make the Internet as a whole work better > so in updating the specification of BGP, the IETF has to consider the > trade off of something that benefits you and the parties you interact > with versus the risk of causing some level of damage to the Internet. > > Obviously, I hope, I am concerned about the damage; you gain, but > somewhere else across the globe, someone else's connectivity may fail. > > Of course it is possible to define a more sophisticated system that > allows communities to go so far and no further but that is not the BGP > we have. > > Tom Petch From nobody Sat Oct 15 05:46:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2F312963B for ; Sat, 15 Oct 2016 05:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 rGO5N1dyOStC for ; Sat, 15 Oct 2016 05:46:07 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 9F3B81295EB for ; Sat, 15 Oct 2016 05:46:07 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bvOLi-000DW9-LU (job@us.ntt.net); Sat, 15 Oct 2016 12:46:03 +0000 Date: Sat, 15 Oct 2016 14:45:56 +0200 From: Job Snijders To: "t.petch" Message-ID: <20161015124556.GW57491@Vurt.local> References: <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <20161011095417.GL19434@gir.theapt.org> <1476317462333.82977@dacor.de> <00fb01d2252f$700c2360$4001a8c0@gateway.2wire.net> <370dd06bff7c425db78dc82c5bce8907@XCH-ALN-014.cisco.com> <015001d226da$32df80c0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015001d226da$32df80c0$4001a8c0@gateway.2wire.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 12:46:08 -0000 Hi, On Sat, Oct 15, 2016 at 12:49:28PM +0100, t.petch wrote: > I think that Brian well expressed the issue in a post 15 minutes > before yours. No. That posting is proposing new radical ideas about propagation behaviourisms that are not part of this specification. A specific design requirement for -large-, stated by member of the working group is the simple transitive nature of the attribute. Given the very different nature of what you and Brian propose, I suspect it might warrant its own draft. > My concern starts with the protocol rather than the implementation, > seeing getting the protocol right as the first step, even if it does > not seem possible at present for a router to enforce the protocol > rigidly. I see BGP as a whole as somewhat weak on security, on > authentication and data integrity, and these things only getting fixed > after a disaster or two. So I am content to specify a protocol which > implementations may or may not catch up with at a later date. I am not content with a protocol for which there are zero implementations. Without implementations, there is no standardisation in IDR. Based on my experience with RFC 1997 - I feel that you may be misrepresenting the risk surface. Kind regards, Job From nobody Sun Oct 16 09:18:21 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CA4129463; Sun, 16 Oct 2016 09:18:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147663469659.25909.1216457085467777630.idtracker@ietfa.amsl.com> Date: Sun, 16 Oct 2016 09:18:16 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-large-community-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 16:18:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Large BGP Communities Authors : Jakob Heitz Job Snijders Keyur Patel Ignas Bagdonas Adam Simpson Nick Hilliard Filename : draft-ietf-idr-large-community-03.txt Pages : 8 Date : 2016-10-16 Abstract: This document describes the Large BGP Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use in four-octet ASNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-large-community-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 16 09:25:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03308129447 for ; Sun, 16 Oct 2016 09:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 HclBxA3DTcDT for ; Sun, 16 Oct 2016 09:25:21 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 E940F129437 for ; Sun, 16 Oct 2016 09:25:21 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bvoFU-0004WP-4Q (job@us.ntt.net); Sun, 16 Oct 2016 16:25:21 +0000 Date: Sun, 16 Oct 2016 12:25:09 -0400 From: Job Snijders To: idr@ietf.org Message-ID: <20161016162509.GL57491@Vurt.local> References: <147663469659.25909.1216457085467777630.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147663469659.25909.1216457085467777630.idtracker@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 16:25:23 -0000 Dear working group, draft-ietf-idr-large-community-03.txt is available for your consideration. Thanky you all for your contributions. ChangeLog: o Make "Representation" section more concise. (Remco van Mook, Job) o Add pmacct to "Implementation status" section. o Consistency: change {2,4}-octet to {two,four}-octet. (Heas, Nick) o Remove some unnecessary words. (Heas) o Remove ATOMIC_AGGREGATE from Aggregation section. (Jeff, Jakob) o Make it clear Extended Communities are unsuitable. (Nick, Job) o Improve use of 'Community' and 'Communities' terms (Nick) o Update authorship list (Job) Kind regards, Job On Sun, Oct 16, 2016 at 09:18:16AM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing of the IETF. > > Title : Large BGP Communities > Authors : Jakob Heitz > Job Snijders > Keyur Patel > Ignas Bagdonas > Adam Simpson > Nick Hilliard > Filename : draft-ietf-idr-large-community-03.txt > Pages : 8 > Date : 2016-10-16 > > Abstract: > This document describes the Large BGP Communities attribute, an > extension to BGP-4. This attribute provides a mechanism to signal > opaque information within separate namespaces to aid in routing > management. The attribute is suitable for use in four-octet ASNs. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-large-community-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sun Oct 16 13:19:31 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFBF129439 for ; Sun, 16 Oct 2016 13:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xr98RIQgJB6A for ; Sun, 16 Oct 2016 13:19:28 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78CA1293EB for ; Sun, 16 Oct 2016 13:19:28 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id ry6so58292813pac.3 for ; Sun, 16 Oct 2016 13:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v2PY3kCCvrIrOB2DasXI8FCgHudIb/K/Z3+hWH66rtY=; b=j2jv9C5dAQA/WDmskJXPnA0U49n52vcrpw7YPi88Oe96Ld48U9yVuuj6vNmAJtj5IQ gQR1+5XcXzK67LcbVnXewDucn3B1UN4bq88JJVgVXamAZ7jzpep3WpyI0F/OwpsMnIHv EYxH8a3ps85XA51Rz9WydW31iggeEg9aw8BRGUt9wPUgd6o/EyYiZWqq2abnpILTc0EB XAUdRxFWwIls7S/kSJ1qSej30Drk6zfp/NPqmX9Z0VMdjV8cBbgW53y3jOej3UrKY11i sb7oB3NM3GDh5ijg4Ibg6i12fY6hU7Z6mZpDgRCqlqMKCdzn7I+2ycNnHNY06QWDrCHx KC6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v2PY3kCCvrIrOB2DasXI8FCgHudIb/K/Z3+hWH66rtY=; b=GECGhi7eezsLunp53vLoKELJaR+MI5Dz4IdbNIg01zSR6Erx36Fc6S2Hew9c6BjdgX e9ZFGy0dJW0nLdIP+IdDxp6TOhGlKpsxV0DDyTwmYl/LsQ5aB5scB6KxpF5Ifz67Qcar 5QDkVqsvkm/leCurVaIE3Fx+67zKcJrhrT62nGAjuSjio8PIUdu9SJ/GTs+9K/WbjU0M X6i0Ppn5/6KYGUaDDKYArKUwQSRiGdsnR3lbixZnq3acLqzWajQITqiRMsxG8LuDUx6u pkugVHEHIVZTsPCaB8VNVhMSfLu5SIhXHS7IMtoUl6Xn9faAlBnxtVp2vlsc0ejHaWwu LPkA== X-Gm-Message-State: AA6/9RmEfESLgFnzpx30IEl9bFdaHVvgI4Kbv2chmwcTxSAlFibAP+MOXjNOukUoOtW7wA== X-Received: by 10.66.142.169 with SMTP id rx9mr27615754pab.122.1476649168317; Sun, 16 Oct 2016 13:19:28 -0700 (PDT) Received: from [10.210.113.133] ([166.177.248.26]) by smtp.gmail.com with ESMTPSA id xv9sm42480083pab.36.2016.10.16.13.19.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 16 Oct 2016 13:19:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (14A456) In-Reply-To: <20161015124556.GW57491@Vurt.local> Date: Sun, 16 Oct 2016 13:19:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8D4A7FDB-FBAC-4914-AE32-7D46EDC564C7@gmail.com> References: <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <20161011095417.GL19434@gir.theapt.org> <1476317462333.82977@dacor.de> <00fb01d2252f$700c2360$4001a8c0@gateway.2wire.net> <370dd06bff7c425db78dc82c5bce8907@XCH-ALN-014.cisco.com> <015001d226da$32df80c0$4001a8c0@gateway.2wire.net> <20161015124556.GW57491@Vurt.local> To: Job Snijders Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 20:19:30 -0000 Sent from my iPhone > On Oct 15, 2016, at 5:45 AM, Job Snijders wrote: >=20 > Hi, >=20 >> On Sat, Oct 15, 2016 at 12:49:28PM +0100, t.petch wrote: >> I think that Brian well expressed the issue in a post 15 minutes >> before yours. >=20 > No. That posting is proposing new radical ideas about propagation > behaviourisms that are not part of this specification. Actually, I was not proposing anything in particular. I'm not sure who it wa= s that suggested "automatic clean-up", but I'm pretty sure it was one of the= co-authors. What I was saying, was if any change (over the current propagation mechanics= ) was to be implemented, it would be best to discuss the specific methods, h= ere and now. I am opposed to any changes to behavior as part of the protocol. I do think all implementations need to provide operators the knobs to change= , add, or remove large communities. I will let Tom speak for himself but I expect he will concur. > A specific > design requirement for -large-, stated by member of the working group is > the simple transitive nature of the attribute. Given the very different > nature of what you and Brian propose, I suspect it might warrant its own > draft. >=20 >> My concern starts with the protocol rather than the implementation, >> seeing getting the protocol right as the first step, even if it does >> not seem possible at present for a router to enforce the protocol >> rigidly. I see BGP as a whole as somewhat weak on security, on >> authentication and data integrity, and these things only getting fixed >> after a disaster or two. So I am content to specify a protocol which >> implementations may or may not catch up with at a later date. >=20 > I am not content with a protocol for which there are zero > implementations. Without implementations, there is no standardisation in > IDR. >=20 Okay, this appears to be the perennial, gigantic disconnect. This is the IETF, not IVTF (vendor). The engineers specify, based on rough consensus. Vendors collaborating witho= ut the general agreement of the WG is not consensus, regardless of implement= ations. The many years leading to "large" are a symptom, as was "extended" which pre= ceded it. I think we all agree on the meat of "large", except possibly the "must" vs "= should" for ASNs. For that, I think WG consensus should be polled.. Brian > Based on my experience with RFC 1997 - I feel that you may be > misrepresenting the risk surface.=20 >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sun Oct 16 14:10:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C912C1294F8 for ; Sun, 16 Oct 2016 14:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 J88Ywl6Y16i9 for ; Sun, 16 Oct 2016 14:10:55 -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 D141E129467 for ; Sun, 16 Oct 2016 14:10:54 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u9GLApLq017005 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Oct 2016 22:10:52 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be cupcake.local Message-ID: <5803ECD9.3060405@foobar.org> Date: Sun, 16 Oct 2016 22:10:49 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.4 (Macintosh/20161007) MIME-Version: 1.0 To: Brian Dickson References: <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <20161011095417.GL19434@gir.theapt.org> <1476317462333.82977@dacor.de> <00fb01d2252f$700c2360$4001a8c0@gateway.2wire.net> <370dd06bff7c425db78dc82c5bce8907@XCH-ALN-014.cisco.com> <015001d226da$32df80c0$4001a8c0@gateway.2wire.net> <20161015124556.GW57491@Vurt.local> <8D4A7FDB-FBAC-4914-AE32-7D46EDC564C7@gmail.com> In-Reply-To: <8D4A7FDB-FBAC-4914-AE32-7D46EDC564C7@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 21:10:57 -0000 Brian Dickson wrote: > > My concern starts with the protocol rather than the implementation, > > seeing getting the protocol right as the first step, even if it does > > not seem possible at present for a router to enforce the protocol > > rigidly. Brian, this is indeed one part of the problem: the lack of a protocol for handling your suggestion. If you have suggestions for a new protocol which will allow a router to determine whether the global administrator field is an ASN, along with an adequate definition of what you intend the term "ASN" to mean in this context, then please post a separate draft and the WG can chew it over. Until there is a protocol in place to make this viable, demanding MUST instead of SHOULD is creating a requirement for standards-track mandatory compliance with a poorly-defined specification which, as you note, cannot be enforced. This is not wise, and it has no place in a standards-track document. Nick From nobody Mon Oct 17 13:29:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E35712998B for ; Mon, 17 Oct 2016 13:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=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 i5jaz-CzUz46 for ; Mon, 17 Oct 2016 13:29:12 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6521295A5 for ; Mon, 17 Oct 2016 13:29:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.187.221.190; From: "Susan Hares" To: "'IETF IDR WG'" Date: Mon, 17 Oct 2016 16:27:31 -0400 Message-ID: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F4_01D22893.5C226FF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdIotF10Qx6LizvwQ9uItB9ryESdDg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 20:29:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01F4_01D22893.5C226FF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt. (10/17 to 10/31). Please comment if draft-ietf-idr-large-community-03.txt is ready for publication. If you have concerns with the text, please be very specific about what is wrong and what needs to change. If you have concerns about operational aspects, please give a complete description of the problem and why this draft does not solve it. This WG LC is not a place to debate whether we should have adopted this technology. The focus of WG LC is whether this technology has implementations (see IDR wiki for examples), and whether these implementation inter-operate. It is also important to consider deployment issue or problems on currently. Sue Hares and John Scudder ------=_NextPart_000_01F4_01D22893.5C226FF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt.  = (10/17 to 10/31).   Please comment if = draft-ietf-idr-large-community-03.txt  is ready for = publication.  

 

If you have = concerns with the text,  please be very specific about what is = wrong and what needs to change.  If you have concerns about = operational aspects, please give a complete description of the problem = and why this draft does not solve it.

 

This WG LC = is not a place to debate whether we should have adopted this = technology. 

 

The focus of = WG LC is whether this technology has implementations (see IDR wiki for = examples),  and whether these implementation inter-operate.  = It is also important to consider deployment issue or problems on = currently. 

 

Sue Hares = and John Scudder

------=_NextPart_000_01F4_01D22893.5C226FF0-- From nobody Mon Oct 17 13:59:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D9B1299A8 for ; Mon, 17 Oct 2016 13:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 c0YaMQ5_MGb2 for ; Mon, 17 Oct 2016 13:59:55 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F2C12957C for ; Mon, 17 Oct 2016 13:59:55 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id CE75578920 for ; Mon, 17 Oct 2016 22:59:53 +0200 (CEST) Date: Mon, 17 Oct 2016 22:59:52 +0200 From: Peter Hessler To: idr@ietf.org Message-ID: <20161017205952.GC19434@gir.theapt.org> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 20:59:57 -0000 On 2016 Oct 17 (Mon) at 16:27:31 -0400 (-0400), Susan Hares wrote: :This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt. (10/17 :to 10/31). Please comment if draft-ietf-idr-large-community-03.txt is :ready for publication. : : : :If you have concerns with the text, please be very specific about what is :wrong and what needs to change. If you have concerns about operational :aspects, please give a complete description of the problem and why this :draft does not solve it. : : : :This WG LC is not a place to debate whether we should have adopted this :technology. : : : :The focus of WG LC is whether this technology has implementations (see IDR :wiki for examples), and whether these implementation inter-operate. It is :also important to consider deployment issue or problems on currently. : : : :Sue Hares and John Scudder : In my opinion, draft-ietf-idr-large-community-03 is ready for publication. Additionally, I have tested inter-operation of OpenBGPD with exabgp and bird. I am also advertising a prefix with large-communities attached to it on the DFZ, 2a02:1698:179::/48. (Disclosure: I wrote the wire-protocol part of the OpenBGPD implementation, and committed it to the OpenBSD tree) -- All I ask is a chance to prove that money can't make me happy. From nobody Mon Oct 17 14:38:46 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E90C1294A1 for ; Mon, 17 Oct 2016 14:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2LjiV7ZVuO6j for ; Mon, 17 Oct 2016 14:38:43 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F65129471 for ; Mon, 17 Oct 2016 14:38:43 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id o68so306351977qkf.3 for ; Mon, 17 Oct 2016 14:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bFWfIaB7RSfJJkxEqVQV2HWh3uMxxyyqmpyxR2nxq90=; b=v6dd4qlZh3oZKCobo+C2XcuT+itH/N91tyXMz/IuU4WdvqUAmpq2KF8mdK6q8//Huf AqXs0Oy9a6gBK0dMZs66pv6yNfSjcNHEYdSmW1INlrhvNKP335RqIOOETWiUN/s/fsPE gKQtkogwLqChN7D3FgIJ8a7h4doPm+OTzivIOZZG1AGpCp1tmVvxp9+zJ8F/qNl7sfqh HInvF6kX0DCAA//1ue+m+szK+9ZHiZ4XjSJjExI3B6nVsTAXdN6tk7o4zA6HuW3vmdWv xWOd0HCNrGLEwL95LEr3XWLrvX8MddhIW95lHb3e04/OVCTL7177ReQ+LDaBQ9Vnpc9I WWNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bFWfIaB7RSfJJkxEqVQV2HWh3uMxxyyqmpyxR2nxq90=; b=b41k4wGWjw4/FVrZww/APin4YVyHqGn5bZ9jHQblX8iqoM9Yg/kg0bq3Pm/XlX6+KT zcyrNfLPNTMOKAO0FZXGnunwPlSHOmVNf25Oqn+o4aCXNLLYvrGCGuNf2qmjojg/qsV8 lwc+JCbhcWer5UligVir9XPF5seX/DV5o5yjDGZNYqbnmYVIVyli6mKiNXgTbED/hpG5 1H7GKX4ovHqc5z06WxJ2paccOX/3ZWoEd7GPBhkDnZybJkc1fhLhUchAnxtHRfWrKZa4 awsIeQr46zh7jiWrrzr00FJ85lcZB6r3qI4o+oZjuABxnWXaC6HON25aLGQiYR368DUh EtWQ== X-Gm-Message-State: AA6/9Rlrsk3gW3eocXjQOppl63VUm5k10NebXHAUdjZC7mhOZb1l0WwKMXZMrVo66T6lLYcUHfgGA09dDkiRFQ== X-Received: by 10.55.77.201 with SMTP id a192mr30460703qkb.198.1476740322800; Mon, 17 Oct 2016 14:38:42 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.105.244 with HTTP; Mon, 17 Oct 2016 14:38:42 -0700 (PDT) In-Reply-To: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> From: Christopher Morrow Date: Mon, 17 Oct 2016 17:38:42 -0400 X-Google-Sender-Auth: VeidKenR_ME_GCkwDOL_HhfCbGo Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a114885965dbb74053f166667 Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 21:38:45 -0000 --001a114885965dbb74053f166667 Content-Type: text/plain; charset=UTF-8 This draft looks good to me. please publish. On Mon, Oct 17, 2016 at 4:27 PM, Susan Hares wrote: > This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt. > (10/17 to 10/31). Please comment if draft-ietf-idr-large-community-03.txt > is ready for publication. > > > > If you have concerns with the text, please be very specific about what is > wrong and what needs to change. If you have concerns about operational > aspects, please give a complete description of the problem and why this > draft does not solve it. > > > > This WG LC is not a place to debate whether we should have adopted this > technology. > > > > The focus of WG LC is whether this technology has implementations (see IDR > wiki for examples), and whether these implementation inter-operate. It is > also important to consider deployment issue or problems on currently. > > > > Sue Hares and John Scudder > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a114885965dbb74053f166667 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This draft looks good to me. please publish.

On Mon, Oct 17, 2016 at 4= :27 PM, Susan Hares <shares@ndzh.com> wrote:

This begi= ns a 2 week WG LC on draft-ietf-idr-large-community-03.txt.=C2=A0 (10/= 17 to 10/31).=C2=A0=C2=A0 Please comment if draft-ietf-idr-large-commu= nity-03.txt=C2=A0 is ready for publication.=C2=A0=C2=A0

<= p class=3D"MsoNormal">=C2=A0

If you= have concerns with the text, =C2=A0please be very specific about what is w= rong and what needs to change.=C2=A0 If you have concerns about operational= aspects, please give a complete description of the problem and why this dr= aft does not solve it.

=C2= =A0

This WG LC is not a place to debate wh= ether we should have adopted this technology.=C2=A0

=C2=A0

The focus = of WG LC is whether this technology has implementations (see IDR wiki for e= xamples),=C2=A0 and whether these implementation inter-operate.=C2=A0 It is= also important to consider deployment issue or problems on currently.=C2= =A0

=C2=A0

Sue Hares and John Scudder

<= br>_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--001a114885965dbb74053f166667-- From nobody Mon Oct 17 14:49:32 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62D412943F for ; Mon, 17 Oct 2016 14:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UE24Darwpe5x for ; Mon, 17 Oct 2016 14:49:27 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D8070129439 for ; Mon, 17 Oct 2016 14:49:27 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E9C311E32B; Mon, 17 Oct 2016 17:51:34 -0400 (EDT) Date: Mon, 17 Oct 2016 17:51:34 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20161017215134.GA464@pfrc.org> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: 'IETF IDR WG' Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 21:49:31 -0000 On Mon, Oct 17, 2016 at 04:27:31PM -0400, Susan Hares wrote: > This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt. (10/17 > to 10/31). Please comment if draft-ietf-idr-large-community-03.txt is > ready for publication. As of version -03, I think the document is clear and largely ready to ship. My one remaining concern is the reserved communities in section 5. Given the remaining text in the document saying "you MUST let people put whatever they want in here", the reservation seems superfluous. I'd suggest outright removing the reservations. Failing that, they need to be better justified. -- Jeff From nobody Mon Oct 17 15:03:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD8E129535 for ; Mon, 17 Oct 2016 15:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 laupT-CVlJiw for ; Mon, 17 Oct 2016 15:03:33 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 D0E7112943F for ; Mon, 17 Oct 2016 15:03:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 776153A; Tue, 18 Oct 2016 00:03:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1476741807; bh=e9EdzyBYhCOhmkAO5dtxYD3Oq7NC o/ExbJOxWD4AhiQ=; b=b6po8XUEAFOVED3y88TxoJasFNOeCBou2DQKW2g5cXaS 3MJLmkGk+ucVPoNJSMnqjcmHsie+VFbEjhuhIwEWKEQFgsR3O10oM0cfCEra0t+o ya9iFyjR+11p0uTyqiO48ymUbH70Jia3EQk3F30nc3LdJuwzS9l/G0M2n/xPbcM= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mr4Y_Sm9MKd2; Tue, 18 Oct 2016 00:03:27 +0200 (CEST) Received: from [IPv6:2a02:a213:a300:9300:5d56:1f4d:74e2:2510] (unknown [IPv6:2a02:a213:a300:9300:5d56:1f4d:74e2:2510]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 8E6D138; Tue, 18 Oct 2016 00:03:27 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_AF0BA535-95DC-4C29-BDD5-C2BF62E2F5E8"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <5803ECD9.3060405@foobar.org> Date: Tue, 18 Oct 2016 00:03:25 +0200 Message-Id: <9E34B3BC-74A8-4EAA-877E-86BDCB31476D@steffann.nl> References: <57F92043.20301@foobar.org> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <20161011095417.GL19434@gir.theapt.org> <1476317462333.82977@dacor.de> <00fb01d2252f$700c2360$4001a8c0@gateway.2wire.net> <370dd06bff7c425db78dc82c5bce8907@XCH-ALN-014.cisco.com> <015001d226da$32df80c0$4001a8c0@gateway.2wire.net> <20161015124556.GW57491@Vurt.local> <8D4A7FDB-FBAC-4914-AE32-7D46EDC564C7@gmail.com> <5803ECD9.3060405@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3124) Archived-At: Cc: idr Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 22:03:34 -0000 --Apple-Mail=_AF0BA535-95DC-4C29-BDD5-C2BF62E2F5E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > Until there is a protocol in place to make this viable, demanding MUST > instead of SHOULD is creating a requirement for standards-track > mandatory compliance with a poorly-defined specification which, as you > note, cannot be enforced. This is not wise, and it has no place in a > standards-track document. I agree. The definition of SHOULD is strict enough as it is: SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. The "full implications must be understood and carefully weighed" is = strong enough for this situation. Cheers, Sander --Apple-Mail=_AF0BA535-95DC-4C29-BDD5-C2BF62E2F5E8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYBUqtAAoJEKAtA7D+JBO5IAAH/jIBlytjSYgpngs8dQO1I7SW nzHOKWAjs/xEdUdJMOcocPCDguLzpcMH454UYrJudv6ksSirvY8rsrVO/G8jvMY0 jAIQzI/lIP/2eIsx8ZpQANv4ODz9mfkpMFvetKk4nMLEMXffb5t3rFEKnGVKWFI/ MjSlwEVQLNeqjFu8g6k3RqeWIRPI1W5nrao9qquBBf360CvnJ0ik0Q0nP0WnVQjN CoIGg2Wh5O5Dbuf1DrxNbXM020NfCTrzQdQwvDuYePlYLY9yqVBNkgavHn/UpM8o Oanh4XJcr6G6qGqeaqrQNYTJmndm6SO2q5sAmYZbziLXUsBhyC1tObhvye3D3jc= =v1Ff -----END PGP SIGNATURE----- --Apple-Mail=_AF0BA535-95DC-4C29-BDD5-C2BF62E2F5E8-- From nobody Tue Oct 18 04:01:38 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAAE1295E0 for ; Tue, 18 Oct 2016 04:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bskyb.onmicrosoft.com 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 S-twCNkxi4TA for ; Tue, 18 Oct 2016 04:01:33 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0069.outbound.protection.outlook.com [104.47.0.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360CD12940A for ; Tue, 18 Oct 2016 04:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BSkyB.onmicrosoft.com; s=selector1-sky-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LfTn1YSRgOt/OWQMfTjqO1UhVsBls/0VAt32vdIhxZo=; b=XV/mUBETo5VIi3U/hld+clR54x9p+ZYiDH/vX4mtyW91U7zoJyopLqXmfnwM4WKi/w8uKrnm1DwEY8cJ1NIWxZAxdTN9tcpKVZh+tkqgEgRxKb1yjQtE3OEiWbKgjKM6h2eAHmEjS2nuw15yQz3la0FgvJ4d1P96DUWjoAPE7F4= Authentication-Results: spf=pass (sender IP is 176.255.244.224) smtp.mailfrom=sky.uk; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=sky.uk; Received-SPF: Pass (protection.outlook.com: domain of sky.uk designates 176.255.244.224 as permitted sender) receiver=protection.outlook.com; client-ip=176.255.244.224; helo=email.bskyb.com; From: "Dickinson, Ian" To: Susan Hares , 'IETF IDR WG' Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) Thread-Index: AdIotF10Qx6LizvwQ9uItB9ryESdDgAeobAw Date: Tue, 18 Oct 2016 11:01:22 +0000 Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE6170E0CE@WPMBX010.bskyb.com> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> In-Reply-To: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [191.255.79.254] Content-Type: multipart/alternative; boundary="_000_9B3BFE0A18160E40BAF1950414D10FAE6170E0CEWPMBX010bskybco_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:176.255.244.224; IPV:CAL; SCL:-1; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(199003)(5423002)(189002)(5001770100001)(76176999)(54356999)(50986999)(86362001)(66066001)(69596002)(19625215002)(33656002)(5890100001)(2920100001)(16236675004)(230783001)(55846006)(7736002)(790700001)(6116002)(102836003)(7846002)(3846002)(8936002)(19580405001)(9686002)(26826002)(19300405004)(512954002)(586003)(189998001)(107886002)(19580395003)(74482002)(8676002)(92566002)(81166006)(106466001)(84326002)(81156014)(2906002)(87936001)(15975445007)(260700001)(5660300001)(2950100002)(11286001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB196; H:email.bskyb.com; FPR:; SPF:Pass; PTR:b0fff4e0.bb.sky.com; A:0; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11OLC002; 1:33if/ki82UQ6z4z0xifCxeqNOMRmCgdeTjNLpVii/kqfqUfv7nKvn2HltUc27OeNIG731zJjkuGOIdv84l/Dt0FR1q5v2bkOLEb0V5J6Eqka/ykmk7PKKyUEQ/kWGpmXn26xoaG/EAPkTI2cik1SWeM91TZ8t+vyQ5dsjBY1wvWDMqAFtO8Tmgo5Y3QKd2yuHuraesslfe6d0R/e4B6A8c3x9Tk1MrcKDH1Ncnq+LdP1mrcddnfUyfaXmOmQau817DZTFX+esi2NPmiaVBs0tA+MR8zKQHIm2opb0AnUnH1+rcErHzu/wKW33KQJle9iJpqY7AEen7dEP3eKeCCdiFdfUqmwYZDNVSh1pJ/H8sA4NudmNiEWk8kpsxxOqE2bqvQIDi97pBBfS/dkOu24RYPLnoRKDlGMGYg2Vci2eZys3mRAStm/Z1/Vf1+si4/O11OyT2GseARBGqbRX+K8aFig7SkE6icqlZikn52yIwmGXZAPgUnBU5TcBff4pfgO7Wm7/YY1trOvV7Hgf4Qq7673a7PiTwscjYb+QW6SuSyqjnsTpjEvDg8Yms/ZKG1p X-MS-Office365-Filtering-Correlation-Id: ec5e3c15-e3c6-4008-ecba-08d3f7461d6c X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB196; 2:JypsYzn5l3M2qM2qw0DOWV1qToqUMQjy3D0mfRpFuArXD8hHyIExsG/HS7ynx0XJqoRh9pXrKIi5XGxmRQFG0tWrJLCcGgnVL+a4rZ9iyAiiKwCX6gHIj8k08oLR0juaQor9wmfpUdVOZiJJYQ9aGZksTK9vOxznvIP98dGPH8yX0kEKUEBtnH+CHAZ+p/5rZJpMiShnvpPIfGgaSxqSSg==; 3:QQ1Ah0LuHZdPzD5+GLWpqRoUyA72z7hdNeh7/jEYXFpSfFUNiIz35i3yClXOIkAi4seTU/MLst7KSd9C4LXTaN3KCIRV6nmR46jjYUDK0Qv5ovODljRmDBwJ3nEDPfvhdXHbT+ICbPrKivTmNxroguFPjJ0vpoFcRPFIqKw2B2ECRD6NuGwUXa4G9fb6SXg756YQpnl5lq4G4E+VckByttaj0H29R4BCmKcmBIKYFtWVhAtFkVll8T+ismZnXCoD7AU0pPUowCnTimkbIfhsb4GqlcCV9neAx0wa862uVyY=; 25:XlBgEtzfOnrrp4OZMdIGOM8jSSfiEcRppjfxxerlfrtYKgAcslpwATIDXB1n+rGjxVb1cCtpAyfYHjRf4ysOEJVlHLU7iMIO4zOUfQFrILAuioSvattprX8lkvprISiea4V9I+dG1dIhc/z+FqI7Dae697V+SW1baOm4/Ry7MoRwnJ+bM+VNC5HNzSHb9S8oaiekMxe6wuqasXbipbeuqC0yvQf4k5kfFVKuvOny3ht0fDXpsowHLOTvhVrz4msoVayUYAdw5wVz9fe7Dp2iXntdM9y69bdHZIFr+AechYgfNruhhPE5vDx49jAzfZQJaSaURAi1JyUtPnjv685d8ha7/YVE8Jed84vkobOdBeVczAMLm8ypItvdq03zXb1QWXFSqXVnvtWCv5RsSzQJEhhyaEwSEUsqEJlizLyFk2SmnYsYSlTwzOdsqFqTtchj X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:AMSPR07MB196; X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB196; 31:RuhcqvWLV42VZn/6CqY6GnILKgBp8YKUW2R+zh05Z3z4TjM/zqkMUplmlqa/2R/7njsSgHFBq/H6noZWlZUsy+QLLQvO+t930MAFUyNJwG6kD/Y+y+Tm7dY1+7P78uUM31a3xcf846Ks0tuLa/CngPoZwo2w1wu9572GJ3mejUE9jiBvWD7RL5my3P/Sx07L1xe2kbGi++dKe4dlbv7k/OwV7xmB9t/35BJ0MtRKURuONfpG1Ow+4NEXg7bLsmCK; 20:FZKBS8GchAmN7YCeeDbqNs4sJvwCJ5x93g9HRC7xjm1e53mXFw44bfj6dp3CoeNCRU5Qbm+mow/146D6uX3c5005Jdi/ru3VbPHHAOVn1YZ0A15bwNxMUu2YQsYzWQaIg+pS2sfqDzaXrxhLh3839IhIMwwLB8LpIoa653gNZrGDsEXQiXztueW90S54eFSZHwAmmO1X4iq9rRLb7+5OU6zTpQTaMg2gCCItRXe0SV+f+IolDa9TSnc0kZPCvDueQolJIip6oXHr0exE17q7cZDEI8qOOiASm4xY/LpqIPE47YGNMqVV65dBIvvDYA5uFm3V6Z0b7miTxwZuJj/+9zu4pnKm+hRwkP0PeZmBc9gkhG0gGBgrAtLBYFrTAQggwETkBNoSu62wvLMX0VEKQtCcE8VV/PBmV1+bgyjoRkSzuR5ncB8/iwN9bhafa2qQ0UZNmxUl9jV3IOFeEVigTyg5nLD+qQxvdTwhWZ8uHLIoEb9rTK9K9YIdFE/5pxIm X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13012025)(13020025)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:AMSPR07MB196; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB196; X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB196; 4:RpqlbkUlfRV5dgsdLQyZkjokGABN82+GzO07gAWx2u5SEriiv/ROHAeUCL3VPdu4wm/WFte06F860MQUYvZ3kqnxE75b1EEq/hnx0jmzt7R7WxwEQs47RFLaJqpQEZk0UlfBoXotEsfx1ilnBVh5SxB42cBhFGTXZxb7vMo4MywQ/L8nXX1I5DittkAGjk+sJbAwG4ZBWYRAWdo/pEH6MuIyu6cYcaJPmuaVzLkzsPmvybTLLthEAnmQIbN9YVWvm7F3X1LD8PLBw4GWETBBoFvvQJR+k3Wecitc/IxXZS0e2LsfjG+arrqIE+/jv7W23RiaPN44bherHDA9/BIYkWT0pyhLBS2/C+KQ2hXbU5k//JO+EbrTY7n8qYN31/tr0d6DvPRmdZoOxkb53obXwztcFwlARydLbXPtWuP6fjEl7x9cJi1nBV/1C63kd6tWsfV9PYwyNHJkEoOL7YYRN+TikR1yQAj1AJdL0daAYb0HLisnJTjdy0zI0XMKAYIf X-Forefront-PRVS: 00997889E7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AMSPR07MB196; 23:awKMKcz1mmQ3UKcvPdg7QeOgMfXwI0IAKFzN5B84oy?= =?us-ascii?Q?buCjtlJzWawQyIM2nmQTaUkeIzSu/dPTVsO+WM5p/g8BGzznajPVFcI8/22q?= =?us-ascii?Q?5jWccqoDftXMy4VDC9vY2l6DkVIHfNrZSVj5iduBxvT+G1I5SF1ezlrf/dwM?= =?us-ascii?Q?tHLRrUpUTkffXp25GpLBvsm8eH1OzouQ6RK+q5BWq7assTmdCfC9G6Li/xn7?= =?us-ascii?Q?I3apwrxWvi55EBkwqkDo3WtN0gdF6i+gEj679nNkfC2Lm/PQax7l7ZCGupKo?= =?us-ascii?Q?MqlFPGz+kr+z4gXeGG+8JUFyYWDEjMJUkvVXV4rzpsoKEC6WAGqrkMg0OmH4?= =?us-ascii?Q?GpRkBWuCpLwk2kMs1WDDwiporMyGwIu+I0mR+ny1d4OmRsty7cDLueStMYDv?= =?us-ascii?Q?Ce/1yw/ERh7xrbbFw9Qys20vm4yTmvwhY/7rpbBLQGjLj1hMTOOZxprWIalZ?= =?us-ascii?Q?Ed1oGSz5HaSfQVIm3H9tBbEK7H4JVt//rzcCPbPJoXUoFyYLpEA8tXAVmJMf?= =?us-ascii?Q?Z7VPqkqy490fqs3qh9Xa/gZIX1sw6WoJr5L8ppFzfSeX6moScQc1BTYoKtXr?= =?us-ascii?Q?ZgET85Q/pvqmdzKP/rVPrTY430x+SS5BWzaviChh+m687t+CdquPVv8LMU9o?= =?us-ascii?Q?9re629naHhifDmXRMLMGkiDak12j/ktwmU1ooRxsbd/4b17FCIZdjnbV/0UF?= =?us-ascii?Q?qUukoI3rPyHKNOh3oiePAvOSzv5/iK0BAKkmzDcXTcq4aUtYAhk/Jm36PbQl?= =?us-ascii?Q?W4K1XEb0EXUl7O6Jf8A22esGV7R8Y4aUJ+0DQM2NlYXKUCzNsD2aAFS7AZvW?= =?us-ascii?Q?xxy8yBZJC+YdVOTFCziYJ1UYKy8+KaMZPq2EQuCATdtDOM3/jkrYNpHPG3af?= =?us-ascii?Q?C0PZNfaUe2oVRcJUjFRKJ/dwQB0SQgQOqZmqt6ExFcSeSPuXg9c8i3cRHOg7?= =?us-ascii?Q?B3eO5kTzpmb7JkhkhfSVhPqvlvSWEf4kk4z3KfOc8uvf+kBljOMitZo6Fk2f?= =?us-ascii?Q?XP+LhEaXPtdB8JPwebs5uWMjsiHjeMmvI1pQRRwqkPbWWcnhAN5cU4gz0v13?= =?us-ascii?Q?ufjIJKxEAGYHzQXysyyj2WTW7kxAZKbYGMD2ZiaI7gyx5tPV1JccYc3Bov1f?= =?us-ascii?Q?9VaECT0X4rNHro6ARl2lDn8GI+K+/AJbD4szIX+ONB0LHFBxrXzHXyg/VXCV?= =?us-ascii?Q?6MPxFB9WhrhichNTUIR12A0KnF4aAIak438l3H+wh4qUy0w7KezgaZ97JbgR?= =?us-ascii?Q?HuNt9jGp6uLKteT0fsne0a0lXZDVe3RX4PtDsy/L8OsZhUYMXJ2O06/s3fCQ?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB196; 6:7dGY6fECX7gIwYty5Wc1ebmOqRTqJClNXumHsO4tmEEhA8BXSkMTjdOS2Zahe0j9cZk9kgUPE83R7GbfyL2k7vHeLD0G70qPvjeQDLqUgJuGG6UyRMejzqBaxJxCxHRMDsHQdO69EduAfkXf6+grOGDXjJd7SrvjcyfiTy56MfXDb4/hsPuDZZJmpoz12n0YJ1zQY5aaCJ7pDAUrVM8DP8vDswhSUhEHEg3PSjr+ifFANSsE7vpMaaq3bzK8HEw9j2rKnfwRoRt++CjbPNQNi9a/olCba4VfsBsTxYmM+AHSRM685XUP+rxw6yRe+RJDZCWWv18rcYBVQFnJQibEXL4JrIFQk5tl3yNo66wojsU=; 5:5nAkYlmNpRKgjDHLx+0ONkbrmy1yD4asWw271vSjCIPrGNMEDjFI9SEIgIYWGfQfgjnXISjkkj3hMJL+4dxa2CpqlZBJNyoI1uWiDA09NqNp4Bz4/Yu5tQarC5WhymxuyS+XW9xszXKhCEeo1f25ezpZqYpDJe5NnRcRMGconCE=; 24:v56KXgffGEYNMF0zk2oybLYVyq5W4wBN5L29NqFuYR0SAYvcnCutGuqtWFiIM/mw+e5t6yOorLwAl9wgQp9TrsTWFZFjevzV7hQoYLFdpoY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB196; 7:+aEi1OsterhSNJzDThWdmJJBWZW5y490MIu16u5eaFTUhI06m9oGO7dVE66NAay4bppUvvAzkjh+CPObikhYxKsUoCjHwbZTwOP1AR0OfFvuzzSzqpUUzepvMdaUF9Utend8lGOZZSdtcmFvDYh9QDUIa1aSMRgb8X2Zjn7vGMTqqauLqpaLMPc+KVQSbONyuGX1X3gYuLeN5bEhOqGDy0VIEOmGdbmVzAmWr8DuiXDk61c4CCN+cBYpsZ7NMvHrPZIopwWLZNFf5era8vK91nWNAEmxOcEjGBmsimFbqAZ5TM1Bi6zY/4nb/qvuPHzjeYipUfi+DXIbQWWKpqleeQ/QDT70SKymb2RownyKnsE= X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2016 11:01:30.0481 (UTC) X-MS-Exchange-CrossTenant-Id: 4f86cebc-57e2-40a0-86cc-01d73be93ba0 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f86cebc-57e2-40a0-86cc-01d73be93ba0; Ip=[176.255.244.224]; Helo=[email.bskyb.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB196 Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 11:01:36 -0000 --_000_9B3BFE0A18160E40BAF1950414D10FAE6170E0CEWPMBX010bskybco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support publication of this draft. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: 17 October 2016 21:28 To: 'IETF IDR WG' Subject: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 t= o 10/31/2016) This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt. (10/1= 7 to 10/31). Please comment if draft-ietf-idr-large-community-03.txt is = ready for publication. If you have concerns with the text, please be very specific about what is = wrong and what needs to change. If you have concerns about operational asp= ects, please give a complete description of the problem and why this draft = does not solve it. This WG LC is not a place to debate whether we should have adopted this tec= hnology. The focus of WG LC is whether this technology has implementations (see IDR = wiki for examples), and whether these implementation inter-operate. It is= also important to consider deployment issue or problems on currently. Sue Hares and John Scudder Information in this email including any attachments may be privileged, conf= idential and is intended exclusively for the addressee. The views expressed= may not be official policy, but the personal views of the originator. If y= ou have received it in error, please notify the sender by return e-mail and= delete it from your system. You should not reproduce, distribute, store, r= etransmit, use or disclose its contents to anyone. Please note we reserve t= he right to monitor all e-mail communication through our internal and exter= nal networks. SKY and the SKY marks are trademarks of Sky plc and Sky Inter= national AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Reg= istration No. 2067075) and Sky Subscribers Services Limited (Registration N= o. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No= . 2247735). All of the companies mentioned in this paragraph are incorporat= ed in England and Wales and share the same registered office at Grant Way, = Isleworth, Middlesex TW7 5QD. --_000_9B3BFE0A18160E40BAF1950414D10FAE6170E0CEWPMBX010bskybco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support publication of this draft.

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: 17 October 2016 21:28
To: 'IETF IDR WG' <idr@ietf.org>
Subject: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17= /2016 to 10/31/2016)

 

This begins a 2 week WG LC on d= raft-ietf-idr-large-community-03.txt.  (10/17 to 10/31).   P= lease comment if draft-ietf-idr-large-community-03.txt  is ready for p= ublication.  

 

If you have concerns with the t= ext,  please be very specific about what is wrong and what needs to ch= ange.  If you have concerns about operational aspects, please give a c= omplete description of the problem and why this draft does not solve it.

 

This WG LC is not a place to de= bate whether we should have adopted this technology. 

 

The focus of WG LC is whether t= his technology has implementations (see IDR wiki for examples),  and w= hether these implementation inter-operate.  It is also important to co= nsider deployment issue or problems on currently. 

 

Sue Hares and John Scudder

Information in this email including any attachments may be privileged, conf= idential and is intended exclusively for the addressee. The views expressed= may not be official policy, but the personal views of the originator. If y= ou have received it in error, please notify the sender by return e-mail and delete it from your system. You sho= uld not reproduce, distribute, store, retransmit, use or disclose its conte= nts to anyone. Please note we reserve the right to monitor all e-mail commu= nication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky= International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Reg= istration No. 2067075) and Sky Subscribers Services Limited (Registration N= o. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No= . 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and shar= e the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. --_000_9B3BFE0A18160E40BAF1950414D10FAE6170E0CEWPMBX010bskybco_-- From nobody Tue Oct 18 04:27:41 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136831295B0 for ; Tue, 18 Oct 2016 04:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pEWbw3fr87IE for ; Tue, 18 Oct 2016 04:27:38 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC1B129566 for ; Tue, 18 Oct 2016 04:27:37 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b81so338698691lfe.1 for ; Tue, 18 Oct 2016 04:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=Uo89/yhcottiFHjvzqI7IrD1XaOHZy3/TM30K5Lep1g=; b=q3Jrr9smWnMw8z70Mx5uMtuefUwoQqH4l0XZfrKx7lKtrztfPIAq38BaL2NnnNGva8 HOksRDT+ki1jU31AZ9sdEiv1hpVMnn3yuZXq4zpG7BBokeDE/Rgcxsjf6ajkxAk12VBY UOJjolkjsM1FJkWQCpbaK9mkMaCQwWvnvZluaUECaJoLFYoVWqDihyLMPvbesZUNaqMS 2catitCTtWAZtmkKPP2T3bU7v7TSPIKgwFdBfFKdd5YEQGubc662HUmObZZA+qgCUd6N JmE1kCwHrUaAjLEtztdG4jU64GXEM9+P7ywY8TDUADvbsz2JCp9goNpfLWp1VM4ZwRLN s9sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=Uo89/yhcottiFHjvzqI7IrD1XaOHZy3/TM30K5Lep1g=; b=XJoTMQzdmcquILpWfWcQN/sv6Rl3J5u4/vsKONUkkBm0WMjrZuoyAu/D0A5LngBRf4 w877clz6O+CIQ7WiipbZj93sSnvoKHJJLfGpyXQwiabSU0cDINDTuQTU8eW1OmSqxVRv EsMkm/wDpSY28WZEaiX7ZgIF2bUj1xXT4Q8ZYQcdvwiH4t0gI9qogFtbyuJsVrsCoVZ3 N/6cBLY6bsyFPoR4jkndz84z7O8eb6riQwdfuGnNPM+vpkAp0n1iUX9MOMMFG0biAg0z eT9m23FVBYt2+CaEC6EPDREXmNGWrRlNwo7sus4qvxFTfnYltKU5KNZ8GF9OUcVH6Zur 7EeA== X-Gm-Message-State: AA6/9Rn6S08p7zJckbpHgdwcxxTX2gF3ualceat4pLMrgtpFAEZUlri48Gc4Q3g7bFFEZQ== X-Received: by 10.25.207.131 with SMTP id f125mr17512682lfg.181.1476790055100; Tue, 18 Oct 2016 04:27:35 -0700 (PDT) Received: from [172.16.237.183] ([62.254.187.248]) by smtp.gmail.com with ESMTPSA id i136sm7267494lfg.36.2016.10.18.04.27.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 04:27:34 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.1a.1.160916 Date: Tue, 18 Oct 2016 04:27:32 -0700 From: Jeff Tantsura To: Susan Hares , 'IETF IDR WG' Message-ID: <19EF4969-7BEB-4C96-837D-9922684C7989@gmail.com> Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> In-Reply-To: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3559609655_1284044467" Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 11:27:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3559609655_1284044467 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Hi Sue, 03 is ready for publication. Thanks! Cheers, Jeff From: Idr on behalf of Susan Hares Date: Monday, October 17, 2016 at 13:27 To: 'IETF IDR WG' Subject: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt. (10/17 to 10/31). Please comment if draft-ietf-idr-large-community-03.txt is ready for publication. If you have concerns with the text, please be very specific about what is wrong and what needs to change. If you have concerns about operational aspects, please give a complete description of the problem and why this draft does not solve it. This WG LC is not a place to debate whether we should have adopted this technology. The focus of WG LC is whether this technology has implementations (see IDR wiki for examples), and whether these implementation inter-operate. It is also important to consider deployment issue or problems on currently. Sue Hares and John Scudder _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --B_3559609655_1284044467 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Sue,

 

03 is ready for publication.

Thanks!

 

Cheers,=

Jef= f

 

 

From: Idr <idr-bounces@ie= tf.org> on behalf of Susan Hares <shares@ndzh.com>
Date: = Monday, October 17, 2016 at 13:27
To: 'IETF IDR WG' <idr@ietf.o= rg>
Subject: [Idr] WG LC on draft-ietf-idr-large-community-03.t= xt (10/17/2016 to 10/31/2016)

 

= This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt.  (= 10/17 to 10/31).   Please comment if draft-ietf-idr-large-communit= y-03.txt  is ready for publication.  

 

If you have concerns with= the text,  please be very specific about what is wrong and what needs = to change.  If you have concerns about operational aspects, please give= a complete description of the problem and why this draft does not solve it.=

 

T= his WG LC is not a place to debate whether we should have adopted this techn= ology. 

 

The focus of WG LC is whether this technology has implementations= (see IDR wiki for examples),  and whether these implementation inter-o= perate.  It is also important to consider deployment issue or problems = on currently. 

 

<= p class=3DMsoNormal>Sue Hares and John Scudder

____________= ___________________________________ Idr mailing list Idr@ietf.org https://ww= w.ietf.org/mailman/listinfo/idr

--B_3559609655_1284044467-- From nobody Tue Oct 18 08:03:24 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834E9129685 for ; Tue, 18 Oct 2016 08:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=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 xSlAFej6NzZH for ; Tue, 18 Oct 2016 08:03:22 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2611312967B for ; Tue, 18 Oct 2016 08:03:22 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.187.221.190; From: "Susan Hares" To: "'IETF IDR WG'" Date: Tue, 18 Oct 2016 11:01:20 -0400 Message-ID: <01f401d22950$7f988470$7ec98d50$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F5_01D2292E.F888B930" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdIpUHjFMTMxey+uRgusubexAa1gwg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Kristian Larsson' Subject: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:03:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01F5_01D2292E.F888B930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit WG: Early testing of the Large Communities draft (draft-ietf-idr-large-community-03.txt) with attribute value of 30 detect that we had an implementation squatting on attribute 30 by a Huawei router. "Squatting" on an attribute is anti-social behavior in the Internet in any release of software. The individuals who did in Huawei have been contacted by Jie Dong, and "asked" if they had made this mistake in any other attribute. These individuals confessed to Attribute 129 (for wide communities). These individuals apologize to the Working group. Now what shall we do? The large community draft is critical for several networks. After talking with the developers and operators, John and I would like to recommend we do the following: IDR should recommend that the following attribute numbers be deprecated: BGP Attribute 30 BGP attribute 129 IDR should ask IANA to assign BGP Large Communities (currently Attribute 30) to a new attribute number. This is a 1 week call to determine if the IDR approves this action. This call will allow the large communities draft to still continue with the 2 week WG LC. John, Alvaro, and I have check the early allocation rules. Implementations should ask for early allocation prior to releasing, and they do not need to be interoperability testing to request the early allocation for the attribute. Sue Hares ------=_NextPart_000_01F5_01D2292E.F888B930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WG: =

 

Early testing of the Large Communities draft = (draft-ietf-idr-large-community-03.txt)  with attribute value of 30 = detect that we had an implementation squatting on attribute 30 by a = Huawei router.   “Squatting” on an attribute is = anti-social behavior in the Internet in any release of software.  =

 

The individuals who did in Huawei have been contacted = by Jie Dong, and “asked” if they had made this mistake in = any other attribute.   These individuals confessed to = Attribute 129 (for wide communities).  These individuals apologize = to the Working group. 

 

Now what = shall we do? The large community draft is critical for several networks. = After talking with the developers and operators, John and I would like = to recommend we do the following:

 

IDR should = recommend that the following attribute numbers be deprecated: =  

 

BGP Attribute 30

BGP attribute 129

 

IDR should = ask IANA to assign BGP Large Communities (currently Attribute 30) to a = new attribute number.  This is a 1 week call to determine if the = IDR approves this action.   This call will allow the large = communities draft to still continue with the 2 week WG LC.  =

 

John, Alvaro, and I have check the early allocation = rules.  Implementations should ask for early allocation prior to = releasing, and they do not need to be interoperability testing to = request the early allocation for the attribute.

 

Sue Hares =

 

 

------=_NextPart_000_01F5_01D2292E.F888B930-- From nobody Tue Oct 18 08:19:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9291294ED for ; Tue, 18 Oct 2016 08:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GXEPFePYdh4l for ; Tue, 18 Oct 2016 08:19:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0839A127A91 for ; Tue, 18 Oct 2016 08:19:24 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 331CB1E1F0; Tue, 18 Oct 2016 11:21:32 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B0D07F51-C9E2-4365-A762-40674381D90F" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Jeffrey Haas In-Reply-To: <01f401d22950$7f988470$7ec98d50$@ndzh.com> Date: Tue, 18 Oct 2016 11:19:22 -0400 Message-Id: <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> To: Sue Hares X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF IDR WG , Kristian Larsson Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:19:27 -0000 --Apple-Mail=_B0D07F51-C9E2-4365-A762-40674381D90F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sue, If 129 is not otherwise contended for, it may be reasonable to simply = request early allocation for the wide communities code point. -- Jeff > On Oct 18, 2016, at 11:01 AM, Susan Hares wrote: >=20 > WG:=20 > =20 > Early testing of the Large Communities draft = (draft-ietf-idr-large-community-03.txt) with attribute value of 30 = detect that we had an implementation squatting on attribute 30 by a = Huawei router. =E2=80=9CSquatting=E2=80=9D on an attribute is = anti-social behavior in the Internet in any release of software. =20 > =20 > The individuals who did in Huawei have been contacted by Jie Dong, and = =E2=80=9Casked=E2=80=9D if they had made this mistake in any other = attribute. These individuals confessed to Attribute 129 (for wide = communities). These individuals apologize to the Working group. =20 > =20 > Now what shall we do? The large community draft is critical for = several networks. After talking with the developers and operators, John = and I would like to recommend we do the following:=20 > =20 > IDR should recommend that the following attribute numbers be = deprecated: =20 > =20 > BGP Attribute 30=20 > BGP attribute 129=20 > =20 > IDR should ask IANA to assign BGP Large Communities (currently = Attribute 30) to a new attribute number. This is a 1 week call to = determine if the IDR approves this action. This call will allow the = large communities draft to still continue with the 2 week WG LC. =20 > =20 > John, Alvaro, and I have check the early allocation rules. = Implementations should ask for early allocation prior to releasing, and = they do not need to be interoperability testing to request the early = allocation for the attribute.=20 > =20 > Sue Hares=20 > =20 > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr = --Apple-Mail=_B0D07F51-C9E2-4365-A762-40674381D90F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sue,

If = 129 is not otherwise contended for, it may be reasonable to simply = request early allocation for the wide communities code point.

-- Jeff

On Oct 18, 2016, at 11:01 AM, Susan Hares <shares@ndzh.com> = wrote:

WG: 
 
Early = testing of the Large Communities draft = (draft-ietf-idr-large-community-03.txt)  with attribute value of 30 = detect that we had an implementation squatting on attribute 30 by a = Huawei router.   =E2=80=9CSquatting=E2=80=9D on an attribute = is anti-social behavior in the Internet in any release of = software.  
 
The = individuals who did in Huawei have been contacted by Jie Dong, and = =E2=80=9Casked=E2=80=9D if they had made this mistake in any other = attribute.   These individuals confessed to Attribute 129 (for = wide communities).  These individuals apologize to the Working = group.  
 
Now what = shall we do? The large community draft is critical for several networks. = After talking with the developers and operators, John and I would like = to recommend we do the following: 
 
IDR = should recommend that the following attribute numbers be deprecated: =  
 
BGP Attribute 30 
BGP = attribute 129 
 
IDR = should ask IANA to assign BGP Large Communities (currently Attribute 30) = to a new attribute number.  This is a 1 week call to determine if = the IDR approves this action.   This call will allow the large = communities draft to still continue with the 2 week WG LC.  
 
John, = Alvaro, and I have check the early allocation rules.  = Implementations should ask for early allocation prior to releasing, and = they do not need to be interoperability testing to request the early = allocation for the attribute. 
 
Sue = Hares 
 
 
_______________________________________________
Idr mailing = list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

= --Apple-Mail=_B0D07F51-C9E2-4365-A762-40674381D90F-- From nobody Tue Oct 18 08:25:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B06A1295A4 for ; Tue, 18 Oct 2016 08:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 Lx6dZatlAJ6k for ; Tue, 18 Oct 2016 08:25:53 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3907129562 for ; Tue, 18 Oct 2016 08:25:52 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id y2so254821547oie.0 for ; Tue, 18 Oct 2016 08:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=GSC0Np9LlVruCNh9Y7+PsMlMVe5zEhEJRl4j4mRP3iM=; b=taduqrMehRvyfmX+d8pYD/g3sWkttHasoYQ9CjfwLf8eFwbSd4m+KZllz5xPlEbk9O UFNOtb0HuHj7OEjGDQfC7qugbPKKYrg9/SoX8Fpepd0QmhQQm8uMSKnpC5anmBgMXBqH WRk+P273tucVJIqJrNrxdZAuv4N/wbKaHWDJ7l0aWdRHfMVjLM8ue6iAVEEv8FmgnorN UGYCf4Rkpsdu1eaENDkqWUdciPKCawdKzsvCR3yWGe8gtSKbYecNy13KYsCBYV1r2BkV 7v/nVnPkIzBeRZKDfLVP0kYF9QbFXnz05GTQH4tUSc7OL2nIdcY6QEv1SAHktvyi4SGB cVBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=GSC0Np9LlVruCNh9Y7+PsMlMVe5zEhEJRl4j4mRP3iM=; b=M+HJCf1ODHVc1rXP8+R6QXuYQQi4zFklsfD8GmDOf7PNQwwDi5K6py7HLgTRUo0kRA lSuP5WI+9On/AeoQt7LqKqiOjFpze8DwAPDzfhtnNBrwbNGW2Pabf/tWO6bWOm1581u/ pHhZ6CxaDJ4ly+zToccBNyGSFhZUEjduZbjExEjTw431B29ssMBN6mntXJ/Rj+awqjer 7dv4T6RW3n5um16xYcwh325CdkXAQ556hA5uU3BOG759UVYVi2SvlVHvJViqW01zV0d3 tZXAzAc0/OXD44AXL8b25rnzegqAm7VVZEssP7kgqWpRLUKlRYlC96sZCGVgS5ILGq4N m59g== X-Gm-Message-State: AA6/9RmsYpD+BBkFlnOFi63dAK46fXXmntWj1Qh8cqv7JMknvyns2V0VbXGmNliZqIMjsg== X-Received: by 10.202.216.69 with SMTP id p66mr846659oig.61.1476804352049; Tue, 18 Oct 2016 08:25:52 -0700 (PDT) Received: from localhost (dhcp-157.238.255.122.noc.gin.ntt.net. [157.238.255.122]) by smtp.gmail.com with ESMTPSA id n196sm13035162oig.8.2016.10.18.08.25.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 08:25:50 -0700 (PDT) Date: Tue, 18 Oct 2016 10:24:34 -0500 From: Job Snijders To: Jeffrey Haas Message-ID: <20161018152434.GB10221@dhcp-157.238.255.122.noc.gin.ntt.net> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: IETF IDR WG , Kristian Larsson , Sue Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:25:54 -0000 On Tue, Oct 18, 2016 at 11:19:22AM -0400, Jeffrey Haas wrote: > If 129 is not otherwise contended for, it may be reasonable to simply > request early allocation for the wide communities code point. and in doing so encourage early self-allocation? :) At this point it is not even clear what exactly has been implemented, the wide communities effort might suffer from an incompatible deployment in the wild. I'd steer clear from this. Kind regards, Job From nobody Tue Oct 18 08:30:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034581295EF for ; Tue, 18 Oct 2016 08:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 25k3P-D5H1XB for ; Tue, 18 Oct 2016 08:30:52 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 BD9A8129562 for ; Tue, 18 Oct 2016 08:30:52 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bwWLs-000CIg-3q (job@us.ntt.net); Tue, 18 Oct 2016 15:30:52 +0000 Date: Tue, 18 Oct 2016 10:30:47 -0500 From: Job Snijders To: Susan Hares Message-ID: <20161018153047.GJ95811@Vurt.local> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01f401d22950$7f988470$7ec98d50$@ndzh.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: 'IETF IDR WG' , 'Kristian Larsson' Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:30:54 -0000 On Tue, Oct 18, 2016 at 11:01:20AM -0400, Susan Hares wrote: > Early testing of the Large Communities draft > (draft-ietf-idr-large-community-03.txt) with attribute value of 30 > detect that we had an implementation squatting on attribute 30 by a > Huawei router. "Squatting" on an attribute is anti-social behavior in > the Internet in any release of software. > > Now what shall we do? The large community draft is critical for several > networks. After talking with the developers and operators, John and I would > like to recommend we do the following: > > IDR should recommend that the following attribute numbers be > deprecated: > > BGP Attribute 30 > BGP attribute 129 > > IDR should ask IANA to assign BGP Large Communities (currently > Attribute 30) to a new attribute number. This is a 1 week call to > determine if the IDR approves this action. This call will allow the > large communities draft to still continue with the 2 week WG LC. I support this course of action. background: Some in the working group might wonder why Large should change instead of Huawei. Huawei routers are treating routes with Large BGP Communities as "withdraw", which makes Large BGP Communities deployments suffer. Large BGP Communities users become unreachable on attribute 30. Had the squatting resulted in Huawei routers crashing or some other form of damage on the Huawei side, the onus would be on Huawei users. This is not the case unfortunatly. There are no winners if either side holds their ground and remains on the codepoint. For Large BGP Communities it is still early enough to update the implementations. Changing the Large BGP Communities path attribute value is a risk adverse strategy. Kind regards, Job From nobody Tue Oct 18 08:32:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D038C12968D for ; Tue, 18 Oct 2016 08:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 csDTdL43REc6 for ; Tue, 18 Oct 2016 08:32:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 802681295A4 for ; Tue, 18 Oct 2016 08:32:05 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id A71C21E1F0; Tue, 18 Oct 2016 11:34:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Jeffrey Haas In-Reply-To: <20161018152434.GB10221@dhcp-157.238.255.122.noc.gin.ntt.net> Date: Tue, 18 Oct 2016 11:32:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <20161018152434.GB10221@dhcp-157.238.255.122.noc.gin.ntt.net> To: Job Snijders X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF IDR WG , Kristian Larsson , Sue Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:32:08 -0000 > On Oct 18, 2016, at 11:24 AM, Job Snijders wrote: >=20 > On Tue, Oct 18, 2016 at 11:19:22AM -0400, Jeffrey Haas wrote: >> If 129 is not otherwise contended for, it may be reasonable to simply >> request early allocation for the wide communities code point. >=20 > and in doing so encourage early self-allocation? :) Or avoid burning a code point when it may simply be asked for formally = again. >=20 > At this point it is not even clear what exactly has been implemented, > the wide communities effort might suffer from an incompatible = deployment > in the wild. I'd steer clear from this. With regard to the feature maturity discussion, I tend to agree. But = there's still the general issue about how to pick a code point to do any = sort of testing. We have internal guidelines for such things, but once = you get into early deployment scenarios, it gets complicated. Conversation on this obviously should continue. -- Jeff >=20 > Kind regards, >=20 > Job From nobody Tue Oct 18 08:41:30 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA051296B1 for ; Tue, 18 Oct 2016 08:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 LQGKQlhiuIdZ for ; Tue, 18 Oct 2016 08:41:27 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4A11296B0 for ; Tue, 18 Oct 2016 08:41:26 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 29108180554; Tue, 18 Oct 2016 17:41:25 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id F04E31A0066; Tue, 18 Oct 2016 17:41:24 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0319.002; Tue, 18 Oct 2016 17:41:24 +0200 From: To: Susan Hares , 'IETF IDR WG' Thread-Topic: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) Thread-Index: AdIpUHjFMTMxey+uRgusubexAa1gwgABMaNw Date: Tue, 18 Oct 2016 15:41:24 +0000 Message-ID: <6259_1476805285_580642A5_6259_1295_19_53C29892C857584299CBF5D05346208A0FA04E6B@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> In-Reply-To: <01f401d22950$7f988470$7ec98d50$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0FA04E6BOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: 'Kristian Larsson' Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:41:29 -0000 --_000_53C29892C857584299CBF5D05346208A0FA04E6BOPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What about assigning attribute 30 and 139 for "Experimental" use? Especiall= y since this registry has none currently. Experimental: Available for experimental use as described in [EXPERIMENTATION]. IANA does not record specific assignments for any particular use. https://tools.ietf.org/html/rfc5226#section-4 [EXPERIMENTATION] = "Assigning Experimental and Testing Numbers Considered Useful" https://tool= s.ietf.org/html/rfc3692 Obviously this assumes that people do use this value for experimentation, i= .e. follow the rule... Regards, --Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, October 18, 2016 5:01 PM To: 'IETF IDR WG' Cc: 'Kristian Larsson' Subject: [Idr] BGP Attribute for Large communities (Attribute 30) was squat= ted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) WG: Early testing of the Large Communities draft (draft-ietf-idr-large-communit= y-03.txt) with attribute value of 30 detect that we had an implementation = squatting on attribute 30 by a Huawei router. "Squatting" on an attribute= is anti-social behavior in the Internet in any release of software. The individuals who did in Huawei have been contacted by Jie Dong, and "ask= ed" if they had made this mistake in any other attribute. These individua= ls confessed to Attribute 129 (for wide communities). These individuals ap= ologize to the Working group. Now what shall we do? The large community draft is critical for several net= works. After talking with the developers and operators, John and I would li= ke to recommend we do the following: IDR should recommend that the following attribute numbers be deprecated: BGP Attribute 30 BGP attribute 129 IDR should ask IANA to assign BGP Large Communities (currently Attribute 30= ) to a new attribute number. This is a 1 week call to determine if the IDR= approves this action. This call will allow the large communities draft t= o still continue with the 2 week WG LC. John, Alvaro, and I have check the early allocation rules. Implementations= should ask for early allocation prior to releasing, and they do not need t= o be interoperability testing to request the early allocation for the attri= bute. Sue Hares ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0FA04E6BOPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What ab= out assigning attribute 30 and 139 for “Experimental” use? Espe= cially since this registry has none currently.

&n= bsp;

      Experimental= : Available for experimental use as described in

       &= nbsp;    [EXPERIMENTATION<= /span>].  IANA does not record specific

       &= nbsp;    assignments for any particular use.

 

https://tools.ietf.org/html/rfc5226#section-4

&n= bsp;

[EXPERIMENTATION] “Assigning Experimental and Testing Numbers Considered Useful”= https://tools.ietf.org/h= tml/rfc3692

&n= bsp;

Obvious= ly this assumes that people do use this value for experimentation, i.e. fol= low the rule…

&n= bsp;

Regards= ,

--Bruno=

&n= bsp;

&n= bsp;

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, October 18, 2016 5:01 PM
To: 'IETF IDR WG'
Cc: 'Kristian Larsson'
Subject: [Idr] BGP Attribute for Large communities (Attribute 30) wa= s squatted on - Let's get a new attribute number (1 week WG call (10/18 to = 10/25)

 

WG:

 

Early testing of the Large Comm= unities draft (draft-ietf-idr-large-community-03.txt)  with attribute = value of 30 detect that we had an implementation squatting on attribute 30 = by a Huawei router.   “Squatting” on an attribute is anti-social behavior in the Internet in any release of software.  =

 

The individuals who did in Huaw= ei have been contacted by Jie Dong, and “asked” if they had mad= e this mistake in any other attribute.   These individuals confes= sed to Attribute 129 (for wide communities).  These individuals apologize to the Working group. 

 

Now what shall we do? The large= community draft is critical for several networks. After talking with the d= evelopers and operators, John and I would like to recommend we do the follo= wing:

 

IDR should recommend that the f= ollowing attribute numbers be deprecated:  

 

BGP Attribute 30

BGP attribute 129

 

IDR should ask IANA to assign B= GP Large Communities (currently Attribute 30) to a new attribute number. &n= bsp;This is a 1 week call to determine if the IDR approves this action. &nb= sp; This call will allow the large communities draft to still continue with the 2 week WG LC. 

 

John, Alvaro, and I have check = the early allocation rules.  Implementations should ask for early allo= cation prior to releasing, and they do not need to be interoperability test= ing to request the early allocation for the attribute.

 

Sue Hares

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0FA04E6BOPEXCLILM21corp_-- From nobody Tue Oct 18 08:44:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9FF1293EE for ; Tue, 18 Oct 2016 08:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=psc.edu 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 chh4AU-kYfN9 for ; Tue, 18 Oct 2016 08:44:49 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [IPv6:2001:5e8:2:46::6a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21A4129494 for ; Tue, 18 Oct 2016 08:44:48 -0700 (PDT) Received: from dengue.psc.edu (dengue.psc.edu [128.182.160.217]) (authenticated bits=0) by mailer2.psc.edu (8.13.8/8.13.8) with ESMTP id u9IFiirh025401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Oct 2016 11:44:45 -0400 DKIM-Filter: OpenDKIM Filter v2.10.3 mailer2.psc.edu u9IFiirh025401 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=psc.edu; s=default; t=1476805485; bh=Fb2LJ+xoR/4OfMck8cUOqCtIt6/lWmV8KkakgEUQYKk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=L7sBbMfKlD07YZXntPWGAgEJq/yIxDdu/XYeU5KTMrlnm9L+i1Ll3uIcH4n+tLATX i7AD/r3fTB6Q32S+MSxs9b1uDdKAyFksxxmWKFXIo3Zq3mnUFcT7+aei1xTou7zwJB L0nsaPVqdArqoaxcRzsuBgMQTgGLCaWX0AL5bH+U= Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Michael H Lambert In-Reply-To: <20161018153047.GJ95811@Vurt.local> Date: Tue, 18 Oct 2016 11:44:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <20161018153047.GJ95811@Vurt.local> To: IETF IDR WG X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Kristian Larsson Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:44:51 -0000 > On 18 Oct 2016, at 11:30, Job Snijders wrote: >=20 > I support this course of action. >=20 > background: Some in the working group might wonder why Large should > change instead of Huawei. >=20 > Huawei routers are treating routes with Large BGP Communities as > "withdraw", which makes Large BGP Communities deployments suffer. = Large > BGP Communities users become unreachable on attribute 30. >=20 > Had the squatting resulted in Huawei routers crashing or some other = form > of damage on the Huawei side, the onus would be on Huawei users. This = is > not the case unfortunatly. >=20 > There are no winners if either side holds their ground and remains on > the codepoint. For Large BGP Communities it is still early enough to > update the implementations. Changing the Large BGP Communities path > attribute value is a risk adverse strategy. Would the same course of action be recommended if it were an open-source = project (eg bird or quagga), rather than a commercial router vendor, = squatting on attribute 30? If the answer is an unequivocal yes, then I = agree with the proposed course of action. Otherwise, I think the burden = falls on the vendor to fix their (with respect to standards) broken = implementation. Michael From nobody Tue Oct 18 08:49:02 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47041296AB for ; Tue, 18 Oct 2016 08:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1WNJbt6biimj for ; Tue, 18 Oct 2016 08:49:00 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 96E491295F3 for ; Tue, 18 Oct 2016 08:49:00 -0700 (PDT) Received: from [IPv6:2620::ce0:101:921:7e08:1435:8b08] (unknown [IPv6:2620:0:ce0:101:921:7e08:1435:8b08]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id B1CCC540AD4; Tue, 18 Oct 2016 11:48:58 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3246\)) From: Jared Mauch In-Reply-To: Date: Tue, 18 Oct 2016 11:48:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <84F3251A-9947-409A-8347-E541FBF196F3@puck.nether.net> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <20161018153047.GJ95811@Vurt.local> To: Michael H Lambert X-Mailer: Apple Mail (2.3246) Archived-At: Cc: IETF IDR WG , Kristian Larsson Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:49:01 -0000 > On Oct 18, 2016, at 11:44 AM, Michael H Lambert = wrote: >=20 >> On 18 Oct 2016, at 11:30, Job Snijders wrote: >>=20 >> I support this course of action. >>=20 >> background: Some in the working group might wonder why Large should >> change instead of Huawei. >>=20 >> Huawei routers are treating routes with Large BGP Communities as >> "withdraw", which makes Large BGP Communities deployments suffer. = Large >> BGP Communities users become unreachable on attribute 30. >>=20 >> Had the squatting resulted in Huawei routers crashing or some other = form >> of damage on the Huawei side, the onus would be on Huawei users. This = is >> not the case unfortunatly. >>=20 >> There are no winners if either side holds their ground and remains on >> the codepoint. For Large BGP Communities it is still early enough to >> update the implementations. Changing the Large BGP Communities path >> attribute value is a risk adverse strategy. >=20 > Would the same course of action be recommended if it were an = open-source project (eg bird or quagga), rather than a commercial router = vendor, squatting on attribute 30? If the answer is an unequivocal yes, = then I agree with the proposed course of action. Otherwise, I think the = burden falls on the vendor to fix their (with respect to standards) = broken implementation. Yes. As Job said, there is no winning move here. I=E2=80=99d like to see the = vendor taken to the woodshed as well, but without a new allocation = everyone suffers. - Jared= From nobody Tue Oct 18 08:51:24 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83551296B8 for ; Tue, 18 Oct 2016 08:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 H_5g7qTByxIj for ; Tue, 18 Oct 2016 08:51:22 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0134.outbound.protection.outlook.com [104.47.34.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB7D1296B6 for ; Tue, 18 Oct 2016 08:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2aNWMvSFAuOq00AxP/KBXsRBFFX0FPkGHBUwSKoWPNg=; b=Em5bvT7WAnjkJGboWzMOQZUOmaLPPtXdh+T4ChIWdQkGugsjN7t3tNtIvmAQxBrjD8KhCLjX703FFUcvUqbxb6mASoMZGbUTuI8yGxl8C13AkmeP/Wm/t44a0t81jTKFvgcwInnGH1OIs2NC2KuHsDkjOnFnOLDUz4dRqwok9y0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.34.170] (66.129.241.10) by BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.4; Tue, 18 Oct 2016 15:51:15 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_7B7E2629-067A-46D1-B668-6FCE251A1D14" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> Date: Tue, 18 Oct 2016 11:51:01 -0400 Message-ID: References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BLUPR13CA0067.namprd13.prod.outlook.com (10.160.82.38) To BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) X-MS-Office365-Filtering-Correlation-Id: da808ac8-1acf-4bb0-0946-08d3f76e9802 X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 2:I4BDXIi5BZpk+iVOv9v+q6ltQcJV8errvi/dtvR/SByLBTQonkVb2PsV3gJU9MrQTVuT0BH1VDpiGul6fs3iiuYDM4GaEaM9kFicX4VTQAffrZcA+L70bQIFZVoVIrnRzgVF+Cxauj4eECcQyb7Ql4MiGkvSe8Kn9PAPBgStoug8BkMDXI6/7K5PlfU/U7oVkFtwdXO2fxU8eQwXg+y+BQ==; 3:AkzPafm7tdcQ2BeSLghTmCj/IOpNuMksu8kYR+ydF+BgkQtiWPnV5F3zwiSWJE2Ie7Ec12WZzgiuEJpr5Kf8/zX0FmnMtVOXXdgD9fOQXJCc0BvHEwq2uFKF1hfOhocyW2k77SAENcm/vDVM9U1MsA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 25:pcXp60nV1HEeAgf8D0dy6ZnsmAEJctF/GCSmLHWhoikesmvediOUWuaPxe2YvE5rx9ppjf0MQrw8B90AGgQxYd4N2bGDUVxkiX6T+qIRq1lTQ5XOd6pSVRKRZL58n1W3XqZ8x/nI8e0LEvFTAnE7GRzqMKgKhaXM4HAfr65T+T51YNi/9zbakjuD3jFCtGJLeCpT0sOV1oyLDNqlmYljywlUPRcyNBRVuUWNSnZ8wkyE/AZIBENY23eXkTzpy1TdjsyvNLaRQ2SVJMPkgBgWrH1+9QznmGpK7gqzLUcWNE2zM5ZDmBXw6TRarLUgSGST5HVQbc75KPlWPzIGiaGqfugbXERFm4sQQXT5dqEHtSTwUb7m+S8bRHzmKuZrYGuLwA7SdUxCkaU0pIzjH9wRD0/orhTIzQWeemGklAo7bRZcjRWXucAcEZyYD61TmGmVkyL9JsD9pr7UsBKC/tx/E0yI/Ux6LW1q6XVgkgc9pQrFKMnOt5j5sugLLseGk4lYL1hcT2ywPg2rtXbFrS5f8kYVr7iN1e0Y78TFqGg/bcl7i6ayE0mD62APVcYhGQUlZOyaeuv1HcLY7bE/b38QSMQZ3PgBJezy6m2pzlOnVGzLUDjBML1uwxHQ6gXEtg/mK9brBXGGNyfWMM3tTAcyXHuWM9gju1pRrmrzxDTf8gPHe+qOzYkJztrJuop6dtKsYeK0kNwVZlLXt7ZQJyLuW5fWv0X1vdmbDQWHlKFrPuDOiq1+lvBqYhDm+uhTA4L88GySnG6uqJ0TBgXUvxW2TKOINuTwrwz72+ys9Cnj6l5OauyShaFs+piu4RWncCKzctdl9PPD/7yVYCMqJPa0A/aa0oj/ZdK9ozRPlg11sD7yTG1YfFlBwLw38UbcuUQ9rFh/EmbTcoH0zFHSiQsb1Q== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 31:hRmv92Q7jEMkAI7mh2COlMxXO5/vCyZ7EH6IToB+xExmo3r0cCrYkzV9lGR85EXCuip2srYKa6qDczUpu4+w+WmdURnCzXN1sgyydQZwIld5yLBxN8HlQ7rKATlfq+4Gk6MemAK6fMlBAi3vdah1KqBmQXXdmej0F2gEAe4FkfsF+/5g9sCGhJpTeoxn3hjVe9rD+HpX0agYUOS9mgsP+/3UO9eCimfu4F9rnyhxWCg/MIL98pbi61rYWio/iM9UGU6NiLM9nuo4yZH8AS8SHQ==; 20:G5tBS2iLiSMZivvzFnMeAe9iwukV/GQ3+9CI2qD0zVN9zhmGInZrEz95Mu0yG4DqOCY2laBIp/e183mJib32DJ6ZIiNU1/wXHM0UclUPoa25KDttKOLb7cee1Wq9XVseswRS1FL8G8wq/rsJN04LkFolzdTiuvGAbpXbt1WRu53dUZPveVK8sLPzXf5nj7UjnVd1FKbqc0AI9Bunx7HYWG1n3e8sHnp9gitGyRfnyDd9P5EMntmmG7CSJNpRnxxIvJp7P3Ex1l/W0VwXchBQce1TjMn7K4cAz6UkMtQ0SJsO84cpAFBgVA9fi21hIdTgrVc7O41uO33h29+BUEHr9mt6zb+n62CNL3R5DVcj2sYft82djquC/ttGKj4P/+mSV3vdIkRT6b3L4hGJxP0fz4z76SCwOx1shY4u8w7unPxyZ1yigt/wKUKQkWTQOsB92oKpjyI9JM17Lju7Wi1Q3MVMwMEC2VQEwtQWfgVQEVkT+spNuZg6mssW2VEnXe8h9T2Bg4W/NK57UsgNRrQXqHFRTKATaQAcII5rYKESGi7suZcfb1/gKS8T/Rr/sLRaqZfXl0QQvFoIUIVPBPu7V1spBKfHmtf0ozBpSAj/gzk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN3PR05MB2498; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 4:7P1oCqL+6hcQKbLDFB3gdi1c3GJ6Z+7J5AlxZXJlNS4Zts8iaBe5boI1AKCqBwdN2dWEv+pkiUoARkgZGEm+dmgCgamr86HetQoIa9WyC6RdoXpJiV9t5T23wxdagu29GQMDW/8pYnqX+jN/FQ4jEGIcxx0ea+WddpJQFIBuE1gREiqx3BwHbIREJUaPm+WDRgOb6BUOQexFhk4ViPwA2KIbGgh8cN8UKYj399uc2o9ggMGmuOGuWSsFZfzYrcCqRlH/CpPiEpuhctwDrryrKwvETaCY/Z8oGERJXDXUqlfQ3t9DXfb7YMyOrvsrhQn8TSyaPTXjCwO172n7nOIO+A5zMB7MpoRsq/MxHyUQj42C7ojwMxGQx+USZkX0VhHdnuLu1CS+MesRAtLD+hIzmJWm0JSI+JHJf3Xq1e5s+4OuAhLhCXsBklXd64ZO+hrIdbnSZpTDKifmorAewMnY0A== X-Forefront-PRVS: 00997889E7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(979002)(6049001)(7916002)(189002)(24454002)(199003)(377454003)(512954002)(260700001)(586003)(69556001)(2906002)(83716003)(92566002)(66066001)(36756003)(6916009)(82746002)(101416001)(81166006)(77096005)(5660300001)(6666003)(110136003)(8676002)(2950100002)(86362001)(3846002)(68736007)(6116002)(7736002)(57306001)(50226002)(7846002)(4326007)(81156014)(84326002)(106356001)(97736004)(42186005)(19580405001)(19580395003)(189998001)(105586002)(50986999)(33656002)(76176999)(141353001)(42262002)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2498; H:[172.29.34.170]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 23:5EmCr5Mq3ebbLQqNdIUzPiNIua771JdLjG1Zx4/HF?= =?us-ascii?Q?lgEJq3SVb9MwyzYSCgE64De+0UkSFyoMWuzvRN+76dW4BwRRrM2wNXo+poiW?= =?us-ascii?Q?dsk2rIVp80atBER4g44sBxbtzdP1rQfmB2CrAIGw7xVTt6dGujzBQaoIN95p?= =?us-ascii?Q?zZM1NPRHZjIL8biHNUKU2ZLPjl7EdMr4vt/tshkEYWexcQunE++Vf0Z6GXL5?= =?us-ascii?Q?cehWgFNno+5YvhTGaZENsu/fr8JXhYqJyKCic4ZJjDAE2VNu/VRKNNM0Uy2r?= =?us-ascii?Q?s2dTNohQhsW5KBVpMilfjKN4xWf3ePRSyAymsr6SoRt1uyKoqrfBY4dXhfDU?= =?us-ascii?Q?/c7riwA8DvHFrNe6IkPSndSDYmKHIu1R4qAhs9FX2hONnfe40Jvw34FsvGB8?= =?us-ascii?Q?Unoap2zuL8glU3Oa9ZDQ36kwsSF00hbqH6Yg+CCpjlvqhKWd3LqAvqpfoBpR?= =?us-ascii?Q?/mtfqqtsvYOIK6sDZBZF0a2JCTujtOVn9IQR+2zuYFx+4NnLtDKyBnTtF3Xy?= =?us-ascii?Q?FUWsjB7gJvhDzPHMf3y/1ymqv50FUjGk3mOsRPEhcBQtQmScrzXPf7gFCEXF?= =?us-ascii?Q?tPfk1TBjeCTWMRpgx8tPDXU4n/x39nl9xfHQ4OG1e61M7hAH8ippnJx1ru6X?= =?us-ascii?Q?IK8334pMfItJfKL/z5Xm/PpmbRzUuGXv2ZKC4iSe5s7h0aCYAXQTsx9sUyDo?= =?us-ascii?Q?bDUjIAgP9o3y8nSVczcPlzSWFA1Ho6cuW3ygnOxvymNYBh3bFMIr6477CSSc?= =?us-ascii?Q?Bs9NmJEWRo3R3IvclzsFd+COajsIMW6DofCy2m1NNqL2L7u67MbODsPlf78f?= =?us-ascii?Q?fo30H84/h/w3wAeW9kpmI0TfxnLiA1Ak8gI1JCJ3OrNjTwJNrOCZdHRrJ4s+?= =?us-ascii?Q?/KAmm3czQlGxaSfaIXrQCTC2z6SfCDlwVDQpG8NIAsIhv0Y1zUO/VLwZcsoa?= =?us-ascii?Q?ZFpuTVc87C5O/PA+WOHiBb/zSY/vApx3hMludkfisAf9ghWSQRc6PGbUUoI4?= =?us-ascii?Q?Agw2sv0g4SKiJm32PtaBRp3VzPnpKaqWc5aJAt+EWcVQMIJo/W+ccN67SbpR?= =?us-ascii?Q?1BTLHN+7TaNHHkZKtlUdwRO8+YNwTUSFk0uhUoo2JNNhkRMmYEDeVI1Y9eJc?= =?us-ascii?Q?p/w5SvXoApkUUJ/2AbUXvnAsJn6fhZlrFXhwiPGjE7jpBk77olvUH9CAwGBu?= =?us-ascii?Q?HEM2e3ioSbRjDRZYngYGKmRXDnIdPquLcq88ARGMo6Dj2oaBCjGv7CDOdYAX?= =?us-ascii?Q?nJUdzxFClVUn8nWyXzfpetnqASKZ4kcXPLuW0qSz5yKOyRNYx/RNcJeu29zl?= =?us-ascii?B?QT09?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 6:d3/Xkn+n35+xPF8ljCihBHt3vcRVibIm7Sq78dnkXtEL/9zqUPZ/lMEl5AoI2zRP+Z1maECAVMp0GXONLSelrIbBQS2WHLZfE/WYJa6Ijo9jpK/uqCxH7JDccZAwH3WP+xg2sw0Mdee4GSZGJUs6G8RmyvCNDK5wQukSUGyWPl9wbAqaKRlzdUpVFAyMsiuLhV5O5W0j8gQ8TIEzr0PsqktpVEWfV/fWeWoXMFd7R92St9bAUKFDNJNw0b2qYjPy7bvnk/r5Kb8uNMvrCPmnnQsczO0J0nE6vLWGfZJGGSN3E7w5g9KUJuOUnLxvg0LRvY6GLqJUjJkDlavD7hEmMA==; 5:mQXmshzvsbjY5YwG1FRjxZYcDKwTxRX46P/fdddhOJ2u/o0HT/it6xTonSSrO7k5QgXAHgq1PxNtGvJPwCgjtwVzw05rwOMz4AJcw2azW6CcIkHEhgbzNWfNrffol3xFdAeFhdIPyk+WuvYEuq9NqQ==; 24:iUEINsxba/w5AnDl59b0m55+QeyCW+HoQhRrTJqD+Cv9tC+eNzw6PPETkzHI0icXe2Vw2UmxUEpu3iFJBBobyqLTqfhbWVS4blN1mrLU71Y= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 7:vLuqSB9ieoa5u6QmvZxp00t6HBKpVwZ4p1PVOpUvsNL3M9bj8FIHhezI57DG0OtLP+svLxrX92CFzpTob1O8oXuJrsps2AambxUEiT01YkBvSGwh3pHy/A2XA7lUmedbiaf3wKL3XCRQS2pAis7N+PFuHlYEYmirZx0bX3H41IYOM2sJdC6hesHbP/e6a+V7jxrS5lTo/7j57H3JpyrUF+uOdA0WMAP3jL0bQyMtpwET7mZqKczUFBv5VG1SYW8iqBRrvK/dmjdBMa9Lzg5n08ZVs31jlxq6V1Vp30g6EQQcQjHAHI8xVIHs9K+nQchNn7RKx2C0brcH10xpwOI7mExVk0Ohw+8bvGvb96PGA2k= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2016 15:51:15.3471 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2498 Archived-At: Cc: IETF IDR WG , Kristian Larsson , Sue Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:51:23 -0000 --Apple-Mail=_7B7E2629-067A-46D1-B668-6FCE251A1D14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Oct 18, 2016, at 11:19 AM, Jeffrey Haas wrote: > If 129 is not otherwise contended for, it may be reasonable to simply = request early allocation for the wide communities code point. The two courses of action are not mutually exclusive -- the code point = can be marked "deprecated" right now and can later be {early} allocated. = It's just a degenerate case of reusing the code point, which is expected = in the case of deprecation -- we just normally expect it to take longer. = Of course if we have working group consensus to request the early = allocation right now, we can skip a step, but generally step-skipping = has not worked well in my experience. :-( --John= --Apple-Mail=_7B7E2629-067A-46D1-B668-6FCE251A1D14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" On Oct 18, 2016, at 11:19 AM, Jeffrey Haas <jhaas@pfrc.org> = wrote:
If 129 is not otherwise contended = for, it may be reasonable to simply request early allocation for the = wide communities code point.

The two courses of action are not mutually = exclusive -- the code point can be marked "deprecated" right now and can = later be {early} allocated. It's just a degenerate case of reusing the = code point, which is expected in the case of deprecation -- we just = normally expect it to take longer. Of course if we have working group = consensus to request the early allocation right now, we can skip a step, = but generally step-skipping has not worked well in my experience. = :-(

--John
= --Apple-Mail=_7B7E2629-067A-46D1-B668-6FCE251A1D14-- From nobody Tue Oct 18 08:52:31 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F59A1296BD for ; Tue, 18 Oct 2016 08:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 GtFi2BYF-lfa for ; Tue, 18 Oct 2016 08:52:28 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 649BF1296B9 for ; Tue, 18 Oct 2016 08:52:28 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bwWgk-0000f5-Sq (job@us.ntt.net); Tue, 18 Oct 2016 15:52:27 +0000 Date: Tue, 18 Oct 2016 10:52:26 -0500 From: Job Snijders To: Michael H Lambert Message-ID: <20161018155226.GM95811@Vurt.local> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <20161018153047.GJ95811@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: IETF IDR WG , Kristian Larsson Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:52:29 -0000 On Tue, Oct 18, 2016 at 11:44:44AM -0400, Michael H Lambert wrote: > > On 18 Oct 2016, at 11:30, Job Snijders wrote: > > I support this course of action. > > > > background: Some in the working group might wonder why Large should > > change instead of Huawei. > > > > Huawei routers are treating routes with Large BGP Communities as > > "withdraw", which makes Large BGP Communities deployments suffer. Large > > BGP Communities users become unreachable on attribute 30. > > > > Had the squatting resulted in Huawei routers crashing or some other form > > of damage on the Huawei side, the onus would be on Huawei users. This is > > not the case unfortunatly. > > > > There are no winners if either side holds their ground and remains on > > the codepoint. For Large BGP Communities it is still early enough to > > update the implementations. Changing the Large BGP Communities path > > attribute value is a risk adverse strategy. > > Would the same course of action be recommended if it were an > open-source project (eg bird or quagga), rather than a commercial > router vendor, squatting on attribute 30? If the answer is an > unequivocal yes, then I agree with the proposed course of action. > Otherwise, I think the burden falls on the vendor to fix their (with > respect to standards) broken implementation. Yes. I don't think the project's license has anything to do with this. I started testing Large BGP Communities in the wild [1], and attached a Large BGP Community to my home LAN prefixes. My significant other discovered that we can't reach parts of the internet. It doesnt matter which vendor caused the unreachability - the fact that there is a reachability problem is sufficient reason for this course of action. Kind regards, Job [1]: http://largebgpcommunities.net/2016/beacon/ From kll@dev.terastrm.net Tue Oct 18 08:49:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FBB1296B2 for ; Tue, 18 Oct 2016 08:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=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 WUsbT8xNOYkP for ; Tue, 18 Oct 2016 08:49:06 -0700 (PDT) Received: from smtp.dev.terastrm.net (smtp.dev.terastrm.net [80.159.241.61]) by ietfa.amsl.com (Postfix) with ESMTP id 571401296B9 for ; Tue, 18 Oct 2016 08:49:05 -0700 (PDT) Received: from Kristians-MacBook-Pro.local (unknown [IPv6:2003:1b3b:ffde:1::5]) by smtp.dev.terastrm.net (Postfix) with ESMTPSA id 03F9E3A011F; Tue, 18 Oct 2016 17:49:03 +0200 (CEST) To: Michael H Lambert , IETF IDR WG References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <20161018153047.GJ95811@Vurt.local> From: Kristian Larsson Message-ID: <85865e76-c48f-1164-2602-1ace0a515a30@dev.terastrm.net> Date: Tue, 18 Oct 2016 17:49:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 18 Oct 2016 08:55:04 -0700 Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:50:08 -0000 On 2016-10-18 17:44, Michael H Lambert wrote: >> On 18 Oct 2016, at 11:30, Job Snijders wrote: >> >> I support this course of action. >> >> background: Some in the working group might wonder why Large should >> change instead of Huawei. >> >> Huawei routers are treating routes with Large BGP Communities as >> "withdraw", which makes Large BGP Communities deployments suffer. Large >> BGP Communities users become unreachable on attribute 30. >> >> Had the squatting resulted in Huawei routers crashing or some other form >> of damage on the Huawei side, the onus would be on Huawei users. This is >> not the case unfortunatly. >> >> There are no winners if either side holds their ground and remains on >> the codepoint. For Large BGP Communities it is still early enough to >> update the implementations. Changing the Large BGP Communities path >> attribute value is a risk adverse strategy. > > Would the same course of action be recommended if it were an > open-source project (eg bird or quagga), rather than a commercial > router vendor, squatting on attribute 30? If the answer is an > unequivocal yes, then I agree with the proposed course of action. > Otherwise, I think the burden falls on the vendor to fix their (with > respect to standards) broken implementation. I think the issue is that we might have a lot of Huawei routers deployed on the Internet with this code so in practical terms it's probably 12-18 months away to have all of them upgraded to a version where they will not drop prefixes with large BGP communities. This will leave networks that want to use large BGP communities with the choice of * using large and not becoming reachable from networks that use Huawei * OR not use large and reach the whole Internet I think a lot of network operators will choose the latter so in the end we'd be slowing down the implementation speed of large rather than punishing Huawei. Kind regards, Kristian. From nobody Tue Oct 18 08:59:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543D91296B3 for ; Tue, 18 Oct 2016 08:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bskyb.onmicrosoft.com 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 wslLyzwYEjM3 for ; Tue, 18 Oct 2016 08:59:48 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40056.outbound.protection.outlook.com [40.107.4.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24134129662 for ; Tue, 18 Oct 2016 08:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BSkyB.onmicrosoft.com; s=selector1-sky-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=teZug/SD85Tjvd54GxifkXip6EmyVbN+vc2ViOrLd6I=; b=GGvro4SJQedUl3DJJz8RicyIRZkYkEbCGNAmj0Dflhf17JMNMlxdZry3tqyA+IcwPARiWJuPbIOHigcNSH8F2BQqvpJSGjp/PYjJsBxVMr+mv22gSOfgth6TYa66BF+GyU0jJq1kmQl3PHIo3AdRTUH7H6N7aD9uT3NtQ4xBZpw= Authentication-Results: spf=pass (sender IP is 176.255.244.224) smtp.mailfrom=sky.uk; dev.terastrm.net; dkim=none (message not signed) header.d=none;dev.terastrm.net; dmarc=pass action=none header.from=sky.uk; Received-SPF: Pass (protection.outlook.com: domain of sky.uk designates 176.255.244.224 as permitted sender) receiver=protection.outlook.com; client-ip=176.255.244.224; helo=email.bskyb.com; From: "Dickinson, Ian" To: Michael H Lambert , IETF IDR WG Thread-Topic: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) Thread-Index: AdIpUHjFMTMxey+uRgusubexAa1gwv//932AgAAD5QD//+7rYA== Date: Tue, 18 Oct 2016 15:50:37 +0000 Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE6170E275@WPMBX010.bskyb.com> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <20161018153047.GJ95811@Vurt.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [191.255.79.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:176.255.244.224; IPV:CAL; SCL:-1; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(199003)(24454002)(189002)(74482002)(46406003)(69596002)(81156014)(2906002)(2171001)(7846002)(5890100001)(11286001)(8746002)(81166006)(92566002)(50466002)(76176999)(8676002)(2920100001)(50986999)(66066001)(8936002)(305945005)(33656002)(23726003)(102836003)(97756001)(6116002)(9686002)(2950100002)(4326007)(586003)(54356999)(7736002)(26826002)(87936001)(86362001)(5660300001)(47776003)(55846006)(3846002)(106466001)(189998001)(5001770100001)(141353001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB198; H:email.bskyb.com; FPR:; SPF:Pass; PTR:b0fff4e0.bb.sky.com; A:0; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD054; 1:B/f5/WpygnDch67JMmmp4of3C3Ss8cmKG6F0EOsTPZaHtjvQqa+oW9lLjFY2OtoMctgPSAMoolzHEDr2lNQpCB+mHobMa/U6gLyZp/c5nBWfVvyJdjCdDH7BBvNLCv13htTsN5ZLuHVPJ9UA10uC/c3F/zHP5mqcjvQ3W7Ny2CGrybZim3tPP0z8WNw6dCl7VlXiTg4Vzt0ISQa6MdBiKahw4R8393LvauRnH5KcXhGlb9mnqvIxY4QxYx7uXJFWwIdcsQ76Z7NiVVV325LCtyaw7Zo3wsChSqaaxv1Sz6LVjbqDr3zAuY2s5O1AtkgvAKvmaqL/QA5vtqZqOAJcW+EafJ0Fy9rNwFeyaHNhMTw1TUoWXr216XPyubGsNPtAeYy8kq2k1I3PFfHPe7fQjaa+TrENHvzbBpXmOr1vZgcWjH3oE5brCJyVaFDUPe1TU8oYj1Hs+YC8rpxmpDdvsQTM02HNwfbMw82hjaE1dpiz0JDytnZ708Dld/yJDo4Wfe9kz+3McVgf8C6JqFI0yNi5r8KLuqngXvDeslUhZK0FDTcVpfDJ7ZJOtfK6nCMhYHeMDETka1lmqSaOx9Vx6A== X-MS-Office365-Filtering-Correlation-Id: 148f65e9-fa23-4fda-bd59-08d3f76e8262 X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB198; 2:zdZBqTMfs08hBN//I/tc7rdVZZOB3RBau3PmauNMPOlehBK3d1GY7isZemoVf/spG9EHk1AhVRf5+ZnFhVLb+N+GknUX9kPTGmeMfsCi/9o7wPq/Rh9gM/g7qvku6aganLBsqCNGsvDbgXrI0czX03mu2NjzlrijJhlBQapyY7INiINmXZtP3TH0BTkVCuiB1wkeulYQs2QgIEYIyjzE8Q==; 3:SyVlDPrqwW01ZHWgqKgZL/zcor2HF3eIYhWwMu5AWGAODrBBGtPapeB808I3Jn5OklWqOLuAxsBkefzBVk0Ra4BeJgiH36OFxRjs85dsAqhoDQHcy1k62YfBLCKZiPxkfd7X0e9Xk6/mEkcPhSjhBfw3Q04nTaPibozzuaqhx/oNTG4OM+m1KqLc/jpdSX0XzdY9FrGVXOqbLs7ZMZfs8ChJtMF7c0mD2cQcdUd+oZS4lYnbo3ORUqc4D6718xez+fCHoO7AS3cfiAa9W0d3bHtxkxfeXszlRsfi4xNilGI= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:AMXPR07MB198; X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB198; 25:X0iV+vyR9W/89ZF0CFZQHhmyBEUwGYbRyCFaeX6vW0jXOSeAAmEkXDhsB8EJ+16R5xqjy5DvVNcMOYcJnCqlyEkxWeOX3qcsciAkih6aL+A7ZbE/FURO1Igf/5jFLBp9l3N9XzokD5LBy4Xt6yZ12NKm8gm4JPZuG5MvrxMnH25jcEb13i/KIGRd2TUbvfpQNOUeNpO4ZmV8SYQZtJ1X6SEcztMrb97IK2C49HVGrpLfHjmh1Bwnn+2wLtWhmAUSEWrGWvhDnRVExplOPyOi8vQ00BexaiwpaZ5yHUVuEh2v1Uw3j3ZcTaNQ+13UwlqjW5x/spSeCp82FWH7s8jf5+E01nnuImZNTN23OKhTZfT9VKGnf8cdAMhCNcF9cNQqHCyxZxw0ohffAysbb0OhJ1dQnV0j5xngaaHgGUm0p1dRQ2uGQCobCNcGbZ7hlk6BEGGNlE5gpAXx6Ki1vYPbUaQnDbJkcRvB18QOGnfuGv5wXj0UHd8PhFayr2ulw9BuC0q6eyXTK2bqJ1ZMWe8QNF882UrXmHQmqeKdwbgDM4DIC+EqW7cJ4ZXGQtpbsh5xpNWd/8xcO1scqJZqXH40F7Tb28SSYXvwnQpp/ugR9Yu/wXUKnshJUrN1OSWccPStaWxg+/icQvWBTLBXY7AEL/TTxaHoRL5zK8vZTmkAB/ONuIz8MKMxzwePegO4nDIWkBXcKqn3fUWdO+gJ6GOyLofXxM7ZDpQ5D9L6PI5MPbpX1luonT9OcVKKmyF9/IKJcyXCcYNV2DyeJt4iXtELSGupNZhMBKwEpyPVhVkBaZQD5sDSp7piv5IFVlQKcCO5Ds9DHi0HXL2R8v7Q6TFu4W3DLO7UyIeOgvAMH0oygT0= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB198; 31:lxag48DL/rjGmVrL8deG2K2TBBbLpkZ7t5sTaelKE8ROhd/GsLX4bOIbyTdrlAroW9T7XGG0TJYhqfDPwbhO6VZZWjOj/odiwkaJh/TFFw+faw3mzbDwN5BxnVrpcnMBbHH1cW688pmnYCSK7xKZtuQ8bi4JDJYpRpLw+pcmyIaYytmNFc8zUDF4yJrjQYyaZ5DAiaAZuKXEmKYqKBSExNo5eMUMR6nvJbJqzGrNOjQ7TXY7V6FNx7o9Kjn0q8uR; 20:dOpV9Hm81LFi2ccqOgfwpckJr+pQzipxXKvVXKNmpu6fhzC6gxVeRWiCpgU/bqif9KaaeKVVl3t0xbyQ8rAoW6ZRbuVb6ZsSwJ+ceI3sGMp12zrhL8kYoGUYDZaq60ixYHTZPEYqB8+H1eCSIV9t9mvZLGbWIZJ+NmTzx5IwCUE7kKUBvZoTtmAuiGvGbc9Y1Xi0ABZGVOUBAcUeYPsXEfbSNegw2l5eZsVJIIgWAGvO5jCdnESvaVmILJ4IKjX8QGvzpSdPyGZR8MeG04fzXIUBT6CzRUXZuQvaV2wSVJuC9F/NbktvLYcXAchA4IGWRoDoQR3Gc0xGUMfcDxNuFLl5xtiyC1Kh2dcLDeCV0jAMMk3J3j8bJflpUfaCobSFmbHUwXr3HLiMjj0HcLDg6oRYKKuuZXwgDBfSKv+wtILfNQyQgt4oxmAfsnN3IJpxZVeMsLEAD36fzBqddXJqeqEno8sol9wd9j0QRmeNMXnEoLAeZazCbdu/XiH3yi4Z X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(13012025)(13020025)(5005006)(3002001)(10201501046)(6055026); SRVR:AMXPR07MB198; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB198; X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB198; 4:nmTtXSSxu7E0M7W9ifY1BFgyGSFEBVer6R64hQO8AmVVvXNuSg0JmM9LlH//rS7Qk0gcnmJRu7KZQ2/JZYmb5gByIuq7BtHKbeKTFLQflRRbSWAo77rIJd609KZrBO6W6XtlvBjjYAnOHkjqN/+Cfy7W62oA7OID6cjIrydQRNSx9vC485Ozr/ivEvI+UtDlCkbXYiZNWbtSWXbFyaRO8SuPhMjapFeTltvbRbLN51XoE1S0ziQuXCqqwfdEC8oh90sbcEKjIp6j/sJ12cfHHLhSBI0rZhQK+Gq2TGb4ApTm4/fXPgTWCCs+JlrokZXxS0LLFwT8fCj6HuzW3HQWCgLswWrd8IK8PsbqPuKvsYvXIUR5xpMCPzgbAgR3Qg7Uu7SV/nDNKm0W/oneUY3FwEVcYFTiTkPZeh+Au1dd677rlWmEIi7v/7Oei1Q+LsHitfYngVGyR1+EZ8ujvvvaCw== X-Forefront-PRVS: 00997889E7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AMXPR07MB198; 23:Uh1o36wQQmhSFWU0SftQ8wVmkoYz3eWPw4IKWmxoKV?= =?us-ascii?Q?1tJFaOc7zakWAv9R2f+VV7q4LloH+GKec2BPiqbJSE7GERVQ26S0CCUMOsD6?= =?us-ascii?Q?8c7SddjWorCF7/PFF+oUzysclyHt/JglBeHaNAyOfHUp1TUC0LGPLu61DDZV?= =?us-ascii?Q?Feh9FzFJSBQshkBpaGLrTYIvbyAO+O3V420A28p6XkKCjF103vox9WEbvZbf?= =?us-ascii?Q?kL8+IpPGN3GoopSMpPvRuT31NlAUB4ZOeSS11eq7C9O+/0oblulBhungZ4ej?= =?us-ascii?Q?Ec1ZyvWkq44DBlQoOlI3iBfsSNJrzfalmj8R6UpD6rY8nFdDO0aveG76EbXW?= =?us-ascii?Q?fNM3GdmVfuAFVOF8ZlnhIKAxvzVlxNiHN0qqbnXe6yO9kf3lLCPalJ9yo6Mb?= =?us-ascii?Q?1QxFxae0xeqzalp50WGl9/jfQH074eChAM3Gpck+m13UWpuwBkcdEz7240T6?= =?us-ascii?Q?O6ThHEWfiF0g8gXld5bu/HP5xsUnMkKkJNiBA3khkB81UliYDnDoPQc2XbS9?= =?us-ascii?Q?G7uXIE0egyFRfFgrxkMKkuE2G6gJrnk/uXDEoYSYq/oIbRZiuJrIdXvJJkUx?= =?us-ascii?Q?A2wCYcPUpZ5c8iZSPg9b+T8tsOm2Fvz8s73VHN1ue1MAcnKcmcbNoiA0ZbNB?= =?us-ascii?Q?xJGrnfRPrBWj10BgxSBE8YmhxhY1Vbwo6lRcnK5G7liOGbQYPSaVybaBkB/V?= =?us-ascii?Q?gXtvb5egXoTvBF7jeU3kGDKY2jGUYnb+xSbYcdp7whUHmgBCQIKfOI891hVD?= =?us-ascii?Q?D0HzA7J6I6m8VKrOBhjq9Xx4QAvH3OgnIrFNh1Di0pS2Zk+kXt/iEvUPTmQQ?= =?us-ascii?Q?3xFGbAOP0WjtSAiMWRvrazB1Ppu0aqF6EHgaAD9CL60mNEOPzuSSGNJM/75j?= =?us-ascii?Q?Jd8cgyLe6HUjfgVrgSthJS850y9yO09ub5WLUCdKo1JPek2KZtZllME7glzF?= =?us-ascii?Q?DC2EO24dL4B4ZtgktxgMgyrxBdxHDDNvIF2ytZy5DZh3ZOqlpJDnH1e08SzD?= =?us-ascii?Q?K6d2J/6W3YVuApf0cAUZZ5PjU5P769NI0xwWQD59oxS1VrK9/xY5bgJxBRsZ?= =?us-ascii?Q?tRc59BYxTT4WY/t256tFZ/YnSntIUm6U2kKtr6fw8OZe+jgv+bobhuZUXzAQ?= =?us-ascii?Q?Eu5HEtb7zY+/Jb9sle4YxkYvA/sQDfPQAcKhOgogMbMYezQMSZQl8aFdwzCX?= =?us-ascii?Q?169FaxYycokZVH1P4ZBikPpnqXVmwnNBxT?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB198; 6:D0mv/sudsNLOVQPN8zEIB8Di97wj8HlHBsSu8vUU9m7IHKDthZYOpm0Vfyyueui4uJvv63nxveQuoN3bGubj8lLXuztYjL7ceY6upndAi2Z9UF1M8nwKgcFE5dlIHSmKDp50fbe9zlFoqmLwp90lAJ9ebUKSeMKzT0jQqzvq/8t3i2IuN0Ktcs7h39tOO6kYTyzu72X49gFQ8p95sqkDXioD3UiuUeoMgeX+f5JqMxC63NRA7dV+EiMQJUqZdlrq6gz8l4XT7I9ioYXwv4rYguMEU70ZrbHX5+I2xB4y9XQpMDhW+RPADJK1RwSZoJswO1BdDBamF7lE4WGn+F9Ks9bYPZwx+otclomsdDzIoYE=; 5:A/4jzbjWdBLyzUC3YBCyB6V/47VPPrXUMreRAS9j2H88wrIyHOPUFwE4qo9lesxq1OixNo6p7OqHdH5w7Fa2TRiKJddF3qex8oT5z5IujhtyOp0+wexZnjFHbbAFmBCtTXHUL2zPumkW67oM8fXO2GruGWpzjr57t/A6MwQsl9M=; 24:mzc6fEa8c24pJ1jmPJ3KeLXUz0tq6j+WHxHnojw0eATW9PQAhBpnFXZ9R9fgV/KXfDK6bwxJihx8s+xf3w5eZHuo5rbrKJktVJx6Z7Hijc4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB198; 7:oVDjdqJXamvYXICekRlA85N9BfloMK/TCsXHGazpzIlzTW1j5O5Igo/FqCMWCd57eEX+aHVVJy5o5/cCCABJWfCrsgD4IZVFmKS7apA9TPTm+yRyyHkfKH3wgYzdzIPTofEOdxMj4bjSJHIAVeBA9c8IVWHzfLfqDF0yyhvCaoEvHhluO8XlQsIynX/Cegs19fYwR5eHgcOzJgP5pm3bBKgzpXV5ESj4r8xogEedOktqoxaVOmJdSyaB1OD6S1x/fyAHvvClqJ8tOc5Z5KAIUYNFh0yY2tmMnpYv8/FtM0ygFeE+Wm8pbKEc8pzRSkhgK7LIAO3kVPA0+9HbgccnSj5ONl63f+skvaqb0MInTwk= X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2016 15:50:39.2848 (UTC) X-MS-Exchange-CrossTenant-Id: 4f86cebc-57e2-40a0-86cc-01d73be93ba0 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f86cebc-57e2-40a0-86cc-01d73be93ba0; Ip=[176.255.244.224]; Helo=[email.bskyb.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB198 Archived-At: Cc: Kristian Larsson Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:59:49 -0000 Michael H Lambert wrote: > Would the same course of action be recommended if it were an > open-source project (eg bird or quagga), rather than a commercial > router vendor, squatting on attribute 30? If the answer is an > unequivocal yes, then I agree with the proposed course of action. > Otherwise, I think the burden falls on the vendor to fix their > (with respect to standards) broken implementation. Whilst I have some sympathy with this view, this issue came to light becaus= e the Huawei implementation is deployed in the Internet, and hence it would= require changes by operators to fix. Given my wish for timeliness for larg= e, I support the proposed action as the least risk approach. What should ha= ppen with regard to the squatting usage, I shall leave to others to comment= on. Ian Information in this email including any attachments may be privileged, conf= idential and is intended exclusively for the addressee. The views expressed= may not be official policy, but the personal views of the originator. If y= ou have received it in error, please notify the sender by return e-mail and= delete it from your system. You should not reproduce, distribute, store, r= etransmit, use or disclose its contents to anyone. Please note we reserve t= he right to monitor all e-mail communication through our internal and exter= nal networks. SKY and the SKY marks are trademarks of Sky plc and Sky Inter= national AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Reg= istration No. 2067075) and Sky Subscribers Services Limited (Registration N= o. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No= . 2247735). All of the companies mentioned in this paragraph are incorporat= ed in England and Wales and share the same registered office at Grant Way, = Isleworth, Middlesex TW7 5QD. From nobody Tue Oct 18 09:01:56 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945F01296CF for ; Tue, 18 Oct 2016 09:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3b-l9kzZc8Pu for ; Tue, 18 Oct 2016 09:01:51 -0700 (PDT) Received: from relay.dacor.de (relay.dacor.de [217.24.56.24]) by ietfa.amsl.com (Postfix) with ESMTP id BE20E1296B8 for ; Tue, 18 Oct 2016 09:01:51 -0700 (PDT) Received: from exchange.dacor.de (astaro1.dacor.de [217.24.48.66]) by relay.dacor.de (Postfix) with ESMTPS id 78A9BE3019; Tue, 18 Oct 2016 18:01:50 +0200 (CEST) Received: from ex02.suecdacor.local (192.168.1.16) by ex02.suecdacor.local (192.168.1.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Oct 2016 18:01:49 +0200 Received: from ex02.suecdacor.local ([::1]) by ex02.suecdacor.local ([::1]) with mapi id 15.00.1210.000; Tue, 18 Oct 2016 18:01:49 +0200 From: Julian Seifert To: Kristian Larsson , Michael H Lambert , IETF IDR WG Thread-Topic: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) Thread-Index: AdIpUHjFMTMxey+uRgusubexAa1gwv//5rmAgAAD5gCAAAE1gIAAI9Bx Date: Tue, 18 Oct 2016 16:01:49 +0000 Message-ID: <1476806492333.16025@dacor.de> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <20161018153047.GJ95811@Vurt.local> , <85865e76-c48f-1164-2602-1ace0a515a30@dev.terastrm.net> In-Reply-To: <85865e76-c48f-1164-2602-1ace0a515a30@dev.terastrm.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [88.133.178.43] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 16:01:54 -0000 Hi, =0A= =0A= Kristian Larsson wrote: =0A= > I think the issue is that we might have a lot of Huawei routers deployed= =0A= > on the Internet with this code so in practical terms it's probably 12-18= =0A= > months away to have all of them upgraded to a version where they will=0A= > not drop prefixes with large BGP communities.=0A= =0A= I think 12-18 months is even too short of an estiomate - it's hard to make = any predictions about that=0A= but it might take a significant longer time until that happens.=0A= So I see no other feasable way than to allocate/request another =0A= numeric attribute and continue from there.=0A= =0A= (While simultaneously the vendor in question should be pushed to =0A= fix his implementation anyway)=0A= =0A= kind regards,=0A= =0A= Julian=0A= =0A= From nobody Tue Oct 18 09:03:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612341296CF for ; Tue, 18 Oct 2016 09:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 maAXT9NRJBtW for ; Tue, 18 Oct 2016 09:03:30 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3AC1296D0 for ; Tue, 18 Oct 2016 09:03:29 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id A7F20788F1 for ; Tue, 18 Oct 2016 18:03:28 +0200 (CEST) Date: Tue, 18 Oct 2016 18:03:27 +0200 From: Peter Hessler To: idr@ietf.org Message-ID: <20161018160327.GC27221@gir.theapt.org> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <20161018153047.GJ95811@Vurt.local> <85865e76-c48f-1164-2602-1ace0a515a30@dev.terastrm.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85865e76-c48f-1164-2602-1ace0a515a30@dev.terastrm.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 16:03:31 -0000 On 2016 Oct 18 (Tue) at 17:49:03 +0200 (+0200), Kristian Larsson wrote: :On 2016-10-18 17:44, Michael H Lambert wrote: :>Would the same course of action be recommended if it were an :>open-source project (eg bird or quagga), rather than a commercial :>router vendor, squatting on attribute 30? If the answer is an :>unequivocal yes, then I agree with the proposed course of action. :>Otherwise, I think the burden falls on the vendor to fix their (with :>respect to standards) broken implementation. : :I think the issue is that we might have a lot of XXXX routers deployed :on the Internet with this code so in practical terms it's probably 12-18 :months away to have all of them upgraded to a version where they will :not drop prefixes with large BGP communities. This is a bad justification, imho. The number of routers deployed is not relevant. That the code shipped to non-testers in a general release is relevent. _And_ that the failure case is Withdraw, as opposed to Crash. If this was just a crasher for vendor Y, I would oppose a renumber. I reluctantly support a renumber. (I'm an open source dev, working on OpenBGPD) -- Jacquin's Postulate on Democratic Government: No man's life, liberty, or property are safe while the legislature is in session. From nobody Tue Oct 18 09:05:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C816812945E for ; Tue, 18 Oct 2016 09:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Vc7RwKD3Jf5o for ; Tue, 18 Oct 2016 09:05:46 -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 021071293EE for ; Tue, 18 Oct 2016 09:05:45 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u9IG5fL3016087 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Oct 2016 17:05:41 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be cupcake.local Message-ID: <5806484F.5080006@foobar.org> Date: Tue, 18 Oct 2016 17:05:35 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.4 (Macintosh/20161007) MIME-Version: 1.0 To: Susan Hares References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> In-Reply-To: <01f401d22950$7f988470$7ec98d50$@ndzh.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: 'IETF IDR WG' , 'Kristian Larsson' Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 16:05:48 -0000 Susan Hares wrote: > IDR should recommend that the following attribute numbers be deprecated: > > BGP Attribute 30 > BGP attribute 129 unless this is a temporary deprecation, I'm not sure if this is a good idea, as it could be interpreted as sending a message to vendors that squatting path attribute code points will result in being told, "that's very naughty and we're going to punish you by ensuring that no-one else gets these numbers, so don't do it again!" There is an objective problem here, namely that there is no vendor-specific range for path attributes. Given the nature of path attribute interpretation, it could be argued that this might be a good thing because different vendors will interpret TLVs in different ways, which is a potential source of bgp session instability. On the other hand, it means that if vendors need to go off and do something new, there are no options other than squatting. A vendor-specific range will at least contain this problem, so that IANA won't run into the same problem in future. On a related issue, it would probably be a good idea to run beacon tests with other path attributes to see how they affect reachability, i.e. have any other vendors squatted any other path attribute values, and if large-communities is moved to 31 or 32, will it suffer the same problem? Nick From nobody Tue Oct 18 09:28:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C76F12945E for ; Tue, 18 Oct 2016 09:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 13DyAXQ028mS for ; Tue, 18 Oct 2016 09:28:11 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EB4C912943F for ; Tue, 18 Oct 2016 09:28:10 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 37BB61E1F0; Tue, 18 Oct 2016 12:30:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Jeffrey Haas In-Reply-To: <5806484F.5080006@foobar.org> Date: Tue, 18 Oct 2016 12:28:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 16:28:12 -0000 Nick (and others), > On Oct 18, 2016, at 12:05 PM, Nick Hilliard wrote: > There is an objective problem here, namely that there is no > vendor-specific range for path attributes. Given the nature of path > attribute interpretation, it could be argued that this might be a good > thing because different vendors will interpret TLVs in different ways, > which is a potential source of bgp session instability. On the other > hand, it means that if vendors need to go off and do something new, > there are no options other than squatting. A vendor-specific range = will > at least contain this problem, so that IANA won't run into the same > problem in future. FWIW, there's a lot of discussion related to this in the RFC 5226 bis = related discussions. Part of the issue with vendor space for standards features has to do = with renumbering issues. A short summary of the prior discussions: - Vendor space makes it easy to prototype. - Once you get a feature beyond a certain point, if there was a = particular first mover, one basically is forced into using that vendor's = space. That makes some implementors uncomfortable because it's under = the control of that party. - There's no strong incentive and several disincentives to renumber = feature code points. Historical example in BGP-land, why SAFI 128 is = used for BGP VPNs.=20 I believe the bigger discussion is how you handle early code point = allocation and, more importantly, versioning features as development = continues. > On a related issue, it would probably be a good idea to run beacon = tests > with other path attributes to see how they affect reachability, i.e. > have any other vendors squatted any other path attribute values, and = if > large-communities is moved to 31 or 32, will it suffer the same = problem? Even passive monitoring is a good start. -- Jeff From nobody Tue Oct 18 09:35:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53D91200DF for ; Tue, 18 Oct 2016 09:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 LY4YK1qANb8p for ; Tue, 18 Oct 2016 09:35:19 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0095.outbound.protection.outlook.com [104.47.32.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEAC0129586 for ; Tue, 18 Oct 2016 09:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZXU0xj9e7GTixqXJ5PnZxngigUQk1NTqsQeVX8axpoU=; b=Gicn5/7mjUG0800+1i3NKEpuyOunc79tQoBNyJpwTosmdmFPS1Bui4sRw3dcUbr9VG4zm0g0FS8ee+6KJl3JYjjZBXlWqMnA6y5gtzRvF1xQwuYa/QSw22uZty1s23CwhPkAKSuNBmzc7gS1A5bWOBV0mqI8xPKZH1YBsXLbga8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.34.170] (66.129.241.10) by CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Tue, 18 Oct 2016 16:35:17 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <5806484F.5080006@foobar.org> Date: Tue, 18 Oct 2016 12:35:08 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BLUPR0601CA0033.namprd06.prod.outlook.com (10.163.210.43) To CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) X-MS-Office365-Filtering-Correlation-Id: 88374dcb-6fa3-4e55-59cd-08d3f774bed6 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 2:GVcD7vDZ68QwkJO+NyRwW+93i/dKhIaojT1LioimtBc+uQ/kP13VeElHZbj9ezjaY/dsW+QTmggFTCMB6porfGzHezR6cB0gAsOu/XjpbgZS911Bc639V4MmgTJnuo7rcMIhqdv+jCUP7zyLMOy58o2zBwWc5MsTbNd95tItH2jzg2DkhKgiM0+vTwUePn8HJyjw1H6J41YV0/+3Xh42zg==; 3:Ey1jXulcK5L/czYzheT1z8KXhg+Gf3w7pGoBhTxsRFkTZwpTXqWy0YU4jzHUmSIWgR4GKqXfzsWM9LmbBYj6Jd4mcrYUh/kpe/ternLUJ/uyGJLMJO8ujHlZWJ9IwVrWQYiVRHnurn/gOBz292W4hg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2505; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 25:u4GQQxMg/W05TGsExOtZPoRGMPh5M6Wfr6A7EY4zZJ42kvh1c7M6BJO1mgNa66bjsE0TVWQrjIRG7imAplW9myWpZf71okkMKR106VPj41G5zForz+2ZOrLz69USFrc6uKfN4dcNnJcfujS9luYdeIKPpHSVv6PCwCTvsAB7DKnKyN9KqBh2H64B8ZwZGWYZKVBk4SHmZ6XYPPYWn5GG9faiK0ARtoUpb6OZnYrYJ9Y7nadv6KQROF7HOVxXbbVxGrSR9QqT80rLxSxu5r/7ylVczAi/IHgNEqDTjwJEZwp6wRuI1Bt173nBAY5EaDM/TMMLPsHcbQzgKpPFkJcfhxZWJMRUpxxJO54cLIVrPdJ3YCJOuC56LoX93Hpb29JoOzEhsazfEFKGAXloV15frn9TIXG9EkD15ksgEaHwca6ntkv9XzRWKPCMyrnFiTlunis/s5usM0ReYW2tkSIpXJHj/yrdQHmpKkDMFUYWcaqhko4q5GzPt6ABrLcgIYcV+4Vr/juTUU1D8QU70vkVn6QS+tlT4lCre40H28EIXoVeGJvdYER+svpZCGLU/PWnPR2o4Me0D2eF3oXoCD92EhX31YEb+uheRqOJl84/SGb2mUXT+N1OQgILK4OWAnAtdjR/Sae83CnC91I6bp9LeSxxozUnoLZrJD5x2pL21XjXvx/OXQzoTF0B+U79TZRUFzoDKK5I2HR77C2QPhxlBKg/HAyqZwh1kcGHul19KL8= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 31:i+47/NonM7lPWFj5q/EExp11gPHVjT+4FliD6RTep2HsMP1CKT0SuqZXqAiZpuOtuM1f+SubHyBnJYIQZp3iQIIBdx2T7PQWes0q5UBman+B5GBFqIJxSnJHP6h3NILzKuYz/7ams1lbWBAYnFJecQeMK2qY7oWPdcTljleDFLo6gsb8HHb8FrLcUchIbpIyapK8ZgGnm3PdWwGRnm8nrXTRb4GFQrBHgkxSn7XmGZzmjydrsH6J7MECfMssJ8Ur; 20:xsBcCnfpvSqLa3M7bKUIo58crkupEBzdIORGuPsLTs5SJIW4uXjuERFvTlzLVUkh9uqY/CPFBMwPO029FzQBkzKCdsg36FifJaWyiuLXo77fJF+b1kVthrhWRUt6C9egNa95lV6z7b8YaAKBf/EZgpPZX/qO68XYkYWkTmQERX9ePtZyxbkkyvt/tyt4SdNeidoGxarvsYUdroMRlbmDRVJKMpTWNmpMwqtMskgBMqYJxLSB83COOTLCfGuy6TCNT087t3gF0p/vH5Bg8DI0ah7yEKGvjMbtNpKioc4w4/TzHkdI9O26wJczbXu30RKs3KTGWs2bt8GuVsFK3gmmNE5+qYheON9seQsbNXPC1JpczBa/tD/ikMRYTNCZ+atqPZUvM1Nl+zj0vL2ybqAfpuaKaLQ9AoiT9pyJ8rqfidBIOpk4wdcNjabyJSquIWzEDF3LFycd6rjeuy9tD4RDDKxUmvorHPKOFUQN4LAda5JyLhCghS5MaH8YPRvGITsyswoCB+OEiKccMRrmqIFJKRGMe69ZP3AARyTn8muemDgKB9oJcDC30VkTiu3Dyd18KTUInfeMC2NhSI7zh03DCsUyz9JhbugAKYPXfrfZp5U= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2505; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2505; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 4:oY3cne4VeKE8K/mWkjOWkbTJy9bsO7tHykNM55KRE2yvRfjQHaqEe/cMeQAWpBfo+nJXf3PVvMWHW3/9fIpqw0kw3+SBCONus1HWy0kZBevuQ+eeFZ0s8/FSGo+8hBgTJlpXIH/IpP9JhzQ63hEFMMwMRjhONZRk1QPTGNbcNDp8IB/q553Oswk6AHmB5zz71lnDR1ng+BN9HboJnE6pbU53zmiFtMSJQDmjP+V/mezVl4QJ0Rkg1M1hBdpuax35YygYNid9r0F64TxERylNXJjjs0ILA1MQoGuX8NGwPrKroEzmA+p9FQwWLxfLGfnRJcfUUjYusM0hZ9eMJdSULn3RQaKgtaz94SoLlooH6b5moYsjZh3AHzW+7eYzAw8kT7IVB/T21NacPFUdsjO12I6TpbtQ0n6w8NuAA18wO9Q= X-Forefront-PRVS: 00997889E7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(24454002)(199003)(377454003)(8746002)(50466002)(50226002)(82746002)(7736002)(305945005)(66066001)(77096005)(2950100002)(189998001)(6916009)(6666003)(33656002)(19580405001)(36756003)(19580395003)(586003)(110136003)(83716003)(97736004)(81156014)(6116002)(92566002)(7846002)(68736007)(97756001)(3846002)(23726003)(86362001)(57306001)(8676002)(50986999)(47776003)(4326007)(5660300001)(42186005)(101416001)(76176999)(105586002)(106356001)(46406003)(2906002)(81166006)(141353001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2505; H:[172.29.34.170]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2505; 23:2jjklOeBIjXpQbMWlKdTwvtJ2TLkXiudbhXlFgtdh?= =?us-ascii?Q?/5ZYgjcK1RI3eHZq+TIgZJRdCSfbR5j62F1Azz6EXZxNg/jkdiWFnYBQ9QAi?= =?us-ascii?Q?XM7V5kw/DPmwF2YqhEX1hPrmS+Cy24eQFMCXGqCZkIQ/9Q45uHryg6PUmGaj?= =?us-ascii?Q?eIvrWFVvcnPcBd5h7inlf4b8vR5H3C4jqTSsD3bjHSgQ/RxGHPW8NnhnkCxR?= =?us-ascii?Q?V8vwtorhPAyi/IdMljG+PEPTCsfxk2aOQZW5n6fpm4dzBbUuxpMc1hGy9t5L?= =?us-ascii?Q?6xYGU/xvQOD2Mgl4uLcbW3VOPj5MqRUtnusNnUJtAJ3F1asOyesNAR4cheJC?= =?us-ascii?Q?VagbvGoC8IbFdMJQip6WtcD0Q5iwclJqgWzR+Dy1bWU/nuHp6AD1ibUSFMQZ?= =?us-ascii?Q?4KIKI9WUBJKdsIgjo7sR0kCLVoXTod+tYPQ4TFqCf6kWZnpj5p4ribx1fywD?= =?us-ascii?Q?Ku3M7GFCX080QHMMCMg2nGzoPLvULflIR/RvbcbeCP1JQbtLkzJ1ka6i0RAq?= =?us-ascii?Q?pSeGBxD1TqO9nRUCAnerqLk5k2mrOalzraMst8wUyvmt7HAgtKJUf3ahk+PN?= =?us-ascii?Q?N4icTFysAz3Dq7fa8rxlAm6xkK7eYLrHrpkn/KnU1CQcyNp8l4PGh9xeRmOY?= =?us-ascii?Q?DSLeFAeWbZD/+4z0rFmT47zj02X5sWu+do/+c0zbLFzyFzMeF34Sx3gtGCY0?= =?us-ascii?Q?x8c0S4rzMs7dpzTsvQrLh6mqTKC7PQx/Ykk4RRcRkpwti8Moa6Ux6VdroBNq?= =?us-ascii?Q?mYFVQk2tLYwYRzjQlVEo67Up2z8ImvUMISb5tmPS85wF5oCPc/kGGIQE1G8Y?= =?us-ascii?Q?LzL029JR38QSdfTdpk0CSapJOj7VIQLvRtqrDDCIm7rA9AJdT/Pil3wrarPB?= =?us-ascii?Q?OXuDsWjMM3etJh32C9uQFiDZWJDb5P3wrkxrUJKFkj1FCqpOWyxO2JLfMkpx?= =?us-ascii?Q?tQYO5JZ6z7SIB/H/jgzuvLK4QrpahemaTEIc314Wvg0INVnkdVa1o31vMLlf?= =?us-ascii?Q?IgV9Mxl+pyjCbmsrpLoDDB2FABRQ1kQs4QpDVcvO3l6h3FLVqlrdWWkXobu4?= =?us-ascii?Q?v/K52DHeCe06LlrwHs/bJQu5Pb+FVVI6SvAVnNN5IT3gsBw2mRRJ2SJvGCaQ?= =?us-ascii?Q?Qre7qEjwzeBjK+4hPX49sXf5jpSuCzIdsdbNneaq6p0o022yu5gyp42XcgG9?= =?us-ascii?Q?lWksvput5J6pGeS3GKn0UqEz/WmDYZp2powEfyjRz0Pur5bkFhkwHhHLqUFd?= =?us-ascii?Q?/waEtIZI0LLdUmRrF/WAYaQQ02iXT+dKhTLGMCn?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 6:zDFVMZCxOJpbZcZIMadvcGvRo0+FFt0fR+RXNxoiyKjfJP8A7SQAWM2AjhC4nO0+4ZfkCFZZU6d55aG2Hr852ZpBWD0Vbon38gKbwDFWj6+ZL2E0EmLDDvIayjSR+pEwy1Bs1Ncv6UOGSBw58xYmXa9cC6U1DXezg84Lm/mUGjZy2p7nKtAIouSnYrsAFewNMHu9Je7Gq9nR8k+19AyTTr+In0oaRl/SbKjxU9JoMD7PqM3iHFi7qcTNTyDDmKWJtz0/onlZStXhVSewXC3CTOvY7fwCHTNmT4b7i7yHOOjae/oWCiLrVfxlR24+C1REur4JbSx4Ig366OJ03q0QT5GhduJOuMYrKoIGoXDrP54=; 5:D4DyQEAlB5v11JGn03h0F6fVKGA2IAiaUYBujBuGH4kpxCXnmqhZG5xj6KMHDCOo/oMpIltxeyDMPIkbsEmBp5yADiDqWgxpcYOvV5FvfYpVaviqeAe9j1EeD2nP9pzoe7IsbjKcD0cQhxmeLtWvtLyP4zy2XCpJgKhG1rxMbBU=; 24:b4u5+M4oAotUMZuf2EF9h/eb/7bBuJQu9WSSrxIkNlSiBnR1CP29kJ3s5AjpmqCChvtBO3w1xs+ucbto7w8v4cCKpDVmL2hHm7HLznhNSLQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2505; 7:qJs9T0qquLuLnuQjCd34wY3+raxiXtN3T0QGxXn8uDy01meqi7AXRHN65CdzmGdRi4H/aGwXuHuOH4ipHNGrY6nQd1vv4+P61ZWH/RpyRJIHZUYePMuxdyguQmENSVJJ4agpRy/NGleL/Il4W2uNwkxLuaG0MvufwEEacZTV0PQ/HZj83mQulXWQKvc9g2tlUASdyOhw7PHlSXuylFdEoW076BMQDVYajYonS98oB7avvjMC/13r6pJEzzJUZa3mzZKkZ6YSxvXHp82HRE2mknn8XjNaAoLIbHYiH8ka9E0ppGeOK/aiEJ47xRGYfmDCvrD4DSZeOevAPpX1FG2o8f4YJA36JV0u3hDv32pTicA= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2016 16:35:17.2361 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2505 Archived-At: Cc: IETF IDR WG , Kristian Larsson , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 16:35:21 -0000 On Oct 18, 2016, at 12:05 PM, Nick Hilliard wrote: > unless this is a temporary deprecation, All deprecation is temporary. It means "you shouldn't use this, and by = the way we might reuse it for something in the future" where "in the = future" probably/usually means "when we run out of unused space" (modulo = my earlier remark to Jeff). Deprecation is therefore the first step in = reusing a code point. I looked for a supporting citation and didn't find one, though. :-( --John= From nobody Tue Oct 18 10:16:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4824126D73 for ; Tue, 18 Oct 2016 10:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=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 TrYidVCJMeLg for ; Tue, 18 Oct 2016 10:16:06 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9AB1296F8 for ; Tue, 18 Oct 2016 10:16:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.187.221.190; From: "Susan Hares" To: "'Jeffrey Haas'" References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> In-Reply-To: <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> Date: Tue, 18 Oct 2016 13:14:21 -0400 Message-ID: <001801d22963$11733630$3459a290$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01D22941.8A631CD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxOA6e5ti/ZI3ng6LJlnwAiipARgGREBAWoOPNOVA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'IETF IDR WG' , 'Kristian Larsson' Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:16:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0019_01D22941.8A631CD0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jeff:=20 =20 This is a good idea to just make 129 an early allocation for wide = communities.=20 =20 Sue=20 =20 From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Sent: Tuesday, October 18, 2016 11:19 AM To: Sue Hares Cc: IETF IDR WG; Kristian Larsson Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) = was squatted on - Let's get a new attribute number (1 week WG call = (10/18 to 10/25) =20 Sue, =20 If 129 is not otherwise contended for, it may be reasonable to simply = request early allocation for the wide communities code point. =20 -- Jeff =20 On Oct 18, 2016, at 11:01 AM, Susan Hares wrote: =20 WG:=20 =20 Early testing of the Large Communities draft = (draft-ietf-idr-large-community-03.txt) with attribute value of 30 = detect that we had an implementation squatting on attribute 30 by a = Huawei router. =E2=80=9CSquatting=E2=80=9D on an attribute is = anti-social behavior in the Internet in any release of software. =20 =20 The individuals who did in Huawei have been contacted by Jie Dong, and = =E2=80=9Casked=E2=80=9D if they had made this mistake in any other = attribute. These individuals confessed to Attribute 129 (for wide = communities). These individuals apologize to the Working group. =20 =20 Now what shall we do? The large community draft is critical for several = networks. After talking with the developers and operators, John and I = would like to recommend we do the following:=20 =20 IDR should recommend that the following attribute numbers be deprecated: = =20 =20 BGP Attribute 30=20 BGP attribute 129=20 =20 IDR should ask IANA to assign BGP Large Communities (currently Attribute = 30) to a new attribute number. This is a 1 week call to determine if = the IDR approves this action. This call will allow the large = communities draft to still continue with the 2 week WG LC. =20 =20 John, Alvaro, and I have check the early allocation rules. = Implementations should ask for early allocation prior to releasing, and = they do not need to be interoperability testing to request the early = allocation for the attribute.=20 =20 Sue Hares=20 =20 =20 _______________________________________________ Idr mailing list Idr@ietf.org = https://www.ietf.org/mailman/listinfo/idr =20 ------=_NextPart_000_0019_01D22941.8A631CD0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Jeff:

 

This is a good idea to just make 129 an early allocation for wide = communities.

 

Sue

 

From:= = Jeffrey Haas [mailto:jhaas@pfrc.org]
Sent: Tuesday, October = 18, 2016 11:19 AM
To: Sue Hares
Cc: IETF IDR WG; = Kristian Larsson
Subject: Re: [Idr] BGP Attribute for Large = communities (Attribute 30) was squatted on - Let's get a new attribute = number (1 week WG call (10/18 to = 10/25)

 

Sue,

 

If 129 is not otherwise contended for, it may be = reasonable to simply request early allocation for the wide communities = code point.

 

-- Jeff

 

On Oct 18, 2016, at 11:01 AM, Susan Hares <shares@ndzh.com> = wrote:

 

WG: 

 =

Early = testing of the Large Communities draft = (draft-ietf-idr-large-community-03.txt)  with attribute value of 30 = detect that we had an implementation squatting on attribute 30 by a = Huawei router.   =E2=80=9CSquatting=E2=80=9D on an attribute = is anti-social behavior in the Internet in any release of = software.  

 =

The = individuals who did in Huawei have been contacted by Jie Dong, and = =E2=80=9Casked=E2=80=9D if they had made this mistake in any other = attribute.   These individuals confessed to Attribute 129 (for = wide communities).  These individuals apologize to the Working = group.  

 =

Now what = shall we do? The large community draft is critical for several networks. = After talking with the developers and operators, John and I would like = to recommend we do the following: 

 =

IDR should = recommend that the following attribute numbers be deprecated: =  

 =

BGP = Attribute 30 

BGP = attribute 129 

 =

IDR should = ask IANA to assign BGP Large Communities (currently Attribute 30) to a = new attribute number.  This is a 1 week call to determine if the = IDR approves this action.   This call will allow the large = communities draft to still continue with the 2 week WG LC.  

 =

John, = Alvaro, and I have check the early allocation rules.  = Implementations should ask for early allocation prior to releasing, and = they do not need to be interoperability testing to request the early = allocation for the attribute. 

 =

Sue = Hares 

 =

 =

__________= _____________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 

------=_NextPart_000_0019_01D22941.8A631CD0-- From nobody Tue Oct 18 10:25:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7A31296F8 for ; Tue, 18 Oct 2016 10:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 wzjuNvjHbD0B for ; Tue, 18 Oct 2016 10:25:40 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4A51296F2 for ; Tue, 18 Oct 2016 10:25:40 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 48242788F1 for ; Tue, 18 Oct 2016 19:25:39 +0200 (CEST) Date: Tue, 18 Oct 2016 19:25:38 +0200 From: Peter Hessler To: idr@ietf.org Message-ID: <20161018172538.GD27221@gir.theapt.org> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:25:42 -0000 On 2016 Oct 18 (Tue) at 12:28:09 -0400 (-0400), Jeffrey Haas wrote: :> On Oct 18, 2016, at 12:05 PM, Nick Hilliard wrote: :> On a related issue, it would probably be a good idea to run beacon tests :> with other path attributes to see how they affect reachability, i.e. :> have any other vendors squatted any other path attribute values, and if :> large-communities is moved to 31 or 32, will it suffer the same problem? : :Even passive monitoring is a good start. I just did a check of the DFZ, both IPv4 and IPv6, and these are the unknown/deprecated attributes on paths that I can see. 20 Connector Attribute (deprecated) [RFC6037] 21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit] count type flags len data in hex -------------------------------------------------------------- 43 Unknown Attribute #20 flags [OTP] len 14: 00 01 00 00 58 d6 00 00 02 8e cf d2 8d b5 2 Unknown Attribute #21 flags [OTP] len 5: 02 00 00 57 da 4 Unknown Attribute #21 flags [OTP] len 5: 07 00 00 2d c8 2 Unknown Attribute #21 flags [OTP] len 5: 14 00 00 39 72 From nobody Tue Oct 18 10:25:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153A9129705 for ; Tue, 18 Oct 2016 10:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 n5_NyPq0QzWX for ; Tue, 18 Oct 2016 10:25:43 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0118.outbound.protection.outlook.com [104.47.33.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89988129666 for ; Tue, 18 Oct 2016 10:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+nom8fgZktgbj7EHLXenXwCsfAhJ7LBa3T02a/LrFpU=; b=cVPMXVVCHKnzbaSdLAiF25WyDpR1cI+YKjjRAhQ7NZOPuhTZBaw1w1y+mfkIzIWRRXnELHyc8LVKAc4hIJ/vUJ1urINWfu12w5AqSj7N3mrSPOVC1SFECTwN78D6j9fA6noMkwx9/itr05Ovd2Dzbh8ou2aYdJQulKQzczCiTgI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.34.170] (66.129.241.10) by CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Tue, 18 Oct 2016 17:25:41 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <001801d22963$11733630$3459a290$@ndzh.com> Date: Tue, 18 Oct 2016 13:25:25 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <019F0FC9-6751-42CD-BA26-3CB0B374748E@juniper.net> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <001801d22963$11733630$3459a290$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: SN1PR17CA0050.namprd17.prod.outlook.com (10.163.3.146) To CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) X-MS-Office365-Filtering-Correlation-Id: 33373418-ff58-4829-f1bd-08d3f77bc952 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 2:uhq6tFYbnKrX/vcVhqqHmOl1hzLlTjMRMadZUEDTWGKVUWR1KD/dCgRBvWRLB13wHll8S5qPBhzwAmylj1b9DWKaPLyBeV9RAm6WqBbsiQG4ubxq1rhp7Zn38SEkwh+izOKz9q3uLpyNMxaMbzioOhymJV0UQ9S4ZlPoyrs1gb0JrnlSin5fAsfiSQtjtZwAVwSJwMvlKTUT9sdvYAxcAQ==; 3:CHYuKcio9PBYp4hCv866A4fgIXUirPv/i15g/cS2wQT8bJT0K0ZH47vmS6SAKbxKflifTZv3nb67plm/Q6UICLyC+6YTb7qTVawX6AYXLXIfUQaFLNDZu5tsgZ227v1kg/f98VzfAgUmsIHFkA7MBg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2508; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 25:mSPbAeetWMO86/S/TouWQxUGQgOmfV/cD6VCcavt0Im/8l93WqqC7Q6hnQlCvBfSvuECtMjq2rhLoH0KIpjBj14p87d9lWkKtp3+aRUtVJ63hbDmd49Oe99wZUxceC6OO9T1bTgDYWvVDDDuXbao6iQ7fvxiYfE7SwrAW7CVueNImOEvSgfC8JmcPLzTYQ88U/ttco9zCsj33A0fN83odz36D+DnbghUaGb5suMGk6FdY14mnLP5K58fppNV6Yu5qFEfJzQar/btOWeEkRKm6s3N2iViwEI6sY+nq9ZvZRoT5/3AmLNBs+2z4SAyTwvZ4B2o84Dlsbh2pfO/rnFsbbkw+w8aNPn7OsAy5xbeKcfB4A+1QLggPJvOdu7uCGlv1Ib39Z/SvhmLA9s29SwR/U7x+S2HOiHRvEgRlRb8nCFWoZL1Jl/6A4knH6AgpXYdd6bTEetbPR3JmooAH9gXClu1dDENUI1oEDbcTquMYUYxqQnwUpIFJYvhswYzM13kbBZ0HwMjEUQtJ74Qsuoloes5fYqDDyxSoSoZh13wkvs7yPla6SuEvluQf+IMBjGKK4tRspqkyfHXDm6L/HNuZ4FtMVh+vAk5NBK361adGEhNXrzcVnyVafwQjVCdhm8FPEw/iKSzr+ji6MoW3Lh5U81KYGWATsKVkZQjg8pLgfcSO0sonkxTAKdYfRF+Phoi9PJpBhEjBoAksE59EbE+DojMu8kDkIwVAV01/vSaOvOAKGkdvaWxN/e7ZjmJfRovcySz4uW8Syzkp+EM1jR4+libpyFbsetxixZXkrRfSsYUzM1PnAsLrUcsRC2BvmMT4UKvUeiTmBv5x1Ux3UTJLts1+XaC+Uf4p0H0enxtE/M= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 31:vTlklc5gOH96+6XgfSmrIQunao4vKKkhpIro/vqftSPIvIuFmZpjnPRoZs1nCG7ROTlMmtCcv75ySvnsmEbqpfBTjhCVRQRs6AI37rL+4xoLP/G1zPXPSVjMTDs2ABqk3y7SQ91A5z7p1mmS+ZcnQPrvDfxuw1pHL3QhJGsWo+S2zRs/zdWTGFMpOJYhzIKIujb68u7VujbPcIV4spIrQqnkzTIzeuINifh2FEApYmdkzXRmRLprX1gUdrhgK+3t; 20:vfDMqPKJhncvWd8q8H3+eqmHan95NUyNUB3qmmifn+nWa8ylG4Yb+UGoLcx5FOMCxS6tA15xOhpL4+FJ1xjnII/0RsujKIeY6405e0VGUMnRirovFmR5xtPEgNmxiCTcZXdtU+XdVGVLU+21cuKKvIu5wXaD2qrQGV3Bpd1r9J3OgmQi2cSH4+em7O+4mtaEX768FUjWAWHXS3NOxLT9pnQOrbT6SJqlluOSeCLbVKRqxPbJT4pn1hunQAU4AEU7ZyefjwyApzEoxvgwPddaXkZNxNaau8C+oacIlSRMFlfmqC+4T5Rxzy3ov+PDgnocgNKQ2xiuukVXW7yXtS10mE1DYN2dYzdCbiJZ5XdWbn2EvtvKUxNdNYs5xdaydmfg+5ZVbrIBIvQB9HnPfShffy4s4DYEUrEg+2hEKZpDgE14XaOo7o4gakGILx/1K8JILWwIAHU6EpoL1pUmfeb4hjH492etcROU9Z4SZpQ7Lp18ncBFfPEYvyDkfZ9zuIwDrba3HvPl6hz1uuSm9khXQg7H29e1w41gKi9NtDDER6MS3BbpswaCP3AWhUJciAGju+sEpRxjD4cX4VC/RCMFG3bxGz3ULMWTfUnSZikjv5U= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2508; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2508; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 4:lCmV8TztntQgKuqz76ry5rbsx0wye9od/D/RjFxdDBChNI6Y4XFSuEJQMsRFR3f/Nmxk0TEe921y9dy8OoBnAVAm/xte3k9oHKQSRrMUf0cK8/4k40gLIqZBX7RsJI0FF3W75RCQls5NsUZQLRdZTo1VKypy5/ihc2t6pTDdiSEXryYjYCigaJpjEf2GFBIPR7xdLE7TowgajuEAysqkwObJtHAzZPDCMLi/3qR22plZ7p8KckM8RHDFRLirov4VbP2bWpFiDFDl068sO3NNmBtyhIGhDb6pXoiwXWVIAnKKGhP63Mui3uQigqqFiTo3GMjH3T17vIEgwaAJbpqw2S7SAWWjQfh85T9D5pTcsVppwotnpyYhJWzZTlLesOgR9v0+fDM3L4z9EOJvAmVk5Kxr6U/6wlta5gWtD+Qlt+I= X-Forefront-PRVS: 00997889E7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(189002)(24454002)(377454003)(8746002)(189998001)(7846002)(229853001)(106356001)(6916009)(2950100002)(6666003)(305945005)(7736002)(15975445007)(77096005)(83716003)(76176999)(5660300001)(50986999)(19580405001)(3846002)(586003)(6116002)(19580395003)(66066001)(33656002)(82746002)(50466002)(47776003)(105586002)(23676002)(42186005)(101416001)(36756003)(86362001)(81166006)(4326007)(2906002)(68736007)(92566002)(97736004)(50226002)(57306001)(81156014)(8676002)(110136003)(141353001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2508; H:[172.29.34.170]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1TUIyNTA4OzIzOndLNzdQc0NxNXlVR2Z4b1FBc0VsWUhMVFF3?= =?utf-8?B?c1J2OFh0Z1ViOHNXenJEdHc3SFR5MVlpVzRrdnRhV2EySGtUcWF3WXpiRFlo?= =?utf-8?B?UGRDWllHV3djdm8xek90TGZkT2hJdG9ETzVVdEtCSlBGL3dpMXFhSkg0c214?= =?utf-8?B?R1FSQ2dDTDM5ZWFxOVNsTFlWWVl4MmxueTg3dnRWQnY0bW1GSGxwTTY3dXhq?= =?utf-8?B?ejhLVFFWTFRZMEZFbTVTNjNibmdHNXFyUS8xZEc1eXhZMWRVWDFmTVBjUzJZ?= =?utf-8?B?TnRQY0E1S1NWMWNEWFBwVnFnLzFEb3FMeStsNGFrOHlsS1FvSjJkZnJrSGIw?= =?utf-8?B?NVBpLzdMWGgzTTQ5SVVyYVM1MnNjeG5yVnEyZ3poVTliU2U0T2hKa0ErN3Ew?= =?utf-8?B?ZGg2SWo3WE4wMVBPclZZNlArcnpnRkQxMUFiSGp0djhrbEJ0YnljSHBsMTRt?= =?utf-8?B?T2s2NGE2Z3BBUnJ0bHBjQ0wvQUN2YW5LVU8zOExDRmVlUjRSdXY3bE5HRTBC?= =?utf-8?B?aHg3QlRNemJEdFBHekRUWG93eUJaVVlPdEs3V0xjbHhySzVteUYvbjk4NFE3?= =?utf-8?B?a2VoRTFMaytCYllkNmg2RWFJYTkwTnlybGhiaU1WWDdFZXJkdzJPcUN5Rysx?= =?utf-8?B?RkdQVG9tMzVtam1ld0tTYmcvY2Q1MjhoN0ZnWDkyYlpQWWY0QzB2a1BVRVl4?= =?utf-8?B?Y0tTRnY3aStlcFhaK051b01iSk50cHFNNTQwSjBpeDVWK1hvMzRXK3lVcHZF?= =?utf-8?B?SEFCeTB1UEhqNzBxNTF4ZnVJWlNQdTJNK0RnNC9FWTdzVFk3aXp2R1o3b0Mz?= =?utf-8?B?KzIwWGtOK3lVYTZabks2Qm1EdVBEdWF2VDJRWlFoUkNpRnlXQ1QzZFBFRTRG?= =?utf-8?B?bWJrcU5qOHBuYVB6dzFBbEtTL3hmbHJ1YWtWbUptK1BXNkRkelFhbDBQb291?= =?utf-8?B?UFZIQ0dUMXpyY0VsZ0d3SlQ3UkRrbi9vNlluNGVkak1OQ0doNjFTVHZZWTRI?= =?utf-8?B?TFhiSGRyY1RIaEJvR005R0VDaHYrWDdCUkVqb215SzJKK29CUGJhV2VwVG9C?= =?utf-8?B?aWdxNFM1TnN3MlVEUUprdnJnbU5MVTNqeHdqVEZJQ01PV2JLM21ObWlUU2My?= =?utf-8?B?VHlFUjhtb2laVFMxM1pZeTE5VEE4VmE3TGhlTHViT2FNb21pZnppMFNtaFdw?= =?utf-8?B?T2lMV0VmemNidy9aMlNVTWhMNDc2ZU85a3I0S2Vma0dqaXRxTUpBZFpDOWRa?= =?utf-8?B?eUczQnYrSjRNTGcySndjQzFuL3pXeXZGVmlnVDdwd0pUQmNqa1puTXdjWTl1?= =?utf-8?B?QjVvZm9Fcmx0WkJOZ0Q5V3FkUXlpTHpkbXY0OEFpWTFOQlgyTWhpRzZEY0pQ?= =?utf-8?B?VkdJbStUa3hVeURzSEFFdlBqMVFwMnQ0dTd5VS9OOWV0a2RzaGZRaXlGU1Rv?= =?utf-8?B?SGhJMlZoYmNvU01UWXFwZ0htR2p6WG9ncDQxVEttSHVvYWVSK2YxYmhreFJ2?= =?utf-8?B?MllXWUZGSWlvenhPV1duUmdhL3dUTmFRWEhxUXJwK0hjRHF6UUd5b0syTk5T?= =?utf-8?B?bkNKT0NtUDdCT3ozV3RYdTlJaWxLWXNKRDZQd1NjeWdUdnZXdFU1amY4aHdN?= =?utf-8?B?MWt3czZKL2tNQW83TTIrc1RoQzVtNWxkUkFiL3U5dDdib3lqSDUzbG4rWFdx?= =?utf-8?B?R0tHdUk5ckJQLzNoTXJRM0dYcVNwMkhKSU53bHlGaDM3bjJTbzFZUTlOclVV?= =?utf-8?B?MnZHMmcycGxLYUtxRXF3UT09?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 6:3oXY2UTgxrCvXoRxpLI1L+2W0QaFU8AA+NmAwdjT+jc3b37bLaxzzqJKinhxnQ9mrqhdqzN0TyfCPM7gOhPohUrIelPdUQP8dqthPEfvDjH9dALXk4YejUkEvF1uKVHcDUU7TL/yEV2Ie4Qd+AYby2NzRHIFWCPD663g/0JZb4F3hwSXNU1VtEOlM6JAgHCtO8mQlOukjxA1bL9eBE7iwIlAG9nYtMZmCwzlBpU8KVJeULRYa57fEwhjlevetdRZAG4z5hmWwBSuaDw3fp0d/8S8yF6xWFjOjhtbKRk0TcB/sHao05AwGyQMWEAL/xCbOJsE+AnX1eJi1N26MHiUt4P9mbYxsCD8Vo94I/EwldI=; 5:E0BevSPvTJoVlKBSBFZyW5rXcYzoDROnxQGuqgl7xXpF7GNHKYREO+j4QkuroJj8sPIRJLgwBfkgEeDRfw7tIys1qvKDmnEGyCko27KNIx9uVKkcHqWeWuLocU0UQeOHgKKzMNN4gMRRBAlhxl6piA==; 24:2GpbvzG/WydLm+P/PmSsYG9q4yyyVZR0FWEkHGLBHidgzj6Gt6d749SWXhE6aP8y0T/G9vFg6dauc8To7PRSw8+XTCNoUeNs4Qmv9W88u10= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 7:eZRIGhQh0iSSvfPdRG0SLMPqY7UD0DE4Vcda+AU7NhJlKFT3kWgF0uQ6HITKPaL4Jx7Md+4wF8aG25Ou3rM1WWfM/+Bzbo6ui72sWJGgqCaQodVtvO5zTKS09jvWLqbZi9r2+qc1qdrMo2exlLIwqdWtON0jSPxbSx1KMZ8XN0yz34RYOmU2Oure5V9QpPHLpvucyhGg8B3ZKo9bQ4ALWGsKcaTldKy7fhIgKpv6lFIVeE1SDpS41jK7XsnOjQHi4q3fsdA4fHIzr6xXHUBGQIWu8UqadVlXebE1bwKrK7KS/6yTxVOhxW4OvT3e+tC8YrSNFmDhajngC4xRcX4tkE7dGNaSuCrQSOy0gEksmZs= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2016 17:25:41.4041 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2508 Archived-At: Cc: IETF IDR WG Subject: [Idr] Early allocation for wide communities [was: Re: BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:25:46 -0000 OK, if we're going straight to the early allocation request, let's fork = the thread. Subject updated. As a reminder, RFC 7120 gives the criteria for early allocation. The = ones I think are relevant for this discussion: b. The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet-Draft. IMO (speaking as a WG member) the current wide communities draft does = this. c. The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable. I am not sure this is true. Is it?=20 d. The Working Group chairs and Area Directors (ADs) judge that there is sufficient interest in the community for early (pre-RFC) implementation and deployment, or that failure to make an early allocation might lead to contention for the code point in the field. We can judge this based on response to this thread. Thanks, --John On Oct 18, 2016, at 1:14 PM, Susan Hares wrote: > Jeff:=20 > =20 > This is a good idea to just make 129 an early allocation for wide = communities.=20 > =20 > Sue=20 > =20 > From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 > Sent: Tuesday, October 18, 2016 11:19 AM > To: Sue Hares > Cc: IETF IDR WG; Kristian Larsson > Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) = was squatted on - Let's get a new attribute number (1 week WG call = (10/18 to 10/25) > =20 > Sue, > =20 > If 129 is not otherwise contended for, it may be reasonable to simply = request early allocation for the wide communities code point. > =20 > -- Jeff > =20 >> On Oct 18, 2016, at 11:01 AM, Susan Hares wrote: >> =20 >> WG:=20 >> =20 >> Early testing of the Large Communities draft = (draft-ietf-idr-large-community-03.txt) with attribute value of 30 = detect that we had an implementation squatting on attribute 30 by a = Huawei router. =E2=80=9CSquatting=E2=80=9D on an attribute is = anti-social behavior in the Internet in any release of software. =20 >> =20 >> The individuals who did in Huawei have been contacted by Jie Dong, = and =E2=80=9Casked=E2=80=9D if they had made this mistake in any other = attribute. These individuals confessed to Attribute 129 (for wide = communities). These individuals apologize to the Working group. =20 >> =20 >> Now what shall we do? The large community draft is critical for = several networks. After talking with the developers and operators, John = and I would like to recommend we do the following:=20 >> =20 >> IDR should recommend that the following attribute numbers be = deprecated: =20 >> =20 >> BGP Attribute 30=20 >> BGP attribute 129=20 >> =20 >> IDR should ask IANA to assign BGP Large Communities (currently = Attribute 30) to a new attribute number. This is a 1 week call to = determine if the IDR approves this action. This call will allow the = large communities draft to still continue with the 2 week WG LC. =20 >> =20 >> John, Alvaro, and I have check the early allocation rules. = Implementations should ask for early allocation prior to releasing, and = they do not need to be interoperability testing to request the early = allocation for the attribute.=20 >> =20 >> Sue Hares=20 >> =20 >> =20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Oct 18 10:29:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A605129713 for ; Tue, 18 Oct 2016 10:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=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 cL8zSn7Zkjg9 for ; Tue, 18 Oct 2016 10:29:30 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346F4129666 for ; Tue, 18 Oct 2016 10:29:30 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.187.221.190; From: "Susan Hares" To: "'Nick Hilliard'" References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> In-Reply-To: <5806484F.5080006@foobar.org> Date: Tue, 18 Oct 2016 13:27:37 -0400 Message-ID: <010a01d22964$ec1233d0$c4369b70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxOA6e5ti/ZI3ng6LJlnwAiipARgH9+98qoOBo/uA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'IETF IDR WG' , 'Kristian Larsson' Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:29:31 -0000 Nick: In my understanding, all deprecations are temporary. A vendor range for attributes is something that is possible if the working group wishes. I do agree operators should beacon 31 or 32. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Nick Hilliard Sent: Tuesday, October 18, 2016 12:06 PM To: Susan Hares Cc: 'IETF IDR WG'; 'Kristian Larsson' Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) Susan Hares wrote: > IDR should recommend that the following attribute numbers be deprecated: > > BGP Attribute 30 > BGP attribute 129 unless this is a temporary deprecation, I'm not sure if this is a good idea, as it could be interpreted as sending a message to vendors that squatting path attribute code points will result in being told, "that's very naughty and we're going to punish you by ensuring that no-one else gets these numbers, so don't do it again!" There is an objective problem here, namely that there is no vendor-specific range for path attributes. Given the nature of path attribute interpretation, it could be argued that this might be a good thing because different vendors will interpret TLVs in different ways, which is a potential source of bgp session instability. On the other hand, it means that if vendors need to go off and do something new, there are no options other than squatting. A vendor-specific range will at least contain this problem, so that IANA won't run into the same problem in future. On a related issue, it would probably be a good idea to run beacon tests with other path attributes to see how they affect reachability, i.e. have any other vendors squatted any other path attribute values, and if large-communities is moved to 31 or 32, will it suffer the same problem? Nick _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Tue Oct 18 10:32:45 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ED91296F9 for ; Tue, 18 Oct 2016 10:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 tznC7dVz5qNu for ; Tue, 18 Oct 2016 10:32:42 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id CD5991296F7 for ; Tue, 18 Oct 2016 10:32:41 -0700 (PDT) Received: from [IPv6:2001:1998:3400:1d::287] (unknown [IPv6:2001:1998:3400:1d::287]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 516205407E5; Tue, 18 Oct 2016 13:32:39 -0400 (EDT) From: Wesley George X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_928BA6A1-8D5A-4425-BA89-596C47C500EC"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Tue, 18 Oct 2016 13:32:37 -0400 Message-Id: <277CCC95-EB94-4213-9AA7-AAFEDF443F20@puck.nether.net> To: Susan Hares , IETF IDR WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:32:43 -0000 --Apple-Mail=_928BA6A1-8D5A-4425-BA89-596C47C500EC Content-Type: multipart/alternative; boundary="Apple-Mail=_D7AEE03B-37AD-4A67-A192-5C2E77D71B45" --Apple-Mail=_D7AEE03B-37AD-4A67-A192-5C2E77D71B45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ve read the draft, I support publication. This is a necessary = mechanism for managing BGP in the modern Internet, and IMO long overdue. = Thanks to the authors and implementers that have pushed this forward. Wes George From: Susan Hares Date: Monday, October 17, 2016 at 4:27 PM To: 'IETF IDR WG' Subject: [Idr] WG LC on draft-ietf-idr-large-community-03.txt = (10/17/2016 to 10/31/2016) This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt. = (10/17 to 10/31). Please comment if = draft-ietf-idr-large-community-03.txt is ready for publication. If you have concerns with the text, please be very specific about what = is wrong and what needs to change. If you have concerns about = operational aspects, please give a complete description of the problem = and why this draft does not solve it. This WG LC is not a place to debate whether we should have adopted this = technology. The focus of WG LC is whether this technology has implementations (see = IDR wiki for examples), and whether these implementation inter-operate. = It is also important to consider deployment issue or problems on = currently. Sue Hares and John Scudder --Apple-Mail=_D7AEE03B-37AD-4A67-A192-5C2E77D71B45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I=E2=80=99ve read the draft, = I support publication. This is a necessary mechanism for managing BGP in the modern Internet, and IMO = long overdue. Thanks to the authors and implementers that have pushed this = forward.

 

Wes George

 

 

From: = Susan Hares <shares@ndzh.com>
Date: Monday, October 17, 2016 at 4:27 PM
= To: 'IETF IDR WG' <idr@ietf.org>
Subject: [Idr] WG LC on = draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

 

This begins a 2 week = WG LC on draft-ietf-idr-large-community-03.txt.  (10/17 to = 10/31).   Please comment if draft-ietf-idr-large-community-03.txt  is ready = for publication.  

 

If you have concerns with the text,  please be = very specific about what is wrong and what needs to change.  If you have concerns about operational aspects, please give a complete description = of the problem and why this draft does not solve it.

 

This WG LC is not a place to debate whether we = should have adopted this technology. 

 

The focus of WG LC is whether this technology has implementations (see IDR wiki for examples),  and whether these implementation inter-operate.  It is also important to consider = deployment issue or problems on currently. 

 

Sue Hares and John Scudder 

= --Apple-Mail=_D7AEE03B-37AD-4A67-A192-5C2E77D71B45-- --Apple-Mail=_928BA6A1-8D5A-4425-BA89-596C47C500EC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYBly2AAoJEBdIPc22E6Uhi8QP/24MyG4mdBpqtcSyQg5L6ity +Z+ImD0mJO7hbW7/TT+vws1USPLqBWylANVUW5EE/XFWKKJPXQwHK7imJOTCslTc lluk2xubE6Ba9TIzs4OMIfnd8FQMGb3xVsVOjm37wXv7vsLK1IYQx3u5nE7upQN4 /uIvrK0OXUhNa/sO8+z/QHSwZPd3bUkgQ02xnPPk4nY/TNMCkW0hthamZ958lpAY vLkdXTI1HBuLxjwubMPmkCNd5kCdwYwgxDWte8YLbqfyajkWc99YWfyUEc1D+CQi R1C8p44NHKYm0eE6rvFobRrwMAvGptl+Aq+St571ToexP5mahEc4sUZoKJ/TmQbA tggf3jInrwcM0/l/89WKb3VF5jS7c9VP1iops3bHunco96etl96fyIUGc5XvcFrN S3x25gntvuXHkVaHH9V2Urxt0bFYzJsuPZ1MYZn7nwibL/Xy5REg9g/+EFbIJAxJ CPl4i5u9hSyPwfRMLm4pR2042a2Qx9/sc7hW2Au0uOKKeO5Q5tjBaQM1QPt4oEYX 0gUIVGM9Xm1nNpuyytK6eq5iM6CNWk9IV51K38H5VOZ1sBBwHZSOQU+QzKNkrhd2 83avT/UZIbby0dT+zte+SlefwTt1LvSg5OSvqlEXWqH0CQhv3tzB+yFMlC0uoro3 tR/IuiKBVprP9/UCbGoH =86WK -----END PGP SIGNATURE----- --Apple-Mail=_928BA6A1-8D5A-4425-BA89-596C47C500EC-- From nobody Tue Oct 18 10:39:05 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD82912973E for ; Tue, 18 Oct 2016 10:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WAoQx_tRSyuX for ; Tue, 18 Oct 2016 10:39:01 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 550FF12973A for ; Tue, 18 Oct 2016 10:39:01 -0700 (PDT) Received: from [IPv6:2001:1998:3400:1d::287] (unknown [IPv6:2001:1998:3400:1d::287]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id A716E540976; Tue, 18 Oct 2016 13:38:57 -0400 (EDT) From: Wesley George X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_C83927C1-955F-4265-933C-4593CCD77BF3"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Tue, 18 Oct 2016 13:38:56 -0400 Message-Id: <173B839F-589F-4EDA-AE70-104B09D17BDC@puck.nether.net> To: Nick Hilliard , Susan Hares Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF IDR WG , Kristian Larsson Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:39:03 -0000 --Apple-Mail=_C83927C1-955F-4265-933C-4593CCD77BF3 Content-Type: multipart/alternative; boundary="Apple-Mail=_5045FE0F-F2CC-4839-A1B9-0CA25B5C97E1" --Apple-Mail=_5045FE0F-F2CC-4839-A1B9-0CA25B5C97E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 10/18/16, 12:05 PM, "Nick Hilliard" wrote: <> I'm not sure if this is a good idea, as it could be interpreted as sending a message to vendors = that squatting path attribute code points will result in being told, = "that's very naughty and we're going to punish you by ensuring that no-one = else gets these numbers, so don't do it again!" I agree with the pragmatic approach of re-allocating so that we aren=E2=80= =99t dependent on various network operators to upgrade code to fix this = problem before large communities can be deployed, but I share the = concern about this setting a bad precedent and rewarding bad behavior. = Admittedly we have little leverage beyond finger-wagging, but I think = the appropriate response here is to ensure a bit of diulian =E4=B8=9F=E8=87= =89 (lose face) aka name and shame for those making the "mistake". For example, an addition to the IANA considerations section such as: IANA is requested to allocate a new codepoint after early testing of the = early-allocated codepoint revealed router vendors such as Huawei with = production software making unauthorized use of (squatting on) unused = codepoints including attribute 30 and 129 in a way that breaks = interoperability if the original early-allocation codepoint were used. Wes George --Apple-Mail=_5045FE0F-F2CC-4839-A1B9-0CA25B5C97E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10/18/16, 12:05 PM, "Nick Hilliard" <nick@foobar.org> wrote:

 

     I'm not sure if this is a good

    idea, as it could be = interpreted as sending a message to vendors that

    squatting path attribute code = points will result in being told, "that's

    very naughty and we're going = to punish you by ensuring that no-one else

    gets these numbers, so don't = do it again!"

   

I agree with the pragmatic approach of re-allocating so that we aren=E2=80=99t dependent = on various network operators to upgrade code to fix this problem before large = communities can be deployed, but I share the concern about this setting a bad = precedent and rewarding bad behavior. Admittedly we have little leverage beyond = finger-wagging, but I think the appropriate response here is to ensure a bit of diulian =E4=B8=9F=E8=87=89= (lose face) aka name and shame for those making the "mistake".

For = example, an addition to the IANA considerations section such as:

IANA is requested to allocate a new codepoint after early testing of the = early-allocated codepoint revealed router vendors such as Huawei with production = software making unauthorized use of (squatting on) unused codepoints including attribute = 30 and 129 in a way that breaks interoperability if the original = early-allocation codepoint were used.


Wes George

= --Apple-Mail=_5045FE0F-F2CC-4839-A1B9-0CA25B5C97E1-- --Apple-Mail=_C83927C1-955F-4265-933C-4593CCD77BF3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYBl4wAAoJEBdIPc22E6UhkYwP/A8ZBafBRzi3yRU22JBWk5hE 5hMr2EinolOppsXOxLS+Dfkgut7jYlebSyY4joQla8blQUSX3i8nosZ8MEfD7RkU STPhyB7DCRfhklI6lMYMgUEqcxM+GB+5FCPzxn8/7NpZjHVRwIIUXxLlXxUh47/w npeZdfQbUfbh1jeAJS7WavjHzFUd/P4bNHAjfJMk7p9NL04fnhLLH2d6SWfmfdG1 FLvL245yrv425URIOQSpVNg7SOqxD7fO8HkxqbgGljlx+Bp4U5WLW0hQr7Ik+sKw wH3k5y45IkFzfmHr43NWWwNzrbchHZhrr/PJ06L+D06/69d4lKz5RY1vvS6hAjyX 62xT98rms2KXQwbj8oMJVo7VdNlD49YfFtdWdLP2lDrQ4FcPgrXcCew+teaDF4xV /LjjwUki+8R5XQSi3xOhlJNu34+n/Xv+qkdqR2eEOhsJ7W9+0fPLDOGfovpcEwh6 Ssg2lIHBHLfRA1WwmKHvsMKlFFkUe24tuRj0N6PXKq/ATRxRV93ZoWjCDFzYSXn/ L+S5Vh4Me5Rk4zxLiwFLg9+qv+341zqf4MaOE2SCNdc/A0tWkhSvcYUWbzQUuTD6 OFA72q0H5ElUfNFK3ZXos+i86K4GID1iaw5ETh9Q4qF0rm3IlgyTT17g5sV8YSbj M9k26vNqxrwsk149ZdD7 =jJ4j -----END PGP SIGNATURE----- --Apple-Mail=_C83927C1-955F-4265-933C-4593CCD77BF3-- From nobody Tue Oct 18 10:40:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AFD1296F0 for ; Tue, 18 Oct 2016 10:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=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 12BbKsF1YqYs for ; Tue, 18 Oct 2016 10:40:34 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D36A1296A6 for ; Tue, 18 Oct 2016 10:40:34 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.187.221.190; From: "Susan Hares" To: "'John G. Scudder'" References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <001801d22963$11733630$3459a290$@ndzh.com> <019F0FC9-6751-42CD-BA26-3CB0B374748E@juniper.net> In-Reply-To: <019F0FC9-6751-42CD-BA26-3CB0B374748E@juniper.net> Date: Tue, 18 Oct 2016 13:38:51 -0400 Message-ID: <00e801d22966$7df0ecf0$79d2c6d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxOA6e5ti/ZI3ng6LJlnwAiipARgGREBAWAcDbSH0CB360z6DFjuIA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'IETF IDR WG' Subject: Re: [Idr] Early allocation for wide communities [was: Re: BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:40:36 -0000 John: Another question is important, are there other wide-communities = implementations. Has anyone else implemented flowspecification?=20 Sue=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Tuesday, October 18, 2016 1:25 PM To: Susan Hares Cc: IETF IDR WG Subject: [Idr] Early allocation for wide communities [was: Re: BGP = Attribute for Large communities (Attribute 30) was squatted on - Let's = get a new attribute number (1 week WG call (10/18 to 10/25)] OK, if we're going straight to the early allocation request, let's fork = the thread. Subject updated. As a reminder, RFC 7120 gives the criteria for early allocation. The = ones I think are relevant for this discussion: b. The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet-Draft. IMO (speaking as a WG member) the current wide communities draft does = this. c. The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable. I am not sure this is true. Is it?=20 d. The Working Group chairs and Area Directors (ADs) judge that there is sufficient interest in the community for early (pre-RFC) implementation and deployment, or that failure to make an early allocation might lead to contention for the code point in the field. We can judge this based on response to this thread. Thanks, --John On Oct 18, 2016, at 1:14 PM, Susan Hares wrote: > Jeff:=20 > =20 > This is a good idea to just make 129 an early allocation for wide = communities.=20 > =20 > Sue=20 > =20 > From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 > Sent: Tuesday, October 18, 2016 11:19 AM > To: Sue Hares > Cc: IETF IDR WG; Kristian Larsson > Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) = was squatted on - Let's get a new attribute number (1 week WG call = (10/18 to 10/25) > =20 > Sue, > =20 > If 129 is not otherwise contended for, it may be reasonable to simply = request early allocation for the wide communities code point. > =20 > -- Jeff > =20 >> On Oct 18, 2016, at 11:01 AM, Susan Hares wrote: >> =20 >> WG:=20 >> =20 >> Early testing of the Large Communities draft = (draft-ietf-idr-large-community-03.txt) with attribute value of 30 = detect that we had an implementation squatting on attribute 30 by a = Huawei router. =E2=80=9CSquatting=E2=80=9D on an attribute is = anti-social behavior in the Internet in any release of software. =20 >> =20 >> The individuals who did in Huawei have been contacted by Jie Dong, = and =E2=80=9Casked=E2=80=9D if they had made this mistake in any other = attribute. These individuals confessed to Attribute 129 (for wide = communities). These individuals apologize to the Working group. =20 >> =20 >> Now what shall we do? The large community draft is critical for = several networks. After talking with the developers and operators, John = and I would like to recommend we do the following:=20 >> =20 >> IDR should recommend that the following attribute numbers be = deprecated: =20 >> =20 >> BGP Attribute 30=20 >> BGP attribute 129=20 >> =20 >> IDR should ask IANA to assign BGP Large Communities (currently = Attribute 30) to a new attribute number. This is a 1 week call to = determine if the IDR approves this action. This call will allow the = large communities draft to still continue with the 2 week WG LC. =20 >> =20 >> John, Alvaro, and I have check the early allocation rules. = Implementations should ask for early allocation prior to releasing, and = they do not need to be interoperability testing to request the early = allocation for the attribute.=20 >> =20 >> Sue Hares=20 >> =20 >> =20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Tue Oct 18 10:45:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630621296FD for ; Tue, 18 Oct 2016 10:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=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 xA7RQ4AVORem for ; Tue, 18 Oct 2016 10:45:18 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C9A12949A for ; Tue, 18 Oct 2016 10:45:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=199.187.221.190; From: "Susan Hares" To: "'John G. Scudder'" References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <001801d22963$11733630$3459a290$@ndzh.com> <019F0FC9-6751-42CD-BA26-3CB0B374748E@juniper.net> In-Reply-To: <019F0FC9-6751-42CD-BA26-3CB0B374748E@juniper.net> Date: Tue, 18 Oct 2016 13:43:34 -0400 Message-ID: <017b01d22967$26530130$72f90390$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxOA6e5ti/ZI3ng6LJlnwAiipARgGREBAWAcDbSH0CB360z6DFjyHA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'IETF IDR WG' Subject: Re: [Idr] Early allocation for wide communities [was: Re: BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:45:19 -0000 John:=20 On #2, (handle attribute #129 attribute and handle new one) - Jie Dong = can probably ask the developers.=20 Sue=20 -----Original Message----- From: John G. Scudder [mailto:jgs@juniper.net]=20 Sent: Tuesday, October 18, 2016 1:25 PM To: Susan Hares Cc: Jeffrey Haas; IETF IDR WG Subject: Early allocation for wide communities [was: Re: [Idr] BGP = Attribute for Large communities (Attribute 30) was squatted on - Let's = get a new attribute number (1 week WG call (10/18 to 10/25)] OK, if we're going straight to the early allocation request, let's fork = the thread. Subject updated. As a reminder, RFC 7120 gives the criteria for early allocation. The = ones I think are relevant for this discussion: b. The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet-Draft. IMO (speaking as a WG member) the current wide communities draft does = this. c. The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable. I am not sure this is true. Is it?=20 d. The Working Group chairs and Area Directors (ADs) judge that there is sufficient interest in the community for early (pre-RFC) implementation and deployment, or that failure to make an early allocation might lead to contention for the code point in the field. We can judge this based on response to this thread. Thanks, --John On Oct 18, 2016, at 1:14 PM, Susan Hares wrote: > Jeff:=20 > =20 > This is a good idea to just make 129 an early allocation for wide = communities.=20 > =20 > Sue=20 > =20 > From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 > Sent: Tuesday, October 18, 2016 11:19 AM > To: Sue Hares > Cc: IETF IDR WG; Kristian Larsson > Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) = was squatted on - Let's get a new attribute number (1 week WG call = (10/18 to 10/25) > =20 > Sue, > =20 > If 129 is not otherwise contended for, it may be reasonable to simply = request early allocation for the wide communities code point. > =20 > -- Jeff > =20 >> On Oct 18, 2016, at 11:01 AM, Susan Hares wrote: >> =20 >> WG:=20 >> =20 >> Early testing of the Large Communities draft = (draft-ietf-idr-large-community-03.txt) with attribute value of 30 = detect that we had an implementation squatting on attribute 30 by a = Huawei router. =E2=80=9CSquatting=E2=80=9D on an attribute is = anti-social behavior in the Internet in any release of software. =20 >> =20 >> The individuals who did in Huawei have been contacted by Jie Dong, = and =E2=80=9Casked=E2=80=9D if they had made this mistake in any other = attribute. These individuals confessed to Attribute 129 (for wide = communities). These individuals apologize to the Working group. =20 >> =20 >> Now what shall we do? The large community draft is critical for = several networks. After talking with the developers and operators, John = and I would like to recommend we do the following:=20 >> =20 >> IDR should recommend that the following attribute numbers be = deprecated: =20 >> =20 >> BGP Attribute 30=20 >> BGP attribute 129=20 >> =20 >> IDR should ask IANA to assign BGP Large Communities (currently = Attribute 30) to a new attribute number. This is a 1 week call to = determine if the IDR approves this action. This call will allow the = large communities draft to still continue with the 2 week WG LC. =20 >> =20 >> John, Alvaro, and I have check the early allocation rules. = Implementations should ask for early allocation prior to releasing, and = they do not need to be interoperability testing to request the early = allocation for the attribute.=20 >> =20 >> Sue Hares=20 >> =20 >> =20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Oct 18 10:50:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6212129731 for ; Tue, 18 Oct 2016 10:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=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 sNu3Zna3fMgf for ; Tue, 18 Oct 2016 10:50:03 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D0E12970F for ; Tue, 18 Oct 2016 10:50:03 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.187.221.190; From: "Susan Hares" To: "'Peter Hessler'" , References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> In-Reply-To: <20161018172538.GD27221@gir.theapt.org> Date: Tue, 18 Oct 2016 13:48:10 -0400 Message-ID: <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxOA6e5ti/ZI3ng6LJlnwAiipARgH9+98qAfpX1oIBtoIawKDC6FJw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:50:05 -0000 Do we know which routers are sending path attributes with 20 or 21? Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Peter Hessler Sent: Tuesday, October 18, 2016 1:26 PM To: idr@ietf.org Subject: [Idr] Unknown Attributes seen in the wild On 2016 Oct 18 (Tue) at 12:28:09 -0400 (-0400), Jeffrey Haas wrote: :> On Oct 18, 2016, at 12:05 PM, Nick Hilliard wrote: :> On a related issue, it would probably be a good idea to run beacon tests :> with other path attributes to see how they affect reachability, i.e. :> have any other vendors squatted any other path attribute values, and if :> large-communities is moved to 31 or 32, will it suffer the same problem? : :Even passive monitoring is a good start. I just did a check of the DFZ, both IPv4 and IPv6, and these are the unknown/deprecated attributes on paths that I can see. 20 Connector Attribute (deprecated) [RFC6037] 21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit] count type flags len data in hex -------------------------------------------------------------- 43 Unknown Attribute #20 flags [OTP] len 14: 00 01 00 00 58 d6 00 00 02 8e cf d2 8d b5 2 Unknown Attribute #21 flags [OTP] len 5: 02 00 00 57 da 4 Unknown Attribute #21 flags [OTP] len 5: 07 00 00 2d c8 2 Unknown Attribute #21 flags [OTP] len 5: 14 00 00 39 72 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Tue Oct 18 10:52:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCF71295C3 for ; Tue, 18 Oct 2016 10:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xMZNlproHTZO for ; Tue, 18 Oct 2016 10:52:15 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6F96E129404 for ; Tue, 18 Oct 2016 10:52:15 -0700 (PDT) Received: from [IPv6:2620::ce0:101:3849:f195:6e10:a7c7] (unknown [IPv6:2620:0:ce0:101:3849:f195:6e10:a7c7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id ECCCA54051B; Tue, 18 Oct 2016 13:52:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3246\)) From: Jared Mauch In-Reply-To: <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> Date: Tue, 18 Oct 2016 13:52:13 -0400 Content-Transfer-Encoding: 7bit Message-Id: <69BB40FC-7A77-43E2-A80B-C176288A2463@puck.nether.net> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3246) Archived-At: Cc: idr@ietf.org, Peter Hessler Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:52:17 -0000 route-views>sh ip bgp path-attribute unknown Network Next Hop 134.89.0.0 216.218.252.164 185.104.128.0/24 129.250.0.11 185.104.129.0/24 129.250.0.11 185.104.130.0/24 129.250.0.11 185.104.131.0/24 129.250.0.11 192.147.168.0 129.250.0.11 198.17.60.0 216.218.252.164 198.17.61.0 216.218.252.164 204.62.150.0/23 208.51.134.254 e.g.: 134.89.0.0 unknown transitive attribute: flag 0xE0 type 0x15 length 0x5 value 1400 0039 72 - Jared > On Oct 18, 2016, at 1:48 PM, Susan Hares wrote: > > Do we know which routers are sending path attributes with 20 or 21? > > Sue > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Peter Hessler > Sent: Tuesday, October 18, 2016 1:26 PM > To: idr@ietf.org > Subject: [Idr] Unknown Attributes seen in the wild > > On 2016 Oct 18 (Tue) at 12:28:09 -0400 (-0400), Jeffrey Haas wrote: > :> On Oct 18, 2016, at 12:05 PM, Nick Hilliard wrote: > :> On a related issue, it would probably be a good idea to run beacon tests > :> with other path attributes to see how they affect reachability, i.e. > :> have any other vendors squatted any other path attribute values, and if > :> large-communities is moved to 31 or 32, will it suffer the same problem? > : > :Even passive monitoring is a good start. > > I just did a check of the DFZ, both IPv4 and IPv6, and these are the > unknown/deprecated attributes on paths that I can see. > > 20 Connector Attribute (deprecated) [RFC6037] > 21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit] > > count type flags len data in hex > -------------------------------------------------------------- > 43 Unknown Attribute #20 flags [OTP] len 14: 00 01 00 00 58 d6 00 00 > 02 8e cf d2 8d b5 > 2 Unknown Attribute #21 flags [OTP] len 5: 02 00 00 57 da > 4 Unknown Attribute #21 flags [OTP] len 5: 07 00 00 2d c8 > 2 Unknown Attribute #21 flags [OTP] len 5: 14 00 00 39 72 > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Oct 18 10:55:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC53E129579 for ; Tue, 18 Oct 2016 10:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 dM_ADDoB8L_q for ; Tue, 18 Oct 2016 10:55:06 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:470:1f0b:8b2::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD381293E3 for ; Tue, 18 Oct 2016 10:55:06 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id CC66E788F1; Tue, 18 Oct 2016 19:55:04 +0200 (CEST) Date: Tue, 18 Oct 2016 19:55:03 +0200 From: 'Peter Hessler' To: Susan Hares Message-ID: <20161018175503.GE27221@gir.theapt.org> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:55:08 -0000 For #20, all are coming from AS 22742 For #21, 2 are from AS 14706, 4 are from AS 11720, and 2 from AS 22490. -peter On 2016 Oct 18 (Tue) at 13:48:10 -0400 (-0400), Susan Hares wrote: :Do we know which routers are sending path attributes with 20 or 21? : :Sue : :-----Original Message----- :From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Peter Hessler :Sent: Tuesday, October 18, 2016 1:26 PM :To: idr@ietf.org :Subject: [Idr] Unknown Attributes seen in the wild : :On 2016 Oct 18 (Tue) at 12:28:09 -0400 (-0400), Jeffrey Haas wrote: ::> On Oct 18, 2016, at 12:05 PM, Nick Hilliard wrote: ::> On a related issue, it would probably be a good idea to run beacon tests ::> with other path attributes to see how they affect reachability, i.e. ::> have any other vendors squatted any other path attribute values, and if ::> large-communities is moved to 31 or 32, will it suffer the same problem? :: ::Even passive monitoring is a good start. : :I just did a check of the DFZ, both IPv4 and IPv6, and these are the :unknown/deprecated attributes on paths that I can see. : :20 Connector Attribute (deprecated) [RFC6037] :21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit] : :count type flags len data in hex :-------------------------------------------------------------- : 43 Unknown Attribute #20 flags [OTP] len 14: 00 01 00 00 58 d6 00 00 02 8e cf d2 8d b5 : 2 Unknown Attribute #21 flags [OTP] len 5: 02 00 00 57 da : 4 Unknown Attribute #21 flags [OTP] len 5: 07 00 00 2d c8 : 2 Unknown Attribute #21 flags [OTP] len 5: 14 00 00 39 72 From nobody Tue Oct 18 10:59:17 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EB8129404 for ; Tue, 18 Oct 2016 10:59:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 BX54_2YTHO15 for ; Tue, 18 Oct 2016 10:59:14 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4661295DE for ; Tue, 18 Oct 2016 10:59:14 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id d132so1727697oib.2 for ; Tue, 18 Oct 2016 10:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Ivk4VV08OauCNsSJtRrlfug5mHg56NeAF+7ZGCJWFj8=; b=rEdWgEGBJs8xVY0R0AoJXEV+XkSseUxxm1TatggmkXiX5Wa4/OYo3XwcfI4KlS4SMq iMABsnLqhl0ZYGqRxq/myY38/4PWDfbDJnNij+VBeYyLQn4fXxH4VQkkRt29cw3ec5KG vcolcePrpm/MxM3BxtddTXWeIlYM4v+b6fg+u6BbW12BNVl4O5ir3dk+PoyJkN2bgFZk FCgDeOzFT1ke36ywEc+QR3umPAmwTXA5uOu2Prll6XpESdK3aPxrAMIXe1VDZC/PM13z I47f/KMnAAbT5nX6zBLH47LBX4m3bW/RmmqIbOgvkHXIfbyB6GAloN1Fd87uK81GGa2o xWeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Ivk4VV08OauCNsSJtRrlfug5mHg56NeAF+7ZGCJWFj8=; b=F3XTxP7Gm6U6Qfndcz7zjlFNdi5VPpRuZf1INq+F8IZMSFyFzOfAK+etFy87A2/nV4 4JRCJHbxeUDJR2kydlLAK1mZ7/EoPWUQaJWLmKnX1194DZB/E91SI8M4dQw6cFPW2ODl e5aAKffvvTTfPEY8TrkYUsWgkaUl106XAuxu7kbXpcGTf6XfLi5unHBCi0ITxZQMUK/y CnRMlrA4CEZ2feWpjd7+yF1UY7gQwa9JT0kn34kqwRektwzL50TsWX5WVPeWUxyFDNDF 84YwFGrS/bma5rlEmczddpTSYz7tlWQ8YlQat7rE+RG4gyfufyAKBYdAZf8KU/4Jdj+h LBYw== X-Gm-Message-State: AA6/9RnaEstLvP3kJYLAa+4969+hxiY+fyXQgjhd2hFzLecUEV899tch6DIAY9/9RqRncw== X-Received: by 10.202.185.9 with SMTP id j9mr387642oif.55.1476813553701; Tue, 18 Oct 2016 10:59:13 -0700 (PDT) Received: from localhost (dhcp-157.238.255.122.noc.gin.ntt.net. [157.238.255.122]) by smtp.gmail.com with ESMTPSA id h91sm12958167oth.40.2016.10.18.10.59.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 10:59:11 -0700 (PDT) Date: Tue, 18 Oct 2016 12:57:53 -0500 From: Job Snijders To: Susan Hares Message-ID: <20161018175753.GD10221@dhcp-157.238.255.122.noc.gin.ntt.net> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <001801d22963$11733630$3459a290$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001801d22963$11733630$3459a290$@ndzh.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: 'IETF IDR WG' , 'Kristian Larsson' Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:59:16 -0000 On Tue, Oct 18, 2016 at 01:14:21PM -0400, Susan Hares wrote: > Jeff: > > This is a good idea to just make 129 an early allocation for wide communities. I have to disagree. It is not known what version of the wide communities draft has been implemented. This code is deployed in the wild, there are no guarantees that those routers will ever be upgraded. I think the -wide- deployment effort will shoot itself in the foot by using 129. Kind regards, Job From nobody Tue Oct 18 11:06:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215521294A9 for ; Tue, 18 Oct 2016 11:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 DST1taK7X1Yn for ; Tue, 18 Oct 2016 11:06:54 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 76967129437 for ; Tue, 18 Oct 2016 11:06:54 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bwYmp-000Fb8-MK (job@us.ntt.net); Tue, 18 Oct 2016 18:06:51 +0000 Date: Tue, 18 Oct 2016 13:06:50 -0500 From: Job Snijders To: "John G. Scudder" Message-ID: <20161018180650.GS95811@Vurt.local> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <001801d22963$11733630$3459a290$@ndzh.com> <019F0FC9-6751-42CD-BA26-3CB0B374748E@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <019F0FC9-6751-42CD-BA26-3CB0B374748E@juniper.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: IETF IDR WG , Susan Hares Subject: Re: [Idr] Early allocation for wide communities [was: Re: BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 18:06:56 -0000 On Tue, Oct 18, 2016 at 01:25:25PM -0400, John G. Scudder wrote: > c. The specifications of these code points must be stable; i.e., if > there is a change, implementations based on the earlier and later > specifications must be seamlessly interoperable. > > I am not sure this is true. Is it? I do not believe that to be true. Kind regards, Job From nobody Tue Oct 18 11:14:39 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717FB129681 for ; Tue, 18 Oct 2016 11:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3_v7V7JQt1qF for ; Tue, 18 Oct 2016 11:14:35 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0A112967B for ; Tue, 18 Oct 2016 11:14:35 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id z189so7850439wmb.1 for ; Tue, 18 Oct 2016 11:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hyN4womoBtGNYV5xZa9TpRW+yq4v/GIbxOs23aql+WI=; b=umhoFbbD2iH6VVg+I14lQlvFUVk6iEGG0b8s8romvOs4YIcObqrxvxC8iGgwrets7V hmjXnTSVl3897blFMFDvtf0rr5Feugnhemx31orK1aHRahve1UYxVjSnNPN00PILdV75 ek7ZYuGpgzDZXFKnticgpIcsLTFhdlTIYdiwZgeg77noPUxewq2pgU0eoL0haWxApEcM gjlRIwmNSfgrE4xdAyE/E2BP2FNl2wZ/fbvidbDmTPcLHOPEKHnZ4dA1wi+3iYCsH9LD jYT6j2cQEoy8/tbJZFvDZrx+uePX1QI3UJn+/D9msrRuNZbMSEHEbkp8aBbw1iqFgFKQ FSjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hyN4womoBtGNYV5xZa9TpRW+yq4v/GIbxOs23aql+WI=; b=hjxOdGkSh1qtZs2eax6fNgplz2GeFEr88YwYbcJqb0MzVN+u3bT1h6KBRnLOdbZppI nQAzwx7Nx8bbvXuNRA3d+QNTlI+FDvgUMmilswdRP2XzrznHXe4pUSHU5Qrl9uIQw4q8 A2CWyheooOW2VvUzp19NdVzoL1NrqzfCGk/ETAcx3/GenCGED5RaxHnDUXGeQjp3t8QD AxZaUZCeZ1sab0I8BHh5aCaFt0GfSMk0m9/oZk+L3CtWU2xs4fjVfpINRdy8efQl3gED w8NN5SZ4uBIHhoEHdFPABHly1AuWsY8YwkKSk1Un+cT/h/26MNzZLMRyr7fwvyCPO+PZ KgSA== X-Gm-Message-State: AA6/9RnuL5Qs8nB+5coKXec2l2/54e3gLCWoDRbfCncW9fMbv3Dy1FZ7lsOA4cQ6Mnp1sLz0vZ/1/9i0a077aw== X-Received: by 10.28.164.70 with SMTP id n67mr1754836wme.61.1476814473979; Tue, 18 Oct 2016 11:14:33 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Tue, 18 Oct 2016 11:14:33 -0700 (PDT) In-Reply-To: <20161018175753.GD10221@dhcp-157.238.255.122.noc.gin.ntt.net> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <001801d22963$11733630$3459a290$@ndzh.com> <20161018175753.GD10221@dhcp-157.238.255.122.noc.gin.ntt.net> From: Robert Raszuk Date: Tue, 18 Oct 2016 20:14:33 +0200 X-Google-Sender-Auth: 3tp5zdME8PbXx44KAVuwPK5gba8 Message-ID: To: Job Snijders Content-Type: multipart/alternative; boundary=001a114a0bec1eec6c053f27aab0 Archived-At: Cc: IETF IDR WG , Kristian Larsson , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 18:14:37 -0000 --001a114a0bec1eec6c053f27aab0 Content-Type: text/plain; charset=UTF-8 I would tend to agree with Job here. I see no point to reserve already known to be "overloaded" code point for wide or for that matter any new BGP attribute. That's the price we pay for no BGP Police or BGP FBI/GBI ... (G=global) r. On Tue, Oct 18, 2016 at 7:57 PM, Job Snijders wrote: > On Tue, Oct 18, 2016 at 01:14:21PM -0400, Susan Hares wrote: > > Jeff: > > > > This is a good idea to just make 129 an early allocation for wide > communities. > > I have to disagree. > > It is not known what version of the wide communities draft has been > implemented. This code is deployed in the wild, there are no guarantees > that those routers will ever be upgraded. > > I think the -wide- deployment effort will shoot itself in the foot by > using 129. > > Kind regards, > > Job > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a114a0bec1eec6c053f27aab0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I would te= nd to agree with Job here.=C2=A0

I see no point to reserve already known to be "overloaded&q= uot; code point for wide or for that matter any new BGP attribute.=C2=A0

That's the price we = pay for no BGP Police or BGP FBI/GBI =C2=A0... (G=3Dglobal)

r.

On Tue, Oct 18, 2016 at 7:57 PM, Job Sni= jders <job@instituut.net> wrote:
On Tue, Oct 18, 2016 at 01:14:21PM -0400, Susan Har= es wrote:
> Jeff:
>
> This is a good idea to just make 129 an early allocation for wide comm= unities.

I have to disagree.

It is not known what version of the wide communities draft has been
implemented. This code is deployed in the wild, there are no guarantees
that those routers will ever be upgraded.

I think the -wide- deployment effort will shoot itself in the foot by
using 129.

Kind regards,

Job

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--001a114a0bec1eec6c053f27aab0-- From nobody Tue Oct 18 11:17:39 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E991296C9 for ; Tue, 18 Oct 2016 11:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=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 Pc7Q8z2uaWKe for ; Tue, 18 Oct 2016 11:17:37 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9DB129681 for ; Tue, 18 Oct 2016 11:17:23 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=199.187.221.190; From: "Susan Hares" To: "'Peter Hessler'" References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> <20161018175503.GE27221@gir.theapt.org> In-Reply-To: <20161018175503.GE27221@gir.theapt.org> Date: Tue, 18 Oct 2016 14:15:39 -0400 Message-ID: <012e01d2296b$a243fd90$e6cbf8b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxOA6e5ti/ZI3ng6LJlnwAiipARgH9+98qAfpX1oIBtoIawAKbWoOFAVjr3hWgo0r08A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 18:17:39 -0000 Peter: A set of ASes, I did not expect. AS 22742 = CT-ED-NET (State of Connecticut) AS14706 = Monterey Bay Aquarium Research Institute AS22490 = The Nerdery, LLC Caida info: http://as-rank.caida.org/?mode0=as-info&mode1=as-table&as=22742 http://as-rank.caida.org/?mode0=as-info&mode1=as-table&as=14706 http://as-rank.caida.org/?mode0=as-info&mode1=as-table&as=22490 Hmm. This is the wild, wild bgp world. Hmm. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of 'Peter Hessler' Sent: Tuesday, October 18, 2016 1:55 PM To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] Unknown Attributes seen in the wild For #20, all are coming from AS 22742 For #21, 2 are from AS 14706, 4 are from AS 11720, and 2 from AS 22490. -peter On 2016 Oct 18 (Tue) at 13:48:10 -0400 (-0400), Susan Hares wrote: :Do we know which routers are sending path attributes with 20 or 21? : :Sue : :-----Original Message----- :From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Peter Hessler :Sent: Tuesday, October 18, 2016 1:26 PM :To: idr@ietf.org :Subject: [Idr] Unknown Attributes seen in the wild : :On 2016 Oct 18 (Tue) at 12:28:09 -0400 (-0400), Jeffrey Haas wrote: ::> On Oct 18, 2016, at 12:05 PM, Nick Hilliard wrote: ::> On a related issue, it would probably be a good idea to run beacon tests ::> with other path attributes to see how they affect reachability, i.e. ::> have any other vendors squatted any other path attribute values, and if ::> large-communities is moved to 31 or 32, will it suffer the same problem? :: ::Even passive monitoring is a good start. : :I just did a check of the DFZ, both IPv4 and IPv6, and these are the :unknown/deprecated attributes on paths that I can see. : :20 Connector Attribute (deprecated) [RFC6037] :21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit] : :count type flags len data in hex :-------------------------------------------------------------- : 43 Unknown Attribute #20 flags [OTP] len 14: 00 01 00 00 58 d6 00 00 02 8e cf d2 8d b5 : 2 Unknown Attribute #21 flags [OTP] len 5: 02 00 00 57 da : 4 Unknown Attribute #21 flags [OTP] len 5: 07 00 00 2d c8 : 2 Unknown Attribute #21 flags [OTP] len 5: 14 00 00 39 72 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Tue Oct 18 12:08:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722301293D6 for ; Tue, 18 Oct 2016 12:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KD82ow8wPFfO for ; Tue, 18 Oct 2016 12:08:52 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4454012940E for ; Tue, 18 Oct 2016 12:08:52 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 09790586B2; Tue, 18 Oct 2016 19:08:52 +0000 (UTC) Date: Tue, 18 Oct 2016 19:08:51 +0000 From: heasley To: Jeffrey Haas Message-ID: <20161018190851.GC15392@shrubbery.net> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161017215134.GA464@pfrc.org> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: 'IETF IDR WG' , Susan Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 19:08:53 -0000 Mon, Oct 17, 2016 at 05:51:34PM -0400, Jeffrey Haas: > On Mon, Oct 17, 2016 at 04:27:31PM -0400, Susan Hares wrote: > > This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt. (10/17 > > to 10/31). Please comment if draft-ietf-idr-large-community-03.txt is > > ready for publication. > > As of version -03, I think the document is clear and largely ready to ship. > > My one remaining concern is the reserved communities in section 5. Given > the remaining text in the document saying "you MUST let people put whatever > they want in here", the reservation seems superfluous. > > I'd suggest outright removing the reservations. Failing that, they need to > be better justified. Part of the idea behind reserving 65535:*:* was to reserve a space that could later be used for well-knowns, if that was desired - but to not spend time now arguing about details of what well-knowns are necessary. 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs. From nobody Tue Oct 18 12:15:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2C9128E18 for ; Tue, 18 Oct 2016 12:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 vkjUKf-wa0zb for ; Tue, 18 Oct 2016 12:15:23 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 83A92127A91 for ; Tue, 18 Oct 2016 12:15:23 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bwZr7-0006Gh-TZ (job@us.ntt.net); Tue, 18 Oct 2016 19:15:22 +0000 Date: Tue, 18 Oct 2016 14:15:21 -0500 From: Job Snijders To: heasley Message-ID: <20161018191521.GT95811@Vurt.local> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161018190851.GC15392@shrubbery.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: 'IETF IDR WG' , Susan Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 19:15:24 -0000 On Tue, Oct 18, 2016 at 07:08:51PM +0000, heasley wrote: > Mon, Oct 17, 2016 at 05:51:34PM -0400, Jeffrey Haas: > > On Mon, Oct 17, 2016 at 04:27:31PM -0400, Susan Hares wrote: > > > This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt. (10/17 > > > to 10/31). Please comment if draft-ietf-idr-large-community-03.txt is > > > ready for publication. > > > > As of version -03, I think the document is clear and largely ready to ship. > > > > My one remaining concern is the reserved communities in section 5. Given > > the remaining text in the document saying "you MUST let people put whatever > > they want in here", the reservation seems superfluous. > > > > I'd suggest outright removing the reservations. Failing that, they need to > > be better justified. > > Part of the idea behind reserving 65535:*:* was to reserve a space that > could later be used for well-knowns, if that was desired - but to not > spend time now arguing about details of what well-knowns are necessary. > > 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs. Jeff argues that a justification should be added. Maybe someone can pitch in one or two sentences that explain why these are reserved? Kind regards, Job From nobody Tue Oct 18 12:29:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C388124281 for ; Tue, 18 Oct 2016 12:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 op4GgmP2x27M for ; Tue, 18 Oct 2016 12:28:37 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88087129416 for ; Tue, 18 Oct 2016 12:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6250; q=dns/txt; s=iport; t=1476818917; x=1478028517; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iRJyo5E+5hVvA5xfNTlccsoEvOyi919Jn/n7I8dcpl4=; b=UEDrBYBibc3xgf2tqIWH/ZvX9fc8mzicbEKXpiFLeqtuaw16705UahOC av2TfGvkDj8iCkXszaYGlBqUyo0eRoi3mUXqTmmueXk3Nukekg7ha0sLk LD/I3BQzfRX/5i+eFu/lVIPuNBT3Uj3DWZKPFYJ8qXW1A2vPgM9nooQWj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAQAvdwZY/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAR1XfAeNLZcFlDiCCBwLgkSDNgIagWk4FAECAQEBAQE?= =?us-ascii?q?BAWInhGEBAQEEAQEBIBETJwsMBAIBCBEEAQEBAgIfBAMCAgIlCxQBCAgCBAENB?= =?us-ascii?q?QgMiD4OtkGFAId5AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBB4U2hFWEXoJtgls?= =?us-ascii?q?FmggBj36Pfox7g38BHjZUgwYcGYE6cocZgQABAQE?= X-IronPort-AV: E=Sophos;i="5.31,511,1473120000"; d="scan'208";a="159005498" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Oct 2016 19:28:36 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u9IJSaEj014035 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Oct 2016 19:28:36 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Oct 2016 14:28:35 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Tue, 18 Oct 2016 14:28:35 -0500 From: "Jakob Heitz (jheitz)" To: "John G. Scudder" , Susan Hares Thread-Topic: [Idr] Early allocation for wide communities [was: Re: BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)] Thread-Index: AQHSKWS0G1ls8+NosUWjaTtAf4m5HaCulzlw Date: Tue, 18 Oct 2016 19:28:35 +0000 Message-ID: <242f34dfe25b497f9271435e61e2b64d@XCH-ALN-014.cisco.com> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <001801d22963$11733630$3459a290$@ndzh.com> <019F0FC9-6751-42CD-BA26-3CB0B374748E@juniper.net> In-Reply-To: <019F0FC9-6751-42CD-BA26-3CB0B374748E@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.162.58] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] Early allocation for wide communities [was: Re: BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 19:28:39 -0000 SSBoYXZlIG5vIG9iamVjdGlvbiB0byBsZXR0aW5nICJ3aWRlIiBoYXZlIGEgY29kZXBvaW50Lg0K RXZlbiBpZiBpdCBpcyBub3Qgc3RhYmxlLg0KV2lkZSBjb21tcyBjb3VsZCBhZGQgYSB2ZXJzaW9u IG51bWJlciBpbnRvIHRoZSBoZWFkZXIgdG8gc2F0aXNmeSAoYyksDQpidXQgZXZlbiBpZiBpdCBk b2Vzbid0LCBJIHdvbid0IG9iamVjdC4NCg0KVGhhbmtzLA0KSmFrb2IuDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gRy4gU2N1ZGRlcg0KPiBTZW50OiBUdWVzZGF5LCBPY3Rv YmVyIDE4LCAyMDE2IDEwOjI1IEFNDQo+IFRvOiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29t Pg0KPiBDYzogSUVURiBJRFIgV0cgPGlkckBpZXRmLm9yZz4NCj4gU3ViamVjdDogW0lkcl0gRWFy bHkgYWxsb2NhdGlvbiBmb3Igd2lkZSBjb21tdW5pdGllcyBbd2FzOiBSZTogQkdQIEF0dHJpYnV0 ZSBmb3IgTGFyZ2UgY29tbXVuaXRpZXMgKEF0dHJpYnV0ZSAzMCkNCj4gd2FzIHNxdWF0dGVkIG9u IC0gTGV0J3MgZ2V0IGEgbmV3IGF0dHJpYnV0ZSBudW1iZXIgKDEgd2VlayBXRyBjYWxsICgxMC8x OCB0byAxMC8yNSldDQo+IA0KPiBPSywgaWYgd2UncmUgZ29pbmcgc3RyYWlnaHQgdG8gdGhlIGVh cmx5IGFsbG9jYXRpb24gcmVxdWVzdCwgbGV0J3MgZm9yayB0aGUgdGhyZWFkLiBTdWJqZWN0IHVw ZGF0ZWQuDQo+IA0KPiBBcyBhIHJlbWluZGVyLCBSRkMgNzEyMCBnaXZlcyB0aGUgY3JpdGVyaWEg Zm9yIGVhcmx5IGFsbG9jYXRpb24uIFRoZSBvbmVzIEkgdGhpbmsgYXJlIHJlbGV2YW50IGZvciB0 aGlzIGRpc2N1c3Npb246DQo+IA0KPiAgICBiLiAgVGhlIGZvcm1hdCwgc2VtYW50aWNzLCBwcm9j ZXNzaW5nLCBhbmQgb3RoZXIgcnVsZXMgcmVsYXRlZCB0bw0KPiAgICAgICAgaGFuZGxpbmcgdGhl IHByb3RvY29sIGVudGl0aWVzIGRlZmluZWQgYnkgdGhlIGNvZGUgcG9pbnRzDQo+ICAgICAgICAo aGVuY2Vmb3J0aCBjYWxsZWQgInNwZWNpZmljYXRpb25zIikgbXVzdCBiZSBhZGVxdWF0ZWx5IGRl c2NyaWJlZA0KPiAgICAgICAgaW4gYW4gSW50ZXJuZXQtRHJhZnQuDQo+IA0KPiBJTU8gKHNwZWFr aW5nIGFzIGEgV0cgbWVtYmVyKSB0aGUgY3VycmVudCB3aWRlIGNvbW11bml0aWVzIGRyYWZ0IGRv ZXMgdGhpcy4NCj4gDQo+ICAgIGMuICBUaGUgc3BlY2lmaWNhdGlvbnMgb2YgdGhlc2UgY29kZSBw b2ludHMgbXVzdCBiZSBzdGFibGU7IGkuZS4sIGlmDQo+ICAgICAgICB0aGVyZSBpcyBhIGNoYW5n ZSwgaW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIHRoZSBlYXJsaWVyIGFuZCBsYXRlcg0KPiAgICAg ICAgc3BlY2lmaWNhdGlvbnMgbXVzdCBiZSBzZWFtbGVzc2x5IGludGVyb3BlcmFibGUuDQo+IA0K PiBJIGFtIG5vdCBzdXJlIHRoaXMgaXMgdHJ1ZS4gSXMgaXQ/DQo+IA0KPiAgICBkLiAgVGhlIFdv cmtpbmcgR3JvdXAgY2hhaXJzIGFuZCBBcmVhIERpcmVjdG9ycyAoQURzKSBqdWRnZSB0aGF0DQo+ ICAgICAgICB0aGVyZSBpcyBzdWZmaWNpZW50IGludGVyZXN0IGluIHRoZSBjb21tdW5pdHkgZm9y IGVhcmx5IChwcmUtUkZDKQ0KPiAgICAgICAgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQs IG9yIHRoYXQgZmFpbHVyZSB0byBtYWtlIGFuIGVhcmx5DQo+ICAgICAgICBhbGxvY2F0aW9uIG1p Z2h0IGxlYWQgdG8gY29udGVudGlvbiBmb3IgdGhlIGNvZGUgcG9pbnQgaW4gdGhlDQo+ICAgICAg ICBmaWVsZC4NCj4gDQo+IFdlIGNhbiBqdWRnZSB0aGlzIGJhc2VkIG9uIHJlc3BvbnNlIHRvIHRo aXMgdGhyZWFkLg0KPiANCj4gVGhhbmtzLA0KPiANCj4gLS1Kb2huDQo+IA0KPiBPbiBPY3QgMTgs IDIwMTYsIGF0IDE6MTQgUE0sIFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+IHdyb3RlOg0K PiA+IEplZmY6DQo+ID4NCj4gPiBUaGlzIGlzIGEgZ29vZCBpZGVhIHRvIGp1c3QgbWFrZSAxMjkg YW4gZWFybHkgYWxsb2NhdGlvbiBmb3Igd2lkZSBjb21tdW5pdGllcy4NCj4gPg0KPiA+IFN1ZQ0K PiA+DQo+ID4gRnJvbTogSmVmZnJleSBIYWFzIFttYWlsdG86amhhYXNAcGZyYy5vcmddDQo+ID4g U2VudDogVHVlc2RheSwgT2N0b2JlciAxOCwgMjAxNiAxMToxOSBBTQ0KPiA+IFRvOiBTdWUgSGFy ZXMNCj4gPiBDYzogSUVURiBJRFIgV0c7IEtyaXN0aWFuIExhcnNzb24NCj4gPiBTdWJqZWN0OiBS ZTogW0lkcl0gQkdQIEF0dHJpYnV0ZSBmb3IgTGFyZ2UgY29tbXVuaXRpZXMgKEF0dHJpYnV0ZSAz MCkgd2FzIHNxdWF0dGVkIG9uIC0gTGV0J3MgZ2V0IGEgbmV3IGF0dHJpYnV0ZQ0KPiBudW1iZXIg KDEgd2VlayBXRyBjYWxsICgxMC8xOCB0byAxMC8yNSkNCj4gPg0KPiA+IFN1ZSwNCj4gPg0KPiA+ IElmIDEyOSBpcyBub3Qgb3RoZXJ3aXNlIGNvbnRlbmRlZCBmb3IsIGl0IG1heSBiZSByZWFzb25h YmxlIHRvIHNpbXBseSByZXF1ZXN0IGVhcmx5IGFsbG9jYXRpb24gZm9yIHRoZSB3aWRlDQo+IGNv bW11bml0aWVzIGNvZGUgcG9pbnQuDQo+ID4NCj4gPiAtLSBKZWZmDQo+ID4NCj4gPj4gT24gT2N0 IDE4LCAyMDE2LCBhdCAxMTowMSBBTSwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4gd3Jv dGU6DQo+ID4+DQo+ID4+IFdHOg0KPiA+Pg0KPiA+PiBFYXJseSB0ZXN0aW5nIG9mIHRoZSBMYXJn ZSBDb21tdW5pdGllcyBkcmFmdCAoZHJhZnQtaWV0Zi1pZHItbGFyZ2UtY29tbXVuaXR5LTAzLnR4 dCkgIHdpdGggYXR0cmlidXRlIHZhbHVlIG9mIDMwDQo+IGRldGVjdCB0aGF0IHdlIGhhZCBhbiBp bXBsZW1lbnRhdGlvbiBzcXVhdHRpbmcgb24gYXR0cmlidXRlIDMwIGJ5IGEgSHVhd2VpIHJvdXRl ci4gICDigJxTcXVhdHRpbmfigJ0gb24gYW4gYXR0cmlidXRlIGlzDQo+IGFudGktc29jaWFsIGJl aGF2aW9yIGluIHRoZSBJbnRlcm5ldCBpbiBhbnkgcmVsZWFzZSBvZiBzb2Z0d2FyZS4NCj4gPj4N Cj4gPj4gVGhlIGluZGl2aWR1YWxzIHdobyBkaWQgaW4gSHVhd2VpIGhhdmUgYmVlbiBjb250YWN0 ZWQgYnkgSmllIERvbmcsIGFuZCDigJxhc2tlZOKAnSBpZiB0aGV5IGhhZCBtYWRlIHRoaXMgbWlz dGFrZSBpbg0KPiBhbnkgb3RoZXIgYXR0cmlidXRlLiAgIFRoZXNlIGluZGl2aWR1YWxzIGNvbmZl c3NlZCB0byBBdHRyaWJ1dGUgMTI5IChmb3Igd2lkZSBjb21tdW5pdGllcykuICBUaGVzZSBpbmRp dmlkdWFscw0KPiBhcG9sb2dpemUgdG8gdGhlIFdvcmtpbmcgZ3JvdXAuDQo+ID4+DQo+ID4+IE5v dyB3aGF0IHNoYWxsIHdlIGRvPyBUaGUgbGFyZ2UgY29tbXVuaXR5IGRyYWZ0IGlzIGNyaXRpY2Fs IGZvciBzZXZlcmFsIG5ldHdvcmtzLiBBZnRlciB0YWxraW5nIHdpdGggdGhlDQo+IGRldmVsb3Bl cnMgYW5kIG9wZXJhdG9ycywgSm9obiBhbmQgSSB3b3VsZCBsaWtlIHRvIHJlY29tbWVuZCB3ZSBk byB0aGUgZm9sbG93aW5nOg0KPiA+Pg0KPiA+PiBJRFIgc2hvdWxkIHJlY29tbWVuZCB0aGF0IHRo ZSBmb2xsb3dpbmcgYXR0cmlidXRlIG51bWJlcnMgYmUgZGVwcmVjYXRlZDoNCj4gPj4NCj4gPj4g QkdQIEF0dHJpYnV0ZSAzMA0KPiA+PiBCR1AgYXR0cmlidXRlIDEyOQ0KPiA+Pg0KPiA+PiBJRFIg c2hvdWxkIGFzayBJQU5BIHRvIGFzc2lnbiBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgKGN1cnJlbnRs eSBBdHRyaWJ1dGUgMzApIHRvIGEgbmV3IGF0dHJpYnV0ZSBudW1iZXIuICBUaGlzIGlzDQo+IGEg MSB3ZWVrIGNhbGwgdG8gZGV0ZXJtaW5lIGlmIHRoZSBJRFIgYXBwcm92ZXMgdGhpcyBhY3Rpb24u ICAgVGhpcyBjYWxsIHdpbGwgYWxsb3cgdGhlIGxhcmdlIGNvbW11bml0aWVzIGRyYWZ0IHRvDQo+ IHN0aWxsIGNvbnRpbnVlIHdpdGggdGhlIDIgd2VlayBXRyBMQy4NCj4gPj4NCj4gPj4gSm9obiwg QWx2YXJvLCBhbmQgSSBoYXZlIGNoZWNrIHRoZSBlYXJseSBhbGxvY2F0aW9uIHJ1bGVzLiAgSW1w bGVtZW50YXRpb25zIHNob3VsZCBhc2sgZm9yIGVhcmx5IGFsbG9jYXRpb24gcHJpb3INCj4gdG8g cmVsZWFzaW5nLCBhbmQgdGhleSBkbyBub3QgbmVlZCB0byBiZSBpbnRlcm9wZXJhYmlsaXR5IHRl c3RpbmcgdG8gcmVxdWVzdCB0aGUgZWFybHkgYWxsb2NhdGlvbiBmb3IgdGhlIGF0dHJpYnV0ZS4N Cj4gPj4NCj4gPj4gU3VlIEhhcmVzDQo+ID4+DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IElkciBtYWlsaW5nIGxpc3QNCj4g Pj4gSWRyQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWRyDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IElkciBtYWlsaW5nIGxpc3QNCj4gPiBJZHJAaWV0Zi5vcmcNCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSWRyIG1haWxpbmcgbGlzdA0K PiBJZHJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZHINCg== From nobody Tue Oct 18 13:27:17 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E5112984F for ; Tue, 18 Oct 2016 13:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 rR7JqQQznQDP for ; Tue, 18 Oct 2016 13:27:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 284A012947D for ; Tue, 18 Oct 2016 13:27:15 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id A59981E1F0; Tue, 18 Oct 2016 16:29:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Jeffrey Haas In-Reply-To: <20161018180650.GS95811@Vurt.local> Date: Tue, 18 Oct 2016 16:27:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8BC27C25-22D2-4B52-A1C8-D2C90E1D54A3@pfrc.org> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <001801d22963$11733630$3459a290$@ndzh.com> <019F0FC9-6751-42CD-BA26-3CB0B374748E@juniper.net> <20161018180650.GS95811@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3226) Archived-At: Cc: Sue Hares , IETF IDR WG Subject: Re: [Idr] Early allocation for wide communities [was: Re: BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:27:16 -0000 > On Oct 18, 2016, at 2:06 PM, Job Snijders wrote: >=20 > On Tue, Oct 18, 2016 at 01:25:25PM -0400, John G. Scudder wrote: >> c. The specifications of these code points must be stable; i.e., = if >> there is a change, implementations based on the earlier and = later >> specifications must be seamlessly interoperable. >>=20 >> I am not sure this is true. Is it?=20 >=20 > I do not believe that to be true. Wide comms was spec-wise pretty stable until recently when we tried to = accommodate large comms as a header. The amount things were perturbed = wasn't much but still was still incompatible. But I agree with the general sentiment: We want it to be at that = stability point before proceeding with the actual early allocation. =20 This also hits the interesting question about versioning to accept my = own criticisms about incremental deployment. What would be nice would be to hear the feedback from the implementors = at Huawei as to their experiences in implementing the spec. This would = give insight to the level of maturity of the draft, along with being a = lot more careful to avoid spec churn if it's actually getting traction. -- Jeff From nobody Tue Oct 18 13:32:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E73129856 for ; Tue, 18 Oct 2016 13:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 xT8AtfL9pZ5l for ; Tue, 18 Oct 2016 13:32:18 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 97740126579 for ; Tue, 18 Oct 2016 13:32:18 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bwb3Y-000EU0-UF (job@us.ntt.net); Tue, 18 Oct 2016 20:32:17 +0000 Date: Tue, 18 Oct 2016 15:32:15 -0500 From: Job Snijders To: Jeffrey Haas Message-ID: <20161018203215.GU95811@Vurt.local> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <001801d22963$11733630$3459a290$@ndzh.com> <019F0FC9-6751-42CD-BA26-3CB0B374748E@juniper.net> <20161018180650.GS95811@Vurt.local> <8BC27C25-22D2-4B52-A1C8-D2C90E1D54A3@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8BC27C25-22D2-4B52-A1C8-D2C90E1D54A3@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: Sue Hares , IETF IDR WG Subject: Re: [Idr] Early allocation for wide communities [was: Re: BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:32:20 -0000 On Tue, Oct 18, 2016 at 04:27:13PM -0400, Jeffrey Haas wrote: > > On Oct 18, 2016, at 2:06 PM, Job Snijders wrote: > > > > On Tue, Oct 18, 2016 at 01:25:25PM -0400, John G. Scudder wrote: > >> c. The specifications of these code points must be stable; i.e., if > >> there is a change, implementations based on the earlier and later > >> specifications must be seamlessly interoperable. > >> > >> I am not sure this is true. Is it? > > > > I do not believe that to be true. > > Wide comms was spec-wise pretty stable until recently when we tried to > accommodate large comms as a header. The amount things were perturbed > wasn't much but still was still incompatible. > > But I agree with the general sentiment: We want it to be at that > stability point before proceeding with the actual early allocation. > > This also hits the interesting question about versioning to accept my > own criticisms about incremental deployment. > > What would be nice would be to hear the feedback from the implementors > at Huawei as to their experiences in implementing the spec. This > would give insight to the level of maturity of the draft, along with > being a lot more careful to avoid spec churn if it's actually getting > traction. Yes, implementor feedback before an early allocation makes a lot of sense. From nobody Tue Oct 18 13:38:04 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CC4129472 for ; Tue, 18 Oct 2016 13:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jbsnCtc67E7Z for ; Tue, 18 Oct 2016 13:38:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4215E129460 for ; Tue, 18 Oct 2016 13:38:02 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 7FC171E1F0; Tue, 18 Oct 2016 16:40:10 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6450A86E-BD00-4A38-AB01-42D1E18F2623" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Jeffrey Haas In-Reply-To: <20161018191521.GT95811@Vurt.local> Date: Tue, 18 Oct 2016 16:38:00 -0400 Message-Id: <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3226) Archived-At: Cc: heasley , IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:38:04 -0000 --Apple-Mail=_6450A86E-BD00-4A38-AB01-42D1E18F2623 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 18, 2016, at 3:15 PM, Job Snijders wrote: >=20 >>=20 >> Part of the idea behind reserving 65535:*:* was to reserve a space = that >> could later be used for well-knowns, if that was desired - but to not >> spend time now arguing about details of what well-knowns are = necessary. >>=20 >> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs. >=20 > Jeff argues that a justification should be added. Maybe someone can > pitch in one or two sentences that explain why these are reserved? That's certainly part of it. While I think many people can see the = reason why you might want to do such a reservation, to do so you should = have a practical reason in the document. For the 65535:*:* case, for symmetry with RFC 1997, you'd probably want = to note that if it's used for that symmetry that either the existing = well known community registry is used at IANA or that a new one would = need to be created. Alternatively, you just say the work is expected = and defer to a future document. Note by doing this, you're setting up some expectations about = translation of communities from one space to another. FWIW, I don't = recommend this and simply suggest that you recommend *not* using these = for common use in case someone decides that they want to do so. I know = your organization and others such as Deutsche Telecom have some thoughts = about what translation infrastructure might look like, and such = mechanisms would have impact. With regard to the 0: and max-uint32: cases, after dealing with the = headaches associated with helping with documents such as the as0 and RFC = 7300 and putting in some restrictions in the configuration... followed = by having to take them away, I'm very reluctant to put in anything = beyond "we think it's a bad idea to use these, so pretty please don't" -- Jeff (ask me about my RFC 7300 hate mail over beer...)= --Apple-Mail=_6450A86E-BD00-4A38-AB01-42D1E18F2623 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 18, 2016, at 3:15 PM, Job Snijders <job@ntt.net> = wrote:


Part of the = idea behind reserving 65535:*:* was to reserve a space that
could later be used for well-knowns, if that was desired - = but to not
spend time now arguing about details of what = well-knowns are necessary.

0:*:* and = 4294967295:*:* mimics rfc1997 and the reserved ASNs.

Jeff argues that a justification should be = added. Maybe someone can
pitch in one or two sentences that = explain why these are reserved?

That's certainly part of it.  While I think many people = can see the reason why you might want to do such a reservation, to do so = you should have a practical reason in the document.

For the 65535:*:* case, = for symmetry with RFC 1997, you'd probably want to note that if it's = used for that symmetry that either the existing well known community = registry is used at IANA or that a new one would need to be created. =  Alternatively, you just say the work is expected and defer to a = future document.

Note by doing this, you're setting up some expectations about = translation of communities from one space to another.  FWIW, I = don't recommend this and simply suggest that you recommend *not* using = these for common use in case someone decides that they want to do so. =  I know your organization and others such as Deutsche Telecom have = some thoughts about what translation infrastructure might look like, and = such mechanisms would have impact.

With regard to the 0: and max-uint32: = cases, after dealing with the headaches associated with helping with = documents such as the as0 and RFC 7300 and putting in some restrictions = in the configuration... followed by having to take them away, I'm very = reluctant to put in anything beyond "we think it's a bad idea to use = these, so pretty please don't"

-- Jeff (ask me about my RFC 7300 hate = mail over beer...)
= --Apple-Mail=_6450A86E-BD00-4A38-AB01-42D1E18F2623-- From nobody Tue Oct 18 13:43:01 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF25312987C for ; Tue, 18 Oct 2016 13:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 puaHeRv-OrdC for ; Tue, 18 Oct 2016 13:42:59 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 13B841296E3 for ; Tue, 18 Oct 2016 13:42:59 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 65EA81E1F0; Tue, 18 Oct 2016 16:45:07 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_41684514-25B2-4FE0-A78A-7714D202A2FF" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Jeffrey Haas In-Reply-To: Date: Tue, 18 Oct 2016 16:42:56 -0400 Message-Id: <76457807-16D9-4358-B618-1BDAB7EEBEF6@pfrc.org> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <001801d22963$11733630$3459a290$@ndzh.com> <20161018175753.GD10221@dhcp-157.238.255.122.noc.gin.ntt.net> To: Robert Raszuk X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF IDR WG , Kristian Larsson , Sue Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:43:00 -0000 --Apple-Mail=_41684514-25B2-4FE0-A78A-7714D202A2FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Robert, > On Oct 18, 2016, at 2:14 PM, Robert Raszuk wrote: >=20 >=20 > I would tend to agree with Job here.=20 >=20 > I see no point to reserve already known to be "overloaded" code point = for wide or for that matter any new BGP attribute.=20 >=20 > That's the price we pay for no BGP Police or BGP FBI/GBI ... = (G=3Dglobal) To clarify my original point, I think holding onto it for early = allocation makes sense. Whether or not the code Huawei is working on is ready for such an = allocation is a different matter. But if the code point is otherwise = associated with the feature, incremental rollout issues aside, seems = reasonable to not waste that code point. -- Jeff (I don't feel super strong about this, but see other threads) --Apple-Mail=_41684514-25B2-4FE0-A78A-7714D202A2FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Robert,

On Oct 18, 2016, at 2:14 PM, = Robert Raszuk <robert@raszuk.net> wrote:


I would = tend to agree with Job here. 

I see = no point to reserve already known to be "overloaded" code point for wide = or for that matter any new BGP attribute. 

That's = the price we pay for no BGP Police or BGP FBI/GBI  ... = (G=3Dglobal)

To = clarify my original point, I think holding onto it for early allocation = makes sense.

Whether or not the code = Huawei is working on is ready for such an allocation is a different = matter.  But if the code point is otherwise associated with the = feature, incremental rollout issues aside, seems reasonable to not waste = that code point.

-- Jeff (I don't = feel super strong about this, but see other threads)

= --Apple-Mail=_41684514-25B2-4FE0-A78A-7714D202A2FF-- From nobody Tue Oct 18 13:50:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CDC12986B for ; Tue, 18 Oct 2016 13:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2OrNVpduNLf1 for ; Tue, 18 Oct 2016 13:50:17 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4A8412985C for ; Tue, 18 Oct 2016 13:50:16 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id z189so14850768wmb.1 for ; Tue, 18 Oct 2016 13:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rbNx6qMgtnXEbR2eZFuUr8U3osYS8mcZGcuUGU8KFAw=; b=C9SDZN5NDSE5fXABVH46BynRN5KpVAWj0PgIML+i9bi+cJLSFoFBIP/pGKRT1/B4YK M7rmQqPo1fJxIN6L8SGFr8JeAm0uwNC0zQwgDDSDoi0E/x8sy4Y+7f05KtHM0rFRGq5K 4oJfGqnu+BKC1RlmSMTG27ZO6YMe+zJZDs6uj64tsICxvhub+EOCEeZusRDhi9IL5ncv u2NATPnseNwGZr9T7p0PL7OZ4EPy0K7pYBseODHzuBWpnxePlnwRSFIp85HuGyX6yCzs Bv0EwmUX0Gy3Ddokkf0rgeMI0s/phpRbaGFD5jhD8f4PbznCgDaEo46DHegQG9lRsaHP eEag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rbNx6qMgtnXEbR2eZFuUr8U3osYS8mcZGcuUGU8KFAw=; b=bBMBDKDcx1s+4heWpO+wmia3cKaK39Gh0GxnsUOzOob4wpzUWsvldu3NAyrnbyZaDW 81Cp6xq9TNVusqBbcXv1w6nbkh0fGMtmDNHzRUEzmLuwWKuVRClYhUu9hEvpTlr7pu5L QjTL+v5LXLscJmniAGRTnEItJbYeLTxEcEELEONNHVht3DnvLR3nxQ99gP1xAydA+bfD 9+Hn9CouLSp3f+a5wJxc29pFNhRb2/alu4QtRv/w2OxXz0/9BSnWeXaUx8phMGM+k+6d E2l/lVJiu//WzCFr1KUfXH/VVQTgZ7CO8Xsz36LHqGmJSg6bGY359sHBoXhzovT1HsAm ve5A== X-Gm-Message-State: AA6/9RmFoKciuJcwsavPHKbD3ghY/SXOCs8w4bBs9rveHkyLNUvPIog8pSHHet7zHwJaC8ONDj/Tp1QnlXeRkQ== X-Received: by 10.28.185.137 with SMTP id j131mr2112970wmf.73.1476823815358; Tue, 18 Oct 2016 13:50:15 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Tue, 18 Oct 2016 13:50:14 -0700 (PDT) In-Reply-To: <76457807-16D9-4358-B618-1BDAB7EEBEF6@pfrc.org> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <001801d22963$11733630$3459a290$@ndzh.com> <20161018175753.GD10221@dhcp-157.238.255.122.noc.gin.ntt.net> <76457807-16D9-4358-B618-1BDAB7EEBEF6@pfrc.org> From: Robert Raszuk Date: Tue, 18 Oct 2016 22:50:14 +0200 X-Google-Sender-Auth: TfbcPrAcVMfbtvtgE5ydvrcp6H8 Message-ID: To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a1148e560e90e20053f29d669 Archived-At: Cc: IETF IDR WG , Kristian Larsson , Sue Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:50:18 -0000 --001a1148e560e90e20053f29d669 Content-Type: text/plain; charset=UTF-8 Hi Jeff, IDR has a rule to progress any doc which demonstrates two implementations. That means that each draft which requires new BGP attribute and is accepted as an IDR WG doc should get IANA code point such that implementations could be delivered without risking any further inter-operability or deployment issues. Not sure how long WG should wait before such code point is depreciated though ... but without it being allocated in some way it is going to always be a challenge. /RR. On Tue, Oct 18, 2016 at 10:42 PM, Jeffrey Haas wrote: > Robert, > > On Oct 18, 2016, at 2:14 PM, Robert Raszuk wrote: > > > I would tend to agree with Job here. > > I see no point to reserve already known to be "overloaded" code point for > wide or for that matter any new BGP attribute. > > That's the price we pay for no BGP Police or BGP FBI/GBI ... (G=global) > > > To clarify my original point, I think holding onto it for early allocation > makes sense. > > Whether or not the code Huawei is working on is ready for such an > allocation is a different matter. But if the code point is otherwise > associated with the feature, incremental rollout issues aside, seems > reasonable to not waste that code point. > > -- Jeff (I don't feel super strong about this, but see other threads) > > --001a1148e560e90e20053f29d669 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jeff,

IDR has a rule to progress any doc which demonstrate= s two implementations. That means that each draft which requires new BGP at= tribute and is accepted as an IDR WG doc should get IANA code point such th= at implementations could be delivered without risking any further inter-ope= rability or deployment issues.=C2=A0

Not sure how long WG should wait before such code point is d= epreciated though ... but without it being allocated in some way it is goin= g to always be a challenge.

/RR.


On Tue, Oct 18, 2016 at 10:42 PM, Jeffrey= Haas <jhaas@pfrc.org> wrote:
Robert,

=
On Oct 18, 2016, at 2:14 PM, Robert Raszuk &= lt;robert@raszuk.net= > wrote:


I would tend to agree with Job here.=C2=A0

<= /div>
I see no point to reserve already known to be "= ;overloaded" code point for wide or for that matter any new BGP attrib= ute.=C2=A0

That's = the price we pay for no BGP Police or BGP FBI/GBI =C2=A0... (G=3Dglobal)

To clarify my original po= int, I think holding onto it for early allocation makes sense.
Whether or not the code Huawei is working on is ready for such= an allocation is a different matter.=C2=A0 But if the code point is otherw= ise associated with the feature, incremental rollout issues aside, seems re= asonable to not waste that code point.

-- Jeff (I = don't feel super strong about this, but see other threads)

--001a1148e560e90e20053f29d669-- From nobody Tue Oct 18 14:41:08 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0F512989B for ; Tue, 18 Oct 2016 14:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=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 SzeYw-zqaVsy for ; Tue, 18 Oct 2016 14:41:05 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB461298C6 for ; Tue, 18 Oct 2016 14:40:53 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.137.219.91; Date: Tue, 18 Oct 2016 16:40:44 -0500 Message-ID: <0aqugaxqujqb9pjsxq892t95.1476826844624@email.android.com> Importance: normal From: Susan Hares To: Robert Raszuk , Jeffrey Haas MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_5308894176352130" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: IETF IDR WG , Kristian Larsson Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 21:41:08 -0000 ----_com.samsung.android.email_5308894176352130 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Um9iZXJ0ClNlZSB0aGUgaWFuYSBydWxlcyBvbiBob3cgbG9uZyBlYXJseSBhbGxvY2F0aW9ucyBj YW4gYmUga2VwdCBhbmQgcmVuZXdlZC4gwqBSRkMgd2FzIGxpc3RlZCBpbiBlYXJsaWVyIGVtYWls LgpTdWUKClNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBOb3RlNSwgYW4gQVQmVCA0RyBMVEUg c21hcnRwaG9uZQotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTogUm9iZXJ0 IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+IERhdGU6IDEwLzE4LzE2ICAzOjUwIFBNICAoR01U LTA2OjAwKSBUbzogSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZz4gQ2M6IEpvYiBTbmlqZGVy cyA8am9iQGluc3RpdHV1dC5uZXQ+LCBJRVRGIElEUiBXRyA8aWRyQGlldGYub3JnPiwgS3Jpc3Rp YW4gTGFyc3NvbiA8a2xsQGRldi50ZXJhc3RybS5uZXQ+LCBTdWUgSGFyZXMgPHNoYXJlc0BuZHpo LmNvbT4gU3ViamVjdDogUmU6IFtJZHJdIEJHUCBBdHRyaWJ1dGUgZm9yIExhcmdlIGNvbW11bml0 aWVzIChBdHRyaWJ1dGUgMzApIHdhcyBzcXVhdHRlZCBvbiAtIExldCdzIGdldCBhIG5ldyBhdHRy aWJ1dGUgbnVtYmVyICgxIHdlZWsgV0cgY2FsbCAoMTAvMTggdG8gMTAvMjUpIApIaSBKZWZmLApJ RFIgaGFzIGEgcnVsZSB0byBwcm9ncmVzcyBhbnkgZG9jIHdoaWNoIGRlbW9uc3RyYXRlcyB0d28g aW1wbGVtZW50YXRpb25zLiBUaGF0IG1lYW5zIHRoYXQgZWFjaCBkcmFmdCB3aGljaCByZXF1aXJl cyBuZXcgQkdQIGF0dHJpYnV0ZSBhbmQgaXMgYWNjZXB0ZWQgYXMgYW4gSURSIFdHIGRvYyBzaG91 bGQgZ2V0IElBTkEgY29kZSBwb2ludCBzdWNoIHRoYXQgaW1wbGVtZW50YXRpb25zIGNvdWxkIGJl IGRlbGl2ZXJlZCB3aXRob3V0IHJpc2tpbmcgYW55IGZ1cnRoZXIgaW50ZXItb3BlcmFiaWxpdHkg b3IgZGVwbG95bWVudCBpc3N1ZXMuwqAKTm90IHN1cmUgaG93IGxvbmcgV0cgc2hvdWxkIHdhaXQg YmVmb3JlIHN1Y2ggY29kZSBwb2ludCBpcyBkZXByZWNpYXRlZCB0aG91Z2ggLi4uIGJ1dCB3aXRo b3V0IGl0IGJlaW5nIGFsbG9jYXRlZCBpbiBzb21lIHdheSBpdCBpcyBnb2luZyB0byBhbHdheXMg YmUgYSBjaGFsbGVuZ2UuCi9SUi4KCk9uIFR1ZSwgT2N0IDE4LCAyMDE2IGF0IDEwOjQyIFBNLCBK ZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3JnPiB3cm90ZToKUm9iZXJ0LApPbiBPY3QgMTgsIDIw MTYsIGF0IDI6MTQgUE0sIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PiB3cm90ZToK Ckkgd291bGQgdGVuZCB0byBhZ3JlZSB3aXRoIEpvYiBoZXJlLsKgCkkgc2VlIG5vIHBvaW50IHRv IHJlc2VydmUgYWxyZWFkeSBrbm93biB0byBiZSAib3ZlcmxvYWRlZCIgY29kZSBwb2ludCBmb3Ig d2lkZSBvciBmb3IgdGhhdCBtYXR0ZXIgYW55IG5ldyBCR1AgYXR0cmlidXRlLsKgClRoYXQncyB0 aGUgcHJpY2Ugd2UgcGF5IGZvciBubyBCR1AgUG9saWNlIG9yIEJHUCBGQkkvR0JJIMKgLi4uIChH PWdsb2JhbCkKVG8gY2xhcmlmeSBteSBvcmlnaW5hbCBwb2ludCwgSSB0aGluayBob2xkaW5nIG9u dG8gaXQgZm9yIGVhcmx5IGFsbG9jYXRpb24gbWFrZXMgc2Vuc2UuCldoZXRoZXIgb3Igbm90IHRo ZSBjb2RlIEh1YXdlaSBpcyB3b3JraW5nIG9uIGlzIHJlYWR5IGZvciBzdWNoIGFuIGFsbG9jYXRp b24gaXMgYSBkaWZmZXJlbnQgbWF0dGVyLsKgIEJ1dCBpZiB0aGUgY29kZSBwb2ludCBpcyBvdGhl cndpc2UgYXNzb2NpYXRlZCB3aXRoIHRoZSBmZWF0dXJlLCBpbmNyZW1lbnRhbCByb2xsb3V0IGlz c3VlcyBhc2lkZSwgc2VlbXMgcmVhc29uYWJsZSB0byBub3Qgd2FzdGUgdGhhdCBjb2RlIHBvaW50 LgotLSBKZWZmIChJIGRvbid0IGZlZWwgc3VwZXIgc3Ryb25nIGFib3V0IHRoaXMsIGJ1dCBzZWUg b3RoZXIgdGhyZWFkcykKCgo= ----_com.samsung.android.email_5308894176352130 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PlJvYmVydDwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+U2VlIHRoZSBpYW5hIHJ1bGVzIG9uIGhvdyBsb25nIGVhcmx5IGFsbG9j YXRpb25zIGNhbiBiZSBrZXB0IGFuZCByZW5ld2VkLiAmbmJzcDtSRkMgd2FzIGxpc3RlZCBpbiBl YXJsaWVyIGVtYWlsLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+U3VlPC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48ZGl2IHN0 eWxlPSJmb250LXNpemU6ODUlO2NvbG9yOiM1NzU3NTciIGRpcj0iYXV0byI+U2VudCB2aWEgdGhl IFNhbXN1bmcgR2FsYXh5IE5vdGU1LCBhbiBBVCZhbXA7VCA0RyBMVEUgc21hcnRwaG9uZTwvZGl2 PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMw MDAwMDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVz c2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogUm9iZXJ0IFJhc3p1ayAmbHQ7cm9iZXJ0QHJh c3p1ay5uZXQmZ3Q7IDwvZGl2PjxkaXY+RGF0ZTogMTAvMTgvMTYgIDM6NTAgUE0gIChHTVQtMDY6 MDApIDwvZGl2PjxkaXY+VG86IEplZmZyZXkgSGFhcyAmbHQ7amhhYXNAcGZyYy5vcmcmZ3Q7IDwv ZGl2PjxkaXY+Q2M6IEpvYiBTbmlqZGVycyAmbHQ7am9iQGluc3RpdHV1dC5uZXQmZ3Q7LCBJRVRG IElEUiBXRyAmbHQ7aWRyQGlldGYub3JnJmd0OywgS3Jpc3RpYW4gTGFyc3NvbiAmbHQ7a2xsQGRl di50ZXJhc3RybS5uZXQmZ3Q7LCBTdWUgSGFyZXMgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDsgPC9k aXY+PGRpdj5TdWJqZWN0OiBSZTogW0lkcl0gQkdQIEF0dHJpYnV0ZSBmb3IgTGFyZ2UgY29tbXVu aXRpZXMgKEF0dHJpYnV0ZSAzMCkgd2FzIHNxdWF0dGVkIG9uIC0gTGV0J3MgZ2V0IGEgbmV3IGF0 dHJpYnV0ZSBudW1iZXIgKDEgd2VlayBXRyBjYWxsICgxMC8xOCB0byAxMC8yNSkgPC9kaXY+PGRp dj48YnI+PC9kaXY+PC9kaXY+PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVs dCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6 ZTpzbWFsbCI+SGkgSmVmZiw8L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0i Zm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj48 YnI+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+SURSIGhhcyBhIHJ1bGUg dG8gcHJvZ3Jlc3MgYW55IGRvYyB3aGljaCBkZW1vbnN0cmF0ZXMgdHdvIGltcGxlbWVudGF0aW9u cy4gVGhhdCBtZWFucyB0aGF0IGVhY2ggZHJhZnQgd2hpY2ggcmVxdWlyZXMgbmV3IEJHUCBhdHRy aWJ1dGUgYW5kIGlzIGFjY2VwdGVkIGFzIGFuIElEUiBXRyBkb2Mgc2hvdWxkIGdldCBJQU5BIGNv ZGUgcG9pbnQgc3VjaCB0aGF0IGltcGxlbWVudGF0aW9ucyBjb3VsZCBiZSBkZWxpdmVyZWQgd2l0 aG91dCByaXNraW5nIGFueSBmdXJ0aGVyIGludGVyLW9wZXJhYmlsaXR5IG9yIGRlcGxveW1lbnQg aXNzdWVzLiZuYnNwOzwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250 LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPjxicj48 L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWws aGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj5Ob3Qgc3VyZSBob3cgbG9uZyBX RyBzaG91bGQgd2FpdCBiZWZvcmUgc3VjaCBjb2RlIHBvaW50IGlzIGRlcHJlY2lhdGVkIHRob3Vn aCAuLi4gYnV0IHdpdGhvdXQgaXQgYmVpbmcgYWxsb2NhdGVkIGluIHNvbWUgd2F5IGl0IGlzIGdv aW5nIHRvIGFsd2F5cyBiZSBhIGNoYWxsZW5nZS48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9kZWZh dWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1z aXplOnNtYWxsIj48YnI+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZv bnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+L1JS LjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlh bCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPjxicj48L2Rpdj48L2Rpdj48 ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBU dWUsIE9jdCAxOCwgMjAxNiBhdCAxMDo0MiBQTSwgSmVmZnJleSBIYWFzIDxzcGFuIGRpcj0ibHRy Ij4mbHQ7PGEgaHJlZj0ibWFpbHRvOmpoYWFzQHBmcmMub3JnIiB0YXJnZXQ9Il9ibGFuayI+amhh YXNAcGZyYy5vcmc8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk Ij5Sb2JlcnQsPGRpdj48YnI+PGRpdj48c3BhbiBjbGFzcz0iIj48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48ZGl2Pk9uIE9jdCAxOCwgMjAxNiwgYXQgMjoxNCBQTSwgUm9iZXJ0IFJhc3p1ayAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0 QHJhc3p1ay5uZXQ8L2E+Jmd0OyB3cm90ZTo8L2Rpdj48YnIgY2xhc3M9Im1fLTg0OTI4NTQwODQ5 NDc2OTA2NTJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj48ZGl2PjxkaXYgZGlyPSJsdHIiPjxk aXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFp bF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7 Zm9udC1zaXplOnNtYWxsIj5JIHdvdWxkIHRlbmQgdG8gYWdyZWUgd2l0aCBKb2IgaGVyZS4mbmJz cDs8L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj48YnI+PC9kaXY+PGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+SSBzZWUgbm8gcG9pbnQgdG8gcmVzZXJ2ZSBhbHJl YWR5IGtub3duIHRvIGJlICJvdmVybG9hZGVkIiBjb2RlIHBvaW50IGZvciB3aWRlIG9yIGZvciB0 aGF0IG1hdHRlciBhbnkgbmV3IEJHUCBhdHRyaWJ1dGUuJm5ic3A7PC9kaXY+PGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+PGJyPjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6 c21hbGwiPlRoYXQncyB0aGUgcHJpY2Ugd2UgcGF5IGZvciBubyBCR1AgUG9saWNlIG9yIEJHUCBG QkkvR0JJICZuYnNwOy4uLiAoRz1nbG9iYWwpPC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3Rl PjxkaXY+PGJyPjwvZGl2Pjwvc3Bhbj5UbyBjbGFyaWZ5IG15IG9yaWdpbmFsIHBvaW50LCBJIHRo aW5rIGhvbGRpbmcgb250byBpdCBmb3IgZWFybHkgYWxsb2NhdGlvbiBtYWtlcyBzZW5zZS48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PldoZXRoZXIgb3Igbm90IHRoZSBjb2RlIEh1YXdlaSBpcyB3 b3JraW5nIG9uIGlzIHJlYWR5IGZvciBzdWNoIGFuIGFsbG9jYXRpb24gaXMgYSBkaWZmZXJlbnQg bWF0dGVyLiZuYnNwOyBCdXQgaWYgdGhlIGNvZGUgcG9pbnQgaXMgb3RoZXJ3aXNlIGFzc29jaWF0 ZWQgd2l0aCB0aGUgZmVhdHVyZSwgaW5jcmVtZW50YWwgcm9sbG91dCBpc3N1ZXMgYXNpZGUsIHNl ZW1zIHJlYXNvbmFibGUgdG8gbm90IHdhc3RlIHRoYXQgY29kZSBwb2ludC48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2Pi0tIEplZmYgKEkgZG9uJ3QgZmVlbCBzdXBlciBzdHJvbmcgYWJvdXQgdGhp cywgYnV0IHNlZSBvdGhlciB0aHJlYWRzKTwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PjwvZGl2 PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+CjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_5308894176352130-- From nobody Tue Oct 18 19:19:45 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A193129517 for ; Tue, 18 Oct 2016 19:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=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 1IWfVj8FltP5 for ; Tue, 18 Oct 2016 19:19:41 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EE5129512 for ; Tue, 18 Oct 2016 19:19:40 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.177.186.123; Date: Tue, 18 Oct 2016 22:19:29 -0400 Message-ID: Importance: normal From: Susan Hares To: Michael H Lambert , IETF IDR WG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_5362982961720410" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Kristian Larsson Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 02:19:43 -0000 ----_com.samsung.android.email_5362982961720410 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 TWljaGFlbAo8aW5kaXZpZHVhbCBjb250cmlidXRvciBoYXQgb24+QWZ0ZXIgbGlzdGVuaW5nIHRv IG51bWVyb3VzIHRhbGtzIGF0IG5hbm9nIGFib3V0IG9wZW4gc291cmNlIGJncCBpbXBsZW1lbnRh dGlvbnMgLSBpdCBpcyBlcXVhbGx5IGltcG9ydGFudCB0byBjb25zaWRlciBvcGVuIHNvdXJjZSBz aW5jZSBpdCBpcyBiZWluZyB1c2VkIGluIG1hbnkgbmV0d29ya3MuCldoYXQgaXMgbW9zdCBpbXBv cnRhbnQgaXMgdG8gcHJvdGVjdCBsYXJnZSBjb21tdW5pdGllcyBmcm9tIGhhdmluZyBwcm9ibGVt cy4KU3VlCgoKU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IE5vdGU1LCBhbiBBVCZUIDRHIExU RSBzbWFydHBob25lCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBNaWNo YWVsIEggTGFtYmVydCA8bGFtYmVydEBwc2MuZWR1PiBEYXRlOiAxMC8xOC8xNiAgMTE6NDQgQU0g IChHTVQtMDU6MDApIFRvOiBJRVRGIElEUiBXRyA8aWRyQGlldGYub3JnPiBDYzogS3Jpc3RpYW4g TGFyc3NvbiA8a2xsQGRldi50ZXJhc3RybS5uZXQ+IFN1YmplY3Q6IFJlOiBbSWRyXSBCR1AgQXR0 cmlidXRlIGZvciBMYXJnZSBjb21tdW5pdGllcyAoQXR0cmlidXRlIDMwKSB3YXMKwqAgc3F1YXR0 ZWQgb24gLSBMZXQncyBnZXQgYSBuZXcgYXR0cmlidXRlIG51bWJlciAoMSB3ZWVrIFdHIGNhbGwg KDEwLzE4IHRvCsKgIDEwLzI1KSAKPiBPbiAxOCBPY3QgMjAxNiwgYXQgMTE6MzAsIEpvYiBTbmlq ZGVycyA8am9iQG50dC5uZXQ+IHdyb3RlOgo+IAo+IEkgc3VwcG9ydCB0aGlzIGNvdXJzZSBvZiBh Y3Rpb24uCj4gCj4gYmFja2dyb3VuZDogU29tZSBpbiB0aGUgd29ya2luZyBncm91cCBtaWdodCB3 b25kZXIgd2h5IExhcmdlIHNob3VsZAo+IGNoYW5nZSBpbnN0ZWFkIG9mIEh1YXdlaS4KPiAKPiBI dWF3ZWkgcm91dGVycyBhcmUgdHJlYXRpbmcgcm91dGVzIHdpdGggTGFyZ2UgQkdQIENvbW11bml0 aWVzIGFzCj4gIndpdGhkcmF3Iiwgd2hpY2ggbWFrZXMgTGFyZ2UgQkdQIENvbW11bml0aWVzIGRl cGxveW1lbnRzIHN1ZmZlci4gTGFyZ2UKPiBCR1AgQ29tbXVuaXRpZXMgdXNlcnMgYmVjb21lIHVu cmVhY2hhYmxlIG9uIGF0dHJpYnV0ZSAzMC4KPiAKPiBIYWQgdGhlIHNxdWF0dGluZyByZXN1bHRl ZCBpbiBIdWF3ZWkgcm91dGVycyBjcmFzaGluZyBvciBzb21lIG90aGVyIGZvcm0KPiBvZiBkYW1h Z2Ugb24gdGhlIEh1YXdlaSBzaWRlLCB0aGUgb251cyB3b3VsZCBiZSBvbiBIdWF3ZWkgdXNlcnMu IFRoaXMgaXMKPiBub3QgdGhlIGNhc2UgdW5mb3J0dW5hdGx5Lgo+IAo+IFRoZXJlIGFyZSBubyB3 aW5uZXJzIGlmIGVpdGhlciBzaWRlIGhvbGRzIHRoZWlyIGdyb3VuZCBhbmQgcmVtYWlucyBvbgo+ IHRoZSBjb2RlcG9pbnQuIEZvciBMYXJnZSBCR1AgQ29tbXVuaXRpZXMgaXQgaXMgc3RpbGwgZWFy bHkgZW5vdWdoIHRvCj4gdXBkYXRlIHRoZSBpbXBsZW1lbnRhdGlvbnMuIENoYW5naW5nIHRoZSBM YXJnZSBCR1AgQ29tbXVuaXRpZXMgcGF0aAo+IGF0dHJpYnV0ZSB2YWx1ZSBpcyBhIHJpc2sgYWR2 ZXJzZSBzdHJhdGVneS4KCldvdWxkIHRoZSBzYW1lIGNvdXJzZSBvZiBhY3Rpb24gYmUgcmVjb21t ZW5kZWQgaWYgaXQgd2VyZSBhbiBvcGVuLXNvdXJjZSBwcm9qZWN0IChlZyBiaXJkIG9yIHF1YWdn YSksIHJhdGhlciB0aGFuIGEgY29tbWVyY2lhbCByb3V0ZXIgdmVuZG9yLCBzcXVhdHRpbmcgb24g YXR0cmlidXRlIDMwP8KgIElmIHRoZSBhbnN3ZXIgaXMgYW4gdW5lcXVpdm9jYWwgeWVzLCB0aGVu IEkgYWdyZWUgd2l0aCB0aGUgcHJvcG9zZWQgY291cnNlIG9mIGFjdGlvbi7CoCBPdGhlcndpc2Us IEkgdGhpbmsgdGhlIGJ1cmRlbiBmYWxscyBvbiB0aGUgdmVuZG9yIHRvIGZpeCB0aGVpciAod2l0 aCByZXNwZWN0IHRvIHN0YW5kYXJkcykgYnJva2VuIGltcGxlbWVudGF0aW9uLgoKTWljaGFlbAoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSWRyIG1haWxp bmcgbGlzdApJZHJAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZHIK ----_com.samsung.android.email_5362982961720410 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2Pk1pY2hhZWw8L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PiZsdDtpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yIGhhdCBvbiZndDs8L2Rp dj48ZGl2PkFmdGVyIGxpc3RlbmluZyB0byBudW1lcm91cyB0YWxrcyBhdCBuYW5vZyBhYm91dCBv cGVuIHNvdXJjZSBiZ3AgaW1wbGVtZW50YXRpb25zIC0gaXQgaXMgZXF1YWxseSBpbXBvcnRhbnQg dG8gY29uc2lkZXIgb3BlbiBzb3VyY2Ugc2luY2UgaXQgaXMgYmVpbmcgdXNlZCBpbiBtYW55IG5l dHdvcmtzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+V2hhdCBpcyBtb3N0IGltcG9ydGFudCBp cyB0byBwcm90ZWN0IGxhcmdlIGNvbW11bml0aWVzIGZyb20gaGF2aW5nIHByb2JsZW1zLjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+U3VlPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48ZGl2IHN0eWxl PSJmb250LXNpemU6ODUlO2NvbG9yOiM1NzU3NTciIGRpcj0iYXV0byI+U2VudCB2aWEgdGhlIFNh bXN1bmcgR2FsYXh5IE5vdGU1LCBhbiBBVCZhbXA7VCA0RyBMVEUgc21hcnRwaG9uZTwvZGl2Pjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAw MDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2Fn ZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogTWljaGFlbCBIIExhbWJlcnQgJmx0O2xhbWJlcnRA cHNjLmVkdSZndDsgPC9kaXY+PGRpdj5EYXRlOiAxMC8xOC8xNiAgMTE6NDQgQU0gIChHTVQtMDU6 MDApIDwvZGl2PjxkaXY+VG86IElFVEYgSURSIFdHICZsdDtpZHJAaWV0Zi5vcmcmZ3Q7IDwvZGl2 PjxkaXY+Q2M6IEtyaXN0aWFuIExhcnNzb24gJmx0O2tsbEBkZXYudGVyYXN0cm0ubmV0Jmd0OyA8 L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbSWRyXSBCR1AgQXR0cmlidXRlIGZvciBMYXJnZSBjb21t dW5pdGllcyAoQXR0cmlidXRlIDMwKSB3YXMKJm5ic3A7IHNxdWF0dGVkIG9uIC0gTGV0J3MgZ2V0 IGEgbmV3IGF0dHJpYnV0ZSBudW1iZXIgKDEgd2VlayBXRyBjYWxsICgxMC8xOCB0bwombmJzcDsg MTAvMjUpIDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PiZndDsgT24gMTggT2N0IDIwMTYsIGF0 IDExOjMwLCBKb2IgU25pamRlcnMgJmx0O2pvYkBudHQubmV0Jmd0OyB3cm90ZTo8YnI+Jmd0OyA8 YnI+Jmd0OyBJIHN1cHBvcnQgdGhpcyBjb3Vyc2Ugb2YgYWN0aW9uLjxicj4mZ3Q7IDxicj4mZ3Q7 IGJhY2tncm91bmQ6IFNvbWUgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgbWlnaHQgd29uZGVyIHdoeSBM YXJnZSBzaG91bGQ8YnI+Jmd0OyBjaGFuZ2UgaW5zdGVhZCBvZiBIdWF3ZWkuPGJyPiZndDsgPGJy PiZndDsgSHVhd2VpIHJvdXRlcnMgYXJlIHRyZWF0aW5nIHJvdXRlcyB3aXRoIExhcmdlIEJHUCBD b21tdW5pdGllcyBhczxicj4mZ3Q7ICJ3aXRoZHJhdyIsIHdoaWNoIG1ha2VzIExhcmdlIEJHUCBD b21tdW5pdGllcyBkZXBsb3ltZW50cyBzdWZmZXIuIExhcmdlPGJyPiZndDsgQkdQIENvbW11bml0 aWVzIHVzZXJzIGJlY29tZSB1bnJlYWNoYWJsZSBvbiBhdHRyaWJ1dGUgMzAuPGJyPiZndDsgPGJy PiZndDsgSGFkIHRoZSBzcXVhdHRpbmcgcmVzdWx0ZWQgaW4gSHVhd2VpIHJvdXRlcnMgY3Jhc2hp bmcgb3Igc29tZSBvdGhlciBmb3JtPGJyPiZndDsgb2YgZGFtYWdlIG9uIHRoZSBIdWF3ZWkgc2lk ZSwgdGhlIG9udXMgd291bGQgYmUgb24gSHVhd2VpIHVzZXJzLiBUaGlzIGlzPGJyPiZndDsgbm90 IHRoZSBjYXNlIHVuZm9ydHVuYXRseS48YnI+Jmd0OyA8YnI+Jmd0OyBUaGVyZSBhcmUgbm8gd2lu bmVycyBpZiBlaXRoZXIgc2lkZSBob2xkcyB0aGVpciBncm91bmQgYW5kIHJlbWFpbnMgb248YnI+ Jmd0OyB0aGUgY29kZXBvaW50LiBGb3IgTGFyZ2UgQkdQIENvbW11bml0aWVzIGl0IGlzIHN0aWxs IGVhcmx5IGVub3VnaCB0bzxicj4mZ3Q7IHVwZGF0ZSB0aGUgaW1wbGVtZW50YXRpb25zLiBDaGFu Z2luZyB0aGUgTGFyZ2UgQkdQIENvbW11bml0aWVzIHBhdGg8YnI+Jmd0OyBhdHRyaWJ1dGUgdmFs dWUgaXMgYSByaXNrIGFkdmVyc2Ugc3RyYXRlZ3kuPGJyPjxicj5Xb3VsZCB0aGUgc2FtZSBjb3Vy c2Ugb2YgYWN0aW9uIGJlIHJlY29tbWVuZGVkIGlmIGl0IHdlcmUgYW4gb3Blbi1zb3VyY2UgcHJv amVjdCAoZWcgYmlyZCBvciBxdWFnZ2EpLCByYXRoZXIgdGhhbiBhIGNvbW1lcmNpYWwgcm91dGVy IHZlbmRvciwgc3F1YXR0aW5nIG9uIGF0dHJpYnV0ZSAzMD8mbmJzcDsgSWYgdGhlIGFuc3dlciBp cyBhbiB1bmVxdWl2b2NhbCB5ZXMsIHRoZW4gSSBhZ3JlZSB3aXRoIHRoZSBwcm9wb3NlZCBjb3Vy c2Ugb2YgYWN0aW9uLiZuYnNwOyBPdGhlcndpc2UsIEkgdGhpbmsgdGhlIGJ1cmRlbiBmYWxscyBv biB0aGUgdmVuZG9yIHRvIGZpeCB0aGVpciAod2l0aCByZXNwZWN0IHRvIHN0YW5kYXJkcykgYnJv a2VuIGltcGxlbWVudGF0aW9uLjxicj48YnI+TWljaGFlbDxicj48YnI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+SWRyIG1haWxpbmcgbGlzdDxicj5J ZHJAaWV0Zi5vcmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHI8 YnI+PC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_5362982961720410-- From nobody Wed Oct 19 00:25:35 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E03129532 for ; Wed, 19 Oct 2016 00:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Cw0ymNUAND3U for ; Wed, 19 Oct 2016 00:25:31 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 883EE129548 for ; Wed, 19 Oct 2016 00:25:30 -0700 (PDT) Received: from www.lamehost.it (unknown [80.76.80.23]) (Authenticated sender: marco@lamehost.it) by seele.lamehost.it (Postfix) with ESMTPSA id 4BBA2746D1; Wed, 19 Oct 2016 09:25:26 +0200 (CEST) Mime-Version: 1.0 Date: Wed, 19 Oct 2016 07:25:26 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <5767d1e478e89fd3970c956cb3167878@www.lamehost.it> X-Mailer: RainLoop/1.10.3.151 From: marco@lamehost.it To: "Nick Hilliard" , "Susan Hares" In-Reply-To: <5806484F.5080006@foobar.org> References: <5806484F.5080006@foobar.org> <01f401d22950$7f988470$7ec98d50$@ndzh.com> X-Originating-IP: 79.24.77.5 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Wed, 19 Oct 2016 09:25:26 +0200 (CEST) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Wed, 19 Oct 2016 09:25:26 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.99.2 at seele X-Virus-Status: Clean Archived-At: Cc: IETF IDR WG , Kristian Larsson Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 07:25:34 -0000 October 18, 2016 6:06 PM, "Nick Hilliard" wrote:=0A=0A>= There is an objective problem here, namely that there is no=0A> vendor-s= pecific range for path attributes. Given the nature of path=0A> attribute= interpretation, it could be argued that this might be a good=0A> thing b= ecause different vendors will interpret TLVs in different ways,=0A> which= is a potential source of bgp session instability. On the other=0A> hand,= it means that if vendors need to go off and do something new,=0A> there = are no options other than squatting. A vendor-specific range will=0A> at = least contain this problem, so that IANA won't run into the same=0A> prob= lem in future.=0A> =0A=0AScary=0A=0A> On a related issue, it would probab= ly be a good idea to run beacon tests=0A> with other path attributes to s= ee how they affect reachability, i.e.=0A> have any other vendors squatted= any other path attribute values, and if=0A> large-communities is moved t= o 31 or 32, will it suffer the same problem?=0A> =0A> Nick=0A=0ADefinitel= y a good idea, but to handle with care.=0AURL: https://labs.ripe.net/Memb= ers/erik/ripe-ncc-and-duke-university-bgp-experiment From nobody Wed Oct 19 00:36:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7913129532 for ; Wed, 19 Oct 2016 00:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ZpcaZYce8FzB for ; Wed, 19 Oct 2016 00:36:03 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 61737129547 for ; Wed, 19 Oct 2016 00:36:02 -0700 (PDT) Received: from www.lamehost.it (unknown [80.76.80.23]) (Authenticated sender: marco@lamehost.it) by seele.lamehost.it (Postfix) with ESMTPSA id 28638746D1; Wed, 19 Oct 2016 09:35:59 +0200 (CEST) Mime-Version: 1.0 Date: Wed, 19 Oct 2016 07:35:59 +0000 Content-Type: multipart/alternative; boundary="--=_RainLoop_222_967948787.1476862559" Message-ID: <483547c6b1659efd478be4d9483d724f@www.lamehost.it> X-Mailer: RainLoop/1.10.3.151 From: marco@lamehost.it To: "Robert Raszuk" , "Job Snijders" In-Reply-To: References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <001801d22963$11733630$3459a290$@ndzh.com> <20161018175753.GD10221@dhcp-157.238.255.122.noc.gin.ntt.net> X-Originating-IP: 79.24.77.5 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Wed, 19 Oct 2016 09:35:59 +0200 (CEST) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Wed, 19 Oct 2016 09:35:59 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.99.2 at seele X-Virus-Status: Clean Archived-At: Cc: IETF IDR WG , Kristian Larsson , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 07:36:05 -0000 ----=_RainLoop_222_967948787.1476862559 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable As there is strong consensus that the community should not allow to vendo= rs to pick up codepoints on their own, i think that the best course of ac= tions is to assign a fresh (not-squatted) number to this draft.=0A=0AFor = what concerns 30 and 129, i suggest to mark them as deprecated with a ref= erence to this thread.=0A=0AOctober 18, 2016 8:14 PM, "Robert Raszuk" wr= ote:=0A=0A I would tend to agree with Job here. I see no point to rese= rve already known to be "overloaded" code point for wide or for that matt= er any new BGP attribute. That's the price we pay for no BGP Police or B= GP FBI/GBI ... (G=3Dglobal) r. =0AOn Tue, Oct 18, 2016 at 7:57 PM, Job = Snijders wrote:=0A=0A On Tue, Oct 18, 2016 at 01:14:21PM -0400, Susan H= ares wrote:=0A> Jeff:=0A>=0A> This is a good idea to just make 129 an ear= ly allocation for wide communities.=0A=0AI have to disagree.=0A=0AIt is n= ot known what version of the wide communities draft has been=0Aimplemente= d. This code is deployed in the wild, there are no guarantees=0Athat thos= e routers will ever be upgraded.=0A=0AI think the -wide- deployment effor= t will shoot itself in the foot by=0Ausing 129.=0A=0AKind regards,=0A=0AJ= ob=0A_______________________________________________=0AIdr mailing list= =0AIdr@ietf.org (mailto:Idr@ietf.org)=0Ahttps://www.ietf.org/mailman/list= info/idr (https://www.ietf.org/mailman/listinfo/idr) ----=_RainLoop_222_967948787.1476862559 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
As there is strong consensus that the community should no= t allow to vendors to pick up codepoints on their own, i think that the b= est course of actions is to assign a fresh (not-squatted) number to this = draft.

For what concerns 30 and 129, i suggest to mark them as dep= recated with a reference to this thread.

October 18, 2016 8:14 PM,= "Robert Raszuk" <robert@raszuk.net&= gt; wrote:
I would tend to a= gree with Job here.
I see no point to reserve already known to= be "overloaded" code point for wide or for that matter any new BGP attri= bute.
That's the price we pay for no BGP Police or BGP FBI/GBI= ... (G=3Dglobal)
r.
On Tue, Oct 18, 2= 016 at 7:57 PM, Job Snijders <job@instituut.net> wrote:

On Tue, Oct 18, 2016 at 01:14:21PM -0400, Susan Hares w= rote:
> Jeff:
>
> This is a good idea to just make 129 = an early allocation for wide communities.

I have to disagre= e.

It is not known what version of the wide communities draft has = been
implemented. This code is deployed in the wild, there are no guar= antees
that those routers will ever be upgraded.

I think the -w= ide- deployment effort will shoot itself in the foot by
using 129.
=
Kind regards,

Job

______________________________= _________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinf= o/idr
----=_RainLoop_222_967948787.1476862559-- From nobody Wed Oct 19 03:53:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74946129677 for ; Wed, 19 Oct 2016 03:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 2l75d89IMSFX for ; Wed, 19 Oct 2016 03:53:40 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20114.outbound.protection.outlook.com [40.107.2.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B85129594 for ; Wed, 19 Oct 2016 03:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5l6XZcdpd3Z1BGWYmcVIerN0zAVPdVsNezPsafozAIA=; b=GM+tnLnPp6ZDAtyK2CJ5w1bJvgcYa7PY8DyZRUVrCaHnm/7+whL+fxI1vHNs6NccIAvPq6gGgM7uPPbVU9vaJFrnCJo6D5+5QE5DN2HLygI4rBOkDZBLCUja8VSa8uEmLI3OSNPjEerjSTEfBT7n4e5HH0fY9HLKnqF4000+KnE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Wed, 19 Oct 2016 10:53:37 +0000 Message-ID: <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> Date: Wed, 19 Oct 2016 11:47:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: DB4PR05CA0033.eurprd05.prod.outlook.com (10.160.40.43) To HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) X-MS-Office365-Filtering-Correlation-Id: 38fa3993-0466-4b53-b185-08d3f80e2e3f X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 2:AXeXxVjOUGKwpoic3HsZOXK5NlGpTLTr7aPL268dSVZ4uBbgiEIVQNr5NsX+8V3B33Fk4/aAK8XGrMnX56xDl1YPF2mrTemtyjWekgRjKVAR+G1Vktop/xwlAfwMBpv0u6cEPXKMlycY5p3xq8H7ZCHzkQJh0lvF9Sn1c81QOfTKmlw+uXddtnN/zQdtNkPWLk0rv8ygl0wR3VT6VrpiIQ==; 3:AxYqXGHNKbqOsjoEY28PMyFwygZUY5yHI1eIKvLTYs2hYvLLICBoVHU87WgrwyhXJMTAs6zz4rDkm4ony5yHbS88K3JjZ1dun32qqsiMA7pVzxtSPu1hd3vvRy/r/WxiLmTtxjUUFogZwl2xp4WWZg==; 25:cUwuEsKvghVgNlMvnN123D6mJ7UJUxmH0vl1/8L8ucayMOSlIkt8iJHkOIu4MX8r77cBHngpThsDyGUPe5RygUyPt4bCA/8ch095BNFF1DubTCZ/YM0UEAzluCEisjGPHD7m41koDXHGOc+7wjJ1/TCNdfDtuyj9S40d8uKqf/gjXIkkYTxCNg+ZS5qHjQ1iUfmyBgPQ8HKd7Wpb9g88g5EzEW5Nak5nLeR8C5zQVfAR7aoKPjLIDgEOWx2cnqYaQ+KL5u6GF5Ix024G2gr83CkbOwYl+ZNROBu1SOAcps8NM7S/fo7yp1ArSN5Unny6x3Gohe1dfPQV1W1f544l/gGozoiLEzrLSQA2i6nfwl1MLUuiQ7jgzMj+Te2WdJCw74dRdp8TUq9UycG5dWo2M0JDjxbOcyC0Ta/T2cEto8l9G2F9XycK240l3/tHo6a3 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 31:UWfYGeaU25NVbjJJiDXtF/qsTXURXT1ej707fTrenOGPwb1TsmboQZH5f80AR7QkWSzz8ECXQi0cy4XaRzDMVJ90kPihmqS3SGYdeAaIDo54Df0n2Z/soh7jc2kHicjgG4FXHInZ8BkVzxrxI1LqdxTt67lWf5RXv0P/BoxCfVvofTavpCuYZaHgQIftlzeCkQSwmWkpGa9+cqkbKfEU1NqD6xkuuzotnhHHrBpbvykENZShNw+jK8KDckZ7swoK; 4:3KRvWYla6LxfueGG1kxn5gKprOe9ejq+ulLZgSw0tQYfSDUZ+c6pJFuDhJPRRo3GXHwo5w31qHbP7A9KpBoFwn3Xyon6z7HY5t0KiBAvPqSS+pyUW/G/R0IpEyb6kCYjLZvVS8npKdTYiTD23nRaFypv3vXpWueMd4fmqz6Z9GOboUU9cp2az06YZzaCCHuYhzKn5ILYDvfQdiAl7n00CXuHViCBik7ifGX6QA1XgXET1rqLpxr1vaatONKQIQF7Y2e+kpScv6FdipFmu4c6RKJACZAwkWBXvY/4xUarldw8itPx97fN/30i8W2/Mx/Uv7NxzKkaZUeyXneZXxkMwhjjRT/d+/zqn75lzncaCE0t0Wz8fQFhg09wxSnQ2jkPKmoNjr2x91wmHIReA/xUlk3QNwOa6UcBMKgOMzOViAyf6TvcLWrV065UdkTEd+oJ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3002; X-Forefront-PRVS: 0100732B76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(24454002)(51444003)(377454003)(199003)(5423002)(189002)(13464003)(47776003)(66066001)(50986999)(77096005)(76176999)(586003)(1456003)(1556002)(50466002)(101416001)(81686999)(14496001)(44716002)(62236002)(86362001)(5660300001)(97736004)(110136003)(105586002)(106356001)(44736004)(116806002)(230783001)(93886004)(305945005)(189998001)(50226002)(68736007)(81816999)(81156014)(6916009)(6666003)(33646002)(7846002)(7736002)(81166006)(19580395003)(92566002)(3846002)(84392002)(230700001)(6116002)(4720700003)(23756003)(4326007)(2906002)(8676002)(61296003)(9686002)(19580405001)(42186005)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3002; 23:pFsFht3SHyVcDgyBFfGAj2n0so+87Yt5s8lhs?= =?iso-8859-1?Q?UvIubC20M3yzupObPtbJhme2cvvQvsBAt1j+5FBG264CX8naVEKIUgKNSB?= =?iso-8859-1?Q?/vvo66kzgLDoPx5U9ALnL6qMnDTGRusSMolTe4FaV0M+aZdxUWjb9rIB9P?= =?iso-8859-1?Q?j3TXuc71AGK3+50x6GM/bQox/hhyR9gGjeqs8tuOLFKg7ZynSpM2uYgdfX?= =?iso-8859-1?Q?siDSFrQz9O8as9sc8zyZekI238oUIF/MvA5zKQBbm4npuCmRifbINLdfWs?= =?iso-8859-1?Q?3tAx11lXqVkLJbZZ1kXsxaidteCiKuylar0U1cse5tOnWlI+omusoc4Ien?= =?iso-8859-1?Q?Ygrxq3XA87AvReGMHtcA5IZE5qhUPS8lYnTWVv+qX0sbMtmVBh1DUNXnQ4?= =?iso-8859-1?Q?GFPQkO4tkmO8AkSHuJygjE1hsBZ6CPdYL06XDXgp76NmCxj61ipQ46XGN3?= =?iso-8859-1?Q?9Vaz1end5cqjW8cPrPloaJT2c/3Ng248aqxtSuP5G++9TIu6FAVmnZJPSb?= =?iso-8859-1?Q?Qhuo4/uCq4QEtaf5lGcLAADiGdjuCy/KWUqn3+jYFeOlGMIeATO6H6Adqp?= =?iso-8859-1?Q?feFqkRd5YtQmwm200p7UUXrWUr08bGfW9vljwTtYIIgXvcBLgCfmd4rhQr?= =?iso-8859-1?Q?axRujqm5KW6ZN2zF6043w8lhRFSovj+bSQkNWUbu4j2jj0fiABiA/6NhIJ?= =?iso-8859-1?Q?8C0hdcoFKPqjDrCHfKgn6Ofw4Qq5K6vwj5sFSylSDCM/eJbcPysLDwuB/0?= =?iso-8859-1?Q?ELtUvGgojKRnC5AyGxGO1gVq2o2y8hXaheLwYkxYpQ34gchDjvaCflOWbN?= =?iso-8859-1?Q?ubHXQCOgKezYYd0f33VWc3kU1P3knAZlMJ7yrpFBKy3lpYPQm3faLb/o61?= =?iso-8859-1?Q?F/BCLmYLzJEYurhigLk4n0777kxaszK2gd9ufkhXwbORKjzHp3uKR9l1R2?= =?iso-8859-1?Q?//99ELOu4tkm0pYn3AKJWJdnJpb4I2dTaZ4YWeDoULSerH7741UlRzGDP1?= =?iso-8859-1?Q?rjKW9ZnepcgoYpYPB/Ywzk0AV5XurZssTWW45oE6yv2K0c8GHt4C0P2VTS?= =?iso-8859-1?Q?EA0WuSVG0HINNkADo+4GfxHxtW2QWZNO+A/6lbxemy1geYME8FuTMU5NhM?= =?iso-8859-1?Q?MVDBmMZ0hfuRz2vZkYhbsRoqixEZ7hTKoW25ucDpr7hHD+MIAFYQDttvDH?= =?iso-8859-1?Q?t4/ZZFty6MPEV72UcqwmJeUdGTxd6tsgt93mj2plT0lpVNk3AxTPCXD1KN?= =?iso-8859-1?Q?OzDgDmJbVds27noFKY3F/ND6NC4QI6Q14I8J+8PMojANCQloldGxKY2WEO?= =?iso-8859-1?Q?7h+vGWwT2+QQ2Ch6ixJtko9TB7mlvZ7nP8kTM3oXmyaG1kTLf2t2y+M9d0?= =?iso-8859-1?Q?tqvw181lAzbfK4Ab0zf14UW0uxmexZjG93Id8PRvkUsuACGnc8HVLmQKe8?= =?iso-8859-1?Q?AqnC3xD/jBHB5KXH5lQ0DDlhdP3o70Hq3rdK1Wa+e2753+uApvjgL5CrGX?= =?iso-8859-1?Q?t8qNBdo3m+h5Foa7NZNaReYYNSHH3qUBoRcgxeUsUhN38J4ck4faqP64Fv?= =?iso-8859-1?Q?rXgRkGFE03+Qcy93xZDfQ+sa4xXE=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:TUNsE34thEx4pFIn9gw4Ueuwn9Xr+agfmHoFZgrwruVNZ0jYITNBSMeHvw3/PoPzvhYVJGS1mxkd6bf5DKrR/2hKa1hTQVO1mb3F1xLi8YKn4OhHgG9IaHeD8HNs03fVvvUf6KqfM1u9lyHV+Z5qbE8yapKAfs6ZG1/wQV8JLUL03KNVX4m85s7H3d755blML7EZbfOxto3qlDaELtywShfLzEAtunQaGh1n9om0YrMHuu8jWTggLfWg09+ogNQ982CWOBStrQmV/O9SfZe421sD6rHro/tpdgyi80VhvbdCd+WU3u0HNCnWK4kbMHDf; 5:586mGppIyY5mhtyBOiOmqYuuouBTaLo/hL7CnYqtVw5Pf4xOCMXCu4BbK5g3ynt9at+HxEvfj8H2vnfuEfLui80+o43sWSy1TfhqF38gWVWBnrcA4eK3mYajZrfenmdoAK99vonfrA+sK3ihTDNGww==; 24:cWM22hIsmFXtSTbTnpPSjtx5b2p3KbZ00RedqPIWucCKTCSQbEtygp9Ys/3RL04KzlpkWJI0QNXMu46Fk2CC0mmc1aCCL3OPX49ggcy1Hdw=; 7:tBBua3998jsh1vNGLfmDGUkBHXKxIq3ivjsQ4WVvyNQcVwMorhxMbnPoNcvmI+mgF0O5jtN9Lv2fbBl/3hC2Mve2EW0dVphpb+PdIKcC93HhzRtZqkcg52+Dk2RPUBwr63PDzXQo4rA2DYjjV0uFnLFDJxZ2FLj4D/gupVcZXbwGY/1RTjqejNaAE07VV9JnRRzlHExD7UtwqsZc+WUC3Rjjkb6SJK704M5ZJxb+agczSiXUCVb7/M2Mi4j0NBRKi+MdnzMqBEZUC8BXblNv8hlsjnJhXyVQq/OMCmXPNqAxMLWa/ydu2fv6YTT/4p7e0thPVwp8YcMNQORnkkkYKPn5iTUADvXvFQW6l5ZPLzA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2016 10:53:37.3274 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 10:53:42 -0000 I remain unhappy with this I-D. I find it ironic that the messages for this Last Call should be interspersed with those relating to what goes wrong when someone somewhere else in the world uses a field in an unexpected way. This reinforces my belief that this I-D should be more forceful in calling out the dangers (eg MUST instead of SHOULD). I think that this I-D is factually incorrect, or at least open to misinterpretation, when it says '[RFC1997] BGP Communities attributes are four-octet values split into two two-octet words. The most significant word is usually interpreted as an Autonomous System Number (ASN) ' RFC1997 says 'The community attribute values ranging from 0x0000000 through 0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved. The rest of the community attribute values shall be encoded using an autonomous system number in the first two octets. ' Note the use of 'shall'. Had that been written after RFC2119 then it would have been IMO 'MUST' or 'SHALL' not the weasily 'SHOULD' so this I-D is weakening the meaning compared to RFC1997. If this I-D were to say that RFC1997 specified a 'MUST' (in effect) but that 20 years of experience showed that it need not be that strong, that ambiguities of interpretation have never been a problem for routing, pehaps by adding a note in the Security Considerations, then I would accept that. As it stands, I think that this I-D is risky (and would be even if everyone who reads it knows what the IETF means by 'SHOULD' - I think that this is not the case and that those outside the IETF will read 'SHOULD' as a stronger enforcement than it is). So, interspersed with those e-mails about other fields that have unexpected values, I oppose this going forward just yet. The question of reserved values is another can of worms. If they are not reserved, then clearly they are an example of 'SHOULD' not meaning 'MUST' so they need reserving, but then, as Jeff is pointing out, you open up the question of translation (something I flagged earlier as an open issue). Tom Petch ----- Original Message ----- From: "Jeffrey Haas" Sent: Tuesday, October 18, 2016 9:38 PM > On Oct 18, 2016, at 3:15 PM, Job Snijders wrote: > >> Part of the idea behind reserving 65535:*:* was to reserve a space that >> could later be used for well-knowns, if that was desired - but to not >> spend time now arguing about details of what well-knowns are necessary. >> >> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs. > > Jeff argues that a justification should be added. Maybe someone can > pitch in one or two sentences that explain why these are reserved? That's certainly part of it. While I think many people can see the reason why you might want to do such a reservation, to do so you should have a practical reason in the document. For the 65535:*:* case, for symmetry with RFC 1997, you'd probably want to note that if it's used for that symmetry that either the existing well known community registry is used at IANA or that a new one would need to be created. Alternatively, you just say the work is expected and defer to a future document. Note by doing this, you're setting up some expectations about translation of communities from one space to another. FWIW, I don't recommend this and simply suggest that you recommend *not* using these for common use in case someone decides that they want to do so. I know your organization and others such as Deutsche Telecom have some thoughts about what translation infrastructure might look like, and such mechanisms would have impact. With regard to the 0: and max-uint32: cases, after dealing with the headaches associated with helping with documents such as the as0 and RFC 7300 and putting in some restrictions in the configuration... followed by having to take them away, I'm very reluctant to put in anything beyond "we think it's a bad idea to use these, so pretty please don't" -- Jeff (ask me about my RFC 7300 hate mail over beer...) From nobody Wed Oct 19 08:00:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834AC1299BD for ; Wed, 19 Oct 2016 08:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JkBGd_Owegdx for ; Wed, 19 Oct 2016 08:00:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 63BB71299AE for ; Wed, 19 Oct 2016 08:00:18 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2B0251E32B; Wed, 19 Oct 2016 11:02:28 -0400 (EDT) Date: Wed, 19 Oct 2016 11:02:27 -0400 From: Jeffrey Haas To: "t.petch" Message-ID: <20161019150227.GB24388@pfrc.org> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 15:00:24 -0000 Tom, On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch wrote: > RFC1997 says > 'The community attribute values ranging from 0x0000000 through > 0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved. > > The rest of the community attribute values shall be encoded using an > autonomous system number in the first two octets. ' > > Note the use of 'shall'. Had that been written after RFC2119 then it > would have been IMO 'MUST' or 'SHALL' not the weasily 'SHOULD' so this > I-D is weakening the meaning compared to RFC1997. It's also worth recognizing, good or not (there's definitely room for value judgment in here), that practice has evolved. As part of working through RFCs to basically say "don't use AS 0" and "don't use AS 65535", the general consensus here and in grow was "yeah, that seems like a good idea". It probably still is. But when code started going into place to enforce that (cli restrictions), the weird edge cases started coming out. People using AS 0 as a "wildcard" in their community policy. People using AS 65535 for BGP peering, etc. Is it a bad idea? Probably. Historically AS 0 type things triggered all sorts of entertaining buggy issues for reasons I've previously written about. AS 65535 is ugly simply because it clutters semantic space for things like the well known communities. And thankfully the issues surrounding 0 as uninitialized variable and UINT16_MAX as being common issues in BGP bugs seem to largely be behind us. > If this I-D were to say that RFC1997 specified a 'MUST' (in effect) but > that 20 years of experience showed that it need not be that strong, that > ambiguities of interpretation have never been a problem for routing, > pehaps by adding a note in the Security Considerations, then I would > accept that. As it stands, I think that this I-D is risky (and would be > even if everyone who reads it knows what the IETF means by 'SHOULD' - I > think that this is not the case and that those outside the IETF will > read 'SHOULD' as a stronger enforcement than it is). And yet, I think this is a case where the SHOULDs get enough "yeah, but..." exceptions that it weakens even the arguments for that. The one case I still find somewhat compelling deals with the strong likelihood that some providers will port their RFC 1997 features into large format via either script or implementation feature. In such cases, porting the well known communities into and out of large format present potential issues. -- Jeff From nobody Wed Oct 19 08:28:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071F61299C7 for ; Wed, 19 Oct 2016 08:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.332 X-Spam-Level: X-Spam-Status: No, score=-107.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 7F0toqc-A2Lm for ; Wed, 19 Oct 2016 08:28:20 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (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 AD8A512965B for ; Wed, 19 Oct 2016 08:28:18 -0700 (PDT) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id a5fcbefd-9610-11e6-a831-005056b685e3; Thu, 20 Oct 2016 01:28:13 +1000 (AEST) Received: from dhcp-221-210.meetings.nanog.org (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 20 Oct 2016 01:28:07 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Geoff Huston In-Reply-To: <483547c6b1659efd478be4d9483d724f@www.lamehost.it> Date: Wed, 19 Oct 2016 10:27:59 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <3BC2E5A3-380D-4F60-A719-6FA5E19FC839@pfrc.org> <001801d22963$11733630$3459a290$@ndzh.com> <20161018175753.GD10221@dhcp-157.238.255.122.noc.gin.ntt.net> <483547c6b1659efd478be4d9483d724f@www.lamehost.it> To: Susan Hares X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF IDR WG , Kristian Larsson , Robert Raszuk Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 15:28:22 -0000 > On 19 Oct. 2016, at 2:35 am, marco@lamehost.it wrote: >=20 > i think that the best course of actions is to assign a fresh = (not-squatted) number to this draft. >=20 fwiw, I agree with this expedient approach. Geoff From nobody Wed Oct 19 10:03:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF3412969A for ; Wed, 19 Oct 2016 10:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 sJeN0qz5mt_j for ; Wed, 19 Oct 2016 10:03:02 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0119.outbound.protection.outlook.com [104.47.1.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12000129487 for ; Wed, 19 Oct 2016 10:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K8bmJDIp9kZlkRSiUjeyfKQHHbp+/9Al4WVxzqdOxM4=; b=UNBckVakfGInN9Mg5JYXpDLW3JJn0+CFbt839FDkIgSxY5Ci6DNKxhB4CWvj7QpJCbOq3R7Hj+tSmQgVlnudhyAPCUShwxftT0yyfmi98y4OwlNeb8BwiMKForEqu4KEHxeaSUHSQbnWbXy4bVKMomzq4m4qQG2h1fb0MrMZepY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by VI1PR0701MB3008.eurprd07.prod.outlook.com (10.173.72.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Wed, 19 Oct 2016 17:02:58 +0000 Message-ID: <026501d22a2a$4cec18e0$4001a8c0@gateway.2wire.net> From: t.petch To: "John G. Scudder" , Nick Hilliard References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> Date: Wed, 19 Oct 2016 17:58:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: DB5PR08CA0038.eurprd08.prod.outlook.com (10.163.102.176) To VI1PR0701MB3008.eurprd07.prod.outlook.com (10.173.72.150) X-MS-Office365-Filtering-Correlation-Id: 59707c49-4019-4afc-08d5-08d3f841c755 X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 2:+hK2aWTzNBaGLMICMrsAoS9XlW827lnLc08L+fSaMd9zvoqVNeIGhcell6oeA0X6bpoihzzJE7rNyYy9maKs1CQcthh9BMVCA8H2BZc62UEHaEe5Mi/eDhPJrgG+cgcGmVbdroLyYZOGEeEcNEpWgISpuQ8cuEulqmhaNj4BW3X38SihPa/OvCQ0fOY//KkYXjUxBuhQLfKb7k+y2JmwnQ==; 3:aoAe/bQU57A+Q205Ia3MEvRODDRAA85l+rjAC1NMXBue8hJaU7GtU1DN1mHIMo8mZOjjmNWzOjRvVaKMbDk7ReeO9Yyli80XpWpQ2zNJqEdblcFBiJ9Yj0spuUAE+eGVuAFuc+epSud2lQ/mVClKWg==; 25:L0n+F8s+i+KADYEDCY6HGFbr84iWANLakQ77fCdz0jDXw07X5rYoWMo8PGCKRPbJpbI5hAN8JzqjF5DBT299sJGeobXOFzxQaRZVt6XlPR7gI+XIL6nWppPZexb73I5/RvKPwNQkbEdWXHfiWomauyg5vR20186SM5Hm+scsBIRNuCym56e0gfm77QVTbs6pzA+5Di7mFSpcmciKQ5Hr0Xvsni9cp/7kzGHR4DHUtF0Gr2eC+aEwOhk5PeA1cHhwq2MmTjqgMVdLLGb47fnEF7WF0RbVImzBBCWZ/rEa6xY00n6AvPrvVaHGPxAax5pQyPni5uZ8BXqxIGprTpD7p4cUcXKqy7XMzyEBtDkH7VJwbvglJQfoBd2IuMSeZdWGdBqJBtrCqjNcjZX/nlyUKz/ZHxylm1iiV/IJLpqtoWBXfjD88YIkTUztXWvuWg9Y X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0701MB3008; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 31:J+c53FKvujFTkLe7BkLaN08bLLSZSSnKU560Jh9s3yNfkYSUeBFnubmP1dTF7XFrwjSL9aWflYd3gM/Dd0R7IwzjPytyWrOaaZSQjEqJTBnVb4WmyE4PGg4EHEyEX4X2O/RlWXZvEOi1IJtEumWNbR+MDMTb85q3198IHWtd+HUwR4xcueNjgpzkIdyGc1eHwwWV5pJwp5RwZEOOJMg6RwTvRwjZETpzQl1k7m6PKPs165FRzdm+jNIMy5npYmxMPZJno9rRoFNgEoDVFit91w==; 4:RXUuO+qGodaCshomGpfuMNwPptGLvI4CedaOydLSHTLRO6PU/1Vyl+2/BhijwzUUnQdwLbJSCdE5sf3eCLu5RKpMf6p/gzkEEaeQT40LWDyqIINS3LrX4wYwrbKl1GaLDIRja13XAM4ODf6RAuVa6m10kJtzYNhAMcrNrqXJP3mxZFinWB9gME/nIxBBPvHTPTSIv80tnejCavfR0276d49Zcw4VDjLjM/SoAVPJ23FlUf/frzPcQAJ6WrLYn3Wdh63pHhwuwR9OnYzHpPAVwfEI4ULWbQ1yB7x6+zb6x6CFR2dwSXMdI8v9PnYJ9/QXZOiF5XLT8W9ljxU84dfdcmHRyrIRd1+MuxOxHQnzg+hk73TWsm+LRRRwOhcnSQyphZTsMNsu7xDVs6f4SIgl5XruYBiskmM829YApnt3vQpPg7Ya78eErDAd+juYwPSr X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR0701MB3008; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3008; X-Forefront-PRVS: 0100732B76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(24454002)(13464003)(199003)(377454003)(51444003)(189002)(105586002)(77096005)(15975445007)(84392002)(1556002)(4720700003)(4326007)(97736004)(81686999)(81156014)(1941001)(106356001)(50226002)(81166006)(44736004)(81816999)(6666003)(189998001)(68736007)(50466002)(23756003)(42186005)(5001770100001)(61296003)(1456003)(33646002)(66066001)(92566002)(9686002)(101416001)(86362001)(7846002)(8676002)(8666005)(5660300001)(14496001)(230700001)(47776003)(7736002)(3846002)(19580395003)(116806002)(305945005)(586003)(76176999)(44716002)(62236002)(6116002)(19580405001)(50986999)(2906002)(74416001)(7059030)(7726001)(141353001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3008; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB3008; 23:GUfs73NYt1DC2/12QkEJvO1TTDnMjZ/FIds+O?= =?iso-8859-1?Q?qggi0IX2EzQufL+hI5rNMos5JztUyzJ0T6u2YvMyLwFNP0DSmKzZQspVAZ?= =?iso-8859-1?Q?xhjJk39t0KGLD58ooz2htN4xGpaVMnPG8HFfvTO8p7t23v1l6m9OeC6Rd1?= =?iso-8859-1?Q?81XMeqxlA8ERNbGLxaaLUEFYI7I+7edncigLTj/ttu4uBsC4FdVlfQdHCu?= =?iso-8859-1?Q?MwR8/hGnUK3UIF+evrgVflRMKMKrdfbOJnDTN3qPJYWbMAiMrCAQdwBnBI?= =?iso-8859-1?Q?u4IuHIksESbb4+rTQS0zgxkzMZyn4rw2Znls2horLZz614vXy0fJQKYSEi?= =?iso-8859-1?Q?kH/7qI8/YrAo+RH7fB7CA9gwoIwm2TwKoY2kSUsihxhADgBOZPn9WyqItR?= =?iso-8859-1?Q?eLc7hl/UxgAR/7Yk6t3J70Tm0byuxUG0JBuawLgLetODLv0Uh4JoCzju3Q?= =?iso-8859-1?Q?Bd+zrnc67ew3l8LecJfJKWzUnWtdmOOiBDnAzjM0+eCotel+2xoZSTdDNT?= =?iso-8859-1?Q?5bvGqHqRJ6Wf2jw8f6l+S9zs5LsZebVtJJ78qKwvHq8ZVyDxTeHBliaOjD?= =?iso-8859-1?Q?hlY9o8jvGxv6a8XQsvy2i0dGff4BmFFQyAk+JQi+HRqQ5DBYaUD8y1qqOX?= =?iso-8859-1?Q?D3mNqijfQYXSnK9GRaXWeFN5Db7pbkuTw3f3Onj20HouVDakCbHyuoN0tJ?= =?iso-8859-1?Q?ptaFZrPJWb2r7Pw87ovPVJhitWFagMqbqx7UekoG/9bUc5qNd2vR/pzH1u?= =?iso-8859-1?Q?5e85DZOa+t6b6pESpre5hmJGr5zKc4GQ3MCrORkU66uwkz6utfF1gVQaJM?= =?iso-8859-1?Q?aWMx7jDgGTsFIIYFjDbPa00kSOHLm3xHk/Px+/A1zpoRt4dQxvp0BX1BYv?= =?iso-8859-1?Q?8pw4/TMd0/6cVGwThDK9VmimNDEvEvAUo/RBHKIu8sCeyU2jaDhz4GdI8m?= =?iso-8859-1?Q?hOPPeXmPD97FhLFP+BuwDWTDn9JGQFYbjxRl0OiZUWqnXedpPSPwQ7wSwI?= =?iso-8859-1?Q?CWkZL5KqlmR03KfVFXz1UqjEGgvM1ZXedPatewxkzFIQ9P9y4eTCie0AAW?= =?iso-8859-1?Q?TLPi5pPYbN+6rtrkKoKzzjZ7H96PfFepyTK/eOH08np1PlfWgAJeNAj3Be?= =?iso-8859-1?Q?yqcxuiVMwMm1qvsyTXAIgxflKlfbazdlERAPs1Whk5QUjEHviGKqAXDlli?= =?iso-8859-1?Q?kfLTRSyrWnTOqmE4bzDCvWXi4lvsDEC2wL00ZMJyj8s5ZrQWVj/kG54Xfh?= =?iso-8859-1?Q?KhXzvOhZLP4vEXGDijzlF5CKN++8BvsOod5LDetih+S4MHsN2J/KxBPrXs?= =?iso-8859-1?Q?5TX9QRQXoc5NAAkC31ohPl6fqJ8EQ7yjKsW0Kwby5o3bTfBx/89mTgldRG?= =?iso-8859-1?Q?sfObrf8vRTWq2b4oprwFy8H4f/DRujrabKNHRgznLt6QsVCzdD1ppUMSQo?= =?iso-8859-1?Q?kZtwbLdMttZbNVurwBaAo00Is2nDnM70V8q/yyjZ599BlUaEM8CxfBKwY2?= =?iso-8859-1?Q?p2elvwqQb2awrEP1SzBYoLZeKh68pfxFEiBAkXXPxARE+nwbxDqxF2Acqv?= =?iso-8859-1?Q?tiMHW6MrrGlSavxSJoS/r322WZx8PtNHSACP0n3YaumqTkQYMVyRMHOoB7?= =?iso-8859-1?Q?cMEcaO714ugdw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 6:34624Qj8Hj2teZardDoxj00E0kdmLahnJM6zYPT9TSi+iD1PpIymqmEbn8qa42mpce8ZB0pOC2852h9eyHSnC5vGApUa5Khk9sjlJuRV32lOSfCnEHOpiuxo+m/mI0D6v7bl7tvVQW26e5v5vljA7Atu55cBIz99FyyIf6tMFJveY6pUj7E7iuYi0P4bUslNlKsKks9vnNybR8HkJ+pvU4vHmSI/KmWm8j/P0xmQ52VFj3GsiOsHllmsrXG1dLqhMWCaaYeG1dWbZ/7s9dcYG2INqKmP++8f5lNAKj0DV80hLakhm+XaFPKzeciW7BBy; 5:4BiBONK13OO9mrDvJEc2mYfMCX40ei5ThWQTwJw6gTvXxzx8tyPJd6wSu0oUpgKINvlovck7nWY8kw38TUmEQqUdYXJbbG79nNhC1dL0MTq3DZEI8f6UUual1xeAy4IUMxZxp8KoEL+ypaiZo4zMbQ==; 24:JP0L2AosTzRoGBwSKNNLTEmia4LFMu1g6A6/RYHuFzwWUb7x75/JHEC6USa6zDVbCSsgE0lXElRi1yJrykckI+TKPZZh32DnJgcJWE0d6SY=; 7:6y8Mv+ka4YIBoyzm+OpZwYiD1ZG8OjYIY4JXyx7gUn8DkZFV/ZVXjtd2qlZ9p5cnubx+3YSBrdfmfNacf2Xct260q6uTFgUxpYJjvmUwP1PNGyFyWSbasbHYsyaaYddG99BqiB9nQ/1vf005zXS4QaEylKA2lXT0v1mh2LSjJ24n+1kHzcNuL6vM8pHpGGJodxhH3DbjB3w6HjmsPFq0SgHs0O6gZOHb0zExcDH+H7Oallfc6qoYGVCWobtC7PzGCd92Pi4z/ndHtJ1vOFA1u5z1556oKOIfOit/90NYYDUoiscQVpmz6JPVc9li01U/7bn8C0rCaq9Gyxe5IkLwlX0ueXTwHUa99CWvPTE2re0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2016 17:02:58.4808 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3008 Archived-At: Cc: IETF IDR WG , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 17:03:05 -0000 ----- Original Message ----- From: "John G. Scudder" Sent: Tuesday, October 18, 2016 5:35 PM > On Oct 18, 2016, at 12:05 PM, Nick Hilliard wrote: > > unless this is a temporary deprecation, > > All deprecation is temporary. It means "you shouldn't use this, and by the way we might reuse it for something in the future" where "in the future" probably/usually means "when we run out of unused space" (modulo my earlier remark to Jeff). Deprecation is therefore the first step in reusing a code point. > > I looked for a supporting citation and didn't find one, though. :-( Mmm so RFCs 3879 Deprecating Site Local Addresses 4159 Deprecation of "ip6.int". 5095 Deprecation of Type 0 Routing Headers in IPv6. 6633 Deprecation of ICMP Source Quench Messages. 6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos 6814 Formally Deprecating Some IPv4 Options. 6918 Formally Deprecating Some ICMPv4 Message Types. 6938 Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH /CLUSTER_ID 7447 Deprecation of BGP Entropy Label Capability Attribute 7526 Deprecating the Anycast Prefix for 6to4 Relay Routers. 7568 Deprecating Secure Sockets Layer Version 3.0. are all temporary and we should look forward their resurrection in future; source quench from site local with SSL3 protection via the 6to4 anycast:-) I note that RFC5226 does not mention the term while RFC5226bis has ' "deprecated" (use is not recommended). ' But then RFC7120 has ' The WG chairs are responsible for informing IANA that the expired assignments are not required and that the code points are to be marked "deprecated". A deprecated code point is not marked as allocated for use as described in any document (that is, it is not allocated) and is not available for allocation in a future document. The WG chairs may inform IANA that a deprecated code point can be completely de-allocated (i.e., made available for new allocations) at any time after it has been deprecated' So I think that deprecation is permanent until you say otherwise so I guess that makes you right! Tom Petch > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Oct 19 10:37:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACB91296B7 for ; Wed, 19 Oct 2016 10:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.953 X-Spam-Level: X-Spam-Status: No, score=-14.953 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 cF5G-x3DQyWb for ; Wed, 19 Oct 2016 10:37:39 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F69129595 for ; Wed, 19 Oct 2016 10:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5752; q=dns/txt; s=iport; t=1476898659; x=1478108259; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/T0QL13JwSU6iNX/LFm8Wr7Uo1KVJcjSO7VsnSGnlS0=; b=bJoGgLBdAarM/F/7Xmm24C7unbcA4Ap1byOmJrMczZ7cr8nsMezmI8Gu /SdGNPtkxjsiQbhs3M0mkagsHJp7HshxpCLMnsAiPRE1uFRkz82LHWkFt VI3yxFmKQtONnARM8S6lMBpy+ZZn8x2TpD6XoK/ormIOTyqHxjXy0d0bx Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0AQDcrgdY/5hdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz4BAQEBAR1XfQcBjSyWe5Q7gggcC4JEgzYCgXw/FAECAQEBAQE?= =?us-ascii?q?BAWIohGIBAQEEAQEBNzQLDAQCAQgRBAEBAR4JBycLFAkIAgQOBQgMiD4Ow3ABA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEXBYY9hFWEKgEBhXoFmg0BkAKBdYRpgzeFa4x?= =?us-ascii?q?+g38BHjZVgwA6gTpyhh2BIAF/AQEB?= X-IronPort-AV: E=Sophos;i="5.31,367,1473120000"; d="scan'208";a="337813751" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2016 17:37:38 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u9JHbcM5027911 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Oct 2016 17:37:38 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Oct 2016 12:37:37 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 19 Oct 2016 12:37:37 -0500 From: "Jakob Heitz (jheitz)" To: "t.petch" Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) Thread-Index: AdIotF10Qx6LizvwQ9uItB9ryESdDgANiv0AACybzYAAADoegAAC4vMAABNp+sQADVTs8A== Date: Wed, 19 Oct 2016 17:37:37 +0000 Message-ID: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> In-Reply-To: <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 17:37:42 -0000 1. Router software cannot check whether a number is an ASN. 2. Any numbers should be allowed between consenting adults. That is within = an AS or between adjacent ASes. 3. "Reserved" means reserved for use. So router software cannot disallow th= ese either. I can see how the existing text is a little terse: The Global Administrator field is intended to allow different Autonomous Systems to define Large BGP Communities without collision. The best we can do is explain the situation: A Large Community that is intended to be sent to multiple ASes SHOULD contain an ASN in the Global Administrator field. The ASN SHOULD be one that is assigned to the entity that defines the meaning of the rest of the Large Community. This allows a route to carry multiple Large Communities, the meaning of each being defined by different independent entities. Tom, will this text satisfy you? Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch > Sent: Wednesday, October 19, 2016 3:47 AM > To: Jeffrey Haas > Cc: IETF IDR WG ; Sue Hares > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/= 2016 to 10/31/2016) >=20 > I remain unhappy with this I-D. >=20 > I find it ironic that the messages for this Last Call should be > interspersed with those relating to what goes wrong when someone > somewhere else in the world uses a field in an unexpected way. This > reinforces my belief that this I-D should be more forceful in calling > out the dangers (eg MUST instead of SHOULD). >=20 > I think that this I-D is factually incorrect, or at least open to > misinterpretation, when it says > '[RFC1997] BGP Communities attributes are four-octet values split into > two two-octet words. The most significant word is usually > interpreted as an Autonomous System Number (ASN) ' >=20 > RFC1997 says > 'The community attribute values ranging from 0x0000000 through > 0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved. >=20 > The rest of the community attribute values shall be encoded using an > autonomous system number in the first two octets. ' >=20 > Note the use of 'shall'. Had that been written after RFC2119 then it > would have been IMO 'MUST' or 'SHALL' not the weasily 'SHOULD' so this > I-D is weakening the meaning compared to RFC1997. >=20 > If this I-D were to say that RFC1997 specified a 'MUST' (in effect) but > that 20 years of experience showed that it need not be that strong, that > ambiguities of interpretation have never been a problem for routing, > pehaps by adding a note in the Security Considerations, then I would > accept that. As it stands, I think that this I-D is risky (and would be > even if everyone who reads it knows what the IETF means by 'SHOULD' - I > think that this is not the case and that those outside the IETF will > read 'SHOULD' as a stronger enforcement than it is). >=20 > So, interspersed with those e-mails about other fields that have > unexpected values, I oppose this going forward just yet. >=20 > The question of reserved values is another can of worms. If they are > not reserved, then clearly they are an example of 'SHOULD' not meaning > 'MUST' so they need reserving, but then, as Jeff is pointing out, you > open up the question of translation (something I flagged earlier as an > open issue). >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Jeffrey Haas" > Sent: Tuesday, October 18, 2016 9:38 PM >=20 > > On Oct 18, 2016, at 3:15 PM, Job Snijders wrote: > > > >> Part of the idea behind reserving 65535:*:* was to reserve a space > that > >> could later be used for well-knowns, if that was desired - but to not > >> spend time now arguing about details of what well-knowns are > necessary. > >> > >> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs. > > > > Jeff argues that a justification should be added. Maybe someone can > > pitch in one or two sentences that explain why these are reserved? >=20 > That's certainly part of it. While I think many people can see the > reason why you might want to do such a reservation, to do so you should > have a practical reason in the document. >=20 > For the 65535:*:* case, for symmetry with RFC 1997, you'd probably want > to note that if it's used for that symmetry that either the existing > well known community registry is used at IANA or that a new one would > need to be created. Alternatively, you just say the work is expected > and defer to a future document. >=20 > Note by doing this, you're setting up some expectations about > translation of communities from one space to another. FWIW, I don't > recommend this and simply suggest that you recommend *not* using these > for common use in case someone decides that they want to do so. I know > your organization and others such as Deutsche Telecom have some thoughts > about what translation infrastructure might look like, and such > mechanisms would have impact. >=20 > With regard to the 0: and max-uint32: cases, after dealing with the > headaches associated with helping with documents such as the as0 and RFC > 7300 and putting in some restrictions in the configuration... followed > by having to take them away, I'm very reluctant to put in anything > beyond "we think it's a bad idea to use these, so pretty please don't" >=20 > -- Jeff (ask me about my RFC 7300 hate mail over beer...) >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Oct 19 11:12:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133D41296D5 for ; Wed, 19 Oct 2016 11:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.731 X-Spam-Level: X-Spam-Status: No, score=-4.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 x6x6dwKNa5do for ; Wed, 19 Oct 2016 11:12:20 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 5193E1296D3 for ; Wed, 19 Oct 2016 11:12:20 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id C4AB8524 for ; Wed, 19 Oct 2016 18:12:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnNnihWZjOKE for ; Wed, 19 Oct 2016 13:12:19 -0500 (CDT) Received: from mail-qk0-f198.google.com (mail-qk0-f198.google.com [209.85.220.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 9225821B for ; Wed, 19 Oct 2016 13:12:19 -0500 (CDT) Received: by mail-qk0-f198.google.com with SMTP id z82so23592939qkb.7 for ; Wed, 19 Oct 2016 11:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pnfqpZjatUkyDkQCLuBCQThfgWAhlFS8U4gw6QJzUUQ=; b=D79q6duP0mojTlkxNBpyzSS8bbMvJoowQDWonmP2QTri2dz6lSMu0kWKsbYKyPjDaZ i4q/GWIQWE3pxmZzGHIuk3fTijvkEx3uLK/l2MPwVtWnqxKlE8VglVrfReyDGoQ7cVWw VgM81VmjXJdks306V4xWTpkhgxoK7cSxeOBy0bBIDwtWFq1aZfjrSgjHGxu1HvEvShmH wF5akpxj6RfPAbGTyBoLnzN9ulYnk/Q8M/fAcN+NlBdzIO0L+BchhPwUgzQvnl8oKmAI bJAv0Yx/qSfCmDMN8rY92hKm699VKJ1LcS0L83aU7u1ImMr3Sxr4Ep1E/cKg1zYwUwwt 4XGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pnfqpZjatUkyDkQCLuBCQThfgWAhlFS8U4gw6QJzUUQ=; b=hlSi+tQ5k5gUjusoFESPD8oKvspTUFAYxgU01aY6EmvP3M9bsvq705044/jTItP75/ z8pU3Vp7fsEHDa25+JEEreBMhX76KEi39/gaqeTq2aF2Hp4om4uXwUrURSAEXdplGPZP cAZYHrYqgwt0PcW4WnFRpU1CvTuY84mnm8dm2r7mMOBdcRvnPTILq3gucmzKuxQmz3EE iOFFx+F5t6ChivgbgFMxClum5xiOkH4K4v6xq5r3dnraXksONZ5SHQNQa1oBMn7atxL3 V8hQW9s2mMHOXiqXyS+8hDcSqmXQUUL9wzaLKhUGi7nNAbJLZq0pac8erHAiKxbWkQFq talw== X-Gm-Message-State: AA6/9RmtmFRS4ytVq7pA+Eu42y++zgV4aHrigO8aNX9LwTP2XSgkQBPtIf34wpDLUlr7ta8ipvVIvPOTEytH1Kva8Y8TwshqnYT9b4OdJRJZoPu3v/D+1GZ9nEjhfBnHch5VsZpSDRA2x1JnSQ== X-Received: by 10.55.56.12 with SMTP id f12mr7409265qka.106.1476900739034; Wed, 19 Oct 2016 11:12:19 -0700 (PDT) X-Received: by 10.55.56.12 with SMTP id f12mr7409243qka.106.1476900738807; Wed, 19 Oct 2016 11:12:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.41.230 with HTTP; Wed, 19 Oct 2016 11:12:18 -0700 (PDT) In-Reply-To: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> From: David Farmer Date: Wed, 19 Oct 2016 13:12:18 -0500 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a114908cae7d29a053f3bbf68 Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 18:12:22 -0000 --001a114908cae7d29a053f3bbf68 Content-Type: text/plain; charset=UTF-8 I believe this is ready to go and support it's publication as-is. However, I believe it would be improved with the addition of something like the following paragraph; While from a BGP protocol perspective it is necessary for large communities to be transitive, as there are many plausible situation where large communities need to be used to signal beyond a singles or even directly adjacent Autonomous Systems. On other other hand, large communities are not necessarily intended to be passed unimpeded across the entirety of the Internet either. Therefore, implementations SHOULD provide a rich set of policy capabilities to allow operators to decide which large communities are received from or propagated to peers. Thanks. On Mon, Oct 17, 2016 at 3:27 PM, Susan Hares wrote: > This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt. > (10/17 to 10/31). Please comment if draft-ietf-idr-large-community-03.txt > is ready for publication. > > > > If you have concerns with the text, please be very specific about what is > wrong and what needs to change. If you have concerns about operational > aspects, please give a complete description of the problem and why this > draft does not solve it. > > > > This WG LC is not a place to debate whether we should have adopted this > technology. > > > > The focus of WG LC is whether this technology has implementations (see IDR > wiki for examples), and whether these implementation inter-operate. It is > also important to consider deployment issue or problems on currently. > > > > Sue Hares and John Scudder > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a114908cae7d29a053f3bbf68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe this is ready to go and support it's publica= tion as-is.=C2=A0 However, I believe it would be improved with the addition= of something like the following paragraph;

=C2=A0 = =C2=A0While from a BGP protocol perspective it is necessary for large commu= nities to be=C2=A0
=C2=A0 =C2=A0transitive, as there are many pla= usible situation where large communities need to=C2=A0
=C2=A0 =C2= =A0be used to signal beyond a singles or even directly adjacent Autonomous = Systems. =C2=A0
=C2=A0 =C2=A0On other other hand, large communiti= es are not necessarily intended to be passed=C2=A0
=C2=A0 =C2=A0u= nimpeded across the entirety of the Internet either. Therefore, implementat= ions=C2=A0
=C2=A0 =C2=A0SHOULD provide a rich set of policy capab= ilities to allow operators to decide which=C2=A0
=C2=A0 =C2=A0lar= ge communities are received from or propagated to peers.
Thanks.

<= br>
On Mon, Oct 17, 2016 at 3:27 PM, Susan Hares = <= shares@ndzh.com> wrote:

This begins a 2 week WG LC on= draft-ietf-idr-large-community-03.txt.=C2=A0 (10/17 to 10/31).=C2=A0= =C2=A0 Please comment if draft-ietf-idr-large-community-03.txt=C2=A0 i= s ready for publication.=C2=A0=C2=A0

=C2=A0

If you have concerns with= the text, =C2=A0please be very specific about what is wrong and what needs= to change.=C2=A0 If you have concerns about operational aspects, please gi= ve a complete description of the problem and why this draft does not solve = it.

=C2=A0

This WG LC is not a place to debate whether we should have= adopted this technology.=C2=A0

=C2=A0

The focus of WG LC is whether = this technology has implementations (see IDR wiki for examples),=C2=A0 and = whether these implementation inter-operate.=C2=A0 It is also important to c= onsider deployment issue or problems on currently.=C2=A0

=

=C2=A0

Sue H= ares and John Scudder


___________________= ____________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr




--
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking &am= p; Telecommunication Services
Office of Information Technology
Univer= sity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Ce= ll: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
--001a114908cae7d29a053f3bbf68-- From nobody Wed Oct 19 11:20:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467B21294D2 for ; Wed, 19 Oct 2016 11:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jtX3HsiCShfe for ; Wed, 19 Oct 2016 11:20:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EA487126FDC for ; Wed, 19 Oct 2016 11:20:53 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 051C81E1F0; Wed, 19 Oct 2016 14:23:03 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4BD346EF-8DAF-4286-8747-0D6A8016081F" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Jeffrey Haas In-Reply-To: Date: Wed, 19 Oct 2016 14:20:52 -0400 Message-Id: <107141A7-5CD2-4E48-8F6C-C737FF370359@pfrc.org> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> To: David Farmer X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 18:20:55 -0000 --Apple-Mail=_4BD346EF-8DAF-4286-8747-0D6A8016081F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 19, 2016, at 2:12 PM, David Farmer wrote: >=20 > I believe this is ready to go and support it's publication as-is. = However, I believe it would be improved with the addition of something = like the following paragraph; >=20 > While from a BGP protocol perspective it is necessary for large = communities to be=20 > transitive, as there are many plausible situation where large = communities need to=20 > be used to signal beyond a singles or even directly adjacent = Autonomous Systems. =20 > On other other hand, large communities are not necessarily intended = to be passed=20 > unimpeded across the entirety of the Internet either. Therefore, = implementations=20 > SHOULD provide a rich set of policy capabilities to allow operators = to decide which=20 > large communities are received from or propagated to peers. >=20 FWIW, I'd rather see such a thing as part of a grow document for good = community practices. I had thought that a BCOP document on communities was out there for BGP = communities in general, but "community" clutters the search engines = quite a bit and I'm not finding such a thing. -- Jeff --Apple-Mail=_4BD346EF-8DAF-4286-8747-0D6A8016081F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 19, 2016, at 2:12 PM, David Farmer <farmer@umn.edu> = wrote:

I believe this is ready to go and support it's = publication as-is.  However, I believe it would be improved with = the addition of something like the following paragraph;

  =  While from a BGP protocol perspective it is necessary for large = communities to be 
   transitive, as = there are many plausible situation where large communities need = to 
   be used to signal beyond a = singles or even directly adjacent Autonomous Systems.  
   On other other hand, large communities are not = necessarily intended to be passed 
  =  unimpeded across the entirety of the Internet either. Therefore, = implementations 
   SHOULD provide a = rich set of policy capabilities to allow operators to decide = which 
   large communities are = received from or propagated to peers.


FWIW, I'd rather see such a thing as part of = a grow document for good community practices.

I had thought that a BCOP document on = communities was out there for BGP communities in general, but = "community" clutters the search engines quite a bit and I'm not finding = such a thing.

--= Jeff

= --Apple-Mail=_4BD346EF-8DAF-4286-8747-0D6A8016081F-- From nobody Wed Oct 19 11:37:54 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FB3129766 for ; Wed, 19 Oct 2016 11:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 6FIn_nH5p1v7 for ; Wed, 19 Oct 2016 11:37:50 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0119.outbound.protection.outlook.com [104.47.42.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58670129559 for ; Wed, 19 Oct 2016 11:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T5JKuc0u1WyAXLD6OQN/ke3qRwd4Tfj3dJZAZH4xyEA=; b=jE4PqOJaO4QH5RJRMplMa9BjmVdSLFG/n4iusjw45As6FcGaltx2vsK1ZaEyDzR7m6xekNTiiS2ZI3owIF6ZxR9sdLXTLQsJOGEmdldypLFNPsBQGB5JLsjomAW1v2oKSGRTi9fki1pW6gwvnJxFifc2VK4Dya9Mklyq+pLNYmo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.34.170] (66.129.241.10) by BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.4; Wed, 19 Oct 2016 18:37:48 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <026501d22a2a$4cec18e0$4001a8c0@gateway.2wire.net> Date: Wed, 19 Oct 2016 14:37:43 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <026501d22a2a$4cec18e0$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BLUPR13CA0087.namprd13.prod.outlook.com (10.160.82.58) To BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) X-MS-Office365-Filtering-Correlation-Id: 2fc8b3cc-9424-4d9c-a58d-08d3f84f0705 X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 2:m4Ipwm7buzfsBISusB++eCHF/soPg5F81fPwrLMkulUhBPb5KDCA/7DhDajY5iZtUshoiNFOeXgn3eGPNCq6H1WgCEpqnVFoH1DVdF1DJGBgPJmWHZiDx5pxeLom2UkmWh877y1BsyBEwt8OBkVyzUBZuy2WkuAxcJd6+ZGoeyr1E2LPAcXxaF+X72fyyXaQYSoWxK4hFIE8CKhziMDFOg==; 3:TvAOULiraWOFVbOg0Dxc+zo8KuG+qZu+nYZujPB9RooKElkA4I5gk+Xq5nPZTYO2+g9BdAqy7s5+3+goK2wHH2apE9YwwKZCMJvsTs2di5EBpfUHXNsY9Wy7tAtd3KxbGWrbdURjjJepbj7ML/GgAQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 25:Oca47Evc12Tc+IiZp2DNS41LHrGNMZBAQP84i32nzaE/C67BcHBAixMZlDSLHTTqqKhnHKr0gNHfAcSdiKasOcx5eXvLDoqmTKrZiU24PFqW6IuF9fU80vEdFu5ZlGAC+sTVw3/96YsbovMgVTS9QUlsVrm55zbp6L+JgWyY4cWy9SlK9LOpNq/4rIl3XvsgbLp2qBrXzX9C5DPrNEmWmZY8s5i53F39wItQU9LDHoMIeBFyGlbFmGVqSKxduXipQRu3qDg6U8qiSYulI9iSn23s5njx8ul5rPeqeE493/4S5slvIeuLStCPaCD1I7huWx85V45ewm3TNqoYnQ65SdUcBxTev/CkhxzayWc50N0W+vbCILwTbKSRANA1Bm5tQZQecL+QwtSW5qidFbCBvAMQ4FG9GFChLnmm2OuCViAc/azbYlzOQ+4n1CPkaljum6TV3qz/G6s0BZmgv0hdxcItUx7gT8kj9jMOYrUD/i3fUthtKoa8cunZgsVjOLGB3ETzZVSx81572VRa+SZQZfHhzgIGku6FAqTT6Xef/DkGE1XEB6CSiPnjpiY1pPjC/rbXFZVOoTT9QO7ZwDVzqCj2ePY/q7bCL04d+f1f28Rj7Y+M2gYYyu/7YJndB9Sp6jKt+clU9Ec4GpLEzl7eI3IGJ1ZecasEJFDtjP0OQHDYKNOpnX3CQS2wNhxJwdR3/etwO5AUuaB9SdGigquZfYqH71szdbLH4/+egegdh3A= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 31:Fn733LrzRytYn74GBYqgxHBh2rMrxF5DpRbf/cNLU1U/BKDn03uTyZ8IV5HadsoYwBqjaokHTnzjYqcuG0HAI1o8nwh2rLTLPGWIV8frLXMQz+be9Q3AtprzzQMBbriuy7c2GqNyGrmSa+lfes/609QsHGFAWbqFE/E2OL/3g9YhKNt7sQ8QGoy2bJQ6CmtOlJoxhPBBwwcqto3ueKH96pjddXtRcdLf9Iaw8W1ALiYxxfPCqOoeIWB/jf56TW67; 20:yycgAZ2DZgp8CX4wZWpHDXS8iz4uPJInP40GKlk+dLxMws8OlypxJUgwA7Nc8czu3+SlNPvmKEUw1l0wlfQlyimAfgFRxhOvH1xyDklRFq5fhp2Lpjn/rVdAP7VBwHyga8Ran7qlGCzNekhvmwv9eZOqnhaylmxOjD65kRuCdnRnE07U0Ti5hGWReaqFGRzKqNLhcnuStd2+PmIkfyij7urq62cyx6nPA7EAcK77JDZZLeC/912aFFRDxemB4pwFQAKXMYjCSiyDTx9MmgMZd1mL7oVgpdVicV8EdtTJxJqa3gViD45Pn6rkFgHxxst0cPnKXGIAo9XmtA3is/d/B2Y71anOcYhNDCqiM6ATUk+jxXSSQ9yNl7wssTDfTJcR6qF3WJtWZtICN5YK3NUNyCPf5VGv/eOObVf6KZYFjoUtU0KqcaWZB0QX72hDMF85rBebJTAityyryizZhhxvM5WybZMce3zpaAgfwZ43FywIJSqkrE88Kn5L5+6gTZvUA6kKQMqLNXh6tWHnySzI1EON0Yv2y5ybTvBPXLNrYUUy1T8V9oWbfyBAWRCCM1wx8lsUvjeW22VFxTD8O6qoKJFTqWEXCheK9jNZky3TlIE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN3PR05MB2497; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 4:np2Tu04okmORleAtjn4n8T13KpeJndQtVAibpvzb44kwSPY5hucD4XtEnSK8/cvnOO225aQVh4jwaHt9ISbgvxO/qO9xwDNFXNyw8NrazbIigd3wccHTD3c1MaEG48aJuASFlfHoZGqdmInpJLnP8QAkiJFsjgZEBUBcYXGNCN0b4b5abofiMaIn7ytQQcfN34UIVLtGFrkhYkIEuxIy+yJ3VyQZp8zimNLa+EF+lX8InJWKGhswCvmspSgShbmKpma1wr46gC1pzC4aFkc4rQLFsVfZ/jqc5grTup6UdcDMUxTxcDSuXUotgtmqDlMXzH/FHH0geiEIcy2E0w7ZJKBPS0wrfA+DHEWqc7QlBwSuxoIAZK/N0zLf1NujW3zNnQLkKe4SxYEarST/D4qsQF140FSX9WcL/p/roQiIW6Yb/iCbXzGPrCWuiT3qkVYuNj0Sp+o+DmuQo84HAjUoLw== X-Forefront-PRVS: 0100732B76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(377454003)(199003)(51444003)(24454002)(77096005)(86362001)(97736004)(8676002)(6666003)(6116002)(7736002)(81166006)(3846002)(81156014)(33656002)(110136003)(7846002)(19580395003)(66066001)(305945005)(586003)(8666005)(189998001)(92566002)(57306001)(19580405001)(4326007)(42186005)(36756003)(5660300001)(76176999)(50986999)(106356001)(82746002)(68736007)(50226002)(8746002)(47776003)(105586002)(2950100002)(2906002)(6916009)(93886004)(83716003)(101416001)(50466002)(23756003)(7059030)(141353001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2497; H:[172.29.34.170]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN3PR05MB2497; 23:GU4lLstP+/b5594E/S3u8VacX64oljp070rbOtK?= =?iso-8859-1?Q?izIffnGdca93beP9nYhqVP+a4sR3Ez67piLIZeCiH1zkdl/BHnpBJNuNJM?= =?iso-8859-1?Q?BR15XE2Ewb8zJ73UjR/5dqwngqaK8+1P/pni+t69TGotIr6FebFzD44YF6?= =?iso-8859-1?Q?oShFQC7sMr3mDv/vN78bZamthjCZ8N4iLoOd2KeeuwXj2JzD+ISubg8NZe?= =?iso-8859-1?Q?6+XN/t7n+11DqnHtS6sLg52Qh/kA+tpiiNz0Y9P8xEx/pmFavkk62Tvp4m?= =?iso-8859-1?Q?5hz/QhNybkt2mIXldLnwIMnr1WJixx1jtcWI7cagmVbWrpokSb3jfS1LoD?= =?iso-8859-1?Q?ZxDBzhHO5WgNKGdLV2iuUWEaNDB2kQW7lU3CRI1+6S+dwP0oD1500yJJi9?= =?iso-8859-1?Q?spk41lH9bkwiM214/kHjSES9RS9sEVloy4nwMtaRYpO786f6FqqVg3LMjv?= =?iso-8859-1?Q?Qj3zuRy3gX9KFaFfoE4EZbJ/FglhXzZ9cWx9NUYEitrnlo+Ygp2VXh5u2U?= =?iso-8859-1?Q?8eMR+0MC2gaq2Zs682vvQEJ2QxxZVQzBGn6jgbYaJNNgO4jED/h8xWP4d9?= =?iso-8859-1?Q?8MDl5KGVQEAOZNjAdTIGBv68MaHhhYjUsozb4K/HmKEfuMf0lcv1cS41UA?= =?iso-8859-1?Q?TLJ4cWUT+zZl5Olb/nFd7lOIfcdmfrPYq76ahtyb40qlJcKvyaj/VPv66C?= =?iso-8859-1?Q?7LWbFUAmojl1gtXYx/PKSYJT5y8IJsVE+fbf2ab/k4oh+DZ4PRO0DIRmYK?= =?iso-8859-1?Q?IoxNNRVpc0hdEAetYmU2EgKWhS3YZPn27FvUR7ua08mmWtkAY33Rbg2+47?= =?iso-8859-1?Q?uXhUEm1r3yEC2mqo81gl5GDqg0Ij5N/IW77kC4u3UuTHbvJ9x8VfnX5mZJ?= =?iso-8859-1?Q?Au/p2pmaioEsS9QfcE5arP6PBDts6oxl+168dUWuiRx76GbBoJvRGK61X7?= =?iso-8859-1?Q?nEl7oAraH5LnZO4D6cjCLSQFMqkw2whzC1cH1IX2K6u/8crGch559OuGnq?= =?iso-8859-1?Q?5jnvezI9DCV+knGwcbKLY7r5skW2cjuRikvFF3bDTJXTgN8fvepi/pcBDB?= =?iso-8859-1?Q?v5TCmNq0oJvFqDpk+4rS7/xIvl3kdlf+AGiCb2aaHoPeu1Taq1RBh0qagN?= =?iso-8859-1?Q?NTURy94yCrPZmV49uZieheQEQ9FyKIOaP43cf+tKOpa+Qi27HAvc3blYMf?= =?iso-8859-1?Q?+cMl/bOC1YE84BZcUHIBcdiSZlq2GG72u/pNH+MYxe3fLVDl03AQpszsyb?= =?iso-8859-1?Q?QfXSkKst0OgXW8rMgAE6f3BDmpHxaZhs1PvNAgtXNSYX9q6RVeizFOpq8L?= =?iso-8859-1?Q?kZ9OBiUa6wiiZleaGLmh5oVYzqin30RPJlnAIn1V/1FWnDfDPieuOMDMHS?= =?iso-8859-1?Q?CmBylTVg=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 6:uydavallUfNYY533rYJlPj/mLxQa1y4ifX1qRLGwZ+Cw+poVinPDkY/xwIR4RZeiwUd54eIg/pMzEBVXAyHyENx/X7B04mCiiv4wQYUp+35F8rOpY4uYYZqshoXUTCQgmvZ1ZAFzNiXJq1IhuMj6pKa8bzMZvqdV2aMgYeEUYOw5yJ1F4ql4JiM51wtDUEIJ86EBqq1YVygfcQ9HkqE2UH3Vz918uR4b5yEw8nJrOyPJtqGu1Hi70LkhcUd4yK2vOl6gJbpHx0faIKd2ltQ2zFxRuaPCyybqrroKRKWkgXUtan7veIi0aOYSs3kk3C9ItcmOI9beJjl1qwtt9CxiIi+MwAovfouBS0t2+i9HGcI=; 5:nHMDZpbWyOuGX3vFZr/MlKxMhnx6SnqPqvoC65ct0Eq2pl2qOMZ2Na8sGnZbP1rH+//wFTfk55Rw33J++i/N+DZokDyE2OWdaF7iM/+lRMV7EH00L1yqtriC3siTy7CT2T91L47RYfVzlylpXq18oxwUymJt5/thl8710c32PTo=; 24:B1AFJKp2iHee3DfbWRuHm6JzulrWGHt66iyvR+LYNPqUU+F2WSjPvHo8L72vtPR6kaAZC6TAzvnD6nI4wlMjnJbsTxMf9oJc7qpOJ9/kDKQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 7:fXOst92QNntALwG7rkPx42ZW2xCRBo0JUYox8TYtShWBojZ4fGONw/tjWIbuBWgSv6fYKckER/YG6GSXNNxuZvU46T45fPbjcZCLqgLrmidLll4qdJVbkrbT411PC55TXYtcOgAoSkIx3nwK5hJZ4+WR3U8YCZaiGLx6S3aMA+YgRaEiCQGi1tx+TXAAwdLm7tdBw7Ju1BU+K5Yd2VtKUjaGae7M2mk1XnsMHebvfI6kX4uscDZCTnkpYzB78vCxZIZdnu6vZIFnZdpci0pSPa8FJqVIxpv6lVtlGTX7w4f9EemKFemvZCFK1tVmdYSpY3Ga9sUChLcoUDN7WN9l/ZQEatjz0mHLGRiB5dwvLN8= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2016 18:37:48.9253 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2497 Archived-At: Cc: IETF IDR WG , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 18:37:52 -0000 On Oct 19, 2016, at 12:58 PM, t.petch wrote: > But then RFC7120 has >=20 > ' The WG chairs are responsible for informing IANA > that the expired assignments are not required and that the code > points are to be marked "deprecated". >=20 > A deprecated code point is not marked as allocated for use as > described in any document (that is, it is not allocated) and is not > available for allocation in a future document. The WG chairs may > inform IANA that a deprecated code point can be completely > de-allocated (i.e., made available for new allocations) at any time > after it has been deprecated' >=20 > So I think that deprecation is permanent until you say otherwise so I > guess that makes you right! Could be even clearer, but as you say if closely parsed it does agree = with what I reckoned it meant. Thanks! --John= From nobody Wed Oct 19 11:54:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39D7129665 for ; Wed, 19 Oct 2016 11:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 PH_wh7G5JzY0 for ; Wed, 19 Oct 2016 11:54:06 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 21CE7129428 for ; Wed, 19 Oct 2016 11:54:06 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id A8F5B540B3D; Wed, 19 Oct 2016 14:54:05 -0400 (EDT) Date: Wed, 19 Oct 2016 14:54:05 -0400 From: Jared Mauch To: "t.petch" Message-ID: <20161019185405.GA12214@puck.nether.net> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 18:54:09 -0000 On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch wrote: > I remain unhappy with this I-D. > > I find it ironic that the messages for this Last Call should be > interspersed with those relating to what goes wrong when someone > somewhere else in the world uses a field in an unexpected way. This > reinforces my belief that this I-D should be more forceful in calling > out the dangers (eg MUST instead of SHOULD). > > I think that this I-D is factually incorrect, or at least open to > misinterpretation, when it says > '[RFC1997] BGP Communities attributes are four-octet values split into > two two-octet words. The most significant word is usually > interpreted as an Autonomous System Number (ASN) ' rfc1998: section 4 gives you the slice + dice bits: -- snip -- rfc 1998 -- To make use of the BGP community attribute, several community values (MCI's AS number: 3561 = 0x0DE9) have been defined that can be used by customers to tag routes so that the appropriate "LOCAL_PREF" values are configured. Table 2 lists the appropriate community attribute values (and the mappings of community to LOCAL_PREF): -- snip -- rfc 1998 -- This is the segmenting, and most customers have "ip bgp community new-format" configured. If your issue is about printf %ull vs %d:%d:%d we operators can solve this by ensuring our vendors do the right thing, which we have already done 20 years ago via rfc1998. This nit is imo not worth picking. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Wed Oct 19 12:46:32 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F16129559 for ; Wed, 19 Oct 2016 12:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KMOZBNqkQIkB for ; Wed, 19 Oct 2016 12:46:29 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6501F1293E3 for ; Wed, 19 Oct 2016 12:46:29 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id f128so52898769qkb.1 for ; Wed, 19 Oct 2016 12:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+hqPofQHGT05M7KFlEekdw2LRBvLJEoM+X5ryHQFLik=; b=WhsbW1mqHrkS0rTNA+e4qXbNEUyjzXcmMmmrVriodvEz2PibE8jSYjnHqD4bpSLlrh hPR/Dhtc00MaO6TySKzeVXKsp2ZEQjTxg12QsolSla3ym9C+bj08h4MuNDixceDxLTkX yO2cEU9eMdP5R62+G/8aL9WuldN/LKKXVTwWUmVblwdKKVLHf3GBboUZ9Oss/3cLrX2M 30Gtd4c9x8rtKqY5dMz7NuT2+TfcDrJ+hqeVve34NF8b6l+l2FLbf4FXlBsCY4PR1tBZ YUaiy2FoE/C/7sbAY4Bi2bdKxNoFl+idwKqnCdwSwwWqWwR+enELwUGlKb6O8P9PtuDW K+6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+hqPofQHGT05M7KFlEekdw2LRBvLJEoM+X5ryHQFLik=; b=Wt0QmbZoZNlAbnl4wFei6PjZlPbMoqMBVLTFMWJuyxbVa5EWvPVOpa8V2TNFFvQdr3 GaFYopBaIFzYrqufzwKJ8nm2O4NewWruFG8KJAvNoELxitXEIyKXkGWPWHCA3VvV5BwW XmEcwaTVVxztnCzTCPYBRWEKFvNoTVhfbugPWkfIYtLRS7vtknEcXndS1hKub23/GjgZ WMKIQftXM5d+Qwg5e6E7XzoApRnXvVGOrx3gLEWtGgOzg7gWNdOG0RsUuvsxVsRx8mtn k5GNP2dmiwwzzoYvmDyRpq882gSuXZygTK14XM6EZ92meB56FqJCFr+pW+qg54lyGK+X iixw== X-Gm-Message-State: AA6/9RnYlGDgRMLJ9jFRrViXCn7cxglE+XTbK7gUb0SwekhV4LGXf7sWsyCzYdrV9DAwdJAI/pcr2xClFBaHhQ== X-Received: by 10.194.74.5 with SMTP id p5mr5988290wjv.92.1476906388382; Wed, 19 Oct 2016 12:46:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.207 with HTTP; Wed, 19 Oct 2016 12:46:27 -0700 (PDT) In-Reply-To: <20161019185405.GA12214@puck.nether.net> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> From: Brian Dickson Date: Wed, 19 Oct 2016 12:46:27 -0700 Message-ID: To: Jared Mauch Content-Type: multipart/alternative; boundary=047d7bd9111aa569a4053f3d1011 Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 19:46:31 -0000 --047d7bd9111aa569a4053f3d1011 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 19, 2016 at 11:54 AM, Jared Mauch wrote: > On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch wrote: > > I remain unhappy with this I-D. > > > > I find it ironic that the messages for this Last Call should be > > interspersed with those relating to what goes wrong when someone > > somewhere else in the world uses a field in an unexpected way. This > > reinforces my belief that this I-D should be more forceful in calling > > out the dangers (eg MUST instead of SHOULD). > > > > I think that this I-D is factually incorrect, or at least open to > > misinterpretation, when it says > > '[RFC1997] BGP Communities attributes are four-octet values split into > > two two-octet words. The most significant word is usually > > interpreted as an Autonomous System Number (ASN) ' > > rfc1998: section 4 gives you the slice + dice bits: > > -- snip -- rfc 1998 -- > To make use of the BGP community attribute, several community values > (MCI's AS number: 3561 = 0x0DE9) have been defined that can be used > by customers to tag routes so that the appropriate "LOCAL_PREF" > values are configured. Table 2 lists the appropriate community > attribute values (and the mappings of community to LOCAL_PREF): > -- snip -- rfc 1998 -- > > This is the segmenting, and most customers have > "ip bgp community new-format" configured. > > If your issue is about printf %ull vs %d:%d:%d we operators > can solve this by ensuring our vendors do the right thing, which > we have already done 20 years ago via rfc1998. > > This nit is imo not worth picking. > > I think Tom was concerned about the usage of "usually", not the 16:16 format. I agree, and I am also concerned. Per Susan Hare's WGLC instructions, here are my specific concerns, and suggested text for correcting those concerns: Concern #1: >From my reading of RFC1997, and from a couple of decades of operational experience, I believe the wording in Section 1 should be as follows: "The most significant word is always an ASN. Private ASN values MAY be used when agreed upon by adjacent BGP peers." (Insert reference to IANA private 32-bit ASN table.) Rationale: The second sentence was not explicitly part of RFC1997, but definitely has been operational practice, and is implied by the meaning of ASN, and tables of 16-bit ASN values (reserved, private, and available/assigned.) Concern #2: And, IMNSHO, the request/demand for parity with RFC1997, calls for similar language when describing the 32-bit first field's interpretation: In Section 2: "Global Administrator: A four-octet namespace identifier. This MUST be an Autonomous System Number. Private ASN values MAY be used when agreed upon by adjacent BGP peers. Private ASN values SHOULD NOT be advertised to peers where their use has not been agreed upon." Rationale: Trying to separate out the "best practice" into a separate, non-Standards-Track document, significantly weakens the practical ability BY OPERATORS to enforce the requirement of exclusive control of the meanings assigned by them, of the number space within communities (regular and wide). The draft, as currently worded, gives third parties "wiggle room" to use non-ASN values as the first 32-bit field. Their argument will be that this document does not say "MUST", and for whatever choice of argument they pick, they are justified in squatting on someone's ASN as the first 32-bit value. Since Section 1 of this document give exclusive semantic control of that portion of the Large Community space -- " a four-octet ASN and two four-octet operator-defined values, each of which can be used to denote properties or actions significant to that ASN." -- squatting needs to be explicitly prohibited via use of "MUST" instead of "SHOULD" in specifying Global Administrator as meaning, exclusively, ASN. Concern #3: In addition, to address concerns the co-authors have expressed, the non-intent of "MUST", to implementers, should be explicitly called out. The proposed wording would be: "The Global Administrator field is intended to allow different Autonomous Systems to define Large BGP Communities without collision. Implementations MUST allow the operator to specify any value for the Global Administrator field. Implementors MUST NOT restrict permitted values of ASN, including non-reserved 16-bit ASN values and non-reserved 32-bit ASN values, which includes all Private Use ASN ranges. Use of third-party ASN values is an explicitly permitted use of Large Communities." Rationale: Avoid any ambiguity for implementation of Large Communities. Interoperation demands compatible interpretation of values of ASN permitted by implementors. Of course, if the above changes are adopted, I approve publication, whole-heartedly. Brian Dickson --047d7bd9111aa569a4053f3d1011 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 19, 2016 at 11:54 AM, Jared Mauch <jared@puck.nether.n= et> wrote:
On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch= wrote:
> I remain unhappy with this I-D.
>
> I find it ironic that the messages for this Last Call should be
> interspersed with those relating to what goes wrong when someone
> somewhere else in the world uses a field in an unexpected way.=C2=A0 T= his
> reinforces my belief that this I-D should be more forceful in calling<= br> > out the dangers (eg MUST instead of SHOULD).
>
> I think that this I-D is factually incorrect, or at least open to
> misinterpretation,=C2=A0 when it says
> '[RFC1997] BGP Communities attributes are four-octet values split = into
>=C2=A0 =C2=A0 two two-octet words.=C2=A0 The most significant word is u= sually
>=C2=A0 =C2=A0 interpreted as an Autonomous System Number (ASN) '
=C2=A0 =C2=A0 =C2=A0 =C2=A0 rfc1998: section 4 gives you the slice += dice bits:

-- snip -- rfc 1998 --
=C2=A0 =C2=A0To make use of the BGP community attribute, several community = values
=C2=A0 =C2=A0(MCI's AS number: 3561 =3D 0x0DE9) have been defined that = can be used
=C2=A0 =C2=A0by customers to tag routes so that the appropriate "LOCAL= _PREF"
=C2=A0 =C2=A0values are configured. Table 2 lists the appropriate community=
=C2=A0 =C2=A0attribute values (and the mappings of community to LOCAL_PREF)= :
-- snip -- rfc 1998 --

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is the segmenting, and most customers have=
"ip bgp community new-format" configured.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If your issue is about printf %ull vs %d:%d:%d = we operators
can solve this by ensuring our vendors do the right thing, which
we have already done 20 years ago via rfc1998.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This nit is imo not worth picking.


I think Tom was concerned about the usage of "usually= ", not the 16:16 format. I agree, and I am also concerned.
<= br>
Per Susan Hare's WGLC instructions, here are my specific = concerns, and suggested text for correcting those concerns:

<= /div>
Concern #1:

From my reading of RFC1997, = and from a couple of decades of operational experience,
I believe= the wording in Section 1 should be as follows:

&q= uot;The most significant word is always an ASN. Private ASN values MAY be u= sed when agreed upon by adjacent BGP peers."
(Insert referen= ce to IANA private 32-bit ASN table.)

Rationale:

The second sentence was not explicitly part of RFC1= 997, but definitely has been operational practice, and is implied by the me= aning of ASN, and tables of 16-bit ASN values (reserved, private, and avail= able/assigned.)

Concern #2:

And, IMNSHO, the request/demand for parity with RFC1997, calls for simil= ar language when describing the 32-bit first field's interpretation:

In Section 2:

"Gl= obal Administrator: =C2=A0A four-octet namespace identifier.=C2=A0 This MUS= T be an Autonomous System Number. Private ASN values MAY be used when agree= d upon by adjacent BGP peers. Private ASN values SHOULD NOT be advertised t= o peers where their use has not been agreed upon."
Rationale:

Trying to separate out the = "best practice" into a separate, non-Standards-Track document, si= gnificantly weakens the practical ability BY OPERATORS to enforce the requi= rement of exclusive control of the meanings assigned by them, of the number= space within communities (regular and wide).

The = draft, as currently worded, gives third parties "wiggle room" to = use non-ASN values as the first 32-bit field. Their argument will be that t= his document does not say "MUST", and for whatever choice of argu= ment they pick, they are justified in squatting on someone's ASN as the= first 32-bit value.=C2=A0

Since Section 1 of this= document give exclusive semantic control of that portion of the Large Comm= unity space -- " a four-octet ASN and two four-octet operator-defined = values, each of which can be used to denote properties or actions significa= nt to that ASN." -- squatting needs to be explicitly prohibited via us= e of "MUST" instead of "SHOULD" in specifying Global Ad= ministrator as meaning, exclusively, ASN.

Concern = #3:

In addition, to address concerns the co-author= s have expressed, the non-intent of "MUST", to implementers, shou= ld be explicitly called out. The proposed wording would be:
"= ;The Global Administrator field is intended to allow different
= =C2=A0 =C2=A0Autonomous Systems to define Large BGP Communities without col= lision.
=C2=A0 =C2=A0Implementations MUST allow the operator to s= pecify any value for the
=C2=A0 =C2=A0Global Administrator field.= Implementors MUST NOT restrict permitted values
=C2=A0 =C2=A0of = ASN, including non-reserved 16-bit ASN values and non-reserved 32-bit ASN
=C2=A0 =C2=A0values, which includes all Private Use ASN ranges. Us= e of third-party ASN values
=C2=A0 =C2=A0is an explicitly permitt= ed use of Large Communities."

Rationale: Avoi= d any ambiguity for implementation of Large Communities. Interoperation dem= ands compatible interpretation of values of ASN permitted by implementors.<= /div>

Of course, if the above changes are adopted, I app= rove publication, whole-heartedly.

Brian Dickson
--047d7bd9111aa569a4053f3d1011-- From nobody Wed Oct 19 13:05:40 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A631296D1 for ; Wed, 19 Oct 2016 13:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 h4aKu_J5lM_s for ; Wed, 19 Oct 2016 13:05:38 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 126D2129476 for ; Wed, 19 Oct 2016 13:05:38 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id B9C8A840 for ; Wed, 19 Oct 2016 20:05:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnSnbCEDUKY9 for ; Wed, 19 Oct 2016 15:05:36 -0500 (CDT) Received: from mail-qk0-f198.google.com (mail-qk0-f198.google.com [209.85.220.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 74DD45FD for ; Wed, 19 Oct 2016 15:05:36 -0500 (CDT) Received: by mail-qk0-f198.google.com with SMTP id z190so26725441qkc.4 for ; Wed, 19 Oct 2016 13:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9NnkClMLRv+F+wCq5k0mFTZGUyk9+HcVg2gn9ce9jjQ=; b=PAtzRkenK3Z2fzfnq1GMfi7Nc6jR0pYiGuIsyDgiVezxQqRmyj1apq+Jr7ZfNlZQyj d5rxEJRq+m5tcEEPe7y8mm/wkw4qE/1VkC67vsYJMlJ3V9xkYGZNOANklMvMvvfzHjmc GOXlfMANMKEv3MYLRdLD4+Z2muHc6BObE4loZsMRIeJC1+ymyIdv1azMBsrCUwjtjH+W G58C6Du7dLc4lfOQY9R3Uuk/fyCp6GOMkEeeABtQTWyrn0FDXwhsDQQQARMufbG0fnST PESWJQd/nYcRsMz/UbrSxOX9Iygk+EqNYD5JB+gJuV/f+z6MS0PUI48ImljZQQvfIVWf OUkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9NnkClMLRv+F+wCq5k0mFTZGUyk9+HcVg2gn9ce9jjQ=; b=k6ZWLfcLEB3CIJvKmxpkAo+D18CcEEMVwIRA4LmESj6znqXvs9Q8QpnhD2S0F/M78l iXkX7Np82kksqk1wjkcurnWA/1bTxeR+iF1SFA/pp4AM5T6RycoryuVS2SmlTDnXyHbf 2ezb6V9K81Mz3u2Q0X0OREa+kMA2yrN43KPPpcCgkq9KH74Jnmk+/V1PEu4/QMprIvNT L7cQkVzp8z0NvotVNYt3AbS3IZJkf/IaM6onQAkbaVM55V/vzHML5+/kYwwVeCX95ze0 fPuSxxdivkkIL6mkif0p5TQl+zopn6K+E/5sdVWz8tiLBQvOeiFTNsgGt8S2mT6LuhNe PGXw== X-Gm-Message-State: AA6/9Rm6EkFo4MztaMAlwKvtBMJxR4/EALbcal3PfBuBwSnu+TrIH/VUMvus+c37Wq+5LAjvzoaN9NG1wGDiQiNDbDHKF3gGRgp4G/QIHMNOZudT9mCN/pnIUprmHH4avJmIH6MHlxj1MchPfg== X-Received: by 10.200.41.201 with SMTP id 9mr7706996qtt.138.1476907535811; Wed, 19 Oct 2016 13:05:35 -0700 (PDT) X-Received: by 10.200.41.201 with SMTP id 9mr7706982qtt.138.1476907535608; Wed, 19 Oct 2016 13:05:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.41.230 with HTTP; Wed, 19 Oct 2016 13:05:34 -0700 (PDT) In-Reply-To: <107141A7-5CD2-4E48-8F6C-C737FF370359@pfrc.org> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <107141A7-5CD2-4E48-8F6C-C737FF370359@pfrc.org> From: David Farmer Date: Wed, 19 Oct 2016 15:05:34 -0500 Message-ID: To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a1139743a06c449053f3d553d Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 20:05:39 -0000 --001a1139743a06c449053f3d553d Content-Type: text/plain; charset=UTF-8 My intent for this was to motivate why it's necessary for implementations to include filtering policies in order to be complete, which I think is in scope for this document. It's not intended to supplant a BCOP document, which would talk about how to use the policies and need way more details and examples. On Wed, Oct 19, 2016 at 1:20 PM, Jeffrey Haas wrote: > > On Oct 19, 2016, at 2:12 PM, David Farmer wrote: > > I believe this is ready to go and support it's publication as-is. > However, I believe it would be improved with the addition of something like > the following paragraph; > > While from a BGP protocol perspective it is necessary for large > communities to be > transitive, as there are many plausible situation where large > communities need to > be used to signal beyond a singles or even directly adjacent Autonomous > Systems. > On other other hand, large communities are not necessarily intended to > be passed > unimpeded across the entirety of the Internet either. Therefore, > implementations > SHOULD provide a rich set of policy capabilities to allow operators to > decide which > large communities are received from or propagated to peers. > > > FWIW, I'd rather see such a thing as part of a grow document for good > community practices. > > I had thought that a BCOP document on communities was out there for BGP > communities in general, but "community" clutters the search engines quite a > bit and I'm not finding such a thing. > > -- Jeff > > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a1139743a06c449053f3d553d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My intent for this was to motivate why it's necessary = for=C2=A0implementations to includ= e filtering policies in order to be complete, which I think is in scope for= this=C2=A0document. It's not intended to=C2=A0supplant=C2=A0a BCOP=C2= =A0document, which=C2=A0would talk about how to use the policies and need way more = details and examples. =C2=A0

On Wed, Oct 19, 2016 at 1:20 PM, Jeffrey Haas <jhaas@= pfrc.org> wrote:

On Oct = 19, 2016, at 2:12 PM, David Farmer <farmer@umn.edu> wrote:

I believe this is ready to go and support it's publication as-is.= =C2=A0 However, I believe it would be improved with the addition of somethi= ng like the following paragraph;

=C2=A0 =C2=A0While fr= om a BGP protocol perspective it is necessary for large communities to be= =C2=A0
=C2=A0 =C2=A0transitive, as there are many plausible situa= tion where large communities need to=C2=A0
=C2=A0 =C2=A0be used t= o signal beyond a singles or even directly adjacent Autonomous Systems. =C2= =A0
=C2=A0 =C2=A0On other other hand, large communities are not n= ecessarily intended to be passed=C2=A0
=C2=A0 =C2=A0unimpeded acr= oss the entirety of the Internet either. Therefore, implementations=C2=A0
=C2=A0 =C2=A0SHOULD provide a rich set of policy capabilities to a= llow operators to decide which=C2=A0
=C2=A0 =C2=A0large communiti= es are received from or propagated to peers.


FWIW, I'd rather see such a thing as part of a grow document for good= community practices.

I had thought that a BCOP do= cument on communities was out there for BGP communities in general, but &qu= ot;community" clutters the search engines quite a bit and I'm not = finding such a thing.

-- Jeff

=



--
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking &am= p; Telecommunication Services
Office of Information Technology
Univer= sity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Ce= ll: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
--001a1139743a06c449053f3d553d-- From nobody Wed Oct 19 15:01:35 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC52129469 for ; Wed, 19 Oct 2016 15:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bQCzYg9tK1du for ; Wed, 19 Oct 2016 15:01:33 -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 D1E5C1295C6 for ; Wed, 19 Oct 2016 15:01:32 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u9JM1TcT080846 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2016 23:01:29 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be cupcake.local Message-ID: <5807ED30.30204@foobar.org> Date: Wed, 19 Oct 2016 23:01:20 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.4 (Macintosh/20161007) MIME-Version: 1.0 To: Jeffrey Haas References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <107141A7-5CD2-4E48-8F6C-C737FF370359@pfrc.org> In-Reply-To: <107141A7-5CD2-4E48-8F6C-C737FF370359@pfrc.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: Sue Hares , IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 22:01:35 -0000 Jeffrey Haas wrote: > I had thought that a BCOP document on communities was out there for BGP > communities in general, but "community" clutters the search engines > quite a bit and I'm not finding such a thing. are you thinking of rfc7454? Dave's suggestion is definitely an operational- rather than a protocol-level issue. draft-ietf-idr-large-community is a protocol definition, so it would be better to see this in a GROW document. Nick From nobody Wed Oct 19 15:25:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE361297F3 for ; Wed, 19 Oct 2016 15:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 sARr0mieZb1E for ; Wed, 19 Oct 2016 15:25:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B912B129492 for ; Wed, 19 Oct 2016 15:25:16 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id CEB091E1F0; Wed, 19 Oct 2016 18:27:26 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3ECDF03A-5CFF-48D4-B805-210000612974" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Jeffrey Haas In-Reply-To: <5807ED30.30204@foobar.org> Date: Wed, 19 Oct 2016 18:25:15 -0400 Message-Id: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <107141A7-5CD2-4E48-8F6C-C737FF370359@pfrc.org> <5807ED30.30204@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3226) Archived-At: Cc: Sue Hares , IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 22:25:18 -0000 --Apple-Mail=_3ECDF03A-5CFF-48D4-B805-210000612974 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 19, 2016, at 6:01 PM, Nick Hilliard wrote: >=20 > Jeffrey Haas wrote: >> I had thought that a BCOP document on communities was out there for = BGP >> communities in general, but "community" clutters the search engines >> quite a bit and I'm not finding such a thing. >=20 > are you thinking of rfc7454? Something more complete than that. An old NANOG output, if I recall = correctly. >=20 > Dave's suggestion is definitely an operational- rather than a > protocol-level issue. draft-ietf-idr-large-community is a protocol > definition, so it would be better to see this in a GROW document. That's the point I was trying to make. Although a "operational = considerations" section is considered reasonable for IETF RFCs these = days. (https://tools.ietf.org/html/rfc5706 = ) >=20 > Nick --Apple-Mail=_3ECDF03A-5CFF-48D4-B805-210000612974 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 19, 2016, at 6:01 PM, Nick Hilliard <nick@foobar.org> = wrote:

Jeffrey Haas wrote:
I had thought that a BCOP document on communities was out = there for BGP
communities in general, but "community" = clutters the search engines
quite a bit and I'm not = finding such a thing.

are you = thinking of rfc7454?

Something more complete than that.  An old NANOG = output, if I recall correctly.


Dave's suggestion is definitely an operational- rather than = a
protocol-level issue. =  draft-ietf-idr-large-community is a protocol
definition, so it would be better to see this in a GROW = document.

That's the point I was trying to make.  Although a = "operational considerations" section is considered reasonable for IETF = RFCs these days. (https://tools.ietf.org/html/rfc5706)



Nick

= --Apple-Mail=_3ECDF03A-5CFF-48D4-B805-210000612974-- From nobody Wed Oct 19 15:29:17 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E439A129854 for ; Wed, 19 Oct 2016 15:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fNR1ChUvR7KV for ; Wed, 19 Oct 2016 15:29:15 -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 EAC6C12984F for ; Wed, 19 Oct 2016 15:29:14 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u9JMTBBj081654 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2016 23:29:11 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be cupcake.local Message-ID: <5807F3AF.9080200@foobar.org> Date: Wed, 19 Oct 2016 23:29:03 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.4 (Macintosh/20161007) MIME-Version: 1.0 To: Brian Dickson References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 22:29:17 -0000 Brian Dickson wrote: > "Global Administrator: A four-octet namespace identifier. This MUST be > an Autonomous System Number. [...] > Implementations MUST allow the operator to specify any value for the > Global Administrator field. Implementors MUST NOT restrict permitted values > of ASN so summarising: - operators: you MUST use an ASN - implementers: you MUST allow any value I'm really not convinced that it's good protocol definition practice to state one set of rules for implementers and another for operators, where the two sets of rules are not actually compatible with each other. Nick From nobody Wed Oct 19 15:31:39 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A08812949F for ; Wed, 19 Oct 2016 15:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 talGfDnvsrwu for ; Wed, 19 Oct 2016 15:31:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C519A129642 for ; Wed, 19 Oct 2016 15:31:35 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 0B34B1E1F0; Wed, 19 Oct 2016 18:33:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Jeffrey Haas In-Reply-To: <5807F3AF.9080200@foobar.org> Date: Wed, 19 Oct 2016 18:31:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <5807F3AF.9080200@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 22:31:38 -0000 > On Oct 19, 2016, at 6:29 PM, Nick Hilliard wrote: >=20 > Brian Dickson wrote: >> "Global Administrator: A four-octet namespace identifier. This MUST = be >> an Autonomous System Number. > [...] >> Implementations MUST allow the operator to specify any value for = the >> Global Administrator field. Implementors MUST NOT restrict = permitted values >> of ASN >=20 > so summarising: >=20 > - operators: you MUST use an ASN > - implementers: you MUST allow any value >=20 > I'm really not convinced that it's good protocol definition practice = to > state one set of rules for implementers and another for operators, = where > the two sets of rules are not actually compatible with each other. I think this is nicely stated. As recently noted, the operator proscription is an operational = consideration. In that context, it's fine. And simply moving it to an = operational considerations section may close this discussion. -- Jeff From nobody Wed Oct 19 15:34:42 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF79F12985B for ; Wed, 19 Oct 2016 15:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.731 X-Spam-Level: X-Spam-Status: No, score=-4.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 8fcPOcm4UQsn for ; Wed, 19 Oct 2016 15:34:39 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 46C6B129858 for ; Wed, 19 Oct 2016 15:34:39 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id BF709217 for ; Wed, 19 Oct 2016 22:34:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-aUeglHX0fe for ; Wed, 19 Oct 2016 17:34:38 -0500 (CDT) Received: from mail-qt0-f200.google.com (mail-qt0-f200.google.com [209.85.216.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 915B1165 for ; Wed, 19 Oct 2016 17:34:38 -0500 (CDT) Received: by mail-qt0-f200.google.com with SMTP id g45so33460180qte.5 for ; Wed, 19 Oct 2016 15:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=68Mf6rLGkl5bFSQis1eCG54Mc3QZhghusE6eENT75Mc=; b=fN/7rAXsaReT9cNQxWhC9ESpJY5II5ywMCNrzUmMgvJkln2zIN2+GwFyLlq8mxUkXn AlYMKgsUe7ZXdJ3KfLLCJgvhH3Rfu9OYSFIc5RuNdOIAJ6Y+6gTSropSbptQ6IbGVGxu OaBNm+gii9uIrPd49Eso3toYuBBaDFA1D4v15tCEup0QBckGO/XzuzbtVHrt0IaV4gbA nIDUy2pNTmPS3cEHi/ZL5SjOpXvqxIvcqCcGp6YagXefsDJAgsv3DKses2KDhNRoM1gd XLR+rmLu9raoF8umsejPwwsdTV9QVHDQJlwqOR4BqMe2CIX531LVSgyxLcl0ODWSQ8I6 NUnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=68Mf6rLGkl5bFSQis1eCG54Mc3QZhghusE6eENT75Mc=; b=hvzuushNR4XHpkvAVsYpMPfdgZg0fgw5v2CpfPXF2rwV76OlT8jpcHv6BFGJohQEIX zxXXkuj8KFNnF2ch7urgULu0leIsvwCQ50MG9e8AscmNfpMAsXeNSq5Jq2NQTFlMBlzv RV0AwVS/1DJyyZ0387OzWFUQtoVPvqJIuEkIz0adq1A+LtfoZEEASa5MF0Z4HFdbtmPm dEDvrvhjB4NCREctaYTmgJZWDwIGLTU9UYzCQ8fW+ahrBLp/fRO6Jo/ZD4oVPgvB+Qsr I0RajADLBljfk7+xVGJLIL5Hf1ro6faerVw4Vlvv8RDbrP+oSwl9btZyXtZ0VFwtzT2g lw+w== X-Gm-Message-State: AA6/9RnXSMhdMiuN4zpxdXrzqGvBuYL3/6TrujugtMOEazoB9E+SP+T0iBV3fd1VLsizDWEHzayvMLDbzi00FuwqGOt8+HHiI/beJxzubRsiPmX+7oxOd8fqVv98FfQ4WdAirs7QTRAX16Rrmw== X-Received: by 10.55.56.12 with SMTP id f12mr8363068qka.106.1476916477950; Wed, 19 Oct 2016 15:34:37 -0700 (PDT) X-Received: by 10.55.56.12 with SMTP id f12mr8363061qka.106.1476916477781; Wed, 19 Oct 2016 15:34:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.41.230 with HTTP; Wed, 19 Oct 2016 15:34:37 -0700 (PDT) In-Reply-To: <5807ED30.30204@foobar.org> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <107141A7-5CD2-4E48-8F6C-C737FF370359@pfrc.org> <5807ED30.30204@foobar.org> From: David Farmer Date: Wed, 19 Oct 2016 17:34:37 -0500 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=001a114908ca057a15053f3f6a64 Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 22:34:41 -0000 --001a114908ca057a15053f3f6a64 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 19, 2016 at 5:01 PM, Nick Hilliard wrote: > Jeffrey Haas wrote: > > I had thought that a BCOP document on communities was out there for BGP > > communities in general, but "community" clutters the search engines > > quite a bit and I'm not finding such a thing. > > are you thinking of rfc7454? > > Dave's suggestion is definitely an operational- rather than a > protocol-level issue. draft-ietf-idr-large-community is a protocol > definition, so it would be better to see this in a GROW document. > > Nick > So it's slightly more than just the wire-protocol issues, it defines a Canonical Representation. I think that's important, but I think it's equally important that to interoperability that implementations include policy tools. I included some motivation for why the tools need to be included, but if you'd prefer to strip that out, I'd be fine with that. So that leaves something like this; Implementations SHOULD provide a rich set of policy capabilities to allow operators to decide which large communities are received from or propagated to peers. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a114908ca057a15053f3f6a64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 19, 2016 at 5:01 PM, Nick Hilliard <nick@foobar.org><= /span> wrote:
Jeffrey = Haas wrote:
> I had thought that a BCOP document on communities was out there for BG= P
> communities in general, but "community" clutters the search = engines
> quite a bit and I'm not finding such a thing.

are you thinking of rfc7454?

Dave's suggestion is definitely an operational- rather than a
protocol-level issue.=C2=A0 draft-ietf-idr-large-community is a protocol definition, so it would be better to see this in a GROW document.

Nick

So it's slightly= more than just the wire-protocol issues, it defines=C2=A0a Canonical Repre= sentation.=C2=A0 I think that's important, but I think it's equally= important that to interoperability that implementations include policy too= ls.=C2=A0 I included some motivation for why the tools need to be included,= but if you'd prefer to strip that out, I'd be fine with that. So t= hat leaves something like this; =C2=A0

=C2=A0 =C2=A0Implementations=C2=A0SHOULD provide a rich set of policy capabilities to allow ope= rators
=C2=A0 =C2=A0to decide which=C2=A0large=C2= =A0communities are received from or propagated to peers.
=


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication Service= s
Office of Information Technology
University of Minnesota=C2=A0=C2= =A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a114908ca057a15053f3f6a64-- From nobody Wed Oct 19 15:37:08 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBA01294EC for ; Wed, 19 Oct 2016 15:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 L3xffxbOJ-LG for ; Wed, 19 Oct 2016 15:37:02 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20868129448 for ; Wed, 19 Oct 2016 15:37:01 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id x79so50337939lff.0 for ; Wed, 19 Oct 2016 15:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UvVH6v7rIbDLBi8OhB7ZTd5WgiDUjkWLnRmAJc5JMNY=; b=oWH/Vb5S5ks9sQK1YGgUzLav/YtT0IbYeFV/b7yABi3l5xUBvUONL3jFVNdyhdGbjh 2kv8g99yyMTNSMrLqc/pjgl/+/9cd8XxFEWr744NBreWeDXpDIlOkxMkJ8bkufW27fmv i//uM2CJc4Yv/IREc9AXUxQYj/wkAciAQfuRzuOQjAkrqcJkd+bgn9/WI2qswLqyajs+ Mf98Iv+9z6ybB9U9tfivNwml+jlQk5CEDQ6jtb1mNVQ4wxoOFbalAOhQ5cn/hxo44oLE se9mfmXlMuV9RmlUqMqUToJTG6L1+mzA1/HJZgEK1CxGD0A5VpTB0lnJYabYjHy9JCLr 3fUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UvVH6v7rIbDLBi8OhB7ZTd5WgiDUjkWLnRmAJc5JMNY=; b=PfZdhbjSyc+tMIuGajkq7mO95F1qkbSmVp5oPxbvWoE/11FmQp+QztsS9Bdzf/qUqc H3GchhH4Ix0UFi8bkwopdsKWqIex8xqNHPSrNHCqC2dsK47yBACaL1DsyUbxLIznZ454 tQZd4KDt6luKcxXBZ/BbwgUM1A8f3hT2dnPtjpcdfCY7iqzF5gBx0fGFGA3aWAiE1q46 TMzCObkXxWF0lmMyH1/u8kKDMn5Jf9D4BVIjMv5jc/gcBFocVNMbLW/Sg8OZoK0g9K4c AHr+qrJkFl5ae8NmVwqvEJsnLJVav/8E4+CH9y025/bfpKxLJrInYT8+he2iED+LR+3v Fr6g== X-Gm-Message-State: AA6/9RnEiBLT4UahQ0FxIYXbz/I+xismR1tqqENRoOfS3DjTifllFcZBtx8WOJM5WrFyP8GIils17A53Er7DTg== X-Received: by 10.28.20.12 with SMTP id 12mr1451168wmu.61.1476916620112; Wed, 19 Oct 2016 15:37:00 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Wed, 19 Oct 2016 15:36:59 -0700 (PDT) In-Reply-To: <5807F3AF.9080200@foobar.org> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <5807F3AF.9080200@foobar.org> From: Robert Raszuk Date: Thu, 20 Oct 2016 00:36:59 +0200 X-Google-Sender-Auth: LFWYdN6o6IHKiijP8QcwJSAJD8k Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=001a1146d99081382d053f3f728b Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 22:37:06 -0000 --001a1146d99081382d053f3f728b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > so summarising: > > - operators: you MUST use an ASN > - implementers: you MUST allow any value > =E2=80=8BIMHO this is too coarse simplification. For operators if we are getting into this here vs in companion GROW doc draft/rfc must define what sending vs receiving operator is expected to do. =E2=80=8BFor implementation allowing any value unless policy is in place. A= nd as such policy must be able to validate against BGP Origin Validation database if present and enabled on the router. Again .. I assume we are all talking about first 4 octets only right ? Or also second 4 octets too ? Best, R. --001a1146d99081382d053f3f728b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
so summarising:

- operators: you MUST use an ASN
- implementers: you MUST allow any value

=E2=80=8BIMHO this is too coarse simplification.=C2=A0=

For operators if we a= re getting into this here vs in companion GROW doc draft/rfc must define wh= at sending vs receiving operator is expected to do.=C2=A0

=E2=80=8BFor implementation allowing = any value unless policy is in place. And as such policy must be able to val= idate against BGP Origin Validation database if present and enabled on the = router.=C2=A0

Again ..= I assume we are all talking about first 4 octets only right ? Or also seco= nd 4 octets too ?

Best= ,
R.

--001a1146d99081382d053f3f728b-- From nobody Wed Oct 19 16:21:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AE3129520 for ; Wed, 19 Oct 2016 16:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BEIrNrxfuQtl for ; Wed, 19 Oct 2016 16:21:39 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93CA129510 for ; Wed, 19 Oct 2016 16:21:38 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id l131so46528722lfl.2 for ; Wed, 19 Oct 2016 16:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PjlUwdg4idaz38BMHd7MuWC5eP8HiwuoGa9Nb6CKxPg=; b=mGd13Q653OxhuN0fs7o7SyPqdY/bkowtTSPtabgilj1vQt2wGd5icnBWFqoc/a8r2/ C+AiQMtB2zmzEqCoJGz2QEvKkvq94/TXLLDnYR6Q/jfhSKNQI6poQ4INtdCv1XuJJpqQ sggoQ3nveA7DqIDyCLL0hTe78mZgBKUX9qnSz7JDVflbDBpWL2zWaLZ2C7AlWb1DXjWG 37fQMtCiSWReY32FxSm70G+huL/YT0WGp5+16Rzg9vLeHsYilYiVQ3eMCWvS1hCRPjSu CxYFW5VBnoAoVs+LhCovoL4neCTg9mALUYL+g52xKuBkVXrgi0TpeiGTho5TjEHk6AtR aQAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PjlUwdg4idaz38BMHd7MuWC5eP8HiwuoGa9Nb6CKxPg=; b=CDqY2OuUmQemcetw5vACGOL0YYznfgc705MUixjVTvOq7essd4UUx9+VDxvl3VyMJy xGjSUs5vUhy6HhlZbs1leKJO1V2Th19a2Ag748M+cLEqf43IbishL5Q7/d4+ioVzO0nQ uBW4KH1cZEt8p8kTse5hv5TI4NF1yzb165ZHBLHNzvMbN8hLKP5q1j0XnTCs5y50kpCT lypctdCN1ATMAhwfMqZlJDlkhIGyd4K5QpA4wTD/918xsQskE5eclevWALTF7/vcJZMn ySFqgr5rd+gaDCVemMkAC+Z9wrM9+tLJZ2qfHEGEv5S/PyWJtYnMVK6PzRt1oP7HDEGA GWYw== X-Gm-Message-State: AA6/9RmYVL3Zuj0FHc6aHfowy2eYEgRO7SDrYr9wqw+ULvpxd7UJHmzj52IWzjIIMjwTZ74arhnFCDZjMBLVTA== X-Received: by 10.28.4.16 with SMTP id 16mr7153360wme.39.1476919296641; Wed, 19 Oct 2016 16:21:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.207 with HTTP; Wed, 19 Oct 2016 16:21:35 -0700 (PDT) In-Reply-To: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <5807F3AF.9080200@foobar.org> From: Brian Dickson Date: Wed, 19 Oct 2016 16:21:35 -0700 Message-ID: To: Robert Raszuk Content-Type: multipart/alternative; boundary=001a1141f0bc09cfe6053f40122a Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 23:21:42 -0000 --001a1141f0bc09cfe6053f40122a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 19, 2016 at 3:36 PM, Robert Raszuk wrote: > so summarising: >> >> - operators: you MUST use an ASN >> - implementers: you MUST allow any value >> > > =E2=80=8BIMHO this is too coarse simplification. > > For operators if we are getting into this here vs in companion GROW doc > draft/rfc must define what sending vs receiving operator is expected to d= o. > > =E2=80=8BFor implementation allowing any value unless policy is in place.= And as > such policy must be able to validate against BGP Origin Validation databa= se > if present and enabled on the router. > You've lost me here. If I am sending prefix X, and I am ASN A, and the community is B:C:V, the BGP OV will show A is allowed to originate X. There are no other restrictions applicable from OV. Also, the meaning of B:C:V is exclusively defined by ASN B, who may or may not be a directly connected peer. Nobody except B is expected to "do" anything. What B does, is a combination of: - What B tells the world - What B tells some subset of the world (e.g. via a customer portal which has restricted access) - What B uses to decide for whom each set of actions is permitted - Any internal policies and procedures known only to B E.g. B may allow B:C:V from customers of B (including customers of customers, etc.) E.g. B may allow B:D:V from anyone for some set of values V and some specific values of "D" E.g. B may allow arbitrary automated functionality associated with B:*:{V1,V2,V3,... VN}, where the second parameter is a BGP peer of B, and VN is a trigger for some particular behavior (filter, prepend, change MED) Every ASN "B" can choose whatever it wants as the methods, mechanisms, values, etc., and those do not need to have any bearing on any other ASN's choices. Some ASNs will choose not to use their own ASN:X:Y, but rather use PRIVATE_ASN:X:Y and only do those on a per-peer basis (with distinct choices of PRIVATE_ASN, X, and Y, which can literally vary by peer, with no global meaning.) So, I think the "unless policy is in place" is a red herring; whether policy is there or not, and regardless of what policy there is, it is ALWAYS "allow any value". > > Again .. I assume we are all talking about first 4 octets only right ? Or > also second 4 octets too ? > > First 4 octets only. Brian --001a1141f0bc09cfe6053f40122a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 19, 2016 at 3:36 PM, Robert Raszuk <robert@raszuk.net&= gt; wrote:
so summarising:

- operators: you MUST use an ASN
- implementers: you MUST allow any value

=E2=80=8BIMHO this is too coarse simplification.=C2=A0

For operat= ors if we are getting into this here vs in companion GROW doc draft/rfc mus= t define what sending vs receiving operator is expected to do.=C2=A0
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small">
= =E2=80=8BFor implementation allowing any value unless policy is in place. A= nd as such policy must be able to validate against BGP Origin Validation da= tabase if present and enabled on the router.=C2=A0
<= /div>

You've lost me here. If I am send= ing prefix X, and I am ASN A, and the community is B:C:V, the BGP OV will s= how A is allowed to originate X. There are no other restrictions applicable= from OV.
Also, the meaning of B:C:V is exclusively defined by AS= N B, who may or may not be a directly connected peer.

<= div>Nobody except B is expected to "do" anything.
What = B does, is a combination of:
- What B tells the world
-= What B tells some subset of the world (e.g. via a customer portal which ha= s restricted access)
- What B uses to decide for whom each set of= actions is permitted
- Any internal policies and procedures know= n only to B

E.g. B may allow B:C:V from customers = of B (including customers of customers, etc.)
E.g. B may allow B:= D:V from anyone for some set of values V and some specific values of "= D"
E.g. B may allow arbitrary automated functionality associ= ated with B:*:{V1,V2,V3,... VN}, where the second parameter is a BGP peer o= f B, and VN is a trigger for some particular behavior (filter, prepend, cha= nge MED)

Every ASN "B" can choose whatev= er it wants as the methods, mechanisms, values, etc., and those do not need= to have any bearing on any other ASN's choices.

Some ASNs will choose not to use their own ASN:X:Y, but rather use PRIVA= TE_ASN:X:Y and only do those on a per-peer basis (with distinct choices of = PRIVATE_ASN, X, and Y, which can literally vary by peer, with no global mea= ning.)

So, I think the "unless policy is in p= lace" is a red herring; whether policy is there or not, and regardless= of what policy there is, it is ALWAYS "allow any value".
=C2=A0

Again .. I assume we are a= ll talking about first 4 octets only right ? Or also second 4 octets too ?<= /div>
=

First 4 = octets only.

Brian=C2=A0
--001a1141f0bc09cfe6053f40122a-- From nobody Wed Oct 19 16:28:16 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39DB12984A for ; Wed, 19 Oct 2016 16:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dc7-UllbktWO for ; Wed, 19 Oct 2016 16:28:14 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72951295A5 for ; Wed, 19 Oct 2016 16:28:13 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id x79so52606921lff.0 for ; Wed, 19 Oct 2016 16:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=J0wQU8JFqvBSyXkNK4bEbjjIH56LBJ/4y8ZoUqp3voc=; b=A5EIJVVP3/XV3kjki/tU2ENPBcjmQwaqSWwzOkA5Ri5AwjqVwfyfl+fTBFMnawzGn2 EDWav+Oaa4gs/I+iZela2y2/kdkDvk4xC6USOq9JawphMANCvUaSy3aDS3yxGWCbaZfa T7utmZwl7fu/q3VX59UNf4ukT5o7PdyBXnMetGAxf7mD/9Md/mo7zwx8XuF6otQ1r93Q w2MRRiSWsGzcqhcOudcfMGFzx9Hyyr2zmhdTVA2OWmU+YvwWYjlvwQR2XNyLtYPzmEAS B1bpZk0VEgQyIH+IEpCRomtB39nfSgdv97nssZdwhdzvQq/eiITBqR5PoKuogV6BQ4qC n/CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=J0wQU8JFqvBSyXkNK4bEbjjIH56LBJ/4y8ZoUqp3voc=; b=aWHwU42kRFiys3EyVNJ394ayyqugZQhbewq1ucCSjIjotllHhE8Y4RyvhH5/ViVCg9 bWCrLwXZoEqkQWdr6l9HcxcDasD3IuBppgC6/TFhTAemc9WVQAxTEdmCStE9RNFPP/aw A6ESX5oQiW6Bqw0xQDKBTu19uYeJJeVGt6Eazye9YmScxUBCgjc+OlLV+22BYbH4bay2 ePjefR9PQU4uk/5cdCy+HTrVEKeLYG7NjPOzEnFhhSBK6uGhidfTbvKccNvlBSSvFwmo uwq1J+NvuUCwOGrKjLyhUH4/BQ6Kkc9vOFT7o5dq7X7IxB+HFzjenD3RrfWME5ZJ1AJ3 LNbg== X-Gm-Message-State: AA6/9RmVGk0IYuJazDH2Bbj8iZuXk+tMmltYqIkyFJikCwS+frh9KIHckzjoDVlq2WZrE87pUPrnURMG5A3jHA== X-Received: by 10.28.46.15 with SMTP id u15mr4309883wmu.61.1476919691888; Wed, 19 Oct 2016 16:28:11 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Wed, 19 Oct 2016 16:28:10 -0700 (PDT) In-Reply-To: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <5807F3AF.9080200@foobar.org> From: Robert Raszuk Date: Thu, 20 Oct 2016 01:28:10 +0200 X-Google-Sender-Auth: 1DMrmXwLh9c3p12RurpGUUGjgv8 Message-ID: To: Brian Dickson Content-Type: multipart/alternative; boundary=001a1142532c98d03d053f402915 Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 23:28:16 -0000 --001a1142532c98d03d053f402915 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brian, Regarding BGP OV I meant to use it as a database of valid ASNs - where it is present.. Nothing to do with actual prefixes in MP_REACH here. > So, I think the "unless policy is in place" is a red herring; whether policy is there or not, > and regardless of what policy there is, it is ALWAYS "allow any value". Well if my policy says drop junk it can not ALWAYS act as "allow any value". Thx, R. On Thu, Oct 20, 2016 at 1:21 AM, Brian Dickson < brian.peter.dickson@gmail.com> wrote: > > > On Wed, Oct 19, 2016 at 3:36 PM, Robert Raszuk wrote: > >> so summarising: >>> >>> - operators: you MUST use an ASN >>> - implementers: you MUST allow any value >>> >> >> =E2=80=8BIMHO this is too coarse simplification. >> >> For operators if we are getting into this here vs in companion GROW doc >> draft/rfc must define what sending vs receiving operator is expected to = do. >> >> =E2=80=8BFor implementation allowing any value unless policy is in place= . And as >> such policy must be able to validate against BGP Origin Validation datab= ase >> if present and enabled on the router. >> > > You've lost me here. If I am sending prefix X, and I am ASN A, and the > community is B:C:V, the BGP OV will show A is allowed to originate X. The= re > are no other restrictions applicable from OV. > Also, the meaning of B:C:V is exclusively defined by ASN B, who may or ma= y > not be a directly connected peer. > > Nobody except B is expected to "do" anything. > What B does, is a combination of: > - What B tells the world > - What B tells some subset of the world (e.g. via a customer portal which > has restricted access) > - What B uses to decide for whom each set of actions is permitted > - Any internal policies and procedures known only to B > > E.g. B may allow B:C:V from customers of B (including customers of > customers, etc.) > E.g. B may allow B:D:V from anyone for some set of values V and some > specific values of "D" > E.g. B may allow arbitrary automated functionality associated with > B:*:{V1,V2,V3,... VN}, where the second parameter is a BGP peer of B, and > VN is a trigger for some particular behavior (filter, prepend, change MED= ) > > Every ASN "B" can choose whatever it wants as the methods, mechanisms, > values, etc., and those do not need to have any bearing on any other ASN'= s > choices. > > Some ASNs will choose not to use their own ASN:X:Y, but rather use > PRIVATE_ASN:X:Y and only do those on a per-peer basis (with distinct > choices of PRIVATE_ASN, X, and Y, which can literally vary by peer, with = no > global meaning.) > > So, I think the "unless policy is in place" is a red herring; whether > policy is there or not, and regardless of what policy there is, it is > ALWAYS "allow any value". > > >> >> Again .. I assume we are all talking about first 4 octets only right ? O= r >> also second 4 octets too ? >> >> > First 4 octets only. > > Brian > --001a1142532c98d03d053f402915 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Brian,

Regarding BGP OV I meant to use it as a database of va= lid ASNs - where it is present.. Nothing to do with actual prefixes in MP_R= EACH here.=C2=A0

> So, I think t= he "unless policy is in place" is a red herring; whether policy i= s there or not,=C2=A0
> and regardless of what policy = there is, it is ALWAYS "allow any value".
<= br>
Well if my policy says drop junk it can not ALWAYS act as "allow an= y value".=C2=A0

Thx,
R.
<= span style=3D"font-size:12.8px">


On Thu, Oct 20, 2016 at 1:21 AM, = Brian Dickson <brian.peter.dickson@gmail.com> wr= ote:


On Wed, Oct 19,= 2016 at 3:36 PM, Robert Raszuk <robert@raszuk.net> wrote:
so summa= rising:

- operators: you MUST use an ASN
- implementers: you MUST allow any value

=E2=80=8BIMHO this is too coarse simplification.=C2=A0

For operat= ors if we are getting into this here vs in companion GROW doc draft/rfc mus= t define what sending vs receiving operator is expected to do.=C2=A0
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small">
= =E2=80=8BFor implementation allowing any value unless policy is in place. A= nd as such policy must be able to validate against BGP Origin Validation da= tabase if present and enabled on the router.=C2=A0
<= /div>

You've lost me here. If I = am sending prefix X, and I am ASN A, and the community is B:C:V, the BGP OV= will show A is allowed to originate X. There are no other restrictions app= licable from OV.
Also, the meaning of B:C:V is exclusively define= d by ASN B, who may or may not be a directly connected peer.

=
Nobody except B is expected to "do" anything.
What B does, is a combination of:
- What B tells the world
- What B tells some subset of the world (e.g. via a customer portal w= hich has restricted access)
- What B uses to decide for whom each= set of actions is permitted
- Any internal policies and procedur= es known only to B

E.g. B may allow B:C:V from cus= tomers of B (including customers of customers, etc.)
E.g. B may a= llow B:D:V from anyone for some set of values V and some specific values of= "D"
E.g. B may allow arbitrary automated functionality= associated with B:*:{V1,V2,V3,... VN}, where the second parameter is a BGP= peer of B, and VN is a trigger for some particular behavior (filter, prepe= nd, change MED)

Every ASN "B" can choose= whatever it wants as the methods, mechanisms, values, etc., and those do n= ot need to have any bearing on any other ASN's choices.

<= /div>
Some ASNs will choose not to use their own ASN:X:Y, but rather us= e PRIVATE_ASN:X:Y and only do those on a per-peer basis (with distinct choi= ces of PRIVATE_ASN, X, and Y, which can literally vary by peer, with no glo= bal meaning.)

So, I think the "unless policy = is in place" is a red herring; whether policy is there or not, and reg= ardless of what policy there is, it is ALWAYS "allow any value".<= /div>
=C2=A0

Agai= n .. I assume we are all talking about first 4 octets only right ? Or also = second 4 octets too ?

<= br>
First 4 octets only.

Brian=C2=A0

--001a1142532c98d03d053f402915-- From nobody Wed Oct 19 16:57:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B76129497 for ; Wed, 19 Oct 2016 16:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6sMpHVcelbjH for ; Wed, 19 Oct 2016 16:56:58 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EE5129448 for ; Wed, 19 Oct 2016 16:56:57 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id l131so48019591lfl.2 for ; Wed, 19 Oct 2016 16:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l2eUCCoHo6Oa1CzGCpFJBdPEnMvOM7q54n7G/V0FYPg=; b=tJv3FAdH2yOOPfK4uyER4kusYNwJbXSSEAfXs/B0VNyvSBQgaDeJ+KMxgBbN3UvIOt OIwr+hRL8Qk5WMJdX3Z5PJVFO3Nd53knKxaHKSYpA2pW7uuuaf8jH+skC/YQbAcvBYZO 9erwoq7A/vMzFhnQEgY0gfDJvoZnCjgc/WkSx3TKl9+hksP598AW33Qtikh+8Rp+ptXC QrHxLbQPcBjstRWkP1X67NF2437BYh9gkXrtH0/F8s36GWSaQpV1Wy85JMxPZ8tAFFEI 7AhVsiAzXKIqjScH7N27TjK/Ug/VOdaUeWR4fjEHuS7B6jrritIeo8Nsro4XXWcEdr5Y nhCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l2eUCCoHo6Oa1CzGCpFJBdPEnMvOM7q54n7G/V0FYPg=; b=VG9RK+jWDb2hwh37NyTE303MBO55ZSRQHJ53hikq8IHr0bfwmpe5Zl1sDTqaWO3FfK zLp37Moxgsmsz6jgt52EOkmy80MHpHpcluW8MUkFcC/07fzxuXhJDWpE67+1kisxsDtZ bzGTyYxYAkE0vfCfzuN/qAwUqXMbJYg6YwWK4U/IN9GTVbwTLxxOwhXUicMlPgUVp2el +hZLoZR1GXJu0rLndabXKYhJzrj4pYbYLxVNXLzcEW09U7Cw12qccDWHC3pk3muvedLy 6BlAXa+pCDpbNuhUtIllY/l964iFza2LM49nQif+5tPegqanUJhb91eeqFChyPUP94Bi vC6Q== X-Gm-Message-State: AA6/9Rn0eaYmpKjyVMHsDRMCt/kHG0htC69GjpCnBmy2QfrM9ILpZBStkadcjl0H3J0pRTaklmcTBKHmtG/bvQ== X-Received: by 10.194.74.5 with SMTP id p5mr6476878wjv.92.1476921415129; Wed, 19 Oct 2016 16:56:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.207 with HTTP; Wed, 19 Oct 2016 16:56:53 -0700 (PDT) In-Reply-To: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <5807F3AF.9080200@foobar.org> From: Brian Dickson Date: Wed, 19 Oct 2016 16:56:54 -0700 Message-ID: To: Robert Raszuk Content-Type: multipart/alternative; boundary=047d7bd9111a4f6052053f40909f Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 23:57:01 -0000 --047d7bd9111a4f6052053f40909f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 19, 2016 at 4:28 PM, Robert Raszuk wrote: > Brian, > > Regarding BGP OV I meant to use it as a database of valid ASNs - where it > is present.. Nothing to do with actual prefixes in MP_REACH here. > > > So, I think the "unless policy is in place" is a red herring; whether > policy is there or not, > > and regardless of what policy there is, it is ALWAYS "allow any value". > > Well if my policy says drop junk it can not ALWAYS act as "allow any > value". > Yes, the implementation should still "allow any value". Given that BGP OV is not guaranteed to be the complete universe of ASNs, and certainly excludes private use ASNs, then NO, use of such a database is an unwise idea. Even using a bogon list or other source of "up to date" ASNs, is not a good idea, at least for on-router enforcement. The timeliness aspect of updates to those has been shown to be a problem. One need only look at any number of mailing lists, where "Please update your bogon filter" messages are common. The real problem is asymmetry. The entity that ends up on the bogon list is harmed, while the action needed to remedy that harm is vast and decentralized (operators), with no guaranteed, reliable speed of resolution of problems. It would be fine to have a configuration management system do mild enforcement or alerting, to limit operator error; but there should always be the ability to over-ride or ignore those protections. Something similar to "re-type your email address" should be about the level of enforcement of ASN values, to avoid fat-fingering things, IMHO. At some point in the future, presuming some kind of better managed peering DB and routing policy language, including publication of "locally well known wide communities", protection mechanisms related to communities would make sense. But not until the preconditions are there (the bits after "presuming"). Brian > > Thx, > R. > > > > On Thu, Oct 20, 2016 at 1:21 AM, Brian Dickson < > brian.peter.dickson@gmail.com> wrote: > >> >> >> On Wed, Oct 19, 2016 at 3:36 PM, Robert Raszuk wrote= : >> >>> so summarising: >>>> >>>> - operators: you MUST use an ASN >>>> - implementers: you MUST allow any value >>>> >>> >>> =E2=80=8BIMHO this is too coarse simplification. >>> >>> For operators if we are getting into this here vs in companion GROW doc >>> draft/rfc must define what sending vs receiving operator is expected to= do. >>> >>> =E2=80=8BFor implementation allowing any value unless policy is in plac= e. And as >>> such policy must be able to validate against BGP Origin Validation data= base >>> if present and enabled on the router. >>> >> >> You've lost me here. If I am sending prefix X, and I am ASN A, and the >> community is B:C:V, the BGP OV will show A is allowed to originate X. Th= ere >> are no other restrictions applicable from OV. >> Also, the meaning of B:C:V is exclusively defined by ASN B, who may or >> may not be a directly connected peer. >> >> Nobody except B is expected to "do" anything. >> What B does, is a combination of: >> - What B tells the world >> - What B tells some subset of the world (e.g. via a customer portal whic= h >> has restricted access) >> - What B uses to decide for whom each set of actions is permitted >> - Any internal policies and procedures known only to B >> >> E.g. B may allow B:C:V from customers of B (including customers of >> customers, etc.) >> E.g. B may allow B:D:V from anyone for some set of values V and some >> specific values of "D" >> E.g. B may allow arbitrary automated functionality associated with >> B:*:{V1,V2,V3,... VN}, where the second parameter is a BGP peer of B, an= d >> VN is a trigger for some particular behavior (filter, prepend, change ME= D) >> >> Every ASN "B" can choose whatever it wants as the methods, mechanisms, >> values, etc., and those do not need to have any bearing on any other ASN= 's >> choices. >> >> Some ASNs will choose not to use their own ASN:X:Y, but rather use >> PRIVATE_ASN:X:Y and only do those on a per-peer basis (with distinct >> choices of PRIVATE_ASN, X, and Y, which can literally vary by peer, with= no >> global meaning.) >> >> So, I think the "unless policy is in place" is a red herring; whether >> policy is there or not, and regardless of what policy there is, it is >> ALWAYS "allow any value". >> >> >>> >>> Again .. I assume we are all talking about first 4 octets only right ? >>> Or also second 4 octets too ? >>> >>> >> First 4 octets only. >> >> Brian >> > > --047d7bd9111a4f6052053f40909f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 19, 2016 at 4:28 PM, Robert Raszuk <robert@raszuk.net&= gt; wrote:
Brian,

=
Regarding BGP OV I meant to use it as a database of valid ASNs - where it = is present.. Nothing to do with actual prefixes in MP_REACH here.=C2=A0

> = So, I think the "unless policy is in place" is a red herring; whe= ther policy is there or not,=C2=A0
> and regardless of what policy there is, i= t is ALWAYS "allow any value".

Well if my policy says drop junk it can not ALWAY= S act as "allow any value".=C2=A0
=

Yes, the implementation should still "allow any va= lue".

Given that BGP OV is not guaranteed to = be the complete universe of ASNs, and certainly excludes private use ASNs, = then NO, use of such a database is an unwise idea.

Even using a bogon list or other source of "up to date" ASNs, is= not a good idea, at least for on-router enforcement. The timeliness aspect= of updates to those has been shown to be a problem.
One need onl= y look at any number of mailing lists, where "Please update your bogon= filter" messages are common.

The real proble= m is asymmetry. The entity that ends up on the bogon list is harmed, while = the action needed to remedy that harm is vast and decentralized (operators)= , with no guaranteed, reliable speed of resolution of problems.
<= br>
It would be fine to have a configuration management system do= mild enforcement or alerting, to limit operator error; but there should al= ways be the ability to over-ride or ignore those protections.
Something similar to "re-type your email address" sho= uld be about the level of enforcement of ASN values, to avoid fat-fingering= things, IMHO.

At some point in the future, presum= ing some kind of better managed peering DB and routing policy language, inc= luding publication of "locally well known wide communities", prot= ection mechanisms related to communities would make sense.
But no= t until the preconditions are there (the bits after "presuming").=

Brian


=C2= =A0

Thx,
R.


On Thu, Oct 20, 2016 at 1:21 AM, Brian Dickson = <brian.peter.dickson@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


On Wed, Oct 19, 2016 at 3:36 PM, Ro= bert Raszuk <robert@raszuk.net> wrote:
so summarising:

- operators: you MUST use an ASN
- implementers: you MUST allow any value

=E2=80=8BIMHO this is too coarse simplification.=C2=A0

For operat= ors if we are getting into this here vs in companion GROW doc draft/rfc mus= t define what sending vs receiving operator is expected to do.=C2=A0
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small">
= =E2=80=8BFor implementation allowing any value unless policy is in place. A= nd as such policy must be able to validate against BGP Origin Validation da= tabase if present and enabled on the router.=C2=A0
<= /div>

You've lost me here. If I = am sending prefix X, and I am ASN A, and the community is B:C:V, the BGP OV= will show A is allowed to originate X. There are no other restrictions app= licable from OV.
Also, the meaning of B:C:V is exclusively define= d by ASN B, who may or may not be a directly connected peer.

=
Nobody except B is expected to "do" anything.
What B does, is a combination of:
- What B tells the world
- What B tells some subset of the world (e.g. via a customer portal w= hich has restricted access)
- What B uses to decide for whom each= set of actions is permitted
- Any internal policies and procedur= es known only to B

E.g. B may allow B:C:V from cus= tomers of B (including customers of customers, etc.)
E.g. B may a= llow B:D:V from anyone for some set of values V and some specific values of= "D"
E.g. B may allow arbitrary automated functionality= associated with B:*:{V1,V2,V3,... VN}, where the second parameter is a BGP= peer of B, and VN is a trigger for some particular behavior (filter, prepe= nd, change MED)

Every ASN "B" can choose= whatever it wants as the methods, mechanisms, values, etc., and those do n= ot need to have any bearing on any other ASN's choices.

<= /div>
Some ASNs will choose not to use their own ASN:X:Y, but rather us= e PRIVATE_ASN:X:Y and only do those on a per-peer basis (with distinct choi= ces of PRIVATE_ASN, X, and Y, which can literally vary by peer, with no glo= bal meaning.)

So, I think the "unless policy = is in place" is a red herring; whether policy is there or not, and reg= ardless of what policy there is, it is ALWAYS "allow any value".<= /div>
=C2=A0

Again .. I assu= me we are all talking about first 4 octets only right ? Or also second 4 oc= tets too ?


First 4 octets only.

Brian= =C2=A0


--047d7bd9111a4f6052053f40909f-- From nobody Wed Oct 19 23:03:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA1F12952E for ; Wed, 19 Oct 2016 23:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 Yp_0MCAT6RhB for ; Wed, 19 Oct 2016 23:03:29 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 7E8B4129441 for ; Wed, 19 Oct 2016 23:03:29 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E05A9A2; Thu, 20 Oct 2016 08:03:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1476943405; bh=Fe2cbxaaISxKeNcAnQr4EDtIAIZUYrYjEMjcu3+uxTk=; h=Date:From:To:Subject:In-Reply-To:References:From; b=JjKI2dgBppjdKVfC0l16bT8LPFJVG6sH+8gYGcXn29kM/kzqzGBOfc3dNSl0tvY6b SGE7sfDyH1eY100NtkvQhUN7lQ7mYOp2C6RrYSPM8VLUmBOpENc5GNwAJADPc7OjeA dcw//ZQTSPThtRcgPO7xUv1uZQKOxyBIhP8YJJJE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D5FDBA1 for ; Thu, 20 Oct 2016 08:03:25 +0200 (CEST) Date: Thu, 20 Oct 2016 08:03:25 +0200 (CEST) From: Mikael Abrahamsson To: IETF IDR WG In-Reply-To: Message-ID: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <5807F3AF.9080200@foobar.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 06:03:31 -0000 On Wed, 19 Oct 2016, Brian Dickson wrote: > Yes, the implementation should still "allow any value". When I have created BGP route policies, I've several times asked myself the question "what will the vendor implementation do itself, and what do I need to do in my policy". So for instance, do I need to implement the well-knowns myself, or is that something that I need to do in my policy? If I for operational reasons want the router to not do something (for instance I do want NO-EXPORT to traverse AS boundary), how do I do that? I think here in the IETF we should always consider to have separate documents for what goes on the wire (compatibility reasons), and what the implementation should do with this information by default in case the user also can set policy. The contents of the -large- fields and whether the implementation should check if this is true is a typical thing that the "wire" document should not over-specify. That should instead be an operational document, and that should involve GROW as well. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Oct 20 02:15:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F49129430 for ; Thu, 20 Oct 2016 02:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 tPNu1PAOBn9G for ; Thu, 20 Oct 2016 02:15:38 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0093.outbound.protection.outlook.com [104.47.0.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DDCC129547 for ; Thu, 20 Oct 2016 02:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Zl1f6t0xd77SwG0l8/NZcv35djIaq71HNabMMD5GuYI=; b=RQQVvj+M2nibYmdLQk0xW/kG/rje4MZiFXA1YGh/zj0c4LRCJnV+2VogIH3GWqcf/36d5RQBD0ETtJfdVsb+tkAkbQtK2yYU2Eu3FyXGDFJUs/ccJ35Y5eqH+SH14uzVm7OHod8SkZoKTN4dlbsWYd5yi5sSpBCvGuzD2BCOgTc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Thu, 20 Oct 2016 09:15:34 +0000 Message-ID: <01ab01d22ab2$2b54f8e0$4001a8c0@gateway.2wire.net> From: t.petch To: Jared Mauch References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> Date: Thu, 20 Oct 2016 09:37:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: DB6PR0601CA0031.eurprd06.prod.outlook.com (10.169.209.17) To HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137) X-MS-Office365-Filtering-Correlation-Id: 6fa3265e-e008-480c-5807-08d3f8c9a607 X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 2:qt4vUOWM/AvlyYaci2iCiPsjjZwWLu41YjB8t0CTr0DCXN/q5z5pg4ZRGviWBu29F4m4Fx6QgVIz+B8CsM2NHGZ/2jTVyP7zFblH9lx9d1ILZ+JjV0MEP1uLFiN8v8NitAFpiydqjB0M/+kcEEHHGKNgBt47dKrC+gERdSzndXEOo4i0lGF9oGP97GK/YG6/JmyxyInJaa9eaVrD0hwi5w==; 3:96zvMhmq63juAKGDGAAuUN3C7qhcgTO9P/sGrWTqJZCBAfCyraa20Ww3GgERx7eeX1ALcA2Si0Vx6Nd48UWAUy73YoL5H0gc6XP/j01GJlmeicrBVz7pcARWJOWC1m/f/Lo60LTunZb+C7p/LtT3rg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3003; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 25:VNO4qHqBvAHGctU9o1hlbtHB9BNnBTgtptga1Yw4YBdxeggOrq7iJ3bKNKwxHY4NrHXStkooCU8mAmcXhZ9EDyZRxHWMjQCl8y4cd9oZUU7PhsVj0gWyCoiafTKLuoZdydhM8Mli7/1BTuhhz7zHd9m2fzRTFL7oja0E7B3WSpS5WqvWGXUipiHCSWbIXHB9l35p1CxAc2o0sbVszPeTmC4FD81oweXF6s4XL6OXkPEgMHaWUuf4wmzSoXlB/5kCpLBwskzkcDzn6yq70AMpe/u5FlFbbv8mHOB6whASfVgxfVaatXR3wWfU+0j1Tv7321qxp9MiU57Op7/x+YWIxFT8s9DmzF08gzEeVD7wgkZe0zjAwUXs8PbcLDLeTqmpucQkBwftEeYaZh2b3CpxOQT7Cu4R9x6c+HvnL3JBA5cuqi+/QlR4ti3kdE+zHyporLBi0rHVoV5iKZn27YwpXXeLvu5Wgeez0yTxa4N8Rv0zdYbOwrdeqdlZW20tul0GSE6VbROJMqIuiBuP22eBz+b6QsSuHoipKHL1Oy8hInIsFDU1GQgTXRTueSTNwuMBlHvkjgWUTBsqcAABETCZcWHGQtcnMJo1skdtyDmbekz6iq1qB8VVPGj0QpINL0/bnr8ZJf94uoGie8PDxGmaKM02eCiXkrIZW5KFxfxc/e2ISRGVtlHDIFy4wJ4oPF1OUmWmp8fxeHWkOBFfaxAaKwEFOXD3YV1vGrBoF3klLg76nUDfaKUOHstVcHU2DO8HqLHFbLMPmNzgZN+D6R/+JDVdg8sjj2ioLnsQlJxH15ordVxFBa75ysJSI4sdEGhp X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 31:fQxoipfdH6K8IgQBX7SaJ58BaPrgFqo0+qqfjppnmV3x/dcjTwugaK6zVnzyS1fqWX/K2WYHXrsVbZHbXwuritUUxYJ9GzK5XZUE64xaekIrdbVsDHzdUxd2FT1SEJxdp3QXUF6NzYBAQe49dYOOo/dis+PxSDyRvv8b64+Raha7+sSPs59AiyWYo09fz09qqp9VqJigbepWrVtIAV+LhIg+2N7dTtf10bBu1HPuhAAL1ZjsYOiZv+gMiCiZXY39Ua+Bb8LEPzfkofAl9gpQ+Q==; 4:/+mLhg475xcpcagVVITvEqO+/zqY6oVJFnn2o+lLJsqB0sufQkYtoHqjTd6RJ1SfKbReDOl/ujE7tczhWLjUdWL2kQBKd7SbptGdbbUNIpz3NPG0M8B1ZFUqCJweipBOAU5vsbs6cXWR88J1Cq+w63IbdEqzjUmxcEFQlkAbFRZ3QVL0DkJ1cqIi8aX4YmCSHMTseGlER1TRctm6WyW3dNBAW/ss0p398E/khjOqr+PmEIB4TGgvJDnpofdZqXbsEXqyqi00CYfxMwss8FiKrJoRb39hklEFk/5GUPWXqiuF9z5VkPrHAhuTGuFsKxI0XnE/D+Caw7hE6R9J7dSCkq/vRlqdnJqAf3oR0kINoWV5v+SDt237VYhvJ2L/jICD5amw33xDsMN7IfsWwlLgr5hxM0JerSAxYixoEQi/2Y9f6Dd5ccMWIJvWY9sfrTWxNrFqe4SM9vMHr7hr+ZCkLw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(124276396282122); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3003; X-Forefront-PRVS: 01018CB5B3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(5423002)(189002)(377454003)(13464003)(24454002)(199003)(51444003)(6916009)(93886004)(68736007)(84392002)(305945005)(19580395003)(86362001)(50226002)(19580405001)(7846002)(6666003)(2906002)(4326007)(42186005)(105586002)(230700001)(575784001)(23756003)(44736004)(61296003)(5660300001)(7736002)(97736004)(230783001)(15975445007)(110136003)(1456003)(3846002)(77096005)(1556002)(6116002)(81686999)(101416001)(9686002)(116806002)(81156014)(76176999)(62236002)(92566002)(50986999)(66066001)(586003)(4720700003)(81816999)(8676002)(14496001)(106356001)(44716002)(33646002)(47776003)(81166006)(50466002)(189998001)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3003; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3003; 23:kIHVP26IuQCoy5ZTyzT52JCaXF0Z9kijVbcxe?= =?iso-8859-1?Q?/VIvVjRECRDiiObZgo08SpV0bQnx9FM5iRxOIvw5Uno3fDju8OK+w3e/tb?= =?iso-8859-1?Q?FJr3Hxvny8KOb1/tgxB8i8NKlCCNxgsegv78QYDttvDL2rSNBrgn4+sXIw?= =?iso-8859-1?Q?UN6h6A/mSrgYW81MnvY5dsdAWmIw8WhY9bk+letwasT58shFtekYTBtkc4?= =?iso-8859-1?Q?hqnnoXdiuH2KABwzTk5aVYR1xF89hlBvJtsai1ykB21rDVR9sFyuJKHfUR?= =?iso-8859-1?Q?nHy6nClTmh16pJ/kCng5DYzW7PDSmG8mPq4b/scfQQ8/BEFBDBhRsqDafL?= =?iso-8859-1?Q?97phnCzmUFj66BQiPSwSThqO3fQZXmXHnCizOFYB0pYwHA0gpx8Go7Nr8Q?= =?iso-8859-1?Q?OqerQYgM+57zoZOOyph+FBs6tPf45El5Dprisi2OBhkdHacX+VeKOShB1K?= =?iso-8859-1?Q?IduDgHQU4ASPsfNYbtX2YokHZnQlWqBVC2/ROBMn44acs8zeBqTKaF/clj?= =?iso-8859-1?Q?YnMSJ3ry1G1RfL1W0Z0V5A/pZwxZjxM+tAXCZ/MGtyzeP6O+C6ZVrpgiMz?= =?iso-8859-1?Q?1AMIt3iQk2rk9ANg9wj5PZNuguNbWoEoWZM1Idb/eGishoFRqPvYD/zkIv?= =?iso-8859-1?Q?4omTkAu2zOLXfhxfWGzEQpHlNHvqNow46YOjtba9uQQuANypZYkF4Sldcq?= =?iso-8859-1?Q?irS/BeghlpJ5vbY9RdZ1xYMUGO1iNGwEujzvK9KuciHKto6tnhunS1sSX3?= =?iso-8859-1?Q?tr/5AFwT4Rpxj/T7Kdyg2dKQ8nWstglt+NXes6SXqHSI5M5bDxXeOQVNGG?= =?iso-8859-1?Q?70brVOl8igny7B7RJUY5AMdb2+tCHcRE+sI3rvahEC7LoD91cpVb8O0x9o?= =?iso-8859-1?Q?AmImtgzMZYv9/e1vL1klwG08+thptxROOnyhMPDpoaS1XS3xXgoU7WyYJt?= =?iso-8859-1?Q?kKlL49XqLTOr+k7ervSv29toBrA6pRv3cJxLaEAhPVvqFH7Quh2K354izl?= =?iso-8859-1?Q?1sqhHqb2ovOSVl/+HAeMulL2IMqMB23ri1XGgOF44yQaV4iHhp+wAKKtuh?= =?iso-8859-1?Q?LJDkq408jCICnX4oJGiteaBBa1sEnbkrznJNU4OB9urMQlEPymb/oUz+w4?= =?iso-8859-1?Q?SGNI5+M+AwtFbhJMhF2U2zCA/uRBNM378beWzcLrCY8/4mu6wsA+HMuW6m?= =?iso-8859-1?Q?o2a9+LedhIubUEbZHFkHmfDSARzkZx6/DKVafIC+WOKZJ8ZdP8SX/XWIqF?= =?iso-8859-1?Q?wQh8JCb+NreLK+uB1bkmuRy67qUAHQU72NZwCzn1GEUbz6CusoAcveI2s5?= =?iso-8859-1?Q?o5pzgltOvSYhv7AyhMtVXP3lHBzohkYWx1JoLrNG6B/pD+pyDAPRBtZYqo?= =?iso-8859-1?Q?Lb6/0IzmZS2P3BH39JPeqlsVL14LfTQA4zBxzkSj7QW9IDtOSyjM12fjgG?= =?iso-8859-1?Q?qTZnr+7pIHW32QhO4OWDG/7yz5kM6lCpCyW110YghhaWTEzeEN6YGap9IC?= =?iso-8859-1?Q?iRNfmPSKMEv977/2+0OpBQ07OhlbzOFHyjlPEgM1POXqK8YUUr9FQ3H0uR?= =?iso-8859-1?Q?l+EkpuoBQgLqnBFc0x4F72FZr82WSZNSpIxEsAHfuXvrOKaXTuu2Y1mqip?= =?iso-8859-1?Q?ncmnccURwtPeZnUq6zbXawiARAHU8hPRJs=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:G1UAAeFVa4y3y9QO4oqXY5bysay68ec14tj+iPgCr4i49A0s4iYINke60tKsIOxJkFckNHvoLG6UyRfzv85WIbN8qU48Yjwy+GUeE7s4yDO6WuSGb0yKRU61lPbmTAM2ERsRx/CT00ApqwRiHHVjQaL+0xnvoNJRc52LYyXF49D+cPImgB1kZi5qxNPAadYc3XZj1fWBlz5RqB+bEeoR5B8DA7r1hzRVlo1P3nGR0mkgBHNrsjS+7QY7AuhO1exMJeDH/SaXiiQqU1o9XLuv8sGKFnSEFYMSDamtDJvpsK/tmjWcXm+mqe7wtPQZpIem; 5:1GsSpIbi6gomvU5zPSleIaPRaqB2t+P2FdDxq9ENP8UPENPaGELS47LJ9WvWQwO3gljknsS0xE9DwdXzw9OIjouh3AFGAbMmC8HROAWGSJeK1kIb/xN29QsFU09RTbxnJNCxMWD8pq5lHyRa6pkKI/kroOtfABWWxms/oiByJxw=; 24:X8AAnNO6U5n0BRh/CKb7piUFoimNVJjIV26CjzBPzQUnWkajq3/WrDq5xx6Rr0R0CcgrtOMnE6upE07B3AVx+7TTdWqItcNxMp4KwGyRl1Y= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 7:la+Yvc2lPjBRfFIaRtQAHWXnJlf92962k9kTgorcXJ+4OOdOq73w0en5pFDcfvEcmsN6KOuBiPWTENmH/Mlbax9bVbcgQzRQmFMCW8WdsEzzIJTVSCbmgxxeI4V3oT5oMzjP4NB11uaTJLvFHrPUi3Bk0DszHHw2C/kHOlmEQ5wqu6coFzb4NzxrqQpm0m5JsVuUITnZaAE4yQAUhIWYFtP3dGJZVB7/WC9Og/BSAvPr6xl+pOzekS+ptndTyv0X2DMuX+n6L+MeQciFKbwG9Co9joD/XCnN4ryNweGIxgySGjZlfMZ4X0QMTMiXAcNfScxHG7kwCuJrfIJak37JPFTK6YiwmfkUFT3ivcGsEuQ= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2016 09:15:34.0740 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3003 Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 09:15:42 -0000 Jared As Brian has pointed out, it was the use of 'usually' that I was concerned with, as watering down the recommended use of an ASN by RFC1997. Excise 'usually' and that part of my concern goes away. Tom Petch ----- Original Message ----- From: "Jared Mauch" Sent: Wednesday, October 19, 2016 7:54 PM > On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch wrote: > > I remain unhappy with this I-D. > > > > I find it ironic that the messages for this Last Call should be > > interspersed with those relating to what goes wrong when someone > > somewhere else in the world uses a field in an unexpected way. This > > reinforces my belief that this I-D should be more forceful in calling > > out the dangers (eg MUST instead of SHOULD). > > > > I think that this I-D is factually incorrect, or at least open to > > misinterpretation, when it says > > '[RFC1997] BGP Communities attributes are four-octet values split into > > two two-octet words. The most significant word is usually > > interpreted as an Autonomous System Number (ASN) ' > > rfc1998: section 4 gives you the slice + dice bits: > > -- snip -- rfc 1998 -- > To make use of the BGP community attribute, several community values > (MCI's AS number: 3561 = 0x0DE9) have been defined that can be used > by customers to tag routes so that the appropriate "LOCAL_PREF" > values are configured. Table 2 lists the appropriate community > attribute values (and the mappings of community to LOCAL_PREF): > -- snip -- rfc 1998 -- > > This is the segmenting, and most customers have > "ip bgp community new-format" configured. > > If your issue is about printf %ull vs %d:%d:%d we operators > can solve this by ensuring our vendors do the right thing, which > we have already done 20 years ago via rfc1998. > > This nit is imo not worth picking. > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared@puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Thu Oct 20 02:15:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67AC129547 for ; Thu, 20 Oct 2016 02:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 gUuQTnS8Dmae for ; Thu, 20 Oct 2016 02:15:40 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0093.outbound.protection.outlook.com [104.47.0.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA4712950E for ; Thu, 20 Oct 2016 02:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oNeIhHViHZuyg2vkaGF47gu3EMvV45JJ3XvkDWVHykw=; b=J7haGKfb77E1sFbLSllP2vz92UsIAgGhM3EP35OYot6grLwvDDUF14PEQe7WY/mMAlfRa8hftVgelBgm378pD5hfLw+cMGJO4uA+xyePicqfAOpF9XFjczg+VjKlph6UVr5HDy5l38Y2VxrEPZBqrpmEitkeSy8x0GF1xUzzxIY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Thu, 20 Oct 2016 09:15:35 +0000 Message-ID: <01ac01d22ab2$2c05f960$4001a8c0@gateway.2wire.net> From: t.petch To: "Jakob Heitz (jheitz)" References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> Date: Thu, 20 Oct 2016 09:55:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: DB6PR0601CA0031.eurprd06.prod.outlook.com (10.169.209.17) To HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137) X-MS-Office365-Filtering-Correlation-Id: 4106a339-d571-4556-451f-08d3f8c9a6c2 X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 2:a48K65x6KYsK6WsI7DslHNZ0x5kwcC0Y8Op1ODPfg/cFRyQTCxcpLi8yFyfVzXO4D/f2uK5tuzKbbQals2wkL01jNMX1FdD1XYwn4QWRbjKe/dFH2YBlX+wzrV458GX4RpjXbEeEPtqlsxwkdLdo6hsdj2X5G4Rr2v78lOVEmvxdPaA8Jy6qS+SpjyMiSnO221MdSyW9nhnyzrbalarQNA==; 3:YGgLIk8u6HGE55BDNa3Dawod47lCOPRzu94RU9R3iyZX/IiNTme+WuFkFlUyfn7FBwmX3e0C/8IjlXT38bnEbc3/xZv1LHryk19G2W3VGICZtkwBnw6o9Dzscy46yAxKZxzhJMwh2L/AZQs2AwS4Fg==; 25:+RmlqVv5ed2PD3Aw02LZNhKzfaajq1PFzzGupqTrHQ6oMyuFll7d6qzTE9Q7Igx+fFe4SzQOtQpZdc+ULWf1WHF3RyYuQGP5Kg96xjsepr0neNmo7VeZMbvRLTxJBqkM8AB3YunbhMpFffdD9mMNQTL9kikY4wujdSUXPIgODJdSWi2SXpLgzssUk9SP23bQZzfaLgWCV4rNml2v490axDc7JkoCSOtWPSxXLGkIRlJsHeFhH/+EXSlLAXFbiUB5ERKiR3p1KCYcM5KIoCFcMcxUfLxq20bRJWYG5m2KWP7+hF237bP4Hd3FyibCNanaa9tW3AmVHNPTyceqhOxtx/YVcqHAY7uQvQkGlCl7j363M/VsK4q1fXim6+9N+fyCYbp8btJf74bWxqrOFKpWaRGN69bpCOyAs+x7foE1fddQPQo5qUhEPs2FS/PU6VKy X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3003; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 31:J0MNsDLzZz//Q05VIwjK/ComihA+zJtG+ICrVnn6zeNSbo0SD1CscMMNlhen2jspsT5ueRk0aHi1sIRosn5nNRGtX4cewr0v2+TbnupXOI6mfTeuTM1uO68q3KVq5d6cKUUMS0OHucTv4WzoldWVPKZxaejT7wCoAD8+AgdwIRg3xK7HmY5bq7eANiPTK7Z3HhMGUmypskyUm8/tOF3N9OvJ7xRqx0s3xXYvQR3bmtLXDJW0KP9M5wE0aaQ+GD4oDjXwDpwKkKhBsr1Bweb8pA==; 4:MDpWe2S1czJlxPcRi2wyOx4Xx+p6ongBi58Qsqm8v4inK8IjLRX3UujfmHfI1PEcvQBgC1h4tEEtZKcVa5bOfBEzjzTY9YNSv2w4jEyAy6W1qDxZ+0QozwWYvYFykG8N7d/J9SQh4UN45bZo68IAgyQjN7rZlJNLdpPTnCHmQC4IOUBLKmkE1NhdQT3Fp917MmmcbkZyu9Fq8x8Xm3nX7uisdh3BHfp5P6N2Lx8XrHad6nFZ+AU1iGtjD+orFa+ty/sANPrDN2H4EDjh9hMpbWcL9AI01ioAgfn3QrX0ybTiznyGGtTrsXrv/x/zmoc7AfZBB0mwv9XV5LR0VD9VVzRcYwjC3kcJXD7I5jRioXnl5HObOIICxipyhXP8qnkTy+vg8j2Ok6hOu+7UJdwQeDJr+LdUmULtxCMidUD4kjZjbglD4G1VIbBn4MucCmymgtnZ77aeRURYJXXDeb1Apmt8GCUVA4EGfTH8C39CaUE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3003; X-Forefront-PRVS: 01018CB5B3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(5423002)(189002)(377454003)(13464003)(24454002)(199003)(51444003)(6916009)(93886004)(68736007)(84392002)(305945005)(19580395003)(86362001)(50226002)(19580405001)(7846002)(6666003)(2906002)(4326007)(42186005)(105586002)(230700001)(23756003)(44736004)(61296003)(5660300001)(7736002)(97736004)(230783001)(15975445007)(110136003)(1456003)(3846002)(77096005)(1556002)(6116002)(81686999)(101416001)(9686002)(116806002)(81156014)(76176999)(62236002)(92566002)(50986999)(66066001)(586003)(4720700003)(81816999)(8676002)(14496001)(106356001)(44716002)(33646002)(47776003)(81166006)(50466002)(189998001)(116284003)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3003; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3003; 23:KnhaMofikMvRZJdrCehrP+4AuRyJ7fARjdpPs?= =?iso-8859-1?Q?FHHS9ZSEVHlUCO0At9DtjLN/EjaO4aNQjs1dxsZcDAGp+kVZNOu3bi0t5H?= =?iso-8859-1?Q?qqKUMec7FSD1bsN9ynuSK+JfE05gbWTB/yJroVkaBQiCCHQq/qlUlJv8Pj?= =?iso-8859-1?Q?4dnbsdYIHV0ngsZblDD0sl//dvJR4TLOcVCej/3VL1V18OFVY0NsNb/Zy1?= =?iso-8859-1?Q?aMwTU/vHnZJ8QeRzNoog39uJ94R4TKmzxzn1ze0peI5UBixexJ4fbtt2WL?= =?iso-8859-1?Q?67Mfd4g97kSFnDKIp2hMYdKH90dEoZrp0sZEKkgoox/zhiNaU02PMX4A8+?= =?iso-8859-1?Q?RO5bnNKOmQ1m+3JPneKqjUp3oAQc/5YO9SvlBTozAVrKZ1wUbrGAHmDdbJ?= =?iso-8859-1?Q?nWT3vIhSncz7ciJGqu/kp+NCnfg0WVh+xwIdw7TVKg9m1Kr+s/2sap66dM?= =?iso-8859-1?Q?3h6AlvJrFs6gFZcehzSHxB0nj9rOtroaNIcsw5LF2d8M6gxz71cI8jyRLL?= =?iso-8859-1?Q?Q79HW9vn7uQLiSciOw7I4hATmI27ClBEjFRiMcCy2SOWMpodivoGIo0x9C?= =?iso-8859-1?Q?R0Mh4ELRpYaq/pzU0ueHAWBKwa/rArfZCbwAU0LVdTbTbXk/Al8gKpVrkK?= =?iso-8859-1?Q?jETv8JOnEl5f7Fy5+hn6cR/XCCFNem6zzALUXPROxESw5qkBa+wV48bKAt?= =?iso-8859-1?Q?//vngt8A1riEb1rV0u8n8D8Ef1fxYcOUoB9+Tt0xu76+rDflX4cpNRLrld?= =?iso-8859-1?Q?7So2k+VvdWNxRRQmoMTxCVHHtXVe1+5JqlRtvJuXKq+LH1d7JOcTaxHK+u?= =?iso-8859-1?Q?cmsaKeCpiAOhYyJEjo6+GQ8D5MVfrEkDL7lWXms28+ojijbMzySWxKao0u?= =?iso-8859-1?Q?i0axRxU+VvqEzK+SCgdXyQDYKmI1pEqrLJjqTWMkV4Ow1UADi87BiE7nVu?= =?iso-8859-1?Q?7hOSFyszqG7sqyZ2vfLQEcWhUzPWaHPhJA/20hWka54ALkr46jPn/lxAJx?= =?iso-8859-1?Q?oygWHCjBMZxYLs3l0jIwNbjxEszxhZWDG7sNLreoQ5tdUlbIO5BlLl66UV?= =?iso-8859-1?Q?FS51e5PLn4/aeAERzr8FSFg0D7djDhZPz/yZiuiULNVKOt8nQ65c7cBPLR?= =?iso-8859-1?Q?EiuIJ8fCbNGh1QkQmqpkePkVlyGwtkWIXTHtiB6H7DG4AyfUHquKsULyEm?= =?iso-8859-1?Q?iZOkdyAmccuFlV1B2HuxMxaE3okYGa9GzW/x4t6j//IPu1fWaTjoUYXCwS?= =?iso-8859-1?Q?I7doVfIlpNh21SeHJdytfDBYYgEq0qXZaDjm6fh3Kri8SPn9Sj1ELMkD3K?= =?iso-8859-1?Q?TR/Xnkp7QPx/aATWq9VodkYEL6jVzFudiY94KfWdCouz33RzYFTK04aNK9?= =?iso-8859-1?Q?aQX9q1xxdk5/sOC0mQUYCu7rTPlf39KXZKwu1Vl5j2LkrBF83lH4q0k63O?= =?iso-8859-1?Q?wgJjDlWUCyoPd3Pmr7/aSN6VkpENYp90ubx5u51lDuYL7VGVVsBFKcgsHc?= =?iso-8859-1?Q?wAlq9hDx2Jm6qzIYZg12fAR0HfWzb0+lBU2fXIS2un1JuAYBobzKd5ZJy8?= =?iso-8859-1?Q?GOyLrXmIJdXn+EID/SRW+PW5dvGmORu9FmuiF7Mmg2wiRqfoigdpuQ18Bh?= =?iso-8859-1?Q?2r8VnWbUvRuF5OzjQ7n/QTMhvxI7imqpYs=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:ToKWZnCDhJvMX0IaIc5vQXyNIatVVPmE6WzHFbFgUDn/e0a3f5Bh6hYWKmzCPCDT1BOs2ivskQ5aGk3GOv9tfI8Qft2SJ1uhNvWPylK9/+pY7IXVGjp52h3rU/QZM00S3KndFHKGenEOxywCgg3DMV3nsYVwEodtuYgYiI6rCNi8pKSS011qJNjn7C6cos9qGpVItOm8IZn+/L14yBS8ExJMMPvJPJ5cvOhmFS/2IW3cGEjD7WUR3CeKn3QPxqH5hQHdy8PMTXEXts9l81DxpRtOUISBvv0rPGVsWLX7GJ1U6MawxtxPuPPqKmZq+M+w; 5:qLV8Mj9UJRtOyMvEaiLnCnwWxwRZmu5U5cwlfsDJc1KqQYU/d8NvP5CO2RN/ZXzXAvHLEu9wbJpBC2hF14PxXV2W3jjQ7cWOJXG/vwPwZhPuKYY2aDts71RwLVOe0u3VoZarU84fGubQ06Ps0QuW9KkQJ7wmPev+u7xJHVTCuVo=; 24:XQTkxrzz9GE7Sj5HGn8QR1YeqB9yR2JaHtL8VYjvXNHQ0DG8YWybi8kC7DAcqchXjfzgWHc/ZW/Np2lOsIQrh/00yf5cBkhk4AhDdwOftg0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 7:4M06V8IV8Kkya5gjDtpAovaWJkPfz9n7QPsutvpTkVq6WitNm/AiN3lRcFiDqocj456e1jgDUB3UBYH3WFOg4bJ91zG7uaoHjOAvraISbBjTmWr5W4KuGjNfMjiut1ag4q3zj5YifW0Evkaf2W2c52+g7R9XrOevd1kYiG3XxFKgU6x2kJ5LR+Zv1JXSqBN6dRVwe2PKAKFOIrRtgJbuY+dwOPmjyDRIvSlAH7PXtwGuvDNjssCu70crmVvTY6QQNpw33Rym3BJnXsOmsNgnHvPiJMAYH2XG1z73X5tAJK+enKbpB9hQESNK29lZFh5HHMM2sjCFIT2A0mc1AwJZ98GYANW47D1pJHiHIx3FMW0= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2016 09:15:35.4472 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3003 Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 09:15:43 -0000 ----- Original Message ----- From: "Jakob Heitz (jheitz)" Sent: Wednesday, October 19, 2016 6:37 PM 1. Router software cannot check whether a number is an ASN. 2. Any numbers should be allowed between consenting adults. That is within an AS or between adjacent ASes. 3. "Reserved" means reserved for use. So router software cannot disallow these either. I can see how the existing text is a little terse: The Global Administrator field is intended to allow different Autonomous Systems to define Large BGP Communities without collision. The best we can do is explain the situation: A Large Community that is intended to be sent to multiple ASes SHOULD contain an ASN in the Global Administrator field. The ASN SHOULD be one that is assigned to the entity that defines the meaning of the rest of the Large Community. This allows a route to carry multiple Large Communities, the meaning of each being defined by different independent entities. Tom, will this text satisfy you? Jakob I struggle to find any form of words that will satisfy me that includes the word 'SHOULD'. Ironically, if the sentence were to use 'MAY', then that would probably be ok, since it accurately conveys the meaning that you may find anything here so you cannot know what it means and so must have other means of authenticating the community before use. Or change it to 'MUST' which I think gives a clear sense of what to expect. That this cannot be enforced I find a red herring - lack of enforcement is a fact of life in BGP as currently defined (as the recent squat on an attribute number shows). 'MUST' would tell any misusers that they are in the wrong so giving peer pressure a better chance of getting things fixed. Also, I had forgotten RFC7454 (until Nick mentioned it) and that prescribes the stripping of communities, which intersects with this issue. RFC7454 addresses some of the security holes in BGP and expects the high order bits of a community to be an ASN so that is another can of worms that needs addresssing in this I-D. Tom Petch Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch > Sent: Wednesday, October 19, 2016 3:47 AM > To: Jeffrey Haas > Cc: IETF IDR WG ; Sue Hares > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) > > I remain unhappy with this I-D. > > I find it ironic that the messages for this Last Call should be > interspersed with those relating to what goes wrong when someone > somewhere else in the world uses a field in an unexpected way. This > reinforces my belief that this I-D should be more forceful in calling > out the dangers (eg MUST instead of SHOULD). > > I think that this I-D is factually incorrect, or at least open to > misinterpretation, when it says > '[RFC1997] BGP Communities attributes are four-octet values split into > two two-octet words. The most significant word is usually > interpreted as an Autonomous System Number (ASN) ' > > RFC1997 says > 'The community attribute values ranging from 0x0000000 through > 0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved. > > The rest of the community attribute values shall be encoded using an > autonomous system number in the first two octets. ' > > Note the use of 'shall'. Had that been written after RFC2119 then it > would have been IMO 'MUST' or 'SHALL' not the weasily 'SHOULD' so this > I-D is weakening the meaning compared to RFC1997. > > If this I-D were to say that RFC1997 specified a 'MUST' (in effect) but > that 20 years of experience showed that it need not be that strong, that > ambiguities of interpretation have never been a problem for routing, > pehaps by adding a note in the Security Considerations, then I would > accept that. As it stands, I think that this I-D is risky (and would be > even if everyone who reads it knows what the IETF means by 'SHOULD' - I > think that this is not the case and that those outside the IETF will > read 'SHOULD' as a stronger enforcement than it is). > > So, interspersed with those e-mails about other fields that have > unexpected values, I oppose this going forward just yet. > > The question of reserved values is another can of worms. If they are > not reserved, then clearly they are an example of 'SHOULD' not meaning > 'MUST' so they need reserving, but then, as Jeff is pointing out, you > open up the question of translation (something I flagged earlier as an > open issue). > > Tom Petch > > ----- Original Message ----- > From: "Jeffrey Haas" > Sent: Tuesday, October 18, 2016 9:38 PM > > > On Oct 18, 2016, at 3:15 PM, Job Snijders wrote: > > > >> Part of the idea behind reserving 65535:*:* was to reserve a space > that > >> could later be used for well-knowns, if that was desired - but to not > >> spend time now arguing about details of what well-knowns are > necessary. > >> > >> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs. > > > > Jeff argues that a justification should be added. Maybe someone can > > pitch in one or two sentences that explain why these are reserved? > > That's certainly part of it. While I think many people can see the > reason why you might want to do such a reservation, to do so you should > have a practical reason in the document. > > For the 65535:*:* case, for symmetry with RFC 1997, you'd probably want > to note that if it's used for that symmetry that either the existing > well known community registry is used at IANA or that a new one would > need to be created. Alternatively, you just say the work is expected > and defer to a future document. > > Note by doing this, you're setting up some expectations about > translation of communities from one space to another. FWIW, I don't > recommend this and simply suggest that you recommend *not* using these > for common use in case someone decides that they want to do so. I know > your organization and others such as Deutsche Telecom have some thoughts > about what translation infrastructure might look like, and such > mechanisms would have impact. > > With regard to the 0: and max-uint32: cases, after dealing with the > headaches associated with helping with documents such as the as0 and RFC > 7300 and putting in some restrictions in the configuration... followed > by having to take them away, I'm very reluctant to put in anything > beyond "we think it's a bad idea to use these, so pretty please don't" > > -- Jeff (ask me about my RFC 7300 hate mail over beer...) > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Oct 20 02:16:02 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A4012950E for ; Thu, 20 Oct 2016 02:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 LFOXDIO-B75d for ; Thu, 20 Oct 2016 02:15:41 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0093.outbound.protection.outlook.com [104.47.0.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59E8129558 for ; Thu, 20 Oct 2016 02:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JxWK2LXkyMbxK/w7jLdK+1croCIwk2R9SvgA1v7gUcU=; b=eRXocasjq6lq+YGAxwkVyILkF3GeBq4TJZgsYOxK3Ae2vwYKr14Z9gSzDRcoRqL4UjX6Nx+1bP1Xb5/MfX1trD1CXS4tLhNeDIQAle20tZL5KYNYrHU+bHGwGVw+4WzrqH02j8n3dIDANxppqO48UPzxeDctKwwx+D5rjp+Y/gg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Thu, 20 Oct 2016 09:15:36 +0000 Message-ID: <01ad01d22ab2$2c8c4060$4001a8c0@gateway.2wire.net> From: t.petch To: Mikael Abrahamsson , IETF IDR WG References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <5807F3AF.9080200@foobar.org> Date: Thu, 20 Oct 2016 10:08:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: DB6PR0601CA0031.eurprd06.prod.outlook.com (10.169.209.17) To HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137) X-MS-Office365-Filtering-Correlation-Id: a7fc4eff-adbc-4ef4-ed4d-08d3f8c9a743 X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 2:1DLuru2m+LbzcoNep0CXPZOzcDPkbP3qwzW5TLkBcsJ7Ike2VgYyjKs3HfVrNdzl15KciK6sg1u1z1Lj3esdPjtqIDX4Kw5xlvtw4l/hAS3tKlS/3HNRlYaddc3469qXjsc6DRVrm9FYLY23RltOCueFX4xomLokudTQYFeKJIXWUBqRO1azsj1aKfdNPAQdP+lKd8lykC5eFzFRamwScQ==; 3:I7pW8osI9kP9wcabPjnZnzYuAApzXNuGN4tekP6yl/l51ewSzYlctGRWzDs2J5fegyWyeZ9Rxxv3AWA9w7W48bDgh2ofIxvTOt5VFd5tprIXFnDVlkY8aUPg8kI4El7bX+DziNcCswy68EDnWGtHqA==; 25:ySBPv4V7m4EgjPZGRs+CAliwYa2lN0mAdGBmmq7WOKM+edF3nWN/HiEbWFitygsBNicCyRyHY4nZ3WCs9arzHg2bwgWsMSOcmqKGqq4MtoSaFZI+G8WN4uX+1fxe2tK3aFC/mTBT+MyikSDiTLr7gvAPiiTaqR3seNS01HK/VBtfhPUyqaH4biBN/sX5d1bVhhqKP3FETFpAJsms6OMkQCbr7BU1NXbOGB4NUMNhDubX2jXHrbniz11ZXw+lQzg6hyLUMFhQMjeU2pPDk4xWvRlb14+LpNOnGiKRRfTyvPzvB77TdQHup+GVbwGCNd6rbfk5JrV8g3nDN+CkWj/yu2tfcPHg+5l3eAySVz7ZkO2eRw8FbBxvEd7lXm4vKJATOT9Y00wkjT0vdKpTNbzSauF7t+WtYOyzB4Ckk/Clpbmc8yTjBTTWPpv3fkOLHggw X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3003; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 31:JSFBONbuQyIOTGN6NyALhCTFg6CAr1Ll0S8yfcWw6tpjo3Tb3MpupSsQNYfwBxlgJYncgbaWpN/cTGwfUSroLkc9mWjBfbRL+06SMesqoW3SFHMigShiCYPb5OUqBnR3Uk0V/UU4Z8+CLDgq+2Rt4ts+qA7KTIOWiPgClqTF8afVwlZGL7n30wVNUKKbfS57W7vrhN7G3wXs90KQtTzoYFyXDRf079bj9HDyogxqnoXIYynv4TQreOvRLwDri3FsOoHaISdIh8OhjAha4IPxjw==; 4:54KjvKYDVzL7zQnI4f+KV0dDvuLPLKXcJNx9ONo6G5nFTo0hv79ADgioYxMoY+1M1E4uGn0KnTk4ogiC7hKaXqxdXbTmkorhs0FKX/ekQmNpkxS2vkwSqmTbE/gJf6TnBznKgurTi8V4zHh3lZQV0XZTaZZS2N/fRSpC+IlKfrTzzuCl39ceqkWAFKO2NWTbaDXXGG/41ci5bbSexozVkxR6b3ATEs7eaMNvViU7E0vrpm7aV0cFMjRc17NKakUyMXDI6fyWx9sr5fxiQE9B2Uo3G3c8T5vTcUK4ei3L48SxtZEblr2bZiYhaKL9DNGAccyL3Ncer9RdqAHmQ0Yyk7898RsAbUEIv5fPdKKCqo8wujAgFYyDW9mPJ09SXzo/aaLtcb7htpxELHjyFAnPHA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3003; X-Forefront-PRVS: 01018CB5B3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(5423002)(189002)(377454003)(13464003)(24454002)(252514010)(57704003)(199003)(51444003)(55674003)(93886004)(68736007)(84392002)(305945005)(19580395003)(86362001)(50226002)(19580405001)(7846002)(6666003)(2906002)(42186005)(105586002)(230700001)(23756003)(44736004)(61296003)(5660300001)(7736002)(97736004)(230783001)(15975445007)(1456003)(3846002)(77096005)(1556002)(6116002)(81686999)(101416001)(9686002)(107886002)(116806002)(81156014)(76176999)(62236002)(92566002)(50986999)(66066001)(586003)(4720700003)(81816999)(8676002)(14496001)(106356001)(44716002)(33646002)(47776003)(81166006)(50466002)(189998001)(5001770100001)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3003; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3003; 23:gEsHhXFtCLJ8Rbl718YgSOzCm0G5dN3vT4CEh?= =?iso-8859-1?Q?to0VLO09oobybz62qjVznlY07iqoFr5fTArEMTphVrPovySBv6tztU/vcN?= =?iso-8859-1?Q?MlYBzv8ULh9yyMTquwWWrJWbgBQySe2ikPAP3DX5n0YGn7/JUmPoBDsbJH?= =?iso-8859-1?Q?A5my4vF4qrz7rZd37wRk3xTj/IxFWotam4zoU17E0ndWKWcLMhdhsygiGG?= =?iso-8859-1?Q?HjI8u/hmxWlLiQ2p8FOaVrbQWNpPgUHmGtJYU/HkFYskHSrI81wKV3RiyO?= =?iso-8859-1?Q?OqsMev/dBaWSJwTvzRIERl6LRFo2Q5SRd1o86Fh/JbHvJKdmWOSvrLLHkq?= =?iso-8859-1?Q?su5f945OumLSWrzYlhoT50L9YmhuJRDmhQ829wbLNP0RkRAvt0q2cg98ag?= =?iso-8859-1?Q?P0Bx3Rl0Dd5tYJBbKpL93xoYpBkuLqeuhHwvlynizf/aZZuHnK/8t9d8rG?= =?iso-8859-1?Q?KCwRNg5XBmSLjzbdxf3XFuKArteo8yBZTyxIWZXYk0IInH6b3VOo8xHNfX?= =?iso-8859-1?Q?PomfwZ8ue1pc2Ur6vUiisj09ayYy+DFMtZ8aI3lnTIxGeVznXFLrg8UpjN?= =?iso-8859-1?Q?xYu3g2BmlyOpwJuf7T9td2nPmR/vfi9dDOlw9oRZFyoOUdnFI3tpjd1Geg?= =?iso-8859-1?Q?aN5QnYaAgdxE/zjYBmqB5dzPFtW38kR0FYJtfthVH2ux6kujKbHNFSkYxM?= =?iso-8859-1?Q?K47I4XY8BZymq+XPkX36KPxlkxWfqstCkU1FJ4fvlZFIm8meyEEHLfXynS?= =?iso-8859-1?Q?aQGrnAwnxKpY9G0c22ftCuJub+fYvVUmA5lVnU10/Fl/TTFq9mwDbbSEuR?= =?iso-8859-1?Q?0ANrzo5qU/SVRr/aScV6spOIIxw8F9zaslG8W66o1vdPBIAp09WJisDpkK?= =?iso-8859-1?Q?+XlIP/cojC7n52HdeCQ+t+LSBygxJP4vL2UH3O7sAX2tLmvHzxKR6uIBt1?= =?iso-8859-1?Q?kk1ypXCVx8m79H27BI6xhfPEZA3BqkJv7Fa7h3vpVlWXithk+D4qvh5Eic?= =?iso-8859-1?Q?lmmkdHHQq7lt43GRHUoUCgl/YDd8sPpGqOQTwDLaSFOmxWkNMS5ogDaAxb?= =?iso-8859-1?Q?L6hsK+0HuM8L0U8Xfw7O+WPmEQIyuQ3Fc+3kyZoH0zmbrhmDQQJ5s1qK7H?= =?iso-8859-1?Q?3XEWjQdgF1NkgsJtHJwSBe86wFVfPRBK8ZXXqVRE9CRIfHNVIzgqmmUMpw?= =?iso-8859-1?Q?PS5mX9e+7Bdb6dhuzMv0FipsmpKF3Y5U9B3uetcWqxtmHiBeJA4UjLdSCK?= =?iso-8859-1?Q?eRKUvayXjobytl7gd5Kh9v2sHbzXg8R6wvHLGqutBBh9pBJQfEQRmHne7m?= =?iso-8859-1?Q?Fbpad1fgF6kcwhifpG0rBlh4xLWtHTVQeDJjhQpE7llJmSWW4y/lqDhe8i?= =?iso-8859-1?Q?KKGL4o1mGLl9C8pp1J3vbRKDph20FJIdSCky3qFZ9knB4V3FPMhoA1/HoX?= =?iso-8859-1?Q?pQh8M7LwX7eq0bBUvx73uGhOubhY3Z3yXXKxrcFeLeZCCTyNuYpSwHDFT+?= =?iso-8859-1?Q?TCNJW8c5r3x6XUZFG1maNWDNPwGfidTIO9sFpgZn2BqMTvGPWJkHdd0bZb?= =?iso-8859-1?Q?yv0sPg6Mu6yH5TLyqvRt19d9lNrnW+QyUgedM/jB3/0dUpH5Ooyb34aLPe?= =?iso-8859-1?Q?0weDp8V5mS6OCy8BxAwbnPqygnucwTvN8z6piKq+0a6OoAjSJixg7O1?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:VCXa2vpiYRhRf//n3HuqKakR/xhL9Swba6QVWmC4p6HnH78WGaNUxB8P7UntiXjentj5IF0pC1mzt7YP8+KLwtILh4bjVYZA9UhNm56Eb1S5Y2E95fN/om7Dt3vrMOUFIcFFpLmL5kpCBVTmZ2WN/pXiQ/31CACllts29Esa/P3T5gKhQowUXJCmlu68A9C4qnaRTfOa4bC28Xe6vUB2wupdCCeNmeBPz/FkCYkObdFfsIIn91bbKow5/4xFufNI01AzvYeZmyZWbBsUiGQ85qJMhtHPTF4bpB8jrf77yimpdGySwZXRc+hCH7Z/ZZME; 5:PqYM/9s9yNYbDvrhAA9k70zrHItZ6m2oSkji7emeCFJY+jtZ764WUY5LKKytDtdooTRDSeLPHe87uU5otm9Sb7U4kmWPq+PpU00WgW/inAT0Ws7RVdxQ5yIH5AdxNaxIpaectWUFbFHetT6wTvMA7nOZy6Ae8vrl89BWM5Qfa9g=; 24:DkKD4AR+A6riTNGz785QV/DsIDGdQxV67jGD9xFxVXcDZjktUkVoDJttfAAotsGC2c/uqX7RQK70GSvNHVAdfwq6h2dQFle2ZiuXsna3jyc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 7:yYXPPNKo1sbly0F+SGzvKPDK6H2JInZOvULI2xozrF/qDb9xdqbK5vwKDsmjz5b57FaeGfHOYY+je8zAQRrSJ112ycorE0Uo/qGAU9ZI7xKwwQuZVZWXVA7KadySgibOiuK5gugh6DBJ26QNEyv2VMjfZjDcsPi/eVkiReYsPzLM+3y9wxqw5ic8nGAosvqQ54M9KxNJDIVSf1QIqtOpIk1quwY53gnbi89kWnYzK09m5IP/aiXyt5b0LLnhedO/1x22B9aZK+wlR/SEcgRbO+h3enBPMZ5zAvqvNQyDp/m3nfNk8b4731CHcGQW2yvZe66LR004p1ODgZ5nKV5NXcVKB5q9DriyQ9lmXXuyW/Y= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2016 09:15:36.3489 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3003 Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 09:15:43 -0000 ----- Original Message ----- From: "Mikael Abrahamsson" Sent: Thursday, October 20, 2016 7:03 AM > On Wed, 19 Oct 2016, Brian Dickson wrote: > > > Yes, the implementation should still "allow any value". > > When I have created BGP route policies, I've several times asked myself > the question "what will the vendor implementation do itself, and what do I > need to do in my policy". > > So for instance, do I need to implement the well-knowns myself, or is that > something that I need to do in my policy? If I for operational reasons > want the router to not do something (for instance I do want NO-EXPORT to > traverse AS boundary), how do I do that? > > I think here in the IETF we should always consider to have separate > documents for what goes on the wire (compatibility reasons), and what the > implementation should do with this information by default in case the user > also can set policy. > > The contents of the -large- fields and whether the implementation should > check if this is true is a typical thing that the "wire" document should > not over-specify. That should instead be an operational document, and that > should involve GROW as well. Mikael In theory, I agree with you but in practice, I expect it will be at least a year or two before GROW produces such a document. In the meantime, I would go with Jeff's suggestion to include an 'Operational Considerations' section in this I-D (and that then could refer to RFC7454 and clarify the meaning of 'high order bits'). But I think that we have yet to agree what such a section would say. Tom Petch > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Oct 20 03:13:54 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A05E129581 for ; Thu, 20 Oct 2016 03:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 AiaSN2BFKwEa for ; Thu, 20 Oct 2016 03:13:51 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 5A034129577 for ; Thu, 20 Oct 2016 03:13:51 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BFC85A2; Thu, 20 Oct 2016 12:13:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1476958428; bh=+BS84+ak9hmk8HlvGftX6aVQdi0JPabNXKxiXsniqq4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=AcI8Dzrl/B8xB2vJBBNGXWkplYwN3Ej7eX6oQV//Eyp+O3HWQ+oyeTFLibCh3T8FX r06raq4BA9XVgpXEfnE/Sq1lM9CjHrBygFb/ZYujjmHQ2HVT638jB0DWMwsZKF0VPr ckRlwXH7XnPRXhGmddNVn9MWCxe+uGOfsG37DXVA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B2696A1; Thu, 20 Oct 2016 12:13:48 +0200 (CEST) Date: Thu, 20 Oct 2016 12:13:48 +0200 (CEST) From: Mikael Abrahamsson To: "t.petch" In-Reply-To: <01ad01d22ab2$2c8c4060$4001a8c0@gateway.2wire.net> Message-ID: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <5807F3AF.9080200@foobar.org> <01ad01d22ab2$2c8c4060$4001a8c0@gateway.2wire.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 10:13:53 -0000 On Thu, 20 Oct 2016, t.petch wrote: > In theory, I agree with you but in practice, I expect it will be at > least a year or two before GROW produces such a document. In the > meantime, I would go with Jeff's suggestion to include an 'Operational > Considerations' section in this I-D (and that then could refer to > RFC7454 and clarify the meaning of 'high order bits'). > > But I think that we have yet to agree what such a section would say. Exactly. So do you still want to delay the progress of this document until we (perhaps never) reach consensus on what the fields should be? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Oct 20 04:59:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D168F1298CC for ; Thu, 20 Oct 2016 04:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 TfdJ780ODmEP for ; Thu, 20 Oct 2016 04:59:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA081298CE for ; Thu, 20 Oct 2016 04:59:28 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 1DECE3B4D9D; Thu, 20 Oct 2016 13:59:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.43]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id ED91635C613; Thu, 20 Oct 2016 13:59:26 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0319.002; Thu, 20 Oct 2016 13:59:26 +0200 From: To: t.petch , IETF IDR WG Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) Thread-Index: AQHSKrKNzLSsMUoHk0O3f9XrQlByO6CxOq5g Date: Thu, 20 Oct 2016 11:59:26 +0000 Message-ID: <515_1476964767_5808B19F_515_1079_1_53C29892C857584299CBF5D05346208A0FA0799F@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <01ab01d22ab2$2b54f8e0$4001a8c0@gateway.2wire.net> In-Reply-To: <01ab01d22ab2$2b54f8e0$4001a8c0@gateway.2wire.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 11:59:31 -0000 May be one suggestion, trying to address Tom's comment, and inspired by RFC= 4360: https://tools.ietf.org/html/rfc4360#section-3.1 OLD: Local Data Part 1: A four-octet operator-defined value. Local Data Part 2: A four-octet operator-defined value NEW: Local Data Part 1: A four-octet value. The format and meaning is define= d by the Autonomous System set in the Global Administrator field. Local Data Part 2: A four-octet value. The format and meaning is define= d by the Autonomous System set in the Global Administrator field. Or some other wording, but I think the point is that "operator-defined" mea= ns the operator of the AS set in the Global Administrator field. --Bruno > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch > Sent: Thursday, October 20, 2016 10:38 AM > To: Jared Mauch > Cc: IETF IDR WG; Sue Hares > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17= /2016 to > 10/31/2016) >=20 > Jared >=20 > As Brian has pointed out, it was the use of 'usually' that I was > concerned with, as watering down the recommended use of an ASN by > RFC1997. Excise 'usually' and that part of my concern goes away. >=20 > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "Jared Mauch" > Sent: Wednesday, October 19, 2016 7:54 PM >=20 >=20 > > On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch wrote: > > > I remain unhappy with this I-D. > > > > > > I find it ironic that the messages for this Last Call should be > > > interspersed with those relating to what goes wrong when someone > > > somewhere else in the world uses a field in an unexpected way. This > > > reinforces my belief that this I-D should be more forceful in > calling > > > out the dangers (eg MUST instead of SHOULD). > > > > > > I think that this I-D is factually incorrect, or at least open to > > > misinterpretation, when it says > > > '[RFC1997] BGP Communities attributes are four-octet values split > into > > > two two-octet words. The most significant word is usually > > > interpreted as an Autonomous System Number (ASN) ' > > > > rfc1998: section 4 gives you the slice + dice bits: > > > > -- snip -- rfc 1998 -- > > To make use of the BGP community attribute, several community > values > > (MCI's AS number: 3561 =3D 0x0DE9) have been defined that can be us= ed > > by customers to tag routes so that the appropriate "LOCAL_PREF" > > values are configured. Table 2 lists the appropriate community > > attribute values (and the mappings of community to LOCAL_PREF): > > -- snip -- rfc 1998 -- > > > > This is the segmenting, and most customers have > > "ip bgp community new-format" configured. > > > > If your issue is about printf %ull vs %d:%d:%d we operators > > can solve this by ensuring our vendors do the right thing, which > > we have already done 20 years ago via rfc1998. > > > > This nit is imo not worth picking. > > > > - Jared > > > > -- > > Jared Mauch | pgp key available via finger from jared@puck.nether.net > > clue++; | http://puck.nether.net/~jared/ My statements are only > mine. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Oct 20 06:14:05 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A75129405 for ; Thu, 20 Oct 2016 06:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 93crtRP4OiEC for ; Thu, 20 Oct 2016 06:13:57 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 3294B127ABE for ; Thu, 20 Oct 2016 06:13:57 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bxDAP-000Ewn-1c (job@us.ntt.net); Thu, 20 Oct 2016 13:13:55 +0000 Date: Thu, 20 Oct 2016 08:13:49 -0500 From: Job Snijders To: bruno.decraene@orange.com Message-ID: <20161020131349.GL1033@Vurt.local> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <01ab01d22ab2$2b54f8e0$4001a8c0@gateway.2wire.net> <515_1476964767_5808B19F_515_1079_1_53C29892C857584299CBF5D05346208A0FA0799F@OPEXCLILM21.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515_1476964767_5808B19F_515_1079_1_53C29892C857584299CBF5D05346208A0FA0799F@OPEXCLILM21.corporate.adroot.infra.ftgroup> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 13:14:04 -0000 Hi Bruno, Do you feel it is not already clear enough from the introduction? """ To address these shortcomings, this document defines a Large BGP Communities attribute encoded as one or more twelve-octet values, each consisting of a four-octet ASN and two four-octet operator- defined values, each of which can be used to denote properties or actions significant to that ASN. ^^^^^^^^ """ Kind regards, Job On Thu, Oct 20, 2016 at 11:59:26AM +0000, bruno.decraene@orange.com wrote: > May be one suggestion, trying to address Tom's comment, and inspired by RFC 4360: > https://tools.ietf.org/html/rfc4360#section-3.1 > > OLD: > Local Data Part 1: A four-octet operator-defined value. > Local Data Part 2: A four-octet operator-defined value > > NEW: > Local Data Part 1: A four-octet value. The format and meaning is defined by the Autonomous System set in the Global Administrator field. > Local Data Part 2: A four-octet value. The format and meaning is defined by the Autonomous System set in the Global Administrator field. > > Or some other wording, but I think the point is that "operator-defined" means the operator of the AS set in the Global Administrator field. > > --Bruno > > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch > > Sent: Thursday, October 20, 2016 10:38 AM > > To: Jared Mauch > > Cc: IETF IDR WG; Sue Hares > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to > > 10/31/2016) > > > > Jared > > > > As Brian has pointed out, it was the use of 'usually' that I was > > concerned with, as watering down the recommended use of an ASN by > > RFC1997. Excise 'usually' and that part of my concern goes away. > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Jared Mauch" > > Sent: Wednesday, October 19, 2016 7:54 PM > > > > > > > On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch wrote: > > > > I remain unhappy with this I-D. > > > > > > > > I find it ironic that the messages for this Last Call should be > > > > interspersed with those relating to what goes wrong when someone > > > > somewhere else in the world uses a field in an unexpected way. This > > > > reinforces my belief that this I-D should be more forceful in > > calling > > > > out the dangers (eg MUST instead of SHOULD). > > > > > > > > I think that this I-D is factually incorrect, or at least open to > > > > misinterpretation, when it says > > > > '[RFC1997] BGP Communities attributes are four-octet values split > > into > > > > two two-octet words. The most significant word is usually > > > > interpreted as an Autonomous System Number (ASN) ' > > > > > > rfc1998: section 4 gives you the slice + dice bits: > > > > > > -- snip -- rfc 1998 -- > > > To make use of the BGP community attribute, several community > > values > > > (MCI's AS number: 3561 = 0x0DE9) have been defined that can be used > > > by customers to tag routes so that the appropriate "LOCAL_PREF" > > > values are configured. Table 2 lists the appropriate community > > > attribute values (and the mappings of community to LOCAL_PREF): > > > -- snip -- rfc 1998 -- > > > > > > This is the segmenting, and most customers have > > > "ip bgp community new-format" configured. > > > > > > If your issue is about printf %ull vs %d:%d:%d we operators > > > can solve this by ensuring our vendors do the right thing, which > > > we have already done 20 years ago via rfc1998. > > > > > > This nit is imo not worth picking. > > > > > > - Jared > > > > > > -- > > > Jared Mauch | pgp key available via finger from jared@puck.nether.net > > > clue++; | http://puck.nether.net/~jared/ My statements are only > > mine. > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Oct 20 06:34:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACB91295F7 for ; Thu, 20 Oct 2016 06:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_DUL=0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 LAkiq-X2ur-O for ; Thu, 20 Oct 2016 06:34:44 -0700 (PDT) Received: from relais-inet.orange.com (relais-aub41.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFB21295E6 for ; Thu, 20 Oct 2016 06:34:43 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 767EB1C00CE; Thu, 20 Oct 2016 15:34:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 1374118007C; Thu, 20 Oct 2016 15:34:42 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0319.002; Thu, 20 Oct 2016 15:34:41 +0200 From: To: Job Snijders Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) Thread-Index: AQHSKtPQCrBkk4eGMkON0rEBH5hX56CxU01g Date: Thu, 20 Oct 2016 13:34:41 +0000 Message-ID: <10701_1476970482_5808C7F2_10701_5009_1_53C29892C857584299CBF5D05346208A0FA07C6E@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <01ab01d22ab2$2b54f8e0$4001a8c0@gateway.2wire.net> <515_1476964767_5808B19F_515_1079_1_53C29892C857584299CBF5D05346208A0FA0799F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20161020131349.GL1033@Vurt.local> In-Reply-To: <20161020131349.GL1033@Vurt.local> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 13:34:47 -0000 Hi Job, > From: Job Snijders [mailto:job@ntt.net] > Sent: Thursday, October 20, 20= 16 3:14 PM >=20 > Hi Bruno, >=20 > Do you feel it is not already clear enough from the introduction? >=20 > """ > To address these shortcomings, this document defines a Large BGP > Communities attribute encoded as one or more twelve-octet values, > each consisting of a four-octet ASN and two four-octet operator- > defined values, each of which can be used to denote properties or > actions significant to that ASN. > ^^^^^^^^ > """ I'm personally fine with the text, but I think that the concern expressed i= s about having his community space squatted by somebody else. i.e. making i= t clear in the document that the community space starting with NNNN: "belon= gs" or is "assigned" by AS NNNN. Looking at the definition of "significant" I don't feel that this fully add= ress the point. e.g. a well-known community may be significant to AS NNNN, = yet this space is not assigned by AS NNNN. King regards, -- Bruno > Kind regards, >=20 > Job >=20 > On Thu, Oct 20, 2016 at 11:59:26AM +0000, bruno.decraene@orange.com wrot= e: > > May be one suggestion, trying to address Tom's comment, and inspired b= y RFC 4360: > > https://tools.ietf.org/html/rfc4360#section-3.1 > > > > OLD: > > Local Data Part 1: A four-octet operator-defined value. > > Local Data Part 2: A four-octet operator-defined value > > > > NEW: > > Local Data Part 1: A four-octet value. The format and meaning is d= efined by the > Autonomous System set in the Global Administrator field. > > Local Data Part 2: A four-octet value. The format and meaning is d= efined by the > Autonomous System set in the Global Administrator field. > > > > Or some other wording, but I think the point is that "operator-defined= " means the > operator of the AS set in the Global Administrator field. > > > > --Bruno > > > > > -----Original Message----- > > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch > > > Sent: Thursday, October 20, 2016 10:38 AM > > > To: Jared Mauch > > > Cc: IETF IDR WG; Sue Hares > > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (= 10/17/2016 to > > > 10/31/2016) > > > > > > Jared > > > > > > As Brian has pointed out, it was the use of 'usually' that I was > > > concerned with, as watering down the recommended use of an ASN by > > > RFC1997. Excise 'usually' and that part of my concern goes away. > > > > > > Tom Petch > > > > > > > > > ----- Original Message ----- > > > From: "Jared Mauch" > > > Sent: Wednesday, October 19, 2016 7:54 PM > > > > > > > > > > On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch wrote: > > > > > I remain unhappy with this I-D. > > > > > > > > > > I find it ironic that the messages for this Last Call should be > > > > > interspersed with those relating to what goes wrong when someone > > > > > somewhere else in the world uses a field in an unexpected way. = This > > > > > reinforces my belief that this I-D should be more forceful in > > > calling > > > > > out the dangers (eg MUST instead of SHOULD). > > > > > > > > > > I think that this I-D is factually incorrect, or at least open = to > > > > > misinterpretation, when it says > > > > > '[RFC1997] BGP Communities attributes are four-octet values spl= it > > > into > > > > > two two-octet words. The most significant word is usually > > > > > interpreted as an Autonomous System Number (ASN) ' > > > > > > > > rfc1998: section 4 gives you the slice + dice bits: > > > > > > > > -- snip -- rfc 1998 -- > > > > To make use of the BGP community attribute, several community > > > values > > > > (MCI's AS number: 3561 =3D 0x0DE9) have been defined that can = be used > > > > by customers to tag routes so that the appropriate "LOCAL_PREF" > > > > values are configured. Table 2 lists the appropriate community > > > > attribute values (and the mappings of community to LOCAL_PREF): > > > > -- snip -- rfc 1998 -- > > > > > > > > This is the segmenting, and most customers have > > > > "ip bgp community new-format" configured. > > > > > > > > If your issue is about printf %ull vs %d:%d:%d we operators > > > > can solve this by ensuring our vendors do the right thing, which > > > > we have already done 20 years ago via rfc1998. > > > > > > > > This nit is imo not worth picking. > > > > > > > > - Jared > > > > > > > > -- > > > > Jared Mauch | pgp key available via finger from jared@puck.nethe= r.net > > > > clue++; | http://puck.nether.net/~jared/ My statements are = only > > > mine. > > > > > > _______________________________________________ > > > Idr mailing list > > > Idr@ietf.org > > > https://www.ietf.org/mailman/listinfo/idr > > > > > _________________________________________________________________________ > ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles ou > privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez= recu ce message > par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messag= es electroniques > etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. > Merci. > > > > This message and its attachments may contain confidential or privilege= d information > that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and= delete this > message and its attachments. > > As emails may be altered, Orange is not liable for messages that have = been modified, > changed or falsified. > > Thank you. > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Oct 20 06:38:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510CF129619 for ; Thu, 20 Oct 2016 06:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_DUL=0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 I6beqI9-ITKt for ; Thu, 20 Oct 2016 06:38:50 -0700 (PDT) Received: from relais-inet.orange.com (relais-aub40.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956EA1295F9 for ; Thu, 20 Oct 2016 06:38:50 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4A140C00C8; Thu, 20 Oct 2016 15:38:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id A7061180040; Thu, 20 Oct 2016 15:38:48 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0319.002; Thu, 20 Oct 2016 15:38:46 +0200 From: To: DECRAENE Bruno IMT/OLN , Job Snijders Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) Thread-Index: AQHSKtPQCrBkk4eGMkON0rEBH5hX56CxU01ggAAE3ZA= Date: Thu, 20 Oct 2016 13:38:45 +0000 Message-ID: <2588_1476970728_5808C8E8_2588_648_1_9ab4dc04-d856-449d-b978-8ea1960a25d1@OPEXCLILMA1.corporate.adroot.infra.ftgroup> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <01ab01d22ab2$2b54f8e0$4001a8c0@gateway.2wire.net> <515_1476964767_5808B19F_515_1079_1_53C29892C857584299CBF5D05346208A0FA0799F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20161020131349.GL1033@Vurt.local> <10701_1476970482_5808C7F2_10701_5009_1_53C29892C857584299CBF5D05346208A0FA07C6E@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <10701_1476970482_5808C7F2_10701_5009_1_53C29892C857584299CBF5D05346208A0FA07C6E@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 13:38:53 -0000 Correction (sorry for the spam) > making it clear in the document that > the community space starting with NNNN: "belongs" or is "assigned" by AS= NNNN. that AS NNNN, owns/control the assignment of the community space starting w= ith NNNN: (Such correction is expected to handle cases where NNNN is not an assigned = AS number. e.g. 0000. ) --Bruno > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of bruno.decraene@oran= ge.com > Sent: Thursday, October 20, 2016 3:35 PM > To: Job Snijders > Cc: IETF IDR WG; Sue Hares > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17= /2016 to > 10/31/2016) >=20 > Hi Job, >=20 > > From: Job Snijders [mailto:job@ntt.net] > Sent: Thursday, October 20,= 2016 3:14 PM > > > > Hi Bruno, > > > > Do you feel it is not already clear enough from the introduction? > > > > """ > > To address these shortcomings, this document defines a Large BGP > > Communities attribute encoded as one or more twelve-octet values, > > each consisting of a four-octet ASN and two four-octet operator- > > defined values, each of which can be used to denote properties or > > actions significant to that ASN. > > ^^^^^^^^ > > """ >=20 > I'm personally fine with the text, but I think that the concern expresse= d is about having his > community space squatted by somebody else. i.e. making it clear in the d= ocument that > the community space starting with NNNN: "belongs" or is "assigned" by AS= NNNN. > Looking at the definition of "significant" I don't feel that this fully = address the point. e.g. a > well-known community may be significant to AS NNNN, yet this space is no= t assigned by > AS NNNN. >=20 > King regards, > -- Bruno >=20 > > Kind regards, > > > > Job > > > > On Thu, Oct 20, 2016 at 11:59:26AM +0000, bruno.decraene@orange.com w= rote: > > > May be one suggestion, trying to address Tom's comment, and inspire= d by RFC 4360: > > > https://tools.ietf.org/html/rfc4360#section-3.1 > > > > > > OLD: > > > Local Data Part 1: A four-octet operator-defined value. > > > Local Data Part 2: A four-octet operator-defined value > > > > > > NEW: > > > Local Data Part 1: A four-octet value. The format and meaning i= s defined by the > > Autonomous System set in the Global Administrator field. > > > Local Data Part 2: A four-octet value. The format and meaning i= s defined by the > > Autonomous System set in the Global Administrator field. > > > > > > Or some other wording, but I think the point is that "operator-defi= ned" means the > > operator of the AS set in the Global Administrator field. > > > > > > --Bruno > > > > > > > -----Original Message----- > > > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch > > > > Sent: Thursday, October 20, 2016 10:38 AM > > > > To: Jared Mauch > > > > Cc: IETF IDR WG; Sue Hares > > > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.tx= t (10/17/2016 to > > > > 10/31/2016) > > > > > > > > Jared > > > > > > > > As Brian has pointed out, it was the use of 'usually' that I was > > > > concerned with, as watering down the recommended use of an ASN by > > > > RFC1997. Excise 'usually' and that part of my concern goes away. > > > > > > > > Tom Petch > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Jared Mauch" > > > > Sent: Wednesday, October 19, 2016 7:54 PM > > > > > > > > > > > > > On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch wrote: > > > > > > I remain unhappy with this I-D. > > > > > > > > > > > > I find it ironic that the messages for this Last Call should= be > > > > > > interspersed with those relating to what goes wrong when som= eone > > > > > > somewhere else in the world uses a field in an unexpected wa= y. This > > > > > > reinforces my belief that this I-D should be more forceful in > > > > calling > > > > > > out the dangers (eg MUST instead of SHOULD). > > > > > > > > > > > > I think that this I-D is factually incorrect, or at least op= en to > > > > > > misinterpretation, when it says > > > > > > '[RFC1997] BGP Communities attributes are four-octet values = split > > > > into > > > > > > two two-octet words. The most significant word is usually > > > > > > interpreted as an Autonomous System Number (ASN) ' > > > > > > > > > > rfc1998: section 4 gives you the slice + dice bits: > > > > > > > > > > -- snip -- rfc 1998 -- > > > > > To make use of the BGP community attribute, several communi= ty > > > > values > > > > > (MCI's AS number: 3561 =3D 0x0DE9) have been defined that c= an be used > > > > > by customers to tag routes so that the appropriate "LOCAL_P= REF" > > > > > values are configured. Table 2 lists the appropriate commun= ity > > > > > attribute values (and the mappings of community to LOCAL_PR= EF): > > > > > -- snip -- rfc 1998 -- > > > > > > > > > > This is the segmenting, and most customers have > > > > > "ip bgp community new-format" configured. > > > > > > > > > > If your issue is about printf %ull vs %d:%d:%d we operators > > > > > can solve this by ensuring our vendors do the right thing, whi= ch > > > > > we have already done 20 years ago via rfc1998. > > > > > > > > > > This nit is imo not worth picking. > > > > > > > > > > - Jared > > > > > > > > > > -- > > > > > Jared Mauch | pgp key available via finger from jared@puck.ne= ther.net > > > > > clue++; | http://puck.nether.net/~jared/ My statements a= re only > > > > mine. > > > > > > > > _______________________________________________ > > > > Idr mailing list > > > > Idr@ietf.org > > > > https://www.ietf.org/mailman/listinfo/idr > > > > > > > > > _________________________________________________________________________ > > ________________________________________________ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou > > privilegiees et ne doivent donc > > > pas etre diffuses, exploites ou copies sans autorisation. Si vous a= vez recu ce message > > par erreur, veuillez le signaler > > > a l'expediteur et le detruire ainsi que les pieces jointes. Les mes= sages electroniques > > etant susceptibles d'alteration, > > > Orange decline toute responsabilite si ce message a ete altere, def= orme ou falsifie. > > Merci. > > > > > > This message and its attachments may contain confidential or privil= eged information > > that may be protected by law; > > > they should not be distributed, used or copied without authorisatio= n. > > > If you have received this email in error, please notify the sender = and delete this > > message and its attachments. > > > As emails may be altered, Orange is not liable for messages that ha= ve been modified, > > changed or falsified. > > > Thank you. > > > > > > _______________________________________________ > > > Idr mailing list > > > Idr@ietf.org > > > https://www.ietf.org/mailman/listinfo/idr >=20 > _________________________________________________________________________ > ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou > privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par > erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant > susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. > Merci. >=20 > This message and its attachments may contain confidential or privileged = information that > may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and d= elete this message > and its attachments. > As emails may be altered, Orange is not liable for messages that have be= en modified, > changed or falsified. > Thank you. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Oct 20 06:39:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26587129968 for ; Thu, 20 Oct 2016 06:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 R7ee4uOMIp8g for ; Thu, 20 Oct 2016 06:39:03 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 8E224129961 for ; Thu, 20 Oct 2016 06:39:03 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bxDYh-0000iH-LF (job@us.ntt.net); Thu, 20 Oct 2016 13:38:59 +0000 Date: Thu, 20 Oct 2016 08:38:57 -0500 From: Job Snijders To: bruno.decraene@orange.com Message-ID: <20161020133857.GO1033@Vurt.local> References: <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <01ab01d22ab2$2b54f8e0$4001a8c0@gateway.2wire.net> <515_1476964767_5808B19F_515_1079_1_53C29892C857584299CBF5D05346208A0FA0799F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20161020131349.GL1033@Vurt.local> <10701_1476970482_5808C7F2_10701_5009_1_53C29892C857584299CBF5D05346208A0FA07C6E@OPEXCLILM21.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10701_1476970482_5808C7F2_10701_5009_1_53C29892C857584299CBF5D05346208A0FA07C6E@OPEXCLILM21.corporate.adroot.infra.ftgroup> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 13:39:13 -0000 On Thu, Oct 20, 2016 at 01:34:41PM +0000, bruno.decraene@orange.com wrote: > > From: Job Snijders [mailto:job@ntt.net] > Sent: Thursday, October > > 20, 2016 3:14 PM > > > > Hi Bruno, > > > > Do you feel it is not already clear enough from the introduction? > > > > """ To address these shortcomings, this document defines a Large > > BGP Communities attribute encoded as one or more twelve-octet > > values, each consisting of a four-octet ASN and two four-octet > > operator- defined values, each of which can be used to denote > > properties or actions significant to that ASN. ^^^^^^^^ """ > > I'm personally fine with the text, but I think that the concern > expressed is about having his community space squatted by somebody > else. i.e. making it clear in the document that the community space > starting with NNNN: "belongs" or is "assigned" by AS NNNN. > Looking at the definition of "significant" I don't feel that this > fully address the point. e.g. a well-known community may be > significant to AS NNNN, yet this space is not assigned by AS NNNN. That is easy to solve: there are no well-known large communities. From nobody Thu Oct 20 07:04:59 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C511129452 for ; Thu, 20 Oct 2016 07:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bDbOg0YXH99a for ; Thu, 20 Oct 2016 07:04:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BA58812952C for ; Thu, 20 Oct 2016 07:04:53 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id D89BA1E1F0; Thu, 20 Oct 2016 10:07:04 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_90476230-EC09-426B-910A-DA1B1AE8B139" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Jeffrey Haas In-Reply-To: <2588_1476970728_5808C8E8_2588_648_1_9ab4dc04-d856-449d-b978-8ea1960a25d1@OPEXCLILMA1.corporate.adroot.infra.ftgroup> Date: Thu, 20 Oct 2016 10:04:52 -0400 Message-Id: <83759244-B42B-48E1-AC5A-E6289D9F66EA@pfrc.org> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <01ab01d22ab2$2b54f8e0$4001a8c0@gateway.2wire.net> <515_1476964767_5808B19F_515_1079_1_53C29892C857584299CBF5D05346208A0FA0799F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20161020131349.GL1033@Vurt.local> <10701_1476970482_5808C7F2_10701_5009_1_53C29892C857584299CBF5D05346208A0FA07C6E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <2588_1476970728_5808C8E8_2588_648_1_9ab4dc04-d856-449d-b978-8ea1960a25d1@OPEXCLILMA1.corporate.adroot.infra.ftgroup> To: bruno.decraene@orange.com X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 14:04:58 -0000 --Apple-Mail=_90476230-EC09-426B-910A-DA1B1AE8B139 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 20, 2016, at 9:38 AM, bruno.decraene@orange.com wrote: >=20 > Correction (sorry for the spam) >=20 >> making it clear in the document that >> the community space starting with NNNN: "belongs" or is "assigned" by = AS NNNN. >=20 > that AS NNNN, owns/control the assignment of the community space = starting with NNNN: >=20 > (Such correction is expected to handle cases where NNNN is not an = assigned AS number. e.g. 0000. ) For some very light definition of "own". =20 For example, if I really like Job's 2914 community road-show, and just = copied and pasted his community configs directly, 2914:* would work fine = for me. But I certainly shouldn't expect that the communities would = survive getting to me through 2914. The above comments aren't intended to recommend any specific change of = text, but merely to point out that getting too hung up on RFC 2119 = semantics is probably counter productive. -- Jeff --Apple-Mail=_90476230-EC09-426B-910A-DA1B1AE8B139 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 20, 2016, at 9:38 AM, bruno.decraene@orange.com wrote:

Correction (sorry for the spam)

making it clear in the = document that
the community space starting with NNNN: = "belongs" or is "assigned" by AS NNNN.

that AS NNNN, = owns/control the assignment of the community space starting with = NNNN:

(Such correction is = expected to handle cases where NNNN is not an assigned AS number. e.g. = 0000. )

For = some very light definition of "own".  

For example, if I really like Job's = 2914 community road-show, and just copied and pasted his community = configs directly, 2914:* would work fine for me.  But I certainly = shouldn't expect that the communities would survive getting to me = through 2914.

The above comments aren't intended to recommend any specific = change of text, but merely to point out that getting too hung up on RFC = 2119 semantics is probably counter productive.

-- Jeff

= --Apple-Mail=_90476230-EC09-426B-910A-DA1B1AE8B139-- From nobody Thu Oct 20 07:56:20 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E778C129644 for ; Thu, 20 Oct 2016 07:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 JqPBMd6sW41F for ; Thu, 20 Oct 2016 07:56:16 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40099.outbound.protection.outlook.com [40.107.4.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9887812963E for ; Thu, 20 Oct 2016 07:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=M3tfKMNNDcLL0GXiIVdG7YdH49MQWsioJe8vFKEzrC4=; b=YPfw8lJesmbANXVEHYIYRQRCYU86t4JkuitqqTJjvVNpyo/l1W/ZBUs7bsk3qONKc7hjzpVLAiNh6QGLJcnuItVeQUKUw/SBY/FDrLDOaOCPFijvKJQGTjgFjcpt5RhMglISThNscDBCZRY+umEos4RBQNDSKDYE4gaicYYxFfc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by HE1PR0701MB3004.eurprd07.prod.outlook.com (10.168.93.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Thu, 20 Oct 2016 14:56:12 +0000 Message-ID: <007701d22ae1$c14b2020$4001a8c0@gateway.2wire.net> From: t.petch To: Mikael Abrahamsson References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <5807F3AF.9080200@foobar.org> <01ad01d22ab2$2c8c4060$4001a8c0@gateway.2wire.net> Date: Thu, 20 Oct 2016 15:53:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: DB4PR06CA0066.eurprd06.prod.outlook.com (10.162.49.34) To HE1PR0701MB3004.eurprd07.prod.outlook.com (10.168.93.138) X-MS-Office365-Filtering-Correlation-Id: 2f43ba79-83eb-4910-1313-08d3f8f93c6e X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 2:zqX6IWc6ET3u/o8PIYaF0rds8EH1Kca9BbGpvDKXpfsnPdkmnbIk9ZKinL83hYzvDSdzC51tFwRdIbPsn9ZUgMwZe77SlJ7bmNcy3oXyCFny/nqT+2DPGpOej3OfwTPu06+VBL5RbY6VXP+eiYHx9rLrcdouk7tV+3OmoXpl2YUZfWyxicl3rNdbujHTGOsBHv+6zi537NwLdMFBy1lfDA==; 3:h3id3ck0Kq5TGqH0M0vOmt1gX2cgNUSZ5AXl0EwhYBWbsS7lXvAp5SUkmxz1PRyVrKlrqKeKyC/KDeB/ZmmkQfu3dlY2RtmSUi1s3bV1TCp0niPwXdoJjsI/Gv/PS3Yq+KzMKNH1MKlFn/+ClSwctg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3004; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 25:+yAwBrXCOvL+mO65hv95KBFib8bgJsG2VpgoZCOHPNzotuyQyMrA35QKmy2df/9tgD1JcRWxOOLKmKdPfR505flUbhQe7fxvKi09imdS99r725Nlem3ytGL9mRyfS3DrfNQfwlfecEEDAFQHh9M65VuYARlvmT932trVSdO4ky+SWyQETDu44Z35Bsik4VtqfrmperJbIqdNZyjZOjftPykJjenqWa9tO35/k7v6dFS55YSStojvYQ7r7TD/P554I1kJYKz9JiZTqM2sra7ZzsR2YS1MB+eNtT0VRkmaylB1L6LixvdwjJT7wD26eRGqBTt5n9/DuJLX8k5BCcUUF2LuqGBGWT07uXozRn3IbR/hIcVz9vQHy7762LwZ9OnnvUZz5UACnAIby2kkUrjrpRII9s9lPyBEnyrA+FeboIdaJNZokC7cM99UbrprdLQKK3WwvrwL14MIMU9KVHlvpZvwmpv64N1Rt3UNCj8S/WibKXvs25RJrXF8Pp7K5H7LFKCuHtluPe7mGBp/YlHvD4UBa4guFknTEwUrmNRaha923+NqsyG1y5t6RAa73Ol2GFO+QbvQMHIr9Y0oXEaO6cZuFegsf7PlvLTfIIpDl2gTUMeXLh12uN86VKeyoE+Emvu6/bzOKAjr6QSFjIMmOfVHTmyQE6xGawEHsZHVmNgag9dF2QR/ArtN5IG6M18+LtLeyuRHoXHjiHgLjWuEAA== X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 31:Txp9N6GeAYJOAeh0KIWt3ovtQJJ+jOvY6ct/PcO0iDpxpE0prII7BzBKb0f17Spglul3JIi0bHX66Au/bH5zJjvGIEoyJWanoi10E6ukLgyYGt96lObfjT05kcLBkMNcBWu+F89Si1nPlVrM/G7hHR7G6jtUyQFBkUdtG8hrAD/cg39jgujph+HuNPEX3dlC27zYhXvOe9+nlzA2XREYm4AwdCQaIXI5zV9W/cuJBffT9toV9YTJoEKLByf4xPoV; 4:UbKAYuA41c/SjlM5u9HwVm0E4NlAwTj5Ifyw+nE502nYjbC3boWWQHNbdat0dhdU5mTOzv+PuOUQx3mPiw9RaI+WG1Eba7yZm98LJPEKunjvIvTu7+d6XL1hLyqUnZ6hu5uMhSv7of+mYUrL9yxTtRBhDiUpO/42kGTj3cGD5kviLN7hkm37BTZPZqtFfiiUKWRq995fk/bJpDPSDunOC9JCtz1iUhH/VptMNfMjEUZeSJzvaNj6JnJVXfkS9owSXqVA1g2Li3TzVTrT40H7iVdJamLw1lwI/IQB4AXridRP3ppcFaY3sIDiUfSMP3nKvB/xnJffhNsTvmWM7NVm01v5fhqKfQwyuqcJc9GjqPQ3iiLFWOvhQ7YTyVdUCEw3zY1uiCw5L25fHjzv3SNsi18eNeDFRaCUR1caU1JnzoETKCHnUGGaXoF79pC0EWyG X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR0701MB3004; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3004; X-Forefront-PRVS: 01018CB5B3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(13464003)(377454003)(252514010)(189002)(24454002)(51444003)(199003)(5423002)(47776003)(6916009)(23756003)(19580395003)(110136003)(105586002)(19580405001)(8676002)(230783001)(116806002)(93886004)(189998001)(4326007)(97736004)(3846002)(1556002)(305945005)(77096005)(50226002)(586003)(92566002)(6116002)(44736004)(68736007)(86362001)(76176999)(50466002)(50986999)(7846002)(230700001)(6666003)(9686002)(5660300001)(101416001)(106356001)(81686999)(1456003)(2906002)(4720700003)(81156014)(62236002)(66066001)(14496001)(81166006)(84392002)(61296003)(44716002)(33646002)(7736002)(81816999)(42186005)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3004; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3004; 23:6E4ey9sngRFbt3mYhSEkcFI7dLb7ZV0iu4sgl?= =?iso-8859-1?Q?lI7fZFb74AYXM++eyoVJW9xelBfGxwal3ebxT6Ln1g6d9IYonN4/WpN6vU?= =?iso-8859-1?Q?D8P7zSDXiP46t31wOGail0z+y9UFl7MWG+iqYJDpxZ2Qaa2dWRLN04CTmk?= =?iso-8859-1?Q?m955OaNPnniwd/uMquHLbeTvbIZEP6t1btSPz0z1yls70TufLFSqBpozQX?= =?iso-8859-1?Q?PDfwnYl57MMMw6wEnDxPmSu0EHyXpe6f26te0WjqIcIFjsV/ttbWjOsj0n?= =?iso-8859-1?Q?cyijuFX9zSW0ScfsgUE8bBVzJj21OAZrqREKimaKCB6fzNyHvKjpkUO9L6?= =?iso-8859-1?Q?3mqUZIHCxosO43LFJ+W3ALHBtmQmMLQAqeHjXFZtA4HRJlEwSQw6qJrPdV?= =?iso-8859-1?Q?9BlLE1yYoyhGTst71kYgKmzQOdbUxaQKpFgv1p/klEo8CrE4c9ucEr8baj?= =?iso-8859-1?Q?qAWZY1ETK1aHOo4UvMYazMNnCD5oMVfMFuWJrpd54mFJIyH2qSBOWOtqCr?= =?iso-8859-1?Q?bCEg/LBQ1p4B0JJeyMZuP+7jF26VFgp7MUFHEguC28NxaHWF0FC8fICuJf?= =?iso-8859-1?Q?qQ48Zu5RGp9fdDd+BZ66wz/XSr3MMuVLD46WlXINlNqfyz4CISjybheNt9?= =?iso-8859-1?Q?tlXet7WTqRqRBMR+ZdSc3V2q1yy1yacS5Tjh6gLgPy+JVU+GtQs/fNqJcB?= =?iso-8859-1?Q?4GyKpsJ4H0a/nqYhJO10zc4la/ZMI3QfdPcSTsigAk1+I24mWoelKifyIX?= =?iso-8859-1?Q?k2ZYySUQxe9ryavJNTmdkkWkDarvXNNrCE/kizHCX7tl5OkSok1zDRJWz8?= =?iso-8859-1?Q?QgMZG7ifWaIKyO8F2N2VeHwXOW8tAC7SWWMgmPaZD2D/B1xCqPIySSpH7G?= =?iso-8859-1?Q?B0h74+t/aDEwYcCeSheaI0ehYvjMZlUO4JvEqnYR71CnHP8q2Qw7FvyYew?= =?iso-8859-1?Q?E0y2j8UMuOA4dLdCSj49k5+q528AakUA1kKTt5iiJ9xVVhxwIwAATX2sPr?= =?iso-8859-1?Q?VXEntftkHMmMxXIP9F3KbwkswZm7qTdfkErNCgRL5bWqjy4QXBTmx/Z/GJ?= =?iso-8859-1?Q?r4khx+v/QEVvSLg9wewg7TXXT7vG194+efekcenSj6tZw3maKShcQoYX5A?= =?iso-8859-1?Q?T98sfNphJVSBYb6Zswl3I5QsXDzbZHUx2DIK0eLb12v4d+C5uootiTGl+j?= =?iso-8859-1?Q?fF+KDILrSzSGOVglrlBeyxYJGiBZvAfeBGOL5X4g6anQa11uqO76skB+b7?= =?iso-8859-1?Q?nhy0jF/eNzkLsLRzRitL0XWwfiqSxkLTJLyp8d8qRJAR7GKk2EIHnrLPua?= =?iso-8859-1?Q?a2qH6rb6/hsruh1plECn3OEaRpxvkinzJqFqcq5c85eMzhCSpvyqb9GJc/?= =?iso-8859-1?Q?X8gVRdISUl4MJp1DqbmB8+9HgwmMEQvoKb0JycWSWveSLWMGB0TsrkVvDa?= =?iso-8859-1?Q?F1zpqqfOvrCyh5IcHjCGxECvO+yW38Jt7xlrzRfrJANP7MxSrMmMn61hmM?= =?iso-8859-1?Q?GomrEjtd2a3GvJDl7llPQnBQ58v66k5ikXMUHtpulA4BhVe8w6cEsY9eXm?= =?iso-8859-1?Q?aR+X1XOjsLp7sVR+Xs8qGq0SP0FpP3oyr9Wwq+a09SpJgDaEr?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 6:J6bC+yTUwQ+B784So5zF6Rf+nAr7+b3nnj5S2SKLvqzPOX+GAi1QsdC9Ynfb3E5TvDVynhO0BmQffBTmvyr6OrOj8OKHObnv99g+ZclxXMjaMHJQ3BReUg+VazuuMP0aR/+WAoPAjZi4viSW9B7q1/UlnAhAu+R/YQeJF+RH9VnVhDcvgWT1fwflDT92bMZKp4k9ax5NelAkZWuQIXc2bBoR0J8xAMqOSgBkbnW8N3OlVJLRnLM9KOcI0tYXP307DwQp9SUNfyyr+PdFOvQb9dSzvgYZy7TDmkgn7c7XTBpRbKP6QyxqEmR7JWD7cz4F; 5:BOyhDgtelev0Tl/vwiM6t6KWYnMAugEkAXMLktgCEgCLvxTrRChon2BYMH3ZWb8e0vDAmut26Xsj4paat273sCv8f8f9oXI6/E7NNhaohhvJgBsUTDXKYsw1TpjIomMvnJQhT2DxkV9RSzu1xSIKTw==; 24:GALVjI32br/T3u5PS07weCmfLBl0awE8vOBtfKewaSlXyD9QdEjg2Cz7NGrl2m+ccadSrI9ndk4QyHz+2m9zFxx8JLLXsi5Z+ANAvO1ygow=; 7:Cfazq9+UZzp8KhLrUcESeBHonW/GYtMY1CirtfulyrFeWUXB4H+O4q51Rb1lJsRHYca008pVo/4RBz/00gBDN4PFuOxm2kwmWKlBo4vs+faXE5mlUbnnQLBMEhLZjoWLFxv02T85h8FjYNGJveLELuhX2M/urVqZWSgCznNq7Ku1D7U0ggaZaHKGY6try5lzBXY4faxZtBskdaQYeKKeNXTQg2vtE6AJfFX1Jq7sQIMYY9rPvXUSQSGuXM+5ujihVIBou291LVWWKYImlAFK47yK0JCVBf1q1lwBJIwxQZsJChs6wfXnZURdVen+TWiLm6fXX7DCKdNkHGOQsixVTSGumUO9r1yfqmQ8TK/Gc8Q= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2016 14:56:12.9570 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3004 Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 14:56:19 -0000 ----- Original Message ----- From: "Mikael Abrahamsson" Sent: Thursday, October 20, 2016 11:13 AM > On Thu, 20 Oct 2016, t.petch wrote: > > > In theory, I agree with you but in practice, I expect it will be at > > least a year or two before GROW produces such a document. In the > > meantime, I would go with Jeff's suggestion to include an 'Operational > > Considerations' section in this I-D (and that then could refer to > > RFC7454 and clarify the meaning of 'high order bits'). > > > > But I think that we have yet to agree what such a section would say. > > Exactly. So do you still want to delay the progress of this document until > we (perhaps never) reach consensus on what the fields should be? It comes back to the same point. If we have no consensus on what the fields should be (and it is the first field that is an ASN which allows the others to be interpreted which is the field that concerns me) and the fields are part of a transitive attribute that goes who knows where in the Internet, then how can they be safely used to influence routing? Specify that and the problem is solved. MUST be an ASN works for me, or, paradoxically, MAY be an ASN (since then it should be obvious the fields cannot be relied on); the idea of stripping them so that they are not transitive has been floated (or make the attribute non-transitive) and I think rejected. It all seems unattractive but then so does routing based on fields that you do not know how to interpret. When the first field is 2914, it may be ASN 2914 but it may be someone else using this big new community for something completely different and claiming that it is only a SHOULD in the RFC so that gives them licence to put something other than an ASN in there - well, something along those lines. To state the obvious, this progresses to the next stage when there is rough consensus to progress it:-) Tom Petch > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Oct 20 08:11:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BB8129627 for ; Thu, 20 Oct 2016 08:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 kXoqb5Z6mXtm for ; Thu, 20 Oct 2016 08:11:24 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4E1129635 for ; Thu, 20 Oct 2016 08:11:21 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id D91F8788F1 for ; Thu, 20 Oct 2016 17:11:19 +0200 (CEST) Date: Thu, 20 Oct 2016 17:11:18 +0200 From: Peter Hessler To: idr@ietf.org Message-ID: <20161020151118.GJ27221@gir.theapt.org> References: <5807F3AF.9080200@foobar.org> <01ad01d22ab2$2c8c4060$4001a8c0@gateway.2wire.net> <007701d22ae1$c14b2020$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007701d22ae1$c14b2020$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 15:11:25 -0000 On 2016 Oct 20 (Thu) at 15:53:36 +0100 (+0100), t.petch wrote: :MUST be an ASN works for me, or, paradoxically, MAY be an ASN (since :then it should be obvious the fields cannot be relied on); the idea of :stripping them so that they are not transitive has been floated (or make :the attribute non-transitive) and I think rejected. I am very happy with MAY instead of SHOULD. Global Administrator: A four-octet namespace identifier. This MAY be an Autonomous System Number. Is this acceptable to you? -peter From nobody Thu Oct 20 08:24:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A3E1297B8 for ; Thu, 20 Oct 2016 08:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 u6yg31WemapJ for ; Thu, 20 Oct 2016 08:24:23 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 A3C7E129657 for ; Thu, 20 Oct 2016 08:24:23 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bxFCg-0009FK-Cg (job@us.ntt.net); Thu, 20 Oct 2016 15:24:23 +0000 Date: Thu, 20 Oct 2016 10:24:18 -0500 From: Job Snijders To: Peter Hessler Message-ID: <20161020152418.GP1033@Vurt.local> References: <5807F3AF.9080200@foobar.org> <01ad01d22ab2$2c8c4060$4001a8c0@gateway.2wire.net> <007701d22ae1$c14b2020$4001a8c0@gateway.2wire.net> <20161020151118.GJ27221@gir.theapt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161020151118.GJ27221@gir.theapt.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 15:24:25 -0000 On Thu, Oct 20, 2016 at 05:11:18PM +0200, Peter Hessler wrote: > On 2016 Oct 20 (Thu) at 15:53:36 +0100 (+0100), t.petch wrote: > :MUST be an ASN works for me, or, paradoxically, MAY be an ASN (since > :then it should be obvious the fields cannot be relied on); the idea of > :stripping them so that they are not transitive has been floated (or make > :the attribute non-transitive) and I think rejected. > > I am very happy with MAY instead of SHOULD. > > Global Administrator: A four-octet namespace identifier. This > MAY be an Autonomous System Number. > > Is this acceptable to you? No. If some network squats on 2914: because they put 0.0.11.98: in the global administrator, good for them. Just like with rfc1997, we know to deal with that. SHOULD aligns with reality. This topic should be closed, perhaps we can agree to disagree. We seem to be suffering from Parkinson's law of triviality. Kind regards, Job From nobody Thu Oct 20 08:32:12 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F1E12965D for ; Thu, 20 Oct 2016 08:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 I-uOwSUAyOm0 for ; Thu, 20 Oct 2016 08:32:05 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 9F305129592 for ; Thu, 20 Oct 2016 08:32:05 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bxFK9-000A2C-7M (job@us.ntt.net); Thu, 20 Oct 2016 15:32:05 +0000 Date: Thu, 20 Oct 2016 10:32:02 -0500 From: Job Snijders To: idr@ietf.org Message-ID: <20161020153202.GQ1033@Vurt.local> References: <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <01ab01d22ab2$2b54f8e0$4001a8c0@gateway.2wire.net> <515_1476964767_5808B19F_515_1079_1_53C29892C857584299CBF5D05346208A0FA0799F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20161020131349.GL1033@Vurt.local> <10701_1476970482_5808C7F2_10701_5009_1_53C29892C857584299CBF5D05346208A0FA07C6E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <2588_1476970728_5808C8E8_2588_648_1_9ab4dc04-d856-449d-b978-8ea1960a25d1@OPEXCLILMA1.corporate.adroot.infra.ftgroup> <83759244-B42B-48E1-AC5A-E6289D9F66EA@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83759244-B42B-48E1-AC5A-E6289D9F66EA@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 15:32:11 -0000 On Thu, Oct 20, 2016 at 10:04:52AM -0400, Jeffrey Haas wrote: > For example, if I really like Job's 2914 community road-show For the others on the list: At this week's NANOG in Dallas, Greg Hankins gave a presentation on Large BGP Communities. The recording can be accessed here: https://www.youtube.com/watch?v=6Z7dzEzMgHk Kind regards, Job From nobody Thu Oct 20 08:39:11 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBA5129996 for ; Thu, 20 Oct 2016 08:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 np2hLWbpi0H8 for ; Thu, 20 Oct 2016 08:39:09 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 11B70129991 for ; Thu, 20 Oct 2016 08:39:09 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bxFQu-000Agk-Sx (job@us.ntt.net); Thu, 20 Oct 2016 15:39:06 +0000 Date: Thu, 20 Oct 2016 10:38:58 -0500 From: Job Snijders To: "t.petch" Message-ID: <20161020153858.GR1033@Vurt.local> References: <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <5807F3AF.9080200@foobar.org> <01ad01d22ab2$2c8c4060$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ad01d22ab2$2c8c4060$4001a8c0@gateway.2wire.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 15:39:10 -0000 On Thu, Oct 20, 2016 at 10:08:17AM +0100, t.petch wrote: > In theory, I agree with you but in practice, I expect it will be at > least a year or two before GROW produces such a document. In the > meantime, I would go with Jeff's suggestion to include an 'Operational > Considerations' section in this I-D (and that then could refer to > RFC7454 and clarify the meaning of 'high order bits'). > > But I think that we have yet to agree what such a section would say. We are certainly not putting in sections for which we have no content. I've mentioned this before: a small group of operators is working on usage guidelines for large bgp communities in the spirit of rfc1998. The document is not ready yet to be published. The target working group will be GROW and its intended status Informational. I think a 12 to 24 month timeframe for the document to mature is reasonable and not a problem. Kind regards, Job From nobody Thu Oct 20 08:42:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDF6129997 for ; Thu, 20 Oct 2016 08:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 MRt9O_5ni-Sd for ; Thu, 20 Oct 2016 08:42:07 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 609D7129996 for ; Thu, 20 Oct 2016 08:42:07 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bxFTl-000AzX-Aw (job@us.ntt.net); Thu, 20 Oct 2016 15:42:03 +0000 Date: Thu, 20 Oct 2016 10:41:53 -0500 From: Job Snijders To: "t.petch" Message-ID: <20161020154153.GT1033@Vurt.local> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <01ab01d22ab2$2b54f8e0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ab01d22ab2$2b54f8e0$4001a8c0@gateway.2wire.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 15:42:09 -0000 Hi Tom, I've removed the word 'usually'. Thank you for the suggestion. Kind regards, Job On Thu, Oct 20, 2016 at 09:37:59AM +0100, t.petch wrote: > Jared > > As Brian has pointed out, it was the use of 'usually' that I was > concerned with, as watering down the recommended use of an ASN by > RFC1997. Excise 'usually' and that part of my concern goes away. > > Tom Petch > > > ----- Original Message ----- > From: "Jared Mauch" > Sent: Wednesday, October 19, 2016 7:54 PM > > > > On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch wrote: > > > I remain unhappy with this I-D. > > > > > > I find it ironic that the messages for this Last Call should be > > > interspersed with those relating to what goes wrong when someone > > > somewhere else in the world uses a field in an unexpected way. This > > > reinforces my belief that this I-D should be more forceful in > calling > > > out the dangers (eg MUST instead of SHOULD). > > > > > > I think that this I-D is factually incorrect, or at least open to > > > misinterpretation, when it says > > > '[RFC1997] BGP Communities attributes are four-octet values split > into > > > two two-octet words. The most significant word is usually > > > interpreted as an Autonomous System Number (ASN) ' > > > > rfc1998: section 4 gives you the slice + dice bits: > > > > -- snip -- rfc 1998 -- > > To make use of the BGP community attribute, several community > values > > (MCI's AS number: 3561 = 0x0DE9) have been defined that can be used > > by customers to tag routes so that the appropriate "LOCAL_PREF" > > values are configured. Table 2 lists the appropriate community > > attribute values (and the mappings of community to LOCAL_PREF): > > -- snip -- rfc 1998 -- > > > > This is the segmenting, and most customers have > > "ip bgp community new-format" configured. > > > > If your issue is about printf %ull vs %d:%d:%d we operators > > can solve this by ensuring our vendors do the right thing, which > > we have already done 20 years ago via rfc1998. > > > > This nit is imo not worth picking. > > > > - Jared > > > > -- > > Jared Mauch | pgp key available via finger from jared@puck.nether.net > > clue++; | http://puck.nether.net/~jared/ My statements are only > mine. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Oct 20 08:49:01 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032B8129975 for ; Thu, 20 Oct 2016 08:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 zu34TN1_CdW2 for ; Thu, 20 Oct 2016 08:48:59 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 EA0DF12964B for ; Thu, 20 Oct 2016 08:48:59 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bxFaS-000Boc-HG (job@us.ntt.net); Thu, 20 Oct 2016 15:48:58 +0000 Date: Thu, 20 Oct 2016 10:48:47 -0500 From: Job Snijders To: David Farmer Message-ID: <20161020154847.GU1033@Vurt.local> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <107141A7-5CD2-4E48-8F6C-C737FF370359@pfrc.org> <5807ED30.30204@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 15:49:01 -0000 On Wed, Oct 19, 2016 at 05:34:37PM -0500, David Farmer wrote: > On Wed, Oct 19, 2016 at 5:01 PM, Nick Hilliard wrote: > > Jeffrey Haas wrote: > > > I had thought that a BCOP document on communities was out there for BGP > > > communities in general, but "community" clutters the search engines > > > quite a bit and I'm not finding such a thing. > > > > are you thinking of rfc7454? > > > > Dave's suggestion is definitely an operational- rather than a > > protocol-level issue. draft-ietf-idr-large-community is a protocol > > definition, so it would be better to see this in a GROW document. > > So it's slightly more than just the wire-protocol issues, it defines a > Canonical Representation. I think that's important, but I think it's > equally important that to interoperability that implementations include > policy tools. I included some motivation for why the tools need to be > included, but if you'd prefer to strip that out, I'd be fine with that. So > that leaves something like this; > > Implementations SHOULD provide a rich set of policy capabilities to > allow operators to decide which large communities are received from > or propagated to peers. This would be a statement without teeth. There are BGP implementations where policy capabilities are not so relevant. I also consider it the operator's job to negotiate with their vendors on what features are available on a box. The market self-corrects. Such text belongs in a commercial request for proposal, not nessecarily in protocol specification. Kind regards, Job From nobody Thu Oct 20 09:01:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5B51294E2 for ; Thu, 20 Oct 2016 09:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 7nOLcskxqo_O for ; Thu, 20 Oct 2016 09:01:46 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 F1743129474 for ; Thu, 20 Oct 2016 09:01:45 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bxFmp-000D8z-Gx (job@us.ntt.net); Thu, 20 Oct 2016 16:01:44 +0000 Date: Thu, 20 Oct 2016 11:01:37 -0500 From: Job Snijders To: Brian Dickson Message-ID: <20161020160137.GV1033@Vurt.local> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 16:01:48 -0000 Dear Brian, Thank you for your time and detailed review. I'll go over the concerns one by one. On Wed, Oct 19, 2016 at 12:46:27PM -0700, Brian Dickson wrote: > Concern #1: > > >From my reading of RFC1997, and from a couple of decades of operational > experience, > I believe the wording in Section 1 should be as follows: > > "The most significant word is always an ASN. Private ASN values MAY be used > when agreed upon by adjacent BGP peers." > (Insert reference to IANA private 32-bit ASN table.) We've discussed this separately in the thread. The reality is that it is a 32-bit field, and it is not possible with today's standards to enforce any semantics on the contents of that 32-bit field. However, operators have a rich experience in scrubbing bgp communities and sanitizing the input. > Concern #2: > > And, IMNSHO, the request/demand for parity with RFC1997, calls for similar > language when describing the 32-bit first field's interpretation: > > In Section 2: > > "Global Administrator: A four-octet namespace identifier. This MUST be an > Autonomous System Number. Private ASN values MAY be used when agreed upon > by adjacent BGP peers. Private ASN values SHOULD NOT be advertised to peers > where their use has not been agreed upon." This strikes me as superfluous. The current text accomodates this practise. But to be honest I expect the practise to die out. Given the spaciousness of Large BGP Communities, I doubt we'll see a lot of private ASN usage in the global administrator field because there is no need to do so anymore. I'm making a note for the "Usage" document, where we can maybe describe that if private ASNs are used in the Global Administrator field the the propagationi characteristics might differ from globally unique ASNs. > Concern #3: > > In addition, to address concerns the co-authors have expressed, the > non-intent of "MUST", to implementers, should be explicitly called out. The > proposed wording would be: > "The Global Administrator field is intended to allow different > Autonomous Systems to define Large BGP Communities without collision. > Implementations MUST allow the operator to specify any value for the > Global Administrator field. Implementors MUST NOT restrict permitted > values of ASN, including non-reserved 16-bit ASN values and > non-reserved 32-bit ASN values, which includes all Private Use ASN > ranges. Use of third-party ASN values is an explicitly permitted use > of Large Communities." > > Rationale: Avoid any ambiguity for implementation of Large Communities. > Interoperation demands compatible interpretation of values of ASN permitted > by implementors. All ASNs are 32-bit values as per 4893/6793 etc. I'm sorry to say, but the added sentences are redundant. "any value" is a the superset of the things you mention. Kind regards, Job From nobody Thu Oct 20 14:59:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAB212967B for ; Thu, 20 Oct 2016 14:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=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 ZWeCnLZp4Am7 for ; Thu, 20 Oct 2016 14:59:49 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 964DB1294F9 for ; Thu, 20 Oct 2016 14:59:49 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bxLNK-0004hW-Qz (job@us.ntt.net); Thu, 20 Oct 2016 21:59:48 +0000 Date: Thu, 20 Oct 2016 16:59:38 -0500 From: Job Snijders To: Jeffrey Haas Message-ID: <20161020215938.GE1074@Vurt.local> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: heasley , IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 21:59:51 -0000 Hi working group, On Tue, Oct 18, 2016 at 04:38:00PM -0400, Jeffrey Haas wrote: > > > On Oct 18, 2016, at 3:15 PM, Job Snijders wrote: > > > >> > >> Part of the idea behind reserving 65535:*:* was to reserve a space that > >> could later be used for well-knowns, if that was desired - but to not > >> spend time now arguing about details of what well-knowns are necessary. > >> > >> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs. > > > > Jeff argues that a justification should be added. Maybe someone can > > pitch in one or two sentences that explain why these are reserved? > > That's certainly part of it. While I think many people can see the > reason why you might want to do such a reservation, to do so you > should have a practical reason in the document. > > For the 65535:*:* case, for symmetry with RFC 1997, you'd probably > want to note that if it's used for that symmetry that either the > existing well known community registry is used at IANA or that a new > one would need to be created. Alternatively, you just say the work is > expected and defer to a future document. > > Note by doing this, you're setting up some expectations about > translation of communities from one space to another. FWIW, I don't > recommend this and simply suggest that you recommend *not* using these > for common use in case someone decides that they want to do so. I > know your organization and others such as Deutsche Telecom have some > thoughts about what translation infrastructure might look like, and > such mechanisms would have impact. > > With regard to the 0: and max-uint32: cases, after dealing with the > headaches associated with helping with documents such as the as0 and > RFC 7300 and putting in some restrictions in the configuration... > followed by having to take them away, I'm very reluctant to put in > anything beyond "we think it's a bad idea to use these, so pretty > please don't" After some off-list back and forth with John Heasley, Adam Chappell, Jeff Haas and the authors, we came up with the following text to address the above raised concern. This will be part of -04. """" 5. Reserved Large BGP Community values The following Global Administrator values are reserved: 0 (the first ASN) [RFC7607], 65535 (UINT_MAX) and 4294967295 (the last ASN) [RFC7300]. Operators SHOULD NOT use these Global Administrator values. Although this document does not define any Special-Use Large BGP Communities, the Global Administrator values specified above could be used if there is a future need for them. """ A preview of the -03 / -04 diff is available here: https://htmlpreview.github.io/?https://github.com/large-bgp-communities/large-bgp-communities/blob/master/draft-ietf-idr-large-community-04-from-3.diff.html Kind regards, Job From nobody Thu Oct 20 15:13:46 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E281294F9 for ; Thu, 20 Oct 2016 15:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 vi6SzgeRGkrP for ; Thu, 20 Oct 2016 15:13:43 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35B4129575 for ; Thu, 20 Oct 2016 15:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4206; q=dns/txt; s=iport; t=1477001623; x=1478211223; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mBuQaAhhFat6y/KaQGdFr4t2n3h3n6EBOhf2RzTeOD8=; b=ZdB6C+QIlj/Ej69kOCOS7Dm5aoSdjnpMl0Lkab/AaHmYnp03h67qH/WQ IW57UfytnspKXb3Wz18PtyGVKhf66OLz/OKluhdWNEWT+KSGkNd/xx12V aNqE1ZuKNdkiRwoLBxHLLV/VZyNhtIFG8igZ9miChx1pk30L+JdDk9Gcy M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQAuQAlY/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz4BAQEBAR1XfQcBjSyWfJQ9gggcD4V2AoF+PxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRiAQEBBAEBATc0CwwEAgEIEQQBAQEeCQcnCxQJCAIEAQ0FCAyIPg7DWgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARcFhj2EVYomBZoOAYYpiVyBdYRpiSSMf4N/AR4?= =?us-ascii?q?2WIMEOoE6cgGIGAF/AQEB?= X-IronPort-AV: E=Sophos;i="5.31,521,1473120000"; d="scan'208";a="338385858" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Oct 2016 22:13:42 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u9KMDgaD021883 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Oct 2016 22:13:42 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Oct 2016 17:13:41 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 20 Oct 2016 17:13:41 -0500 From: "Jakob Heitz (jheitz)" To: Job Snijders , Jeffrey Haas Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) Thread-Index: AdIotF10Qx6LizvwQ9uItB9ryESdDgANiv0AACybzYAAADoegAAC4vMAAGdvEAAAChhMkA== Date: Thu, 20 Oct 2016 22:13:41 +0000 Message-ID: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> In-Reply-To: <20161020215938.GE1074@Vurt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: heasley , IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 22:13:45 -0000 In addition, to deal with the values for the GA field, we will replace The Global Administrator field is intended to allow different Autonomous Systems to define Large BGP Communities without collision. with A Large Community that is intended to be sent to multiple ASes SHOULD contain an ASN in the Global Administrator field. The ASN SHOULD be one that is assigned to the entity that defines the meaning of the rest of the Large Community. This allows a route to carry multiple Large Communities, the meaning of each being defined by different independent entities. Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders > Sent: Thursday, October 20, 2016 3:00 PM > To: Jeffrey Haas > Cc: heasley ; IETF IDR WG ; Sue Hares <= shares@ndzh.com> > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/= 2016 to 10/31/2016) >=20 > Hi working group, >=20 > On Tue, Oct 18, 2016 at 04:38:00PM -0400, Jeffrey Haas wrote: > > > > > On Oct 18, 2016, at 3:15 PM, Job Snijders wrote: > > > > > >> > > >> Part of the idea behind reserving 65535:*:* was to reserve a space t= hat > > >> could later be used for well-knowns, if that was desired - but to no= t > > >> spend time now arguing about details of what well-knowns are necessa= ry. > > >> > > >> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs. > > > > > > Jeff argues that a justification should be added. Maybe someone can > > > pitch in one or two sentences that explain why these are reserved? > > > > That's certainly part of it. While I think many people can see the > > reason why you might want to do such a reservation, to do so you > > should have a practical reason in the document. > > > > For the 65535:*:* case, for symmetry with RFC 1997, you'd probably > > want to note that if it's used for that symmetry that either the > > existing well known community registry is used at IANA or that a new > > one would need to be created. Alternatively, you just say the work is > > expected and defer to a future document. > > > > Note by doing this, you're setting up some expectations about > > translation of communities from one space to another. FWIW, I don't > > recommend this and simply suggest that you recommend *not* using these > > for common use in case someone decides that they want to do so. I > > know your organization and others such as Deutsche Telecom have some > > thoughts about what translation infrastructure might look like, and > > such mechanisms would have impact. > > > > With regard to the 0: and max-uint32: cases, after dealing with the > > headaches associated with helping with documents such as the as0 and > > RFC 7300 and putting in some restrictions in the configuration... > > followed by having to take them away, I'm very reluctant to put in > > anything beyond "we think it's a bad idea to use these, so pretty > > please don't" >=20 > After some off-list back and forth with John Heasley, Adam Chappell, > Jeff Haas and the authors, we came up with the following text to address > the above raised concern. >=20 > This will be part of -04. >=20 > """" > 5. Reserved Large BGP Community values >=20 > The following Global Administrator values are reserved: 0 (the first > ASN) [RFC7607], 65535 (UINT_MAX) and 4294967295 (the last ASN) > [RFC7300]. Operators SHOULD NOT use these Global Administrator > values. >=20 > Although this document does not define any Special-Use Large BGP > Communities, the Global Administrator values specified above could be > used if there is a future need for them. > """ >=20 > A preview of the -03 / -04 diff is available here: >=20 > https://htmlpreview.github.io/?https://github.com/large-bgp-communities/l= arge-bgp-communities/blob/master/draft- > ietf-idr-large-community-04-from-3.diff.html >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Oct 20 15:50:22 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BCA129455 for ; Thu, 20 Oct 2016 15:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 XGg86oQzukHS for ; Thu, 20 Oct 2016 15:50:19 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 ACE5C127A90 for ; Thu, 20 Oct 2016 15:50:19 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bxMAC-0004WK-9H (job@us.ntt.net); Thu, 20 Oct 2016 22:50:17 +0000 Date: Thu, 20 Oct 2016 17:50:04 -0500 From: Job Snijders To: "Jakob Heitz (jheitz)" Message-ID: <20161020225004.GG1074@Vurt.local> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: heasley , Sue Hares , IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 22:50:21 -0000 Hi Jakob, I am not sure what issue this replacement resolves. With the replacement text in the document I feel I have more questions than answers. Usually a community is intended to be sent to one AS to trigger an action, and to multiple ASes if the community is of informative nature. We know we can attach multiple Large BGP Communities to a route, because of the variable length of the attribute. In an earlier response I pointed at text that addresses this specific feature already in the current text: https://mailarchive.ietf.org/arch/msg/idr/_QULjIUDaBB4JqDR8IXuIYkAVJw Kind regards, Job On Thu, Oct 20, 2016 at 10:13:41PM +0000, Jakob Heitz (jheitz) wrote: > In addition, to deal with the values for the GA field, we will replace > > The Global Administrator field is intended to allow different > Autonomous Systems to define Large BGP Communities without collision. > > with > > A Large Community that is intended to be sent to multiple ASes > SHOULD contain an ASN in the Global Administrator field. The ASN > SHOULD be one that is assigned to the entity that defines the > meaning of the rest of the Large Community. This allows a route to > carry multiple Large Communities, the meaning of each being defined > by different independent entities. From nobody Thu Oct 20 16:06:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046881296AD for ; Thu, 20 Oct 2016 16:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 4A6x-RV2izvc for ; Thu, 20 Oct 2016 16:06:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0695129675 for ; Thu, 20 Oct 2016 16:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1863; q=dns/txt; s=iport; t=1477004782; x=1478214382; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iIPaWjE95gR5Lc592XSIBQy9UAJDCeS+XxKRjLFbbHg=; b=UKGLF1J1e7lfkD8c4u82xUoDyJNXIarkb9q+/nQwYe6iA9Iq2MEY4k9L 2T918LMrCa0t5Si86lGlyAy2NhoajXsZUK7m/+OywOGv+iYsOS7RYEmRy FSMHfGMi0x5RQgKONjuLE3QBmJBJ+NJnEM+eTP4wm3oaSlagvZzrBMGtI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAQA1TQlY/51dJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgz4BAQEBAR1XfQcBjSyWfJQ9gggnhXoCgX8/FAECAQEBAQEBAWIohGI?= =?us-ascii?q?BAQEEOj8MBAIBCBEEAQEBHgkHMhQJCAIEDgUIDIg+DsNbAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBFwWGPYRViiYFmg4BhimJXJACjH+DfwEeNliDBDqBOnKIGQF/AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.31,521,1473120000"; d="scan'208";a="162086199" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Oct 2016 23:06:21 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u9KN6LTE026783 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Oct 2016 23:06:21 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Oct 2016 18:06:21 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 20 Oct 2016 18:06:20 -0500 From: "Jakob Heitz (jheitz)" To: Job Snijders Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) Thread-Index: AdIotF10Qx6LizvwQ9uItB9ryESdDgANiv0AACybzYAAADoegAAC4vMAAGdvEAAAChhMkP//vVQAgABPXBA= Date: Thu, 20 Oct 2016 23:06:20 +0000 Message-ID: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161020225004.GG1074@Vurt.local> In-Reply-To: <20161020225004.GG1074@Vurt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: heasley , Sue Hares , IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 23:06:24 -0000 Evidently, it wasn't clear. Now it is. Thanks, Jakob. > -----Original Message----- > From: Job Snijders [mailto:job@ntt.net] > Sent: Thursday, October 20, 2016 3:50 PM > To: Jakob Heitz (jheitz) > Cc: Jeffrey Haas ; heasley ; IETF IDR= WG ; Sue Hares > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/= 2016 to 10/31/2016) >=20 > Hi Jakob, >=20 > I am not sure what issue this replacement resolves. With the replacement > text in the document I feel I have more questions than answers. >=20 > Usually a community is intended to be sent to one AS to trigger an > action, and to multiple ASes if the community is of informative nature. > We know we can attach multiple Large BGP Communities to a route, because > of the variable length of the attribute. >=20 > In an earlier response I pointed at text that addresses this specific > feature already in the current text: https://mailarchive.ietf.org/arch/ms= g/idr/_QULjIUDaBB4JqDR8IXuIYkAVJw >=20 > Kind regards, >=20 > Job >=20 >=20 > On Thu, Oct 20, 2016 at 10:13:41PM +0000, Jakob Heitz (jheitz) wrote: > > In addition, to deal with the values for the GA field, we will replace > > > > The Global Administrator field is intended to allow different > > Autonomous Systems to define Large BGP Communities without collision= . > > > > with > > > > A Large Community that is intended to be sent to multiple ASes > > SHOULD contain an ASN in the Global Administrator field. The ASN > > SHOULD be one that is assigned to the entity that defines the > > meaning of the rest of the Large Community. This allows a route to > > carry multiple Large Communities, the meaning of each being defined > > by different independent entities. From nobody Thu Oct 20 16:46:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4107F129630 for ; Thu, 20 Oct 2016 16:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 fnKS0KnsGkhU for ; Thu, 20 Oct 2016 16:46:06 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0466129549 for ; Thu, 20 Oct 2016 16:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2824; q=dns/txt; s=iport; t=1477007166; x=1478216766; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Tn63L9j57FLABs2xBB8n+MliumEn5XRfzdXTQmx4TpQ=; b=fXhazUJYLRiViXnQoISbiNWZ7VqPnO0cY+nMoxm2wk52t5de84Bk70G4 2xwTcKrryi1bYiAklED+/YHta0QvaHXKPRfedgn3jISNynBQ90HMIf61e JnkiivPy6dRnlcaPtrvqt7CS/DWTZ508jHl8hDESNpGHg+KJPS0YY/LS5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAQDsVglY/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz4BAQEBAR1XfQcBjSyWfJQ9gggcC4V6AoF9PxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRiAQEBBAEBATc0CwwEAgEIEQQBAQEeCQcnCxQJCAIEDgUIDIg+DsNiAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBFwWGPYRViiYFmg4BhimJXJACjH+DfwEeNliDBDq?= =?us-ascii?q?BOnKIGQF/AQEB?= X-IronPort-AV: E=Sophos;i="5.31,521,1473120000"; d="scan'208";a="159918751" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2016 23:46:05 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u9KNk5fu031636 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Oct 2016 23:46:05 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Oct 2016 18:46:04 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 20 Oct 2016 18:46:04 -0500 From: "Jakob Heitz (jheitz)" To: Job Snijders Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) Thread-Index: AdIotF10Qx6LizvwQ9uItB9ryESdDgANiv0AACybzYAAADoegAAC4vMAAGdvEAAAChhMkP//vVQAgABPXBCAAJVk4A== Date: Thu, 20 Oct 2016 23:46:04 +0000 Message-ID: <2894c1eb263143cc8129ec8e381957dc@XCH-ALN-014.cisco.com> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161020225004.GG1074@Vurt.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: heasley , IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 23:46:08 -0000 Perhaps, we should add in an operations section that we should not and will= not go any further. In particular, within an AS and between adjacent BGP neighbors, ANY values = will be allowed. The only requirement is that sender and receiver have the same understandin= g of the contents, but no RFC is required to say this. Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz) > Sent: Thursday, October 20, 2016 4:06 PM > To: Job Snijders > Cc: heasley ; Sue Hares ; IETF IDR W= G > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/= 2016 to 10/31/2016) >=20 > Evidently, it wasn't clear. Now it is. >=20 > Thanks, > Jakob. >=20 >=20 > > -----Original Message----- > > From: Job Snijders [mailto:job@ntt.net] > > Sent: Thursday, October 20, 2016 3:50 PM > > To: Jakob Heitz (jheitz) > > Cc: Jeffrey Haas ; heasley ; IETF I= DR WG ; Sue Hares > > > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/1= 7/2016 to 10/31/2016) > > > > Hi Jakob, > > > > I am not sure what issue this replacement resolves. With the replacemen= t > > text in the document I feel I have more questions than answers. > > > > Usually a community is intended to be sent to one AS to trigger an > > action, and to multiple ASes if the community is of informative nature. > > We know we can attach multiple Large BGP Communities to a route, becaus= e > > of the variable length of the attribute. > > > > In an earlier response I pointed at text that addresses this specific > > feature already in the current text: https://mailarchive.ietf.org/arch/= msg/idr/_QULjIUDaBB4JqDR8IXuIYkAVJw > > > > Kind regards, > > > > Job > > > > > > On Thu, Oct 20, 2016 at 10:13:41PM +0000, Jakob Heitz (jheitz) wrote: > > > In addition, to deal with the values for the GA field, we will replac= e > > > > > > The Global Administrator field is intended to allow different > > > Autonomous Systems to define Large BGP Communities without collisi= on. > > > > > > with > > > > > > A Large Community that is intended to be sent to multiple ASes > > > SHOULD contain an ASN in the Global Administrator field. The ASN > > > SHOULD be one that is assigned to the entity that defines the > > > meaning of the rest of the Large Community. This allows a route to > > > carry multiple Large Communities, the meaning of each being defined > > > by different independent entities. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Oct 20 17:28:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D59129439 for ; Thu, 20 Oct 2016 17:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dWyGfSJJch89 for ; Thu, 20 Oct 2016 17:28:28 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088EB1293E4 for ; Thu, 20 Oct 2016 17:28:27 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id b81so108779570lfe.1 for ; Thu, 20 Oct 2016 17:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QdMum387+CMSzfhWz9fg/KdCu30ZNSztFeudEDjq1sw=; b=x49sEj9ohyLyemoENFkZ0o0cYD66btvEkrMCwttNX3oAG6q3gUQTkOifEwm8mkXtcI 00tYbvGJGZybzH4WSzJ1wR6ebnpwO54Z9WFysgDCfpmzvWINCXPzalxnkpemDFA+SXZR WYjWoPsBAoLpBwjoIbybvrZzsaIUue70de2fSDjJJ5h+HS410hAgV0+oWXBD+qcZjXUz aA+unOboE1Iz0aGbU2cfcu7Srs6b9LLkktpXfyIoQfDd4R9S3HMJ54z+C4vAxqgH2sWn YH274zIIFxKuWu3ppnkZct6Q17n0of6WYFFIttN/SF0U23QpqzLPDmhoprdCA1qEiHXK q8Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QdMum387+CMSzfhWz9fg/KdCu30ZNSztFeudEDjq1sw=; b=BVaOZaVxrDDh2tUiY6ULvX1jd3MDkZZhqU6dSzM9mhNa2PzZtTmUGueH8W+2G5CCkW L0+S2iqSUsC/jvbh8qqFzAcD4WIFwOb15FZCh/QNy3Xx8A4NBiRK6DdilN5+k7MgOCEa mcNK6XFoweYDMY0mPzAJghESsJdMSLs7Sqnlp/drarOA6MooKm97GxDXg+8FJ1KRFd3z zVlvJ/+onWxunLWCLp2MCRaN5G65iGJ6XfegpuTwz2YjHGfhjz6BNnL6SdITxmOCZqjo k5rsLKVJB1BzLlQva6sASYKVbt4P7roLVTbg22BotXysoMrMxRfsG52rebu6X4KmAj8n N/qA== X-Gm-Message-State: ABUngveUQP9ttLUey1qhB4nIbaO30dcVer6gIsJEyILrRbI2BBsKqv4mOBtU0SFJi30Zw8Orqxr0ysOkcb7BNA== X-Received: by 10.194.94.168 with SMTP id dd8mr1753536wjb.96.1477009705533; Thu, 20 Oct 2016 17:28:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.207 with HTTP; Thu, 20 Oct 2016 17:28:24 -0700 (PDT) In-Reply-To: <2894c1eb263143cc8129ec8e381957dc@XCH-ALN-014.cisco.com> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161020225004.GG1074@Vurt.local> <2894c1eb263143cc8129ec8e381957dc@XCH-ALN-014.cisco.com> From: Brian Dickson Date: Thu, 20 Oct 2016 17:28:24 -0700 Message-ID: To: "Jakob Heitz (jheitz)" Content-Type: multipart/alternative; boundary=047d7bb03a24d40972053f551ec0 Archived-At: Cc: heasley , IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 00:28:31 -0000 --047d7bb03a24d40972053f551ec0 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 20, 2016 at 4:46 PM, Jakob Heitz (jheitz) wrote: > Perhaps, we should add in an operations section that we should not and > will not go any further. > In particular, within an AS and between adjacent BGP neighbors, ANY values > will be allowed. > The only requirement is that sender and receiver have the same > understanding of the contents, > but no RFC is required to say this. > > Jakob, I think you still don't understand the purpose or the mechanics of communities, as what you say makes almost no sense. The reason "large" needs to be an optional, transitive attribute, is that the intended party, whose ASN is in the Global Administrator field, is not necessarily the first or second party (the one setting the community, or the one that is the BGP peer of the first party). The community may travel an arbitrary number of AS hops before it is received by the ASN in question (global admin). That ASN is the one who is the (ultimate) intended recipient (of the community), and whose interprets the latter 8 octets of the community, using whatever logic he/she wishes. (The prefix will probably propagate much further, but we are only concerned about the ASN that is the global administrator of the community.) This is NOT limited to within an AS, nor to adjacent BGP peers. As such, the intermediate AS hops will receive the prefix with the attached Large Community, but will not have any understanding of the contents. They are expected to pass them along, as this is the necessary part of communities' functioning. A -> X -> Y -> Z -> B are the Autonomous Systems passing the prefix. A sets the community. The community is B:something:something. B interprets the community. X, Y, and Z, pass it along without acting on it. I'm sorry to raise a fuss, but since you are involved in editing the I-D, it would put my mind at ease to hear you say that you understand the above. Putting text into this document, if you don't understand the above, may be harmful to the document, and to operator folks who are trying to get the bugs out of the document before it advances. Sincerely, Brian > Thanks, > Jakob. > > > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz > (jheitz) > > Sent: Thursday, October 20, 2016 4:06 PM > > To: Job Snijders > > Cc: heasley ; Sue Hares ; IETF IDR > WG > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt > (10/17/2016 to 10/31/2016) > > > > Evidently, it wasn't clear. Now it is. > > > > Thanks, > > Jakob. > > > > > > > -----Original Message----- > > > From: Job Snijders [mailto:job@ntt.net] > > > Sent: Thursday, October 20, 2016 3:50 PM > > > To: Jakob Heitz (jheitz) > > > Cc: Jeffrey Haas ; heasley ; IETF > IDR WG ; Sue Hares > > > > > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt > (10/17/2016 to 10/31/2016) > > > > > > Hi Jakob, > > > > > > I am not sure what issue this replacement resolves. With the > replacement > > > text in the document I feel I have more questions than answers. > > > > > > Usually a community is intended to be sent to one AS to trigger an > > > action, and to multiple ASes if the community is of informative nature. > > > We know we can attach multiple Large BGP Communities to a route, > because > > > of the variable length of the attribute. > > > > > > In an earlier response I pointed at text that addresses this specific > > > feature already in the current text: https://mailarchive.ietf.org/ > arch/msg/idr/_QULjIUDaBB4JqDR8IXuIYkAVJw > > > > > > Kind regards, > > > > > > Job > > > > > > > > > On Thu, Oct 20, 2016 at 10:13:41PM +0000, Jakob Heitz (jheitz) wrote: > > > > In addition, to deal with the values for the GA field, we will > replace > > > > > > > > The Global Administrator field is intended to allow different > > > > Autonomous Systems to define Large BGP Communities without > collision. > > > > > > > > with > > > > > > > > A Large Community that is intended to be sent to multiple ASes > > > > SHOULD contain an ASN in the Global Administrator field. The ASN > > > > SHOULD be one that is assigned to the entity that defines the > > > > meaning of the rest of the Large Community. This allows a route to > > > > carry multiple Large Communities, the meaning of each being defined > > > > by different independent entities. > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7bb03a24d40972053f551ec0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 20, 2016 at 4:46 PM, Jakob Heitz (jheitz) <jheitz@cisco.com= > wrote:
Perhaps, we should= add in an operations section that we should not and will not go any furthe= r.
In particular, within an AS and between adjacent BGP neighbors, ANY values = will be allowed.
The only requirement is that sender and receiver have the same understandin= g of the contents,
but no RFC is required to say this.


Jakob,

I thin= k you still don't understand the purpose or the mechanics of communitie= s, as what you say makes almost no sense.

The reas= on "large" needs to be an optional, transitive attribute, is that= the intended party, whose ASN
is in the Global Administrator fie= ld, is not necessarily the first or second party (the one setting the commu= nity,
or the one that is the BGP peer of the first party).=C2=A0<= /div>

The community may travel an arbitrary number of AS= hops before it is received by the ASN in question (global admin).=C2=A0
That ASN is the one who is the (ultimate) intended recipient (of th= e community), and whose interprets the latter 8 octets=C2=A0
of t= he community, using whatever logic he/she wishes. (The prefix will probably= propagate much further, but we
are only concerned about the ASN = that is the global administrator of the community.)

This is NOT limited to within an AS, nor to adjacent BGP peers.

As such, the intermediate AS hops will receive the prefix w= ith the attached Large Community, but will
not have any understan= ding of the contents. They are expected to pass them along, as this is the<= /div>
necessary part of communities' functioning.

A -> X -> Y -> Z -> B are the Autonomous Systems passin= g the prefix.
A sets the community. The community is B:something:= something.
B interprets the community.
X, Y, and Z, pas= s it along without acting on it.

I'm sorry to = raise a fuss, but since you are involved in editing the I-D, it would put m= y mind at ease to hear you say
that you understand the above.

Putting text into this document, if you don't und= erstand the above, may be harmful to the document,
and to operato= r folks who are trying to get the bugs out of the document before it advanc= es.

Sincerely,
Brian

=C2=A0
Thanks,
Jakob.


> -----Original Message-----
> From: Idr [mailto:idr-bounces@= ietf.org] On Behalf Of Jakob Heitz (jheitz)
> Sent: Thursday, October 20, 2016 4:06 PM
> To: Job Snijders <job@ntt.net>= ;
> Cc: heasley <heas@shrubbery.n= et>; Sue Hares <shares@ndzh.co= m>; IETF IDR WG <idr@ietf.org= >
> Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt= (10/17/2016 to 10/31/2016)
>
> Evidently, it wasn't clear. Now it is.
>
> Thanks,
> Jakob.
>
>
> > -----Original Message-----
> > From: Job Snijders [mailto:job@ntt= .net]
> > Sent: Thursday, October 20, 2016 3:50 PM
> > To: Jakob Heitz (jheitz) <= jheitz@cisco.com>
> > Cc: Jeffrey Haas <jhaas@pfrc= .org>; heasley <heas@shrubb= ery.net>; IETF IDR WG <idr@ietf.o= rg>; Sue Hares
> > <shares@ndzh.com> > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-0= 3.txt (10/17/2016 to 10/31/2016)
> >
> > Hi Jakob,
> >
> > I am not sure what issue this replacement resolves. With the repl= acement
> > text in the document I feel I have more questions than answers. > >
> > Usually a community is intended to be sent to one AS to trigger a= n
> > action, and to multiple ASes if the community is of informative n= ature.
> > We know we can attach multiple Large BGP Communities to a route, = because
> > of the variable length of the attribute.
> >
> > In an earlier response I pointed at text that addresses this spec= ific
> > feature already in the current text: https://mailarchive.ietf.org/arch/msg/idr/_QULjIU= DaBB4JqDR8IXuIYkAVJw
> >
> > Kind regards,
> >
> > Job
> >
> >
> > On Thu, Oct 20, 2016 at 10:13:41PM +0000, Jakob Heitz (jheitz) wr= ote:
> > > In addition, to deal with the values for the GA field, we wi= ll replace
> > >
> > >=C2=A0 =C2=A0 The Global Administrator field is intended to a= llow different
> > >=C2=A0 =C2=A0 Autonomous Systems to define Large BGP Communit= ies without collision.
> > >
> > > with
> > >
> > >=C2=A0 =C2=A0A Large Community that is intended to be sent to= multiple ASes
> > >=C2=A0 =C2=A0SHOULD contain an ASN in the Global Administrato= r field. The ASN
> > >=C2=A0 =C2=A0SHOULD be one that is assigned to the entity tha= t defines the
> > >=C2=A0 =C2=A0meaning of the rest of the Large Community.=C2= =A0 This allows a route to
> > >=C2=A0 =C2=A0carry multiple Large Communities, the meaning of= each being defined
> > >=C2=A0 =C2=A0by different independent entities.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--047d7bb03a24d40972053f551ec0-- From nobody Thu Oct 20 17:46:56 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AF2127735 for ; Thu, 20 Oct 2016 17:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 8zbdBoRpmBBA for ; Thu, 20 Oct 2016 17:46:52 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906861294C8 for ; Thu, 20 Oct 2016 17:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30818; q=dns/txt; s=iport; t=1477010811; x=1478220411; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9U/yeuyx8/3N84q+BRdIbMSOPLKUUnSLRK8S8qjB1og=; b=a44mCVSSmeNMqOcqOEPAgO/YpadVyOzC6eJpR5387s8G08GCsv5i5qO5 +lisc3PFbk0YWqiWtk+KeDc3s+G1tMILfxqOAYclTntLhTVyIKXRC9XWa X+naoVyo1mfyM9ouTWSeJGI5cUegdIDieT0B88MMd7bOtofG4YL8Q+5WD k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAQBwZAlY/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgwg2AQEBAQEdV30HAY0slnyHXoxfgggcAQqFegIagVw/FAECAQE?= =?us-ascii?q?BAQEBAWIohGIBAQEEAQEBIAQGQQUGDAQCAQgRBAEBASAHAwICAh8GCxQJCAIED?= =?us-ascii?q?gUIDIgkAxcOtmiJBQ2DawEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhj2EVYJHgVx?= =?us-ascii?q?agk6CWwWJJIsOhSc1AYYphk+DDZACiGiEF4N/AR42WIMEOoE6cgGGaYEvAX8BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.31,521,1473120000"; d="scan'208,217";a="337677958" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2016 00:46:50 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u9L0koPE000763 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Oct 2016 00:46:50 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Oct 2016 19:46:49 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 20 Oct 2016 19:46:49 -0500 From: "Jakob Heitz (jheitz)" To: Brian Dickson Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) Thread-Index: AdIotF10Qx6LizvwQ9uItB9ryESdDgANiv0AACybzYAAADoegAAC4vMAAGdvEAAAChhMkP//vVQAgABPXBCAAJVk4P//NroAgABTmJA= Date: Fri, 21 Oct 2016 00:46:49 +0000 Message-ID: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161020225004.GG1074@Vurt.local> <2894c1eb263143cc8129ec8e381957dc@XCH-ALN-014.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.84] Content-Type: multipart/alternative; boundary="_000_dc81002a2d93480eb0aeec334b35b5c8XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Cc: heasley , IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 00:46:55 -0000 --_000_dc81002a2d93480eb0aeec334b35b5c8XCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkbyB1bmRlcnN0YW5kIHRoYXQgdGhlIGNvbW11bml0eSBtYXkgdHJhdmVsIHNldmVyYWwgQVMg aG9wcy4NClRoYXQncyB3aHkgSSB3cm90ZQ0KDQoNCiAgQSBMYXJnZSBDb21tdW5pdHkgdGhhdA0K DQogIGlzIGludGVuZGVkIHRvIGJlIHNlbnQgdG8gbXVsdGlwbGUgQVNlcyBTSE9VTEQgY29udGFp biBhbiBBU04NCg0KICBpbiB0aGUgR2xvYmFsIEFkbWluaXN0cmF0b3IgZmllbGQuIFRoZSBBU04g U0hPVUxEIGJlIG9uZSB0aGF0DQoNCiAgaXMgYXNzaWduZWQgdG8gdGhlIGVudGl0eQ0KDQogIHRo YXQgZGVmaW5lcyB0aGUgbWVhbmluZyBvZiB0aGUgcmVzdCBvZiB0aGUgTGFyZ2UgQ29tbXVuaXR5 Lg0KDQpJIGFsc28gdW5kZXJzdGFuZCB0aGF0IHRoaXMgaXMgbm90IHRoZSBvbmx5IGNhc2UgYW5k IHRoYXQgY29tbXVuaXRpZXMNCmFyZSBvZnRlbiB1c2VkIHdpdGhpbiBhbiBBUyBvbmx5LiBXZSBN VVNUIE5PVCByZXN0cmljdCB0aGF0IHVzZS4NCg0KQWxzbywgZXZlbiB0aG91Z2ggQVMgQiBkZWZp bmVzIHRoZSBjb21tdW5pdHkgdGhhdCBoYXMgR0E9QiwgQVMgQg0KaXMgbm90IGFsd2F5cyB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LiBNYW55IElTUHMgdXNlIGNvbW11bml0aWVzDQp0byBzaWduYWwg cHJvcGVydGllcyBvZiByb3V0ZXMgdGhhdCB0aGV5IHNlbmQgdG8gdGhlaXIgY3VzdG9tZXJzLg0K SW4gdGhhdCBjYXNlLCBBUyBCIGlzIHRoZSBzZW5kZXIsIG5vdCB0aGUgcmVjaXBpZW50Lg0KDQpJ IHdyb3RlICJlbnRpdHkiIGFuZCBub3QgIkFTIiwgYmVjYXVzZSBzb21lb25lIG1heSBjcmVhdGUg b25seSBhDQpzaW5nbGUgQkdQIEFTLCBidXQgYmUgYXNzaWduZWQgbWFueSBBU05zLiBUaGF0IHNv bWVvbmUgaXMgZW50aXRsZWQNCnRvIHVzZSBhbnkgb2YgaGVyIGFzc2lnbmVkIEFTTnMsIG5vdCBq dXN0IHRoZSBvbmUgaW4gdXNlIGJ5IGhlciBBUy4NCg0KDQpUaGFua3MsDQpKYWtvYi4NCg0KRnJv bTogQnJpYW4gRGlja3NvbiBbbWFpbHRvOmJyaWFuLnBldGVyLmRpY2tzb25AZ21haWwuY29tXQ0K U2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjAsIDIwMTYgNToyOCBQTQ0KVG86IEpha29iIEhlaXR6 IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPg0KQ2M6IEpvYiBTbmlqZGVycyA8am9iQG50dC5u ZXQ+OyBoZWFzbGV5IDxoZWFzQHNocnViYmVyeS5uZXQ+OyBJRVRGIElEUiBXRyA8aWRyQGlldGYu b3JnPjsgU3VlIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+DQpTdWJqZWN0OiBSZTogW0lkcl0gV0cg TEMgb24gZHJhZnQtaWV0Zi1pZHItbGFyZ2UtY29tbXVuaXR5LTAzLnR4dCAoMTAvMTcvMjAxNiB0 byAxMC8zMS8yMDE2KQ0KDQoNCg0KT24gVGh1LCBPY3QgMjAsIDIwMTYgYXQgNDo0NiBQTSwgSmFr b2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBjaXNjby5j b20+PiB3cm90ZToNClBlcmhhcHMsIHdlIHNob3VsZCBhZGQgaW4gYW4gb3BlcmF0aW9ucyBzZWN0 aW9uIHRoYXQgd2Ugc2hvdWxkIG5vdCBhbmQgd2lsbCBub3QgZ28gYW55IGZ1cnRoZXIuDQpJbiBw YXJ0aWN1bGFyLCB3aXRoaW4gYW4gQVMgYW5kIGJldHdlZW4gYWRqYWNlbnQgQkdQIG5laWdoYm9y cywgQU5ZIHZhbHVlcyB3aWxsIGJlIGFsbG93ZWQuDQpUaGUgb25seSByZXF1aXJlbWVudCBpcyB0 aGF0IHNlbmRlciBhbmQgcmVjZWl2ZXIgaGF2ZSB0aGUgc2FtZSB1bmRlcnN0YW5kaW5nIG9mIHRo ZSBjb250ZW50cywNCmJ1dCBubyBSRkMgaXMgcmVxdWlyZWQgdG8gc2F5IHRoaXMuDQoNCkpha29i LA0KDQpJIHRoaW5rIHlvdSBzdGlsbCBkb24ndCB1bmRlcnN0YW5kIHRoZSBwdXJwb3NlIG9yIHRo ZSBtZWNoYW5pY3Mgb2YgY29tbXVuaXRpZXMsIGFzIHdoYXQgeW91IHNheSBtYWtlcyBhbG1vc3Qg bm8gc2Vuc2UuDQoNClRoZSByZWFzb24gImxhcmdlIiBuZWVkcyB0byBiZSBhbiBvcHRpb25hbCwg dHJhbnNpdGl2ZSBhdHRyaWJ1dGUsIGlzIHRoYXQgdGhlIGludGVuZGVkIHBhcnR5LCB3aG9zZSBB U04NCmlzIGluIHRoZSBHbG9iYWwgQWRtaW5pc3RyYXRvciBmaWVsZCwgaXMgbm90IG5lY2Vzc2Fy aWx5IHRoZSBmaXJzdCBvciBzZWNvbmQgcGFydHkgKHRoZSBvbmUgc2V0dGluZyB0aGUgY29tbXVu aXR5LA0Kb3IgdGhlIG9uZSB0aGF0IGlzIHRoZSBCR1AgcGVlciBvZiB0aGUgZmlyc3QgcGFydHkp Lg0KDQpUaGUgY29tbXVuaXR5IG1heSB0cmF2ZWwgYW4gYXJiaXRyYXJ5IG51bWJlciBvZiBBUyBo b3BzIGJlZm9yZSBpdCBpcyByZWNlaXZlZCBieSB0aGUgQVNOIGluIHF1ZXN0aW9uIChnbG9iYWwg YWRtaW4pLg0KVGhhdCBBU04gaXMgdGhlIG9uZSB3aG8gaXMgdGhlICh1bHRpbWF0ZSkgaW50ZW5k ZWQgcmVjaXBpZW50IChvZiB0aGUgY29tbXVuaXR5KSwgYW5kIHdob3NlIGludGVycHJldHMgdGhl IGxhdHRlciA4IG9jdGV0cw0Kb2YgdGhlIGNvbW11bml0eSwgdXNpbmcgd2hhdGV2ZXIgbG9naWMg aGUvc2hlIHdpc2hlcy4gKFRoZSBwcmVmaXggd2lsbCBwcm9iYWJseSBwcm9wYWdhdGUgbXVjaCBm dXJ0aGVyLCBidXQgd2UNCmFyZSBvbmx5IGNvbmNlcm5lZCBhYm91dCB0aGUgQVNOIHRoYXQgaXMg dGhlIGdsb2JhbCBhZG1pbmlzdHJhdG9yIG9mIHRoZSBjb21tdW5pdHkuKQ0KDQpUaGlzIGlzIE5P VCBsaW1pdGVkIHRvIHdpdGhpbiBhbiBBUywgbm9yIHRvIGFkamFjZW50IEJHUCBwZWVycy4NCg0K QXMgc3VjaCwgdGhlIGludGVybWVkaWF0ZSBBUyBob3BzIHdpbGwgcmVjZWl2ZSB0aGUgcHJlZml4 IHdpdGggdGhlIGF0dGFjaGVkIExhcmdlIENvbW11bml0eSwgYnV0IHdpbGwNCm5vdCBoYXZlIGFu eSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBjb250ZW50cy4gVGhleSBhcmUgZXhwZWN0ZWQgdG8gcGFz cyB0aGVtIGFsb25nLCBhcyB0aGlzIGlzIHRoZQ0KbmVjZXNzYXJ5IHBhcnQgb2YgY29tbXVuaXRp ZXMnIGZ1bmN0aW9uaW5nLg0KDQpBIC0+IFggLT4gWSAtPiBaIC0+IEIgYXJlIHRoZSBBdXRvbm9t b3VzIFN5c3RlbXMgcGFzc2luZyB0aGUgcHJlZml4Lg0KQSBzZXRzIHRoZSBjb21tdW5pdHkuIFRo ZSBjb21tdW5pdHkgaXMgQjpzb21ldGhpbmc6c29tZXRoaW5nLg0KQiBpbnRlcnByZXRzIHRoZSBj b21tdW5pdHkuDQpYLCBZLCBhbmQgWiwgcGFzcyBpdCBhbG9uZyB3aXRob3V0IGFjdGluZyBvbiBp dC4NCg0KSSdtIHNvcnJ5IHRvIHJhaXNlIGEgZnVzcywgYnV0IHNpbmNlIHlvdSBhcmUgaW52b2x2 ZWQgaW4gZWRpdGluZyB0aGUgSS1ELCBpdCB3b3VsZCBwdXQgbXkgbWluZCBhdCBlYXNlIHRvIGhl YXIgeW91IHNheQ0KdGhhdCB5b3UgdW5kZXJzdGFuZCB0aGUgYWJvdmUuDQoNClB1dHRpbmcgdGV4 dCBpbnRvIHRoaXMgZG9jdW1lbnQsIGlmIHlvdSBkb24ndCB1bmRlcnN0YW5kIHRoZSBhYm92ZSwg bWF5IGJlIGhhcm1mdWwgdG8gdGhlIGRvY3VtZW50LA0KYW5kIHRvIG9wZXJhdG9yIGZvbGtzIHdo byBhcmUgdHJ5aW5nIHRvIGdldCB0aGUgYnVncyBvdXQgb2YgdGhlIGRvY3VtZW50IGJlZm9yZSBp dCBhZHZhbmNlcy4NCg0KU2luY2VyZWx5LA0KQnJpYW4NCg0KDQpUaGFua3MsDQpKYWtvYi4NCg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElkciBbbWFpbHRvOmlkci1i b3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP ZiBKYWtvYiBIZWl0eiAoamhlaXR6KQ0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyMCwgMjAx NiA0OjA2IFBNDQo+IFRvOiBKb2IgU25pamRlcnMgPGpvYkBudHQubmV0PG1haWx0bzpqb2JAbnR0 Lm5ldD4+DQo+IENjOiBoZWFzbGV5IDxoZWFzQHNocnViYmVyeS5uZXQ8bWFpbHRvOmhlYXNAc2hy dWJiZXJ5Lm5ldD4+OyBTdWUgSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5k emguY29tPj47IElFVEYgSURSIFdHIDxpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+ DQo+IFN1YmplY3Q6IFJlOiBbSWRyXSBXRyBMQyBvbiBkcmFmdC1pZXRmLWlkci1sYXJnZS1jb21t dW5pdHktMDMudHh0ICgxMC8xNy8yMDE2IHRvIDEwLzMxLzIwMTYpDQo+DQo+IEV2aWRlbnRseSwg aXQgd2Fzbid0IGNsZWFyLiBOb3cgaXQgaXMuDQo+DQo+IFRoYW5rcywNCj4gSmFrb2IuDQo+DQo+ DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBKb2IgU25pamRlcnMg W21haWx0bzpqb2JAbnR0Lm5ldDxtYWlsdG86am9iQG50dC5uZXQ+XQ0KPiA+IFNlbnQ6IFRodXJz ZGF5LCBPY3RvYmVyIDIwLCAyMDE2IDM6NTAgUE0NCj4gPiBUbzogSmFrb2IgSGVpdHogKGpoZWl0 eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBjaXNjby5jb20+Pg0KPiA+IENjOiBK ZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3JnPG1haWx0bzpqaGFhc0BwZnJjLm9yZz4+OyBoZWFz bGV5IDxoZWFzQHNocnViYmVyeS5uZXQ8bWFpbHRvOmhlYXNAc2hydWJiZXJ5Lm5ldD4+OyBJRVRG IElEUiBXRyA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+PjsgU3VlIEhhcmVzDQo+ ID4gPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4NCj4gPiBTdWJqZWN0 OiBSZTogW0lkcl0gV0cgTEMgb24gZHJhZnQtaWV0Zi1pZHItbGFyZ2UtY29tbXVuaXR5LTAzLnR4 dCAoMTAvMTcvMjAxNiB0byAxMC8zMS8yMDE2KQ0KPiA+DQo+ID4gSGkgSmFrb2IsDQo+ID4NCj4g PiBJIGFtIG5vdCBzdXJlIHdoYXQgaXNzdWUgdGhpcyByZXBsYWNlbWVudCByZXNvbHZlcy4gV2l0 aCB0aGUgcmVwbGFjZW1lbnQNCj4gPiB0ZXh0IGluIHRoZSBkb2N1bWVudCBJIGZlZWwgSSBoYXZl IG1vcmUgcXVlc3Rpb25zIHRoYW4gYW5zd2Vycy4NCj4gPg0KPiA+IFVzdWFsbHkgYSBjb21tdW5p dHkgaXMgaW50ZW5kZWQgdG8gYmUgc2VudCB0byBvbmUgQVMgdG8gdHJpZ2dlciBhbg0KPiA+IGFj dGlvbiwgYW5kIHRvIG11bHRpcGxlIEFTZXMgaWYgdGhlIGNvbW11bml0eSBpcyBvZiBpbmZvcm1h dGl2ZSBuYXR1cmUuDQo+ID4gV2Uga25vdyB3ZSBjYW4gYXR0YWNoIG11bHRpcGxlIExhcmdlIEJH UCBDb21tdW5pdGllcyB0byBhIHJvdXRlLCBiZWNhdXNlDQo+ID4gb2YgdGhlIHZhcmlhYmxlIGxl bmd0aCBvZiB0aGUgYXR0cmlidXRlLg0KPiA+DQo+ID4gSW4gYW4gZWFybGllciByZXNwb25zZSBJ IHBvaW50ZWQgYXQgdGV4dCB0aGF0IGFkZHJlc3NlcyB0aGlzIHNwZWNpZmljDQo+ID4gZmVhdHVy ZSBhbHJlYWR5IGluIHRoZSBjdXJyZW50IHRleHQ6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvaWRyL19RVUxqSVVEYUJCNEpxRFI4SVh1SVlrQVZKdw0KPiA+DQo+ID4gS2lu ZCByZWdhcmRzLA0KPiA+DQo+ID4gSm9iDQo+ID4NCj4gPg0KPiA+IE9uIFRodSwgT2N0IDIwLCAy MDE2IGF0IDEwOjEzOjQxUE0gKzAwMDAsIEpha29iIEhlaXR6IChqaGVpdHopIHdyb3RlOg0KPiA+ ID4gSW4gYWRkaXRpb24sIHRvIGRlYWwgd2l0aCB0aGUgdmFsdWVzIGZvciB0aGUgR0EgZmllbGQs IHdlIHdpbGwgcmVwbGFjZQ0KPiA+ID4NCj4gPiA+ICAgIFRoZSBHbG9iYWwgQWRtaW5pc3RyYXRv ciBmaWVsZCBpcyBpbnRlbmRlZCB0byBhbGxvdyBkaWZmZXJlbnQNCj4gPiA+ICAgIEF1dG9ub21v dXMgU3lzdGVtcyB0byBkZWZpbmUgTGFyZ2UgQkdQIENvbW11bml0aWVzIHdpdGhvdXQgY29sbGlz aW9uLg0KPiA+ID4NCj4gPiA+IHdpdGgNCj4gPiA+DQo+ID4gPiAgIEEgTGFyZ2UgQ29tbXVuaXR5 IHRoYXQgaXMgaW50ZW5kZWQgdG8gYmUgc2VudCB0byBtdWx0aXBsZSBBU2VzDQo+ID4gPiAgIFNI T1VMRCBjb250YWluIGFuIEFTTiBpbiB0aGUgR2xvYmFsIEFkbWluaXN0cmF0b3IgZmllbGQuIFRo ZSBBU04NCj4gPiA+ICAgU0hPVUxEIGJlIG9uZSB0aGF0IGlzIGFzc2lnbmVkIHRvIHRoZSBlbnRp dHkgdGhhdCBkZWZpbmVzIHRoZQ0KPiA+ID4gICBtZWFuaW5nIG9mIHRoZSByZXN0IG9mIHRoZSBM YXJnZSBDb21tdW5pdHkuICBUaGlzIGFsbG93cyBhIHJvdXRlIHRvDQo+ID4gPiAgIGNhcnJ5IG11 bHRpcGxlIExhcmdlIENvbW11bml0aWVzLCB0aGUgbWVhbmluZyBvZiBlYWNoIGJlaW5nIGRlZmlu ZWQNCj4gPiA+ICAgYnkgZGlmZmVyZW50IGluZGVwZW5kZW50IGVudGl0aWVzLg0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJZHIgbWFpbGlu ZyBsaXN0DQo+IElkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3Jn PG1haWx0bzpJZHJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkcg0KDQo= --_000_dc81002a2d93480eb0aeec334b35b5c8XCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJMdWNpZGEgQ29uc29s ZSI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNCA1IDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5U ZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6Ikx1Y2lkYSBDb25zb2xl Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmOw0KCWNvbG9yOiM3MDMwQTA7DQoJZm9u dC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpu b25lIG5vbmU7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Ikx1Y2lkYSBDb25zb2xlIjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29s b3I6IzcwMzBBMCI+SSBkbyB1bmRlcnN0YW5kIHRoYXQgdGhlIGNvbW11bml0eSBtYXkgdHJhdmVs IHNldmVyYWwgQVMgaG9wcy48bzpwPjwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+VGhhdCdzIHdoeSBJIHdyb3Rl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWY7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7IEEgTGFyZ2UgQ29tbXVuaXR5IHRoYXQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyBpcyA8Yj48c3BhbiBzdHlsZT0iY29s b3I6cmVkIj5pbnRlbmRlZCB0byBiZSBzZW50IHRvIG11bHRpcGxlIEFTZXM8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJjb2xvcjpyZWQiPg0KPC9zcGFuPlNIT1VMRCBjb250YWluIGFuIEFTTjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7IGluIHRoZSBHbG9iYWwg QWRtaW5pc3RyYXRvciBmaWVsZC4gVGhlIEFTTiBTSE9VTEQgYmUgb25lIHRoYXQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyBpcyBhc3NpZ25lZCB0byB0aGUg ZW50aXR5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgdGhh dCBkZWZpbmVzIHRoZSBtZWFuaW5nIG9mIHRoZSByZXN0IG9mIHRoZSBMYXJnZSBDb21tdW5pdHku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xv cjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5JIGFsc28gdW5kZXJzdGFuZCB0aGF0 IHRoaXMgaXMgbm90IHRoZSBvbmx5IGNhc2UgYW5kIHRoYXQgY29tbXVuaXRpZXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjoj NzAzMEEwIj5hcmUgb2Z0ZW4gdXNlZCB3aXRoaW4gYW4gQVMgb25seS4gV2UgTVVTVCBOT1QgcmVz dHJpY3QgdGhhdCB1c2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+ QWxzbywgZXZlbiB0aG91Z2ggQVMgQiBkZWZpbmVzIHRoZSBjb21tdW5pdHkgdGhhdCBoYXMgR0E9 QiwgQVMgQjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPmlzIG5vdCBhbHdheXMgdGhlIGludGVuZGVkIHJlY2lw aWVudC4gTWFueSBJU1BzIHVzZSBjb21tdW5pdGllczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPnRvIHNpZ25h bCBwcm9wZXJ0aWVzIG9mIHJvdXRlcyB0aGF0IHRoZXkgc2VuZCB0byB0aGVpciBjdXN0b21lcnMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWY7Y29sb3I6IzcwMzBBMCI+SW4gdGhhdCBjYXNlLCBBUyBCIGlzIHRoZSBzZW5kZXIsIG5vdCB0 aGUgcmVjaXBpZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkkg d3JvdGUgJnF1b3Q7ZW50aXR5JnF1b3Q7IGFuZCBub3QgJnF1b3Q7QVMmcXVvdDssIGJlY2F1c2Ug c29tZW9uZSBtYXkgY3JlYXRlIG9ubHkgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPnNpbmdsZSBCR1AgQVMs IGJ1dCBiZSBhc3NpZ25lZCBtYW55IEFTTnMuIFRoYXQgc29tZW9uZSBpcyBlbnRpdGxlZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2Nv bG9yOiM3MDMwQTAiPnRvIHVzZSBhbnkgb2YgaGVyIGFzc2lnbmVkIEFTTnMsIG5vdCBqdXN0IHRo ZSBvbmUgaW4gdXNlIGJ5IGhlciBBUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjoj NzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBD b25zb2xlJnF1b3Q7O2NvbG9yOiM3MDMwQTAiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOiM3MDMwQTAiPkpha29iLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gQnJpYW4gRGlja3NvbiBbbWFpbHRvOmJyaWFuLnBldGVyLmRpY2tzb25AZ21haWwu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBPY3RvYmVyIDIwLCAyMDE2IDU6Mjgg UE08YnI+DQo8Yj5Ubzo8L2I+IEpha29iIEhlaXR6IChqaGVpdHopICZsdDtqaGVpdHpAY2lzY28u Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSm9iIFNuaWpkZXJzICZsdDtqb2JAbnR0Lm5ldCZndDs7 IGhlYXNsZXkgJmx0O2hlYXNAc2hydWJiZXJ5Lm5ldCZndDs7IElFVEYgSURSIFdHICZsdDtpZHJA aWV0Zi5vcmcmZ3Q7OyBTdWUgSGFyZXMgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtJZHJdIFdHIExDIG9uIGRyYWZ0LWlldGYtaWRyLWxhcmdlLWNvbW11 bml0eS0wMy50eHQgKDEwLzE3LzIwMTYgdG8gMTAvMzEvMjAxNik8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBPY3QgMjAsIDIwMTYgYXQgNDo0NiBQTSwg SmFrb2IgSGVpdHogKGpoZWl0eikgJmx0OzxhIGhyZWY9Im1haWx0bzpqaGVpdHpAY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+amhlaXR6QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+UGVyaGFwcywgd2Ugc2hvdWxkIGFkZCBpbiBhbiBvcGVyYXRpb25zIHNl Y3Rpb24gdGhhdCB3ZSBzaG91bGQgbm90IGFuZCB3aWxsIG5vdCBnbyBhbnkgZnVydGhlci48YnI+ DQpJbiBwYXJ0aWN1bGFyLCB3aXRoaW4gYW4gQVMgYW5kIGJldHdlZW4gYWRqYWNlbnQgQkdQIG5l aWdoYm9ycywgQU5ZIHZhbHVlcyB3aWxsIGJlIGFsbG93ZWQuPGJyPg0KVGhlIG9ubHkgcmVxdWly ZW1lbnQgaXMgdGhhdCBzZW5kZXIgYW5kIHJlY2VpdmVyIGhhdmUgdGhlIHNhbWUgdW5kZXJzdGFu ZGluZyBvZiB0aGUgY29udGVudHMsPGJyPg0KYnV0IG5vIFJGQyBpcyByZXF1aXJlZCB0byBzYXkg dGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkpha29iLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHRoaW5rIHlvdSBzdGlsbCBkb24ndCB1bmRlcnN0YW5kIHRoZSBwdXJw b3NlIG9yIHRoZSBtZWNoYW5pY3Mgb2YgY29tbXVuaXRpZXMsIGFzIHdoYXQgeW91IHNheSBtYWtl cyBhbG1vc3Qgbm8gc2Vuc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSByZWFzb24gJnF1b3Q7bGFyZ2UmcXVvdDsgbmVlZHMgdG8gYmUg YW4gb3B0aW9uYWwsIHRyYW5zaXRpdmUgYXR0cmlidXRlLCBpcyB0aGF0IHRoZSBpbnRlbmRlZCBw YXJ0eSwgd2hvc2UgQVNOPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5pcyBpbiB0aGUgR2xvYmFsIEFkbWluaXN0cmF0b3IgZmllbGQsIGlzIG5vdCBu ZWNlc3NhcmlseSB0aGUgZmlyc3Qgb3Igc2Vjb25kIHBhcnR5ICh0aGUgb25lIHNldHRpbmcgdGhl IGNvbW11bml0eSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPm9yIHRoZSBvbmUgdGhhdCBpcyB0aGUgQkdQIHBlZXIgb2YgdGhlIGZpcnN0IHBhcnR5 KS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIGNvbW11bml0eSBtYXkgdHJhdmVsIGFuIGFyYml0cmFyeSBudW1iZXIgb2YgQVMg aG9wcyBiZWZvcmUgaXQgaXMgcmVjZWl2ZWQgYnkgdGhlIEFTTiBpbiBxdWVzdGlvbiAoZ2xvYmFs IGFkbWluKS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYXQgQVNOIGlzIHRoZSBvbmUgd2hvIGlzIHRoZSAodWx0aW1hdGUpIGludGVu ZGVkIHJlY2lwaWVudCAob2YgdGhlIGNvbW11bml0eSksIGFuZCB3aG9zZSBpbnRlcnByZXRzIHRo ZSBsYXR0ZXIgOCBvY3RldHMmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPm9mIHRoZSBjb21tdW5pdHksIHVzaW5nIHdoYXRldmVyIGxvZ2lj IGhlL3NoZSB3aXNoZXMuIChUaGUgcHJlZml4IHdpbGwgcHJvYmFibHkgcHJvcGFnYXRlIG11Y2gg ZnVydGhlciwgYnV0IHdlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5hcmUgb25seSBjb25jZXJuZWQgYWJvdXQgdGhlIEFTTiB0aGF0IGlzIHRoZSBn bG9iYWwgYWRtaW5pc3RyYXRvciBvZiB0aGUgY29tbXVuaXR5Lik8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBOT1QgbGltaXRlZCB0 byB3aXRoaW4gYW4gQVMsIG5vciB0byBhZGphY2VudCBCR1AgcGVlcnMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIHN1Y2gsIHRoZSBpbnRl cm1lZGlhdGUgQVMgaG9wcyB3aWxsIHJlY2VpdmUgdGhlIHByZWZpeCB3aXRoIHRoZSBhdHRhY2hl ZCBMYXJnZSBDb21tdW5pdHksIGJ1dCB3aWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ub3QgaGF2ZSBhbnkgdW5kZXJzdGFuZGluZyBvZiB0aGUg Y29udGVudHMuIFRoZXkgYXJlIGV4cGVjdGVkIHRvIHBhc3MgdGhlbSBhbG9uZywgYXMgdGhpcyBp cyB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pm5lY2Vzc2FyeSBwYXJ0IG9mIGNvbW11bml0aWVzJyBmdW5jdGlvbmluZy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSAtJmd0OyBYIC0mZ3Q7 IFkgLSZndDsgWiAtJmd0OyBCIGFyZSB0aGUgQXV0b25vbW91cyBTeXN0ZW1zIHBhc3NpbmcgdGhl IHByZWZpeC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkEgc2V0cyB0aGUgY29tbXVuaXR5LiBUaGUgY29tbXVuaXR5IGlzIEI6c29tZXRoaW5nOnNv bWV0aGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkIgaW50ZXJwcmV0cyB0aGUgY29tbXVuaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WCwgWSwgYW5kIFosIHBhc3MgaXQgYWxvbmcgd2l0 aG91dCBhY3Rpbmcgb24gaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkknbSBzb3JyeSB0byByYWlzZSBhIGZ1c3MsIGJ1dCBzaW5jZSB5b3Ug YXJlIGludm9sdmVkIGluIGVkaXRpbmcgdGhlIEktRCwgaXQgd291bGQgcHV0IG15IG1pbmQgYXQg ZWFzZSB0byBoZWFyIHlvdSBzYXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnRoYXQgeW91IHVuZGVyc3RhbmQgdGhlIGFib3ZlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QdXR0aW5nIHRleHQg aW50byB0aGlzIGRvY3VtZW50LCBpZiB5b3UgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgYWJvdmUsIG1h eSBiZSBoYXJtZnVsIHRvIHRoZSBkb2N1bWVudCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCB0byBvcGVyYXRvciBmb2xrcyB3aG8gYXJlIHRy eWluZyB0byBnZXQgdGhlIGJ1Z3Mgb3V0IG9mIHRoZSBkb2N1bWVudCBiZWZvcmUgaXQgYWR2YW5j ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlNpbmNlcmVseSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkJyaWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxicj4NCkpha29iLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBJZHIgW21haWx0bzo8YSBocmVmPSJt YWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmciPmlkci1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24g QmVoYWxmIE9mIEpha29iIEhlaXR6IChqaGVpdHopPGJyPg0KJmd0OyBTZW50OiBUaHVyc2RheSwg T2N0b2JlciAyMCwgMjAxNiA0OjA2IFBNPGJyPg0KJmd0OyBUbzogSm9iIFNuaWpkZXJzICZsdDs8 YSBocmVmPSJtYWlsdG86am9iQG50dC5uZXQiPmpvYkBudHQubmV0PC9hPiZndDs8YnI+DQomZ3Q7 IENjOiBoZWFzbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86aGVhc0BzaHJ1YmJlcnkubmV0Ij5oZWFz QHNocnViYmVyeS5uZXQ8L2E+Jmd0OzsgU3VlIEhhcmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hh cmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0OzsgSUVURiBJRFIgV0cgJmx0Ozxh IGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0 OyBTdWJqZWN0OiBSZTogW0lkcl0gV0cgTEMgb24gZHJhZnQtaWV0Zi1pZHItbGFyZ2UtY29tbXVu aXR5LTAzLnR4dCAoMTAvMTcvMjAxNiB0byAxMC8zMS8yMDE2KTxicj4NCiZndDs8YnI+DQomZ3Q7 IEV2aWRlbnRseSwgaXQgd2Fzbid0IGNsZWFyLiBOb3cgaXQgaXMuPGJyPg0KJmd0Ozxicj4NCiZn dDsgVGhhbmtzLDxicj4NCiZndDsgSmFrb2IuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJvbTogSm9i IFNuaWpkZXJzIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmpvYkBudHQubmV0Ij5qb2JAbnR0Lm5l dDwvYT5dPGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDIwLCAyMDE2IDM6 NTAgUE08YnI+DQomZ3Q7ICZndDsgVG86IEpha29iIEhlaXR6IChqaGVpdHopICZsdDs8YSBocmVm PSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSI+amhlaXR6QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IENjOiBKZWZmcmV5IEhhYXMgJmx0OzxhIGhyZWY9Im1haWx0bzpqaGFhc0BwZnJj Lm9yZyI+amhhYXNAcGZyYy5vcmc8L2E+Jmd0OzsgaGVhc2xleSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmhlYXNAc2hydWJiZXJ5Lm5ldCI+aGVhc0BzaHJ1YmJlcnkubmV0PC9hPiZndDs7IElFVEYgSURS IFdHICZsdDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0 OzsgU3VlIEhhcmVzPGJyPg0KJmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5k emguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBS ZTogW0lkcl0gV0cgTEMgb24gZHJhZnQtaWV0Zi1pZHItbGFyZ2UtY29tbXVuaXR5LTAzLnR4dCAo MTAvMTcvMjAxNiB0byAxMC8zMS8yMDE2KTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBI aSBKYWtvYiw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSBhbSBub3Qgc3VyZSB3aGF0 IGlzc3VlIHRoaXMgcmVwbGFjZW1lbnQgcmVzb2x2ZXMuIFdpdGggdGhlIHJlcGxhY2VtZW50PGJy Pg0KJmd0OyAmZ3Q7IHRleHQgaW4gdGhlIGRvY3VtZW50IEkgZmVlbCBJIGhhdmUgbW9yZSBxdWVz dGlvbnMgdGhhbiBhbnN3ZXJzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBVc3VhbGx5 IGEgY29tbXVuaXR5IGlzIGludGVuZGVkIHRvIGJlIHNlbnQgdG8gb25lIEFTIHRvIHRyaWdnZXIg YW48YnI+DQomZ3Q7ICZndDsgYWN0aW9uLCBhbmQgdG8gbXVsdGlwbGUgQVNlcyBpZiB0aGUgY29t bXVuaXR5IGlzIG9mIGluZm9ybWF0aXZlIG5hdHVyZS48YnI+DQomZ3Q7ICZndDsgV2Uga25vdyB3 ZSBjYW4gYXR0YWNoIG11bHRpcGxlIExhcmdlIEJHUCBDb21tdW5pdGllcyB0byBhIHJvdXRlLCBi ZWNhdXNlPGJyPg0KJmd0OyAmZ3Q7IG9mIHRoZSB2YXJpYWJsZSBsZW5ndGggb2YgdGhlIGF0dHJp YnV0ZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSW4gYW4gZWFybGllciByZXNwb25z ZSBJIHBvaW50ZWQgYXQgdGV4dCB0aGF0IGFkZHJlc3NlcyB0aGlzIHNwZWNpZmljPGJyPg0KJmd0 OyAmZ3Q7IGZlYXR1cmUgYWxyZWFkeSBpbiB0aGUgY3VycmVudCB0ZXh0OiA8YSBocmVmPSJodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lkci9fUVVMaklVRGFCQjRKcURSOElY dUlZa0FWSnciIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvaWRyL19RVUxqSVVEYUJCNEpxRFI4SVh1SVlrQVZKdzwvYT48YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgS2luZCByZWdhcmRzLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBKb2I8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT24g VGh1LCBPY3QgMjAsIDIwMTYgYXQgMTA6MTM6NDFQTSAmIzQzOzAwMDAsIEpha29iIEhlaXR6IChq aGVpdHopIHdyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7IEluIGFkZGl0aW9uLCB0byBkZWFsIHdp dGggdGhlIHZhbHVlcyBmb3IgdGhlIEdBIGZpZWxkLCB3ZSB3aWxsIHJlcGxhY2U8YnI+DQomZ3Q7 ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBUaGUgR2xvYmFsIEFk bWluaXN0cmF0b3IgZmllbGQgaXMgaW50ZW5kZWQgdG8gYWxsb3cgZGlmZmVyZW50PGJyPg0KJmd0 OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IEF1dG9ub21vdXMgU3lzdGVtcyB0byBkZWZpbmUgTGFy Z2UgQkdQIENvbW11bml0aWVzIHdpdGhvdXQgY29sbGlzaW9uLjxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgd2l0aDxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsmbmJzcDsgJm5ic3A7QSBMYXJnZSBDb21tdW5pdHkgdGhhdCBpcyBpbnRlbmRlZCB0 byBiZSBzZW50IHRvIG11bHRpcGxlIEFTZXM8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJz cDtTSE9VTEQgY29udGFpbiBhbiBBU04gaW4gdGhlIEdsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxk LiBUaGUgQVNOPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7U0hPVUxEIGJlIG9uZSB0 aGF0IGlzIGFzc2lnbmVkIHRvIHRoZSBlbnRpdHkgdGhhdCBkZWZpbmVzIHRoZTxicj4NCiZndDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO21lYW5pbmcgb2YgdGhlIHJlc3Qgb2YgdGhlIExhcmdlIENv bW11bml0eS4mbmJzcDsgVGhpcyBhbGxvd3MgYSByb3V0ZSB0bzxicj4NCiZndDsgJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwO2NhcnJ5IG11bHRpcGxlIExhcmdlIENvbW11bml0aWVzLCB0aGUgbWVhbmlu ZyBvZiBlYWNoIGJlaW5nIGRlZmluZWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDti eSBkaWZmZXJlbnQgaW5kZXBlbmRlbnQgZW50aXRpZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IElk ciBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpJZHJAaWV0Zi5vcmciPklk ckBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWRyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZHI8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZHIgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOklkckBpZXRmLm9yZyI+SWRyQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHI8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_dc81002a2d93480eb0aeec334b35b5c8XCHALN014ciscocom_-- From nobody Thu Oct 20 18:48:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659A01294B1 for ; Thu, 20 Oct 2016 18:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 U3vnpRF_lNA4 for ; Thu, 20 Oct 2016 18:48:45 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE14F1293F2 for ; Thu, 20 Oct 2016 18:48:44 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id l131so110926615lfl.2 for ; Thu, 20 Oct 2016 18:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yx2fceWQ1/wLLn1kcQ644YhUOeciGkFdZ8q+8/EO2ig=; b=wllyWJAGfeQeRk1HOpCV80JdMpyOb4WeR+jVzXKireOY0RM+sePlVANNWTliKtObzS r1I/C/sJ//YtlXpZkJV6pUF1FwPl4ei6/O5QUnU779V6urnjxy1hBbYENFbcmLjBpVse t9iNRQzlrWvI9EmbA5kX6HM1lKukyMn9zXW0jQXAACBi/HN5K7R/ZfEQ4ajrYrNVE6DP FXym9uHt6+j/F4ViB7sWncoubfZSmOrLZTMYQ2CxSeitzrJqgPKPpM3HjvDOARGZOAxN PLRC60aLtaY1cPEtctQ/w3KMryDIn88indlkFqu7hFkPFIkD4pSdeYdkhWMuUPSM3yUB vQIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yx2fceWQ1/wLLn1kcQ644YhUOeciGkFdZ8q+8/EO2ig=; b=O+HLohiWSzkMyncQiHL7C3XdNcwLx7S6wpiQYm3E/WLDKfd7kcJUKX4rTYCidqhV5O qbS7q7TzmRhYkRElDEUz+GKZit70F78ij4G1OmN08qDprvV+utRye2RJMbyfH/9RZ//1 rDU299oUUArFXWbJC04RHczoYhw8uU9Gz+9sO6pkaBL/wGwwxRAwxUoZcDffAspksEhW SpnyqbdMvz3jDR3NeHlLPfqqjojdb5PlxNcEvLccgmR/OdEZL0GCNtyZM6rsT/8FVFqT 3ezFfqcVpenpxKdKLzykxTtif6gmaM9HWQWpyJjdDww0FJpn9YBjUHuqxMsIP4TUETzM VNaA== X-Gm-Message-State: AA6/9RndjdCPQlXwTeR9FUOcJKSs0i+cpchy0jjBbEBrsu+DANDukI3TYWyfEaklbUgHHNW3fFEuoDMsXvMvAA== X-Received: by 10.28.222.70 with SMTP id v67mr692787wmg.84.1477014523044; Thu, 20 Oct 2016 18:48:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.207 with HTTP; Thu, 20 Oct 2016 18:48:41 -0700 (PDT) In-Reply-To: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161020225004.GG1074@Vurt.local> <2894c1eb263143cc8129ec8e381957dc@XCH-ALN-014.cisco.com> From: Brian Dickson Date: Thu, 20 Oct 2016 18:48:41 -0700 Message-ID: To: "Jakob Heitz (jheitz)" Content-Type: multipart/alternative; boundary=001a114b103cf96871053f563df7 Archived-At: Cc: heasley , IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 01:48:48 -0000 --001a114b103cf96871053f563df7 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 20, 2016 at 5:46 PM, Jakob Heitz (jheitz) wrote: > I do understand that the community may travel several AS hops. > > That's why I wrote > > > > A Large Community that > > is *intended to be sent to multiple ASes* SHOULD contain an ASN > > in the Global Administrator field. The ASN SHOULD be one that > > is assigned to the entity > > that defines the meaning of the rest of the Large Community. > > > > I also understand that this is not the only case and that communities > > are often used within an AS only. We MUST NOT restrict that use. > > > Agreed. I think the tweak to your wording along the lines of: "...within an AS and across AS boundaries, ANY values will be allowed." That removes the notion of adjacent, as well as whether B is sender or recipient. Entity is fine. Thanks, Brian > Also, even though AS B defines the community that has GA=B, AS B > > is not always the intended recipient. Many ISPs use communities > > to signal properties of routes that they send to their customers. > > In that case, AS B is the sender, not the recipient. > > > > I wrote "entity" and not "AS", because someone may create only a > > single BGP AS, but be assigned many ASNs. That someone is entitled > > to use any of her assigned ASNs, not just the one in use by her AS. > > > > > > Thanks, > > Jakob. > > > > *From:* Brian Dickson [mailto:brian.peter.dickson@gmail.com] > *Sent:* Thursday, October 20, 2016 5:28 PM > *To:* Jakob Heitz (jheitz) > *Cc:* Job Snijders ; heasley ; IETF IDR > WG ; Sue Hares > > *Subject:* Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt > (10/17/2016 to 10/31/2016) > > > > > > > > On Thu, Oct 20, 2016 at 4:46 PM, Jakob Heitz (jheitz) > wrote: > > Perhaps, we should add in an operations section that we should not and > will not go any further. > In particular, within an AS and between adjacent BGP neighbors, ANY values > will be allowed. > The only requirement is that sender and receiver have the same > understanding of the contents, > but no RFC is required to say this. > > > > Jakob, > > > > I think you still don't understand the purpose or the mechanics of > communities, as what you say makes almost no sense. > > > > The reason "large" needs to be an optional, transitive attribute, is that > the intended party, whose ASN > > is in the Global Administrator field, is not necessarily the first or > second party (the one setting the community, > > or the one that is the BGP peer of the first party). > > > > The community may travel an arbitrary number of AS hops before it is > received by the ASN in question (global admin). > > That ASN is the one who is the (ultimate) intended recipient (of the > community), and whose interprets the latter 8 octets > > of the community, using whatever logic he/she wishes. (The prefix will > probably propagate much further, but we > > are only concerned about the ASN that is the global administrator of the > community.) > > > > This is NOT limited to within an AS, nor to adjacent BGP peers. > > > > As such, the intermediate AS hops will receive the prefix with the > attached Large Community, but will > > not have any understanding of the contents. They are expected to pass them > along, as this is the > > necessary part of communities' functioning. > > > > A -> X -> Y -> Z -> B are the Autonomous Systems passing the prefix. > > A sets the community. The community is B:something:something. > > B interprets the community. > > X, Y, and Z, pass it along without acting on it. > > > > I'm sorry to raise a fuss, but since you are involved in editing the I-D, > it would put my mind at ease to hear you say > > that you understand the above. > > > > Putting text into this document, if you don't understand the above, may be > harmful to the document, > > and to operator folks who are trying to get the bugs out of the document > before it advances. > > > > Sincerely, > > Brian > > > > > > Thanks, > Jakob. > > > > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz > (jheitz) > > Sent: Thursday, October 20, 2016 4:06 PM > > To: Job Snijders > > Cc: heasley ; Sue Hares ; IETF IDR > WG > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt > (10/17/2016 to 10/31/2016) > > > > Evidently, it wasn't clear. Now it is. > > > > Thanks, > > Jakob. > > > > > > > -----Original Message----- > > > From: Job Snijders [mailto:job@ntt.net] > > > Sent: Thursday, October 20, 2016 3:50 PM > > > To: Jakob Heitz (jheitz) > > > Cc: Jeffrey Haas ; heasley ; IETF > IDR WG ; Sue Hares > > > > > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt > (10/17/2016 to 10/31/2016) > > > > > > Hi Jakob, > > > > > > I am not sure what issue this replacement resolves. With the > replacement > > > text in the document I feel I have more questions than answers. > > > > > > Usually a community is intended to be sent to one AS to trigger an > > > action, and to multiple ASes if the community is of informative nature. > > > We know we can attach multiple Large BGP Communities to a route, > because > > > of the variable length of the attribute. > > > > > > In an earlier response I pointed at text that addresses this specific > > > feature already in the current text: https://mailarchive.ietf.org/ > arch/msg/idr/_QULjIUDaBB4JqDR8IXuIYkAVJw > > > > > > Kind regards, > > > > > > Job > > > > > > > > > On Thu, Oct 20, 2016 at 10:13:41PM +0000, Jakob Heitz (jheitz) wrote: > > > > In addition, to deal with the values for the GA field, we will > replace > > > > > > > > The Global Administrator field is intended to allow different > > > > Autonomous Systems to define Large BGP Communities without > collision. > > > > > > > > with > > > > > > > > A Large Community that is intended to be sent to multiple ASes > > > > SHOULD contain an ASN in the Global Administrator field. The ASN > > > > SHOULD be one that is assigned to the entity that defines the > > > > meaning of the rest of the Large Community. This allows a route to > > > > carry multiple Large Communities, the meaning of each being defined > > > > by different independent entities. > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > --001a114b103cf96871053f563df7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 20, 2016 at 5:46 PM, Jakob Heitz (jheitz) <jheitz@cisco.com= > wrote:

I do understand that the community may travel several AS hops.<= u>

That's why I wrote

=C2=A0

=C2=A0 A Large Community tha= t

=C2=A0 is intended to be sent to multiple ASes SHOULD contain an ASN

=C2=A0 in the Global Adminis= trator field. The ASN SHOULD be one that

=C2=A0 is assigned to the en= tity

=C2=A0 that defines the mean= ing of the rest of the Large Community.

=C2=A0

I also understand that this is = not the only case and that communities

are often used within an AS only. We M= UST NOT restrict that use.

=C2=A0


Agreed.

I think the= tweak to your wording along the lines of:
"...within an AS = and across AS boundaries, ANY values will be allowed."
That = removes the notion of adjacent, as well as whether B is sender or recipient= .

Entity is fine.

Thanks,=
Brian
=C2=A0

Also, even though AS B defines the com= munity that has GA=3DB, AS B

is not always the intended recipient. = Many ISPs use communities

to signal properties of routes that th= ey send to their customers.

In that case, AS B is the sender, not = the recipient.

=C2=A0

I wrote "entity" and not &qu= ot;AS", because someone may create only a

single BGP AS, but be assigned many AS= Ns. That someone is entitled

to use any of her assigned ASNs, not j= ust the one in use by her AS.

=C2=A0

=C2=A0

Thanks,

Jakob.

=C2=A0

From: Brian Dickson [mailto:brian.peter.dic= kson@gmail.com]
Sent: Thursday, October 20, 2016 5:28 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: Job Snijders <job@ntt.net>; heasley <heas@shrubbery.net>; IETF IDR WG <idr@ietf.org>; Sue Hares = <shares@ndzh.com>

=C2=A0

=C2=A0

=C2=A0

On Thu, Oct 20, 2016 at 4:46 PM, Jakob Heitz (jheitz= ) <jheitz@cisco.co= m> wrote:

Perhaps, we should ad= d in an operations section that we should not and will not go any further.<= br> In particular, within an AS and between adjacent BGP neighbors, ANY values = will be allowed.
The only requirement is that sender and receiver have the same understandin= g of the contents,
but no RFC is required to say this.

=C2=A0

Jakob,

=C2=A0

I think you still don't understand the purpose o= r the mechanics of communities, as what you say makes almost no sense.

=C2=A0

The reason "large" needs to be an optional= , transitive attribute, is that the intended party, whose ASN=

is in the Global Administrator field, is not necessa= rily the first or second party (the one setting the community,

or the one that is the BGP peer of the first party).= =C2=A0

=C2=A0

The community may travel an arbitrary number of AS h= ops before it is received by the ASN in question (global admin).=C2=A0

That ASN is the one who is the (ultimate) intended r= ecipient (of the community), and whose interprets the latter 8 octets=C2=A0=

of the community, using whatever logic he/she wishes= . (The prefix will probably propagate much further, but we

are only concerned about the ASN that is the global = administrator of the community.)

=C2=A0

This is NOT limited to within an AS, nor to adjacent= BGP peers.

=C2=A0

As such, the intermediate AS hops will receive the p= refix with the attached Large Community, but will

not have any understanding of the contents. They are= expected to pass them along, as this is the

necessary part of communities' functioning.

=C2=A0

A -> X -> Y -> Z -> B are the Autonomous= Systems passing the prefix.

A sets the community. The community is B:something:s= omething.

B interprets the community.

X, Y, and Z, pass it along without acting on it.<= /u>

=C2=A0

I'm sorry to raise a fuss, but since you are inv= olved in editing the I-D, it would put my mind at ease to hear you say

that you understand the above.

=C2=A0

Putting text into this document, if you don't un= derstand the above, may be harmful to the document,

and to operator folks who are trying to get the bugs= out of the document before it advances.

=C2=A0

Sincerely,

Brian

=C2=A0

=C2=A0

Thanks,
Jakob.



> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz)
> Sent: Thursday, October 20, 2016 4:06 PM
> To: Job Snijders <= job@ntt.net>
> Cc: heasley <heas@shrubbery.net>; Sue Hares <shares@ndzh.com>; IETF IDR WG <idr@ietf.org>
> Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt= (10/17/2016 to 10/31/2016)
>
> Evidently, it wasn't clear. Now it is.
>
> Thanks,
> Jakob.
>
>
> > -----Original Message-----
> > From: Job Snijders [mailto:job@ntt.net]
> > Sent: Thursday, October 20, 2016 3:50 PM
> > To: Jakob Heitz (jheitz) <jheitz@cisco.com>
> > Cc: Jeffrey Haas <jhaas@pfrc.org>; heasley <heas@shrubbery.net>; IETF IDR WG <idr@ietf.org>; Sue Hares=
> > <shares@n= dzh.com>
> > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-0= 3.txt (10/17/2016 to 10/31/2016)
> >
> > Hi Jakob,
> >
> > I am not sure what issue this replacement resolves. With the repl= acement
> > text in the document I feel I have more questions than answers. > >
> > Usually a community is intended to be sent to one AS to trigger a= n
> > action, and to multiple ASes if the community is of informative n= ature.
> > We know we can attach multiple Large BGP Communities to a route, = because
> > of the variable length of the attribute.
> >
> > In an earlier response I pointed at text that addresses this spec= ific
> > feature already in the current text: https://mailarchive.ietf.org/arch/msg/idr/_QULjIUDaBB4JqDR8IXuIYk= AVJw
> >
> > Kind regards,
> >
> > Job
> >
> >
> > On Thu, Oct 20, 2016 at 10:13:41PM +0000, Jakob Heitz (jheitz) wr= ote:
> > > In addition, to deal with the values for the GA field, we wi= ll replace
> > >
> > >=C2=A0 =C2=A0 The Global Administrator field is intended to a= llow different
> > >=C2=A0 =C2=A0 Autonomous Systems to define Large BGP Communit= ies without collision.
> > >
> > > with
> > >
> > >=C2=A0 =C2=A0A Large Community that is intended to be sent to= multiple ASes
> > >=C2=A0 =C2=A0SHOULD contain an ASN in the Global Administrato= r field. The ASN
> > >=C2=A0 =C2=A0SHOULD be one that is assigned to the entity tha= t defines the
> > >=C2=A0 =C2=A0meaning of the rest of the Large Community.=C2= =A0 This allows a route to
> > >=C2=A0 =C2=A0carry multiple Large Communities, the meaning of= each being defined
> > >=C2=A0 =C2=A0by different independent entities.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

=C2=A0


--001a114b103cf96871053f563df7-- From nobody Thu Oct 20 22:23:46 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C781294EA for ; Thu, 20 Oct 2016 22:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 arAiN0gQsl8r for ; Thu, 20 Oct 2016 22:23:43 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D448129483 for ; Thu, 20 Oct 2016 22:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1633; q=dns/txt; s=iport; t=1477027423; x=1478237023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/qdYp567B0YjtW0Ac5TEz2d7cR3XivWVjNa1tgOoUvY=; b=GQ5lxPstUz6f5mcM4q0NqX3Hpe2Dw8BQoctof/V5cShKe+2II8mx3W0b VN6hoEfClAXE+nQ4a5+m2/NHqAeta8psF93NDDRAJ9Y9/nQVgE3UEcr0E /GWhjRWoKFfJ4gZTztx71MM8/60jAHIOiGdC1bXqTLSDrf84X9rKRV/YM Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B8AQAepglY/4kNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgz4BAQEBAR1XfY00lnyUPoIHHAuCRIM2AoF2PxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?iAQEBAwEBAQE3NAsFCwIBCA4KHhAnCyUCBA4FFIg2CA7DLgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARcFhj2BfQiCUIQZEQEcgzCCLwWIR5FLAZAMj32NAYN/AR42WYN?= =?us-ascii?q?GgTpyhiiCIAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,374,1473120000"; d="scan'208";a="338358808" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2016 05:23:40 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u9L5NeEn019234 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Oct 2016 05:23:40 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Oct 2016 00:23:39 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 21 Oct 2016 00:23:40 -0500 From: "Jakob Heitz (jheitz)" To: Mikael Abrahamsson Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) Thread-Index: AdIotF10Qx6LizvwQ9uItB9ryESdDgANiv0AACybzYAAADoegAAC4vMAABNp+sQAGz+KgAAB1DGAAAWtwoAAAEbugP//uo5zgABbxgCAAGZngIABM2it Date: Fri, 21 Oct 2016 05:23:40 +0000 Message-ID: <3CFE82FB-8A77-46E4-8459-C428E9B93BD6@cisco.com> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <5807F3AF.9080200@foobar.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 05:23:45 -0000 This is a matter for your vendor documentation. In the case of IOS-XR, the router software acts upon the well-known communi= ties. For example, no-export is acted upon before the neighbor outbound pol= icy is run. Thanks, Jakob. > On Oct 19, 2016, at 11:03 PM, Mikael Abrahamsson wrote= : >=20 >> On Wed, 19 Oct 2016, Brian Dickson wrote: >>=20 >> Yes, the implementation should still "allow any value". >=20 > When I have created BGP route policies, I've several times asked myself t= he question "what will the vendor implementation do itself, and what do I n= eed to do in my policy". >=20 > So for instance, do I need to implement the well-knowns myself, or is tha= t something that I need to do in my policy? If I for operational reasons wa= nt the router to not do something (for instance I do want NO-EXPORT to trav= erse AS boundary), how do I do that? >=20 > I think here in the IETF we should always consider to have separate docum= ents for what goes on the wire (compatibility reasons), and what the implem= entation should do with this information by default in case the user also c= an set policy. >=20 > The contents of the -large- fields and whether the implementation should = check if this is true is a typical thing that the "wire" document should no= t over-specify. That should instead be an operational document, and that sh= ould involve GROW as well. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Oct 21 03:57:04 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB4812970F for ; Fri, 21 Oct 2016 03:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 hVFyx5Wq802y for ; Fri, 21 Oct 2016 03:57:00 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0101.outbound.protection.outlook.com [104.47.1.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A2B1296F0 for ; Fri, 21 Oct 2016 03:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/b6yyZrRPngvyYNO5Ov9ald9eyJ445L8HUvc0yZHvgA=; b=RtsAaoMJB3ctwKvmYESlf5wOwXHv4cxhWAt2nXIr9zaRpSiBDLsnu3olD2o7grOoGG2MakDrNfz3Vkm7hO1bk9Pn4uGGPAR186iipyFPzYQFuMtzTJXLbZVDfApbk1Nwm1B7pMq/SJqJU7rmLM7+mVd0iJUh/7uClUff3S+tIvo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by AM5PR0701MB2996.eurprd07.prod.outlook.com (10.168.156.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Fri, 21 Oct 2016 10:56:56 +0000 Message-ID: <017501d22b89$7ded8e00$4001a8c0@gateway.2wire.net> From: t.petch To: "Jakob Heitz (jheitz)" , Brian Dickson References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161020225004.GG1074@Vurt.local> <2894c1eb263143cc8129ec8e381957dc@XCH-ALN-014.cisco.com> Date: Fri, 21 Oct 2016 11:54:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: DB6PR0601CA0044.eurprd06.prod.outlook.com (10.169.209.30) To AM5PR0701MB2996.eurprd07.prod.outlook.com (10.168.156.146) X-MS-Office365-Filtering-Correlation-Id: 27a3cde7-11f2-4087-20e8-08d3f9a0f97d X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 2:dTmKaHeBu4jIB8BsTSSs7Nos0GLWNbVHX6h5rdAYfQLUQ+XZWCTSQpHKAYkSZ2kN0xNqLVFQ265sTF6rYYO5gDSoJ7P4+XCwcGdKgVZeM+4YQwR411r1zLWExu2uEa7rFKEV6mXOMz3I2WY2tzKlpKrskfEivYNIcNGmQSaMaQXXH3BqdLexxdRoSXkvR63PmBU3kZygnSmPggO4OEOqSg==; 3:iAmixZFdGUvUor9qWgM0tTDlLcyqMjFys+NdXBQQif/PP7FEXFEpzzsceJsWkd8jdAUkspsqa6u/O5ysQg64TtRZiiEnO3QMvY2iAdU53goUmSzop1UDS4G2r+onmY8OQulfKOFCRl/zE/R33HfZkQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0701MB2996; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 25:RB5i0CtMpMfFCOrC+P2CukDJLulObuuzx+v63le/7pJoCS6KiCCt/uHmI8fZtyoc/mOtly2CHV+s+q1piYxKcLFLCxazVsH0jsov/6jiCTDV7Vc4SFCUAtT9Z2FhpxwOTvD27I9txCdfLpMugi75OR7KXfcg5jEjojHWTnzc23tdQZUUOA9B6v6yJ0qeZ0yq5BGX/rnVYq7F73lUlSgkl+C5qiXQ8K5gh92cC5g3luZ3E6YQsek1BUn2P6olZz4WI5MePtcloYS34V6X7OACb3I0UpCKrgRglAwtHYRCKftLsNfTda7pozeynVJ82blY9Ryp4DoMXgLlfC63oul+MVoXxOgdJShOCGUW59qMKOfwHk4k2Inn3TcVZgWv6np38yKwcHf657BniDguSrDzasuvF7vWhzcaZS+XvYykAX3s4+wyJLKJAlMArvxd7SsiFDNLwUbd87fpumKucbEhB7dpQBEjBIu2DD5My2GTIQJtxILTzkRkC8+OnqnGclsnb0KQPx/dxNyKnjICPJhyFnNtad9pTCiI032QpCK6RCQK04s6EjSXboZtL/BRKV7mIw0JZu1ilygoqsnUNRTzjQPiK724L5X25eyAffBkp1S3jbFjXUihrNYhPb4qeMf+cbxuYwWi4EnunnUDP8k8/SzV6YfspEzGB2F/IB5A6RA7FHX0BKcRAJ75P2cffY2F4EczB5x4jaq6+0t5eS7B0zT5yaWOTxvz4Q2404Y3x4M0MhtF7Vd7itVf7T/Fjfzy+dSImr9WNRlKPnvGOfE/pix8dEXxLEGhv6ov09UdLIZJ84YmCbT/tyWqCyVZdv9Roimiaa6XcwNmdZNBOMcvQw== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 31:JZkVIdhYzT96WeRamMrtKRRJkCrwOZuwJE/MY7fS1/ix8fnlFkI4ILr1NhLSmSCjNVK4TYeNp/MWeCOCenkII53uv4B1M6zxMybSHRfREKh7jsDwmIWd4CuEjc1zO3V+JLDhA7j/SoL4eT2mSkPfWfyzVuDzeNhUbSzTwd5sTwC0bfRiolPmJaw729USFL/OxUaUP3rUjR0kubqNY3EpwDzCPnQyQeMFJntcs6FcQjbBvvMTBoi3n5QlahkDvIQMEciTjivc45GgJ/iRqZjg0A==; 4:EnGaIZdzmwl5KsUEJQBm/M/mVu0UFY0/D/LREwzNGzV5Ga5aEeOzLzB9pZnuMVu7kFqBL9Y8wsqDrUBecfFkuhG2SWbEDI2g6E2YfLWnE/eC2bLcjYw+Oy3Q/LNm55Bf/CX/yGyYxYV93H2DJw6P+Jhs2oTCIKoAa95uQKj+NWmg4FEu245NoK+UYX1BplVyGZFyoQdnMRqcYidqnstbQzvhgqcvA7GaoXK5wTHn8IPhdh+JlOvOqESnVhBdLyG0d/t6T73K4Z4mzTNGQipt4v8au4W0QWTsqY9ItubKECSTRK+0mXBwCfh/T4EdpOFIKQzPnTZ+cXqSmB4wHUzu1KfdSLPYgvMYpaJ4DXuphBjPr+4QUaGhyxBiJrIrbMY7otd15Y449czOJ/0Aze2THu+JwAZg3NvMJJHzdhtI6Lk8Ppg3nLRzseOaL9wrpyqAIipRpIW+km4N2h4q49LFP3OddVlQZdVwFfl76QksyfI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(788757137089)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM5PR0701MB2996; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2996; X-Forefront-PRVS: 01026E1310 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(377454003)(189002)(24454002)(199003)(54094003)(13464003)(5423002)(47776003)(81816999)(105586002)(77096005)(5001770100001)(5660300001)(93886004)(3846002)(23676002)(5890100001)(5820100001)(15975445007)(4720700003)(6666003)(9686002)(62236002)(230783001)(61296003)(586003)(44716002)(42186005)(92566002)(230700001)(1556002)(106356001)(33646002)(116806002)(50226002)(86362001)(50466002)(68736007)(101416001)(50986999)(66066001)(44736004)(81686999)(19580395003)(14496001)(2906002)(84392002)(4326007)(6116002)(97736004)(8676002)(189998001)(81166006)(7736002)(7846002)(305945005)(81156014)(1456003)(76176999)(19580405001)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2996; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTY7MjM6T05xenBGb2hxTmt2anFGbWdBREtrbkNW?= =?utf-8?B?dWNSMXhvUkUyd1pSZS9mR3U2c0JhQzdYdDZwaGNOYytVeCsrMFlUd1pDRDh5?= =?utf-8?B?R2gwMEVxNGVNTU9oK054S0luZVY0WkVOcmVMak5QWXo1dmtSdjNPSysxM0tI?= =?utf-8?B?NXNsYU5Fd1VtaXJhNlYxWjB5K0QwUkdaTTVXZUJiTElGNDRWVGNyTXJmd3Jx?= =?utf-8?B?NXhkYVE5dkRMcFgvOWVoZE9aS0VvS0JpMVBIaWF6RFNOTGNkRnFFdnI4Yzg0?= =?utf-8?B?VThUdWlZSU5nYUltV0tKY0JYN3dqa29IK3lRZTVzbXF2am5SR0xvS3ZkY2JE?= =?utf-8?B?ZE9IZEp4Ykt1SExIaVBUV3BPbW5Wc0RDMkV3RHlYcVFDK2phZmF5Y1h5OVFQ?= =?utf-8?B?SWFhT2ZlTXdXczFhWU5mRGRIYjkxSFVCNW1ndUp1UHpqODB5WlVGSGJocmJK?= =?utf-8?B?OWJvcGxFUVdqK01jVWRYSng0SklBdVpkTDhuNGg1WU5HRUZjNzZ4ODZrdXRX?= =?utf-8?B?dDl1ZTJDSUxKQWpEOTFNTWJIZlVQYm5ROG9qQmNDemNtMzAvTjFDYkJMK0RY?= =?utf-8?B?anFkTTBBcmZqQ284eHJPU1M5OXJEVVlxREptVE91Rmh3OTczRWNmWHg3MXRr?= =?utf-8?B?bUJoMEJNVlpmd1FUbHJOYXN5S0M2d1ZSay9uN2FTR3B4akhzL1FPczlHcS9n?= =?utf-8?B?dUpRckt4Y24wNjE4c2NFRDQ2emJqUXdoK2Z4bEhNclk5VmhQK1ljSzgzM0Yv?= =?utf-8?B?UVVaK0hjb1UxZ0ZxeHhPK1JIUUNweUtzaHpYTFJnZXJWdko3WWVhYm42cU5Z?= =?utf-8?B?a2VwWExIVmt2R3NnTHBkVG90WlNDL0tyczEzYWFCV0RveVpaVTNvY0txSkRZ?= =?utf-8?B?UDYxY1g1Mlc4K3BqbmNjQWlPYVd0K2NyeUY1b1JVTVQ3N0k3S2dnNHY0WlZP?= =?utf-8?B?NDIvb0YyNTh4dk1iaktHZk5DY2pWWko1YkFSOEtRYUFxdXVXNVJ2cGZ4RVJG?= =?utf-8?B?RktGdHpWYTh3SnhGd2oxQnlQOW1oQU9JcjV0bllGVHZFeTZXcVU2QlFWOVlu?= =?utf-8?B?Z1dWN202S1I2eE5GTENjbldvYjhRNythVlA5dzM2TmVyVXZKbTZndVB1bTZ3?= =?utf-8?B?L2pyNUV5cDVJVkJ2RlI0dlJnNnUxWDhCcERabWVNRTl6ejhZamVXeisvdXpS?= =?utf-8?B?VjduSWhPR1lYYzJ3TzhNVGZkZnVweFdqUG9iTTd6eDdCZEhQc2hqUGNkbTdQ?= =?utf-8?B?S25ZSkx2YVB2Nk1VS0JUZFJhSENFQUZBWXhvaUxoV25WUk9GckZSaTRkZXdP?= =?utf-8?B?bm1wazFGd2dFZEl3U0k5Nnd5d29jakRxZUg3L0VRdjhSK3Y2dzRib2s2aE5S?= =?utf-8?B?Nk40SWVkUGRnTTU3Rkc2UWxna1ZCTUdiTjNoRktYSk13WTlTNS9zZnJPMVFw?= =?utf-8?B?eGtPVWVQOFRXZVFqeGJ3WjF1alFxOUtXZ0RFcFhUVTNVRWgvaEhFT21WdGVK?= =?utf-8?B?NkY5WStZMEJ2c0drMVNXQ2hjVldWUEs5RmJPUTd4UXh1cTF3MjNuNEZoZCtS?= =?utf-8?B?Rnl1eTl5UFgyeURoaUpqM3RiSjNCMWozM2hBdFFEQ1kwa1ptN0Q1cElTM21M?= =?utf-8?B?cEQwdWZyaWZHYTBabWpHWHU3K0FYb3h6MHlVMTFrSUR4Y0YxK1hEbXBsVjV0?= =?utf-8?B?TnUySFJubERhYnEwN3dkVW5YYUlWd2dYZWIzTzJDbFA0dU1BZStaVkc4Ullk?= =?utf-8?B?dEZENVJ3SzAzcjRWQVVuRFk5b2xGaXFvWTNTYjF2Zm5rczJyWEQrQWdRK3BR?= =?utf-8?B?UDkwNkFwNzhrbDdQMm1PNmd4VXFJYW8wc2tDNWRySFQ5RE54Nkp4WTRkM1dv?= =?utf-8?B?My9hTk5vOTg3cklGTVlFbDR6MWhNY05pb09zLzlnRzRRQlZTZzFvKzI4RmYy?= =?utf-8?B?MkF4YnkzR1ZyZ2ppQktCbFAxTG01L1lFMTJ2bGhiY05nOEtCNlJwcWg5RzZN?= =?utf-8?B?cEs5NGNpNW5mZ0VzZGZjTk5PN2dIQUQrbGE1Yk1XY1d4b2RyV2hlWjRHdGxX?= =?utf-8?B?cy9qODhrdmgrSG1PL1VDdEpXOTNHc1pJZUF3S2k1VEhSV1h0SWdxUG1KK2xw?= =?utf-8?Q?ersnam9HSGpS/4k92UTfq56mEpdflIWMAyxyV4Vl46R8QK?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 6:yoXRjMoMVv9XNTETGSpLcd4zBMsd1uYNa1ndLSAdOV8XRdmoBnVq73gUur4Eve9aTgi+sX5f7J6wQ4T3+6YiMAI3ocRR7T1aOncSwdBr6ILCI3HTOIl+joQ5w6w300EQf7+hh4S9YjGoLShltFO6BNOpEudFgTlrRPsEazNnnuza8X/b8F/pSESwhJx73o3CvTTqIsGfULlc8qBMstSkhm5QoT02ACKgUF1VHr2jO305GGqQPxWU/bClhsVGTfN3czZfmGLhS+hATzyR478mAd71qpZHQuEhovIR/Dw0COCFGtrTsp2VKFvch526RTMx; 5:ll9tE1iaNQ4bDDHTrnOY1lmB5WYj/rXsc8fbIHc9g5CjN287iUzKEaZ5TxfkN5ns28CG1y1uxL/DmXEDNXRN9ZGiUtCq55pIt1e9o80H9eGVRWU5f72nrapdft6rZS4uBZSQzpZU0fP7konW1ZRDbyeUvG5g7Dy7Q7M0EdVNaDg=; 24:w7dOPWr5BQqqmQKhLFt+pKZ8CoepguqUZjNR/eGx7Ol/evti6KfmIa3Xwxm6DeqrA98NDl6R+wi+CWISsvL6s4CsJzqrU7VQKqJoZeBeXKk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 7:dtndS2G2ovh9yPMCmpley6p7E7yMliqTk+8NkHULpwqjomOsRbi7tBAte2/w1v74dwrs20r3SGiJR5J2KfUsL8jFqmtuAXeANsfUpZEPZc4ZJYutbMG12f5RCqvm9VZkjXv8yiDP4sv46NAy85srUEmRI1pDRO4C/N0y0kXEsbSUrA1oov9oWAcuE3SgVQgkXSlqilBKYH1B6FwuXYPSXvU0MtnIFl8vH5Bnj+XBeCgmvB2x40A272xS3PYDxVt4ac/Ordrpsl2QQy3BIkVvnThnc2cP4JMC6p51Vw84k5UOIqa8ONet9D8vvNBU/u2NO8n8ac216g7p/CVlpsbPPr4ummU5FTJjIHjtnEd6KR0= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2016 10:56:56.0188 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2996 Archived-At: Cc: IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 10:57:03 -0000 ----- Original Message ----- From: "Jakob Heitz (jheitz)" Sent: Friday, October 21, 2016 1:46 AM > I do understand that the community may travel several AS hops. > That's why I wrote > > A Large Community that > > is intended to be sent to multiple ASes SHOULD contain an ASN > > in the Global Administrator field. The ASN SHOULD be one that > > is assigned to the entity > > that defines the meaning of the rest of the Large Community. > > I also understand that this is not the only case and that communities > are often used within an AS only. We MUST NOT restrict that use. > > Also, even though AS B defines the community that has GA=B, AS B > is not always the intended recipient. Many ISPs use communities > to signal properties of routes that they send to their customers. > In that case, AS B is the sender, not the recipient. > > I wrote "entity" and not "AS", because someone may create only a > single BGP AS, but be assigned many ASNs. That someone is entitled > to use any of her assigned ASNs, not just the one in use by her AS. Jakob I read the words and share some of Brian's uncertainties. " A Large Community that is intended to be sent to multiple ASes SHOULD contain an ASN in the Global Administrator field. " For me, that is not the BGP protocol we have. Rather, " A Large Community is sent as a BGP transitive attribute which means that it will be sent to and received by a large number of ASes of which only one, or a small number, will be expected to understand and act upon the community. Thes ASes may or may not be adjacent to the AS originating the community. So that a recipient can tell whether or not the community is intended for it, the Global Administrator contains an ASN ..." except of course some want the freedom to put any value in the Global Administrator field in which case the recipients cannot tell (which is where I keep on coming from:-( BGP as specified does not have a mechanism to limit the distribution of a transitive attribute. I wonder if part of this disconnect is that in practice, a lot of stripping goes on so that attributes such as these are not really transitive at all. The impression I get is that the current attribute works despite being intended to be transitive when in practice it may not be so that replacing like for like, with just an increase in size, is not expected to create any routing issues. Perhaps we should have two communities, one transitive which MUST have an ASN and one not, although as Jeff pointed out, that would probably fail in the face of Route Reflectors and so is a non-starter. Tom Petch > > Thanks, > Jakob. > > From: Brian Dickson [mailto:brian.peter.dickson@gmail.com] > Sent: Thursday, October 20, 2016 5:28 PM > To: Jakob Heitz (jheitz) > Cc: Job Snijders ; heasley ; IETF IDR WG ; Sue Hares > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) > > > > On Thu, Oct 20, 2016 at 4:46 PM, Jakob Heitz (jheitz) > wrote: > Perhaps, we should add in an operations section that we should not and will not go any further. > In particular, within an AS and between adjacent BGP neighbors, ANY values will be allowed. > The only requirement is that sender and receiver have the same understanding of the contents, > but no RFC is required to say this. > > Jakob, > > I think you still don't understand the purpose or the mechanics of communities, as what you say makes almost no sense. > > The reason "large" needs to be an optional, transitive attribute, is that the intended party, whose ASN > is in the Global Administrator field, is not necessarily the first or second party (the one setting the community, > or the one that is the BGP peer of the first party). > > The community may travel an arbitrary number of AS hops before it is received by the ASN in question (global admin). > That ASN is the one who is the (ultimate) intended recipient (of the community), and whose interprets the latter 8 octets > of the community, using whatever logic he/she wishes. (The prefix will probably propagate much further, but we > are only concerned about the ASN that is the global administrator of the community.) > > This is NOT limited to within an AS, nor to adjacent BGP peers. > > As such, the intermediate AS hops will receive the prefix with the attached Large Community, but will > not have any understanding of the contents. They are expected to pass them along, as this is the > necessary part of communities' functioning. > > A -> X -> Y -> Z -> B are the Autonomous Systems passing the prefix. > A sets the community. The community is B:something:something. > B interprets the community. > X, Y, and Z, pass it along without acting on it. > > I'm sorry to raise a fuss, but since you are involved in editing the I-D, it would put my mind at ease to hear you say > that you understand the above. > > Putting text into this document, if you don't understand the above, may be harmful to the document, > and to operator folks who are trying to get the bugs out of the document before it advances. > > Sincerely, > Brian > > > Thanks, > Jakob. > > > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz) > > Sent: Thursday, October 20, 2016 4:06 PM > > To: Job Snijders > > > Cc: heasley >; Sue Hares >; IETF IDR WG > > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) > > > > Evidently, it wasn't clear. Now it is. > > > > Thanks, > > Jakob. > > > > > > > -----Original Message----- > > > From: Job Snijders [mailto:job@ntt.net] > > > Sent: Thursday, October 20, 2016 3:50 PM > > > To: Jakob Heitz (jheitz) > > > > Cc: Jeffrey Haas >; heasley >; IETF IDR WG >; Sue Hares > > > > > > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) > > > > > > Hi Jakob, > > > > > > I am not sure what issue this replacement resolves. With the replacement > > > text in the document I feel I have more questions than answers. > > > > > > Usually a community is intended to be sent to one AS to trigger an > > > action, and to multiple ASes if the community is of informative nature. > > > We know we can attach multiple Large BGP Communities to a route, because > > > of the variable length of the attribute. > > > > > > In an earlier response I pointed at text that addresses this specific > > > feature already in the current text: https://mailarchive.ietf.org/arch/msg/idr/_QULjIUDaBB4JqDR8IXuIYkAVJw > > > > > > Kind regards, > > > > > > Job > > > > > > > > > On Thu, Oct 20, 2016 at 10:13:41PM +0000, Jakob Heitz (jheitz) wrote: > > > > In addition, to deal with the values for the GA field, we will replace > > > > > > > > The Global Administrator field is intended to allow different > > > > Autonomous Systems to define Large BGP Communities without collision. > > > > > > > > with > > > > > > > > A Large Community that is intended to be sent to multiple ASes > > > > SHOULD contain an ASN in the Global Administrator field. The ASN > > > > SHOULD be one that is assigned to the entity that defines the > > > > meaning of the rest of the Large Community. This allows a route to > > > > carry multiple Large Communities, the meaning of each being defined > > > > by different independent entities. > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > ------------------------------------------------------------------------ -------- > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nobody Fri Oct 21 05:36:45 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10D71295D9 for ; Fri, 21 Oct 2016 05:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ypxM-GVj6fmW for ; Fri, 21 Oct 2016 05:36:41 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14EB3129420 for ; Fri, 21 Oct 2016 05:36:41 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 139so222591548itm.1 for ; Fri, 21 Oct 2016 05:36: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:from:date:message-id:subject:to :cc; bh=ktlMaKFL6LpesLHmgM/ti2NI35Pxg+WayeZLYqFo19c=; b=0wZIIs4fZigEUucGnq0b4jG0mKCKkCgxJ6ybQc5abPzhoAUE0SsnY+Nb8XrhEZ0Yz6 ZBzmKX1JZixVsG/OvPCv7DvCBENkDdy060oxkbBuEUbsYqhiaNlEP4y0M+DSAm6QTC7i QnfJyTjTzpGu45GJ9z3HCrWBswxMoy9V9nAGtVYKef+7zi4Th/4sOYjHTG0dllO7Ye3o 0IYzznpolPSlZ6RwefIHV0mhSqLDjY/f4ogcLQqvcOUwxtIygiBs+XesVwL+kUZAqrPV 57KyfF/N5CGHjmCg7giBuDahK3W3wM5KhdDUNd68+k6bdsHkP0JV3+slTcLMrRzJR8sG TPhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ktlMaKFL6LpesLHmgM/ti2NI35Pxg+WayeZLYqFo19c=; b=cWERUBqjJWdSj6PMQeFJAuk8KKCtXkUSx6UmREAIL/p2IIvPx77dD52KXjyZ0kW3h+ UJGChB2rzM0v6WF3WT7aFMrml0cZoPv/20XgkWtzJXgAi4GY8yBtnPezHeSckXfsunHg drvY4Yh6l+x0uEDsHOv9qC6mUKKeA41D+UwGW1WiQ9DNaf52z3TXxKfRgfkL/tesxvBR Gw5crBVHv6frbQkNF+6bBwX7aZWiOsei1yAHRnIBN/6eYPNZQqrB61ESlGuREjdu7USa ELzOj6UrltmhIh5AgH/rRi9FfP56fcNWmwKZMPnpsmaiGOOW50LvTfo/b7c045WIpWII pjwg== X-Gm-Message-State: ABUngvfp4I4gYjF4AqM9KuERGfsrIEKmrT0X/EZV9d8zyvLDuZHY36LJ8AxKP0aOhLETF5gtOlKOzK0DI1z1Rw== X-Received: by 10.107.133.13 with SMTP id h13mr761980iod.148.1477053400302; Fri, 21 Oct 2016 05:36:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.14.212 with HTTP; Fri, 21 Oct 2016 05:36:38 -0700 (PDT) In-Reply-To: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> From: Adam Chappell Date: Fri, 21 Oct 2016 14:36:38 +0200 Message-ID: To: "Jakob Heitz (jheitz)" Content-Type: multipart/alternative; boundary=001a113e88d03d4af1053f5f4b0b Archived-At: Cc: heasley , IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 12:36:43 -0000 --001a113e88d03d4af1053f5f4b0b Content-Type: text/plain; charset=UTF-8 Hi Jakob. I must confess I find the original text slightly simpler, and I can't read obvious benefit from the replacement text, because: - Large Community attributes are tags on routes. They are going to go exactly where advertisement policy says they should go, so not much point calling out the case where they are received by multiple ASes or otherwise. - If we think it's rude to use private ASNs or steal Job's ASN, it's an operational matter identical to the one faced today. - Propagation zone of LC attributes is influenceable by any peers in the path; but any savvy operator is unwise to rely on behaviour associated with unfettered or un-manipulated attributes. (Already covered with adequate wording in sec. 7 I think). I think the new statement might actually be back-to-front in what it says. It seems to say that we should use the ASN that defined the LD1 and LD2 parts that we wish to make use of, which isn't helpful. We probably agree that the ASN referenced in the GA field has ultimate authority on the definition of semantics and is probably the only AS one can practically rely on to effect such semantics. So if it helps, perhaps state that? -- Adam. On 21 October 2016 at 00:13, Jakob Heitz (jheitz) wrote: > In addition, to deal with the values for the GA field, we will replace > > The Global Administrator field is intended to allow different > Autonomous Systems to define Large BGP Communities without collision. > > with > > A Large Community that > is intended to be sent to multiple ASes SHOULD contain an ASN > in the Global Administrator field. The ASN SHOULD be one that > is assigned to the entity > that defines the meaning of the rest of the Large Community. > This allows a route to carry multiple Large Communities, the meaning > of each being defined by different independent entities. > > Thanks, > Jakob. > > > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders > > Sent: Thursday, October 20, 2016 3:00 PM > > To: Jeffrey Haas > > Cc: heasley ; IETF IDR WG ; Sue Hares > > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt > (10/17/2016 to 10/31/2016) > > > > Hi working group, > > > > On Tue, Oct 18, 2016 at 04:38:00PM -0400, Jeffrey Haas wrote: > > > > > > > On Oct 18, 2016, at 3:15 PM, Job Snijders wrote: > > > > > > > >> > > > >> Part of the idea behind reserving 65535:*:* was to reserve a space > that > > > >> could later be used for well-knowns, if that was desired - but to > not > > > >> spend time now arguing about details of what well-knowns are > necessary. > > > >> > > > >> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs. > > > > > > > > Jeff argues that a justification should be added. Maybe someone can > > > > pitch in one or two sentences that explain why these are reserved? > > > > > > That's certainly part of it. While I think many people can see the > > > reason why you might want to do such a reservation, to do so you > > > should have a practical reason in the document. > > > > > > For the 65535:*:* case, for symmetry with RFC 1997, you'd probably > > > want to note that if it's used for that symmetry that either the > > > existing well known community registry is used at IANA or that a new > > > one would need to be created. Alternatively, you just say the work is > > > expected and defer to a future document. > > > > > > Note by doing this, you're setting up some expectations about > > > translation of communities from one space to another. FWIW, I don't > > > recommend this and simply suggest that you recommend *not* using these > > > for common use in case someone decides that they want to do so. I > > > know your organization and others such as Deutsche Telecom have some > > > thoughts about what translation infrastructure might look like, and > > > such mechanisms would have impact. > > > > > > With regard to the 0: and max-uint32: cases, after dealing with the > > > headaches associated with helping with documents such as the as0 and > > > RFC 7300 and putting in some restrictions in the configuration... > > > followed by having to take them away, I'm very reluctant to put in > > > anything beyond "we think it's a bad idea to use these, so pretty > > > please don't" > > > > After some off-list back and forth with John Heasley, Adam Chappell, > > Jeff Haas and the authors, we came up with the following text to address > > the above raised concern. > > > > This will be part of -04. > > > > """" > > 5. Reserved Large BGP Community values > > > > The following Global Administrator values are reserved: 0 (the first > > ASN) [RFC7607], 65535 (UINT_MAX) and 4294967295 (the last ASN) > > [RFC7300]. Operators SHOULD NOT use these Global Administrator > > values. > > > > Although this document does not define any Special-Use Large BGP > > Communities, the Global Administrator values specified above could be > > used if there is a future need for them. > > """ > > > > A preview of the -03 / -04 diff is available here: > > > > https://htmlpreview.github.io/?https://github.com/large-bgp- > communities/large-bgp-communities/blob/master/draft- > > ietf-idr-large-community-04-from-3.diff.html > > > > Kind regards, > > > > Job > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > -- -- Adam. --001a113e88d03d4af1053f5f4b0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jakob.

I must confess I find the ori= ginal text slightly simpler, and I can't read obvious benefit from the = replacement text, because:

- Large Community = attributes are tags on routes. They are going to go exactly where advertise= ment policy says they should go, so not much point calling out the case whe= re they are received by multiple ASes or otherwise.

- If we think it's rude to use private ASNs or steal Job's ASN, i= t's an operational matter identical to the one faced today.
=

- Propagation zone of LC attributes is influenceab= le by any peers in the path; but any savvy operator is unwise to rely on be= haviour associated with unfettered or un-manipulated attributes. (Already c= overed with adequate wording in sec. 7 I think).

=
I think the new statement might actually be back-to-front in what it s= ays. It seems to say that we should use the ASN that defined the LD1 and LD= 2 parts that we wish to make use of, which isn't helpful. We probably a= gree that the ASN referenced in the GA field has ultimate authority on the = definition of semantics and is probably the only AS one can practically rel= y on to effect such semantics. So if it helps, perhaps state that?

-- Adam.





On 21 October 2016 at 00:13, Jakob Heitz (jheitz) &l= t;jheitz@cisco.com> wrote:
In addition, to deal = with the values for the GA field, we will replace

=C2=A0 =C2=A0The Global Administrator field is intended to allow different<= br> =C2=A0 =C2=A0Autonomous Systems to define Large BGP Communities without col= lision.

with

=C2=A0 A Large Community that
=C2=A0 is intended to be sent to multiple ASes SHOULD contain an ASN
=C2=A0 in the Global Administrator field. The ASN SHOULD be one that
=C2=A0 is assigned to the entity
=C2=A0 that defines the meaning of the rest of the Large Community.
=C2=A0 This allows a route to carry multiple Large Communities, the meaning=
=C2=A0 of each being defined by different independent entities.

Thanks,
Jakob.


> -----Original Message-----
> From: Idr [mailto:idr-bounces@= ietf.org] On Behalf Of Job Snijders
> Sent: Thursday, October 20, 2016 3:00 PM
> To: Jeffrey Haas <jhaas@pfrc.org<= /a>>
> Cc: heasley <heas@shrubbery.net>; IETF IDR WG <idr@ietf.org>; Sue Hares <shares@ndzh.com>
> Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt= (10/17/2016 to 10/31/2016)
>
> Hi working group,
>
> On Tue, Oct 18, 2016 at 04:38:00PM -0400, Jeffrey Haas wrote:
> >
> > > On Oct 18, 2016, at 3:15 PM, Job Snijders <job@ntt.net> wrote:
> > >
> > >>
> > >> Part of the idea behind reserving 65535:*:* was to reser= ve a space that
> > >> could later be used for well-knowns, if that was desired= - but to not
> > >> spend time now arguing about details of what well-knowns= are necessary.
> > >>
> > >> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved= ASNs.
> > >
> > > Jeff argues that a justification should be added. Maybe some= one can
> > > pitch in one or two sentences that explain why these are res= erved?
> >
> > That's certainly part of it.=C2=A0 While I think many people = can see the
> > reason why you might want to do such a reservation, to do so you<= br> > > should have a practical reason in the document.
> >
> > For the 65535:*:* case, for symmetry with RFC 1997, you'd pro= bably
> > want to note that if it's used for that symmetry that either = the
> > existing well known community registry is used at IANA or that a = new
> > one would need to be created.=C2=A0 Alternatively, you just say t= he work is
> > expected and defer to a future document.
> >
> > Note by doing this, you're setting up some expectations about=
> > translation of communities from one space to another.=C2=A0 FWIW,= I don't
> > recommend this and simply suggest that you recommend *not* using = these
> > for common use in case someone decides that they want to do so.= =C2=A0 I
> > know your organization and others such as Deutsche Telecom have s= ome
> > thoughts about what translation infrastructure might look like, a= nd
> > such mechanisms would have impact.
> >
> > With regard to the 0: and max-uint32: cases, after dealing with t= he
> > headaches associated with helping with documents such as the as0 = and
> > RFC 7300 and putting in some restrictions in the configuration...=
> > followed by having to take them away, I'm very reluctant to p= ut in
> > anything beyond "we think it's a bad idea to use these, = so pretty
> > please don't"
>
> After some off-list back and forth with John Heasley, Adam Chappell, > Jeff Haas and the authors, we came up with the following text to addre= ss
> the above raised concern.
>
> This will be part of -04.
>
> """"
> 5.=C2=A0 Reserved Large BGP Community values
>
>=C2=A0 =C2=A0 The following Global Administrator values are reserved: 0= (the first
>=C2=A0 =C2=A0 ASN) [RFC7607], 65535 (UINT_MAX) and 4294967295 (the last= ASN)
>=C2=A0 =C2=A0 [RFC7300].=C2=A0 Operators SHOULD NOT use these Global Ad= ministrator
>=C2=A0 =C2=A0 values.
>
>=C2=A0 =C2=A0 Although this document does not define any Special-Use La= rge BGP
>=C2=A0 =C2=A0 Communities, the Global Administrator values specified ab= ove could be
>=C2=A0 =C2=A0 used if there is a future need for them.
> """
>
> A preview of the -03 / -04 diff is available here:
>
> https://htmlpreview.github.io/?https://github.com/lar= ge-bgp-communities/large-bgp-communities/blob/master/draft- > ietf-idr-large-community-04-from-3.diff.html
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr



--
=

-- Ad= am.
--001a113e88d03d4af1053f5f4b0b-- From nobody Fri Oct 21 05:59:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D6D1295F0 for ; Fri, 21 Oct 2016 05:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 MLIw5iPB2OgK for ; Fri, 21 Oct 2016 05:59:33 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id C6C891295DD for ; Fri, 21 Oct 2016 05:59:33 -0700 (PDT) Received: from [10.233.195.11] (c-69-136-137-59.hsd1.mi.comcast.net [69.136.137.59]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 8730B540CD0; Fri, 21 Oct 2016 08:59:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jared Mauch X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Fri, 21 Oct 2016 08:59:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <257C497A-BE91-47AD-85DE-9E5B3E64795B@puck.nether.net> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> To: Adam Chappell Archived-At: Cc: heasley , IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 12:59:35 -0000 I share others concerns here as well. I see no clarity from this change.=20 Jared Mauch > On Oct 21, 2016, at 8:36 AM, Adam Chappell wrote= : >=20 > I must confess I find the original text slightly simpler, and I can't read= obvious benefit from the replacement text, because: From nobody Fri Oct 21 08:19:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5858129602 for ; Fri, 21 Oct 2016 08:19:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=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 a-x6hewlHCTK for ; Fri, 21 Oct 2016 08:19:45 -0700 (PDT) Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12F412955B for ; Fri, 21 Oct 2016 08:19:44 -0700 (PDT) X-Footer: aTNkLm5s Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Fri, 21 Oct 2016 17:19:39 +0200 To: "Jakob Heitz (jheitz)" , Job Snijders , Jeffrey Haas References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> From: "i3D.net - Martijn Schmidt" Organization: i3D.net Message-ID: Date: Fri, 21 Oct 2016 17:19:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: heasley , IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 15:19:48 -0000 Hello Jakob, I think we need to ask ourselves whether the new wording is really relevant to implementors. The answer here appears to be that it's not, because the draft states "Implementations MUST allow the operator to specify any value for the Global Administrator field." and no amount of SHOULD will override the MUST. Secondly, there's literally no way for the vendor to check whether an ASN belongs to "the entity that defines the meaning of the rest of the Large Community" so it's completely unenforceable and therefore doesn't belong in a protocol specification / IDR draft. If we want to instruct operators to do something, it SHOULD be done in a RFC1998-like BCP/GROW document and I'd be happy to contribute some wording which seeks to make that happen when the draft is submitted to GROW for adoption as a WG subject. Best regards, Martijn Schmidt On 10/21/2016 12:13 AM, Jakob Heitz (jheitz) wrote: > In addition, to deal with the values for the GA field, we will replace > > The Global Administrator field is intended to allow different > Autonomous Systems to define Large BGP Communities without collision. > > with > > A Large Community that > is intended to be sent to multiple ASes SHOULD contain an ASN > in the Global Administrator field. The ASN SHOULD be one that > is assigned to the entity > that defines the meaning of the rest of the Large Community. > This allows a route to carry multiple Large Communities, the meaning > of each being defined by different independent entities. > > Thanks, > Jakob. > > >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders >> Sent: Thursday, October 20, 2016 3:00 PM >> To: Jeffrey Haas >> Cc: heasley ; IETF IDR WG ; Sue Hares >> Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) >> >> Hi working group, >> >> On Tue, Oct 18, 2016 at 04:38:00PM -0400, Jeffrey Haas wrote: >>>> On Oct 18, 2016, at 3:15 PM, Job Snijders wrote: >>>> >>>>> Part of the idea behind reserving 65535:*:* was to reserve a space that >>>>> could later be used for well-knowns, if that was desired - but to not >>>>> spend time now arguing about details of what well-knowns are necessary. >>>>> >>>>> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs. >>>> Jeff argues that a justification should be added. Maybe someone can >>>> pitch in one or two sentences that explain why these are reserved? >>> That's certainly part of it. While I think many people can see the >>> reason why you might want to do such a reservation, to do so you >>> should have a practical reason in the document. >>> >>> For the 65535:*:* case, for symmetry with RFC 1997, you'd probably >>> want to note that if it's used for that symmetry that either the >>> existing well known community registry is used at IANA or that a new >>> one would need to be created. Alternatively, you just say the work is >>> expected and defer to a future document. >>> >>> Note by doing this, you're setting up some expectations about >>> translation of communities from one space to another. FWIW, I don't >>> recommend this and simply suggest that you recommend *not* using these >>> for common use in case someone decides that they want to do so. I >>> know your organization and others such as Deutsche Telecom have some >>> thoughts about what translation infrastructure might look like, and >>> such mechanisms would have impact. >>> >>> With regard to the 0: and max-uint32: cases, after dealing with the >>> headaches associated with helping with documents such as the as0 and >>> RFC 7300 and putting in some restrictions in the configuration... >>> followed by having to take them away, I'm very reluctant to put in >>> anything beyond "we think it's a bad idea to use these, so pretty >>> please don't" >> After some off-list back and forth with John Heasley, Adam Chappell, >> Jeff Haas and the authors, we came up with the following text to address >> the above raised concern. >> >> This will be part of -04. >> >> """" >> 5. Reserved Large BGP Community values >> >> The following Global Administrator values are reserved: 0 (the first >> ASN) [RFC7607], 65535 (UINT_MAX) and 4294967295 (the last ASN) >> [RFC7300]. Operators SHOULD NOT use these Global Administrator >> values. >> >> Although this document does not define any Special-Use Large BGP >> Communities, the Global Administrator values specified above could be >> used if there is a future need for them. >> """ >> >> A preview of the -03 / -04 diff is available here: >> >> https://htmlpreview.github.io/?https://github.com/large-bgp-communities/large-bgp-communities/blob/master/draft- >> ietf-idr-large-community-04-from-3.diff.html >> >> Kind regards, >> >> Job >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Oct 21 08:42:45 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10511295C9 for ; Fri, 21 Oct 2016 08:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Wrlrbax5qtkK for ; Fri, 21 Oct 2016 08:42:41 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AD71293E9 for ; Fri, 21 Oct 2016 08:42:40 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id m138so171798776itm.0 for ; Fri, 21 Oct 2016 08:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wcAChagqJXpgxbdUXF50BkGDSaTOsxH/nAotkBehHsE=; b=mbZ04XLmMGsCyAgD+egiMVv2gDNW+5CO5VEtghdUi5ekYazzoy52NkYe4nOlF317y2 nx5SnML9676py6UQ93slIBB3QOEC2W57HbY1Q5nSsX1NmnKlAuWYn4Ff+ZoxZm22GLRM h08WJEQL6f7WTNHJB56SPLMz4yMkFFn92anyK8hcMtw/xUtfcQ9webRgrhpoq6Tjkau0 mNIchbpGcVsrZqWaY1mXfCAv3mioOcjov45YS/VpIGKGIMG13t+bRNFbJGRdlXl7qfZG 8ppFnr02HuJvm0GOO/I2FWz2UrN2lSqBzrPtG5Ne2Re83uqtwp/NDLfbyUeWsk0DdS4d LFzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wcAChagqJXpgxbdUXF50BkGDSaTOsxH/nAotkBehHsE=; b=LqJ8WyQQaDqryWTYNdp/FwXkfJc1WxdZ3chcUVRrHYvsA/pi0Ni5Bmb1QcDTS+0jmV zFcsyt8iMFqUqKnBG6GASUTMCtN+Fln+4gvrC87yN/hG4QWR6y1/e7tiv5LaYIzqrDAP tEq5W7goSYPUjat4Wk2e2Wq2BP9Xu089gEGMDrCKumcbt4jl5kYO2PkujnpBpEQLLBnC EEbsw1zvYtxiNL+xi6n0IVIOho1YPnp6g+wuQIRiiZOmP/LWLaIS7umqw5jkoLM1PTwa cCaRJw4nxWlM0nd4FVPS+L+glLJkDcDO8S620KBuWtv3ZTKOFQrLK36AaFk+KC/2hNwJ dV7A== X-Gm-Message-State: ABUngvf/8KBCIaYwviuBIosv2T6s7ppdU6lsQ/yVVzdETMA7ZPZIeRV8sVkgj0xSaRN+pZAbbiQK51DxnPQWVQ== X-Received: by 10.36.254.65 with SMTP id w62mr1688445ith.118.1477064558739; Fri, 21 Oct 2016 08:42:38 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.107.17.232 with HTTP; Fri, 21 Oct 2016 08:42:37 -0700 (PDT) In-Reply-To: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> From: Robert Raszuk Date: Fri, 21 Oct 2016 17:42:37 +0200 X-Google-Sender-Auth: 96mpSZVNAaMUBjW4yy_uEBfSARk Message-ID: To: "i3D.net - Martijn Schmidt" Content-Type: multipart/alternative; boundary=94eb2c031b985588e7053f61e4cb Archived-At: Cc: IETF IDR WG , heasley , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 15:42:44 -0000 --94eb2c031b985588e7053f61e4cb Content-Type: text/plain; charset=UTF-8 Hi Martijn, > Secondly, there's literally no way for the vendor to check whether an > ASN belongs to "the entity that defines the meaning of the rest of the > Large Community" Why not ? If you do not make those 4 octets configurable by spec and always fill it with AS number defined in your BGP instance you will have assurance it is ASN of the entity that defines the rest 8 octets of the LC as otherwise you will likely not establish any EBGP sessions to your peers. So there is very easy way to enforce it today in any BGP implementation. However the question is should it be enforced at all ? Best, R. On Fri, Oct 21, 2016 at 5:19 PM, i3D.net - Martijn Schmidt < martijnschmidt@i3d.net> wrote: > Hello Jakob, > > I think we need to ask ourselves whether the new wording is really > relevant to implementors. The answer here appears to be that it's not, > because the draft states "Implementations MUST allow the operator to > specify any value for the Global Administrator field." and no amount of > SHOULD will override the MUST. > > Secondly, there's literally no way for the vendor to check whether an > ASN belongs to "the entity that defines the meaning of the rest of the > Large Community" so it's completely unenforceable and therefore doesn't > belong in a protocol specification / IDR draft. > > If we want to instruct operators to do something, it SHOULD be done in a > RFC1998-like BCP/GROW document and I'd be happy to contribute some > wording which seeks to make that happen when the draft is submitted to > GROW for adoption as a WG subject. > > Best regards, > Martijn Schmidt > > On 10/21/2016 12:13 AM, Jakob Heitz (jheitz) wrote: > > In addition, to deal with the values for the GA field, we will replace > > > > The Global Administrator field is intended to allow different > > Autonomous Systems to define Large BGP Communities without collision. > > > > with > > > > A Large Community that > > is intended to be sent to multiple ASes SHOULD contain an ASN > > in the Global Administrator field. The ASN SHOULD be one that > > is assigned to the entity > > that defines the meaning of the rest of the Large Community. > > This allows a route to carry multiple Large Communities, the meaning > > of each being defined by different independent entities. > > > > Thanks, > > Jakob. > > > > > >> -----Original Message----- > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders > >> Sent: Thursday, October 20, 2016 3:00 PM > >> To: Jeffrey Haas > >> Cc: heasley ; IETF IDR WG ; Sue > Hares > >> Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt > (10/17/2016 to 10/31/2016) > >> > >> Hi working group, > >> > >> On Tue, Oct 18, 2016 at 04:38:00PM -0400, Jeffrey Haas wrote: > >>>> On Oct 18, 2016, at 3:15 PM, Job Snijders wrote: > >>>> > >>>>> Part of the idea behind reserving 65535:*:* was to reserve a space > that > >>>>> could later be used for well-knowns, if that was desired - but to not > >>>>> spend time now arguing about details of what well-knowns are > necessary. > >>>>> > >>>>> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs. > >>>> Jeff argues that a justification should be added. Maybe someone can > >>>> pitch in one or two sentences that explain why these are reserved? > >>> That's certainly part of it. While I think many people can see the > >>> reason why you might want to do such a reservation, to do so you > >>> should have a practical reason in the document. > >>> > >>> For the 65535:*:* case, for symmetry with RFC 1997, you'd probably > >>> want to note that if it's used for that symmetry that either the > >>> existing well known community registry is used at IANA or that a new > >>> one would need to be created. Alternatively, you just say the work is > >>> expected and defer to a future document. > >>> > >>> Note by doing this, you're setting up some expectations about > >>> translation of communities from one space to another. FWIW, I don't > >>> recommend this and simply suggest that you recommend *not* using these > >>> for common use in case someone decides that they want to do so. I > >>> know your organization and others such as Deutsche Telecom have some > >>> thoughts about what translation infrastructure might look like, and > >>> such mechanisms would have impact. > >>> > >>> With regard to the 0: and max-uint32: cases, after dealing with the > >>> headaches associated with helping with documents such as the as0 and > >>> RFC 7300 and putting in some restrictions in the configuration... > >>> followed by having to take them away, I'm very reluctant to put in > >>> anything beyond "we think it's a bad idea to use these, so pretty > >>> please don't" > >> After some off-list back and forth with John Heasley, Adam Chappell, > >> Jeff Haas and the authors, we came up with the following text to address > >> the above raised concern. > >> > >> This will be part of -04. > >> > >> """" > >> 5. Reserved Large BGP Community values > >> > >> The following Global Administrator values are reserved: 0 (the first > >> ASN) [RFC7607], 65535 (UINT_MAX) and 4294967295 (the last ASN) > >> [RFC7300]. Operators SHOULD NOT use these Global Administrator > >> values. > >> > >> Although this document does not define any Special-Use Large BGP > >> Communities, the Global Administrator values specified above could be > >> used if there is a future need for them. > >> """ > >> > >> A preview of the -03 / -04 diff is available here: > >> > >> https://htmlpreview.github.io/?https://github.com/large-bgp- > communities/large-bgp-communities/blob/master/draft- > >> ietf-idr-large-community-04-from-3.diff.html > >> > >> Kind regards, > >> > >> Job > >> > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --94eb2c031b985588e7053f61e4cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martijn,
>= Secondly, there's literally no way for the vendor to check whether an<= /span>
>=C2=A0ASN belongs to "the entity that defines the meaning of the = rest of the
>=C2=A0Large Community"

Why not ?=C2=A0
If you do not make those 4 octets configurable by spec and always fill = it=C2=A0
with AS number defined in your BGP instance you will have assuran= ce it=C2=A0
is ASN of the entity that defines the rest 8 octets of the LC = as otherwise=C2=A0
you will likely not establish any EBGP sessions=C2=A0to your peers.

So = there is very easy way to enforce it today in any BGP implementation.=C2=A0=

However the question is should it be enforced at all ?=C2=A0=

<= /span>
Best,
R.









On Fri, Oct 21, 2016 at 5:19 PM, i3D.net - Martijn Schmidt <martijn= schmidt@i3d.net> wrote:
Hello Jakob,

I think we need to ask ourselves whether the new wording is really
relevant to implementors. The answer here appears to be that it's not,<= br> because the draft states "Implementations MUST allow the operator to specify any value for the Global Administrator field." and no amount o= f
SHOULD will override the MUST.

Secondly, there's literally no way for the vendor to check whether an ASN belongs to "the entity that defines the meaning of the rest of the=
Large Community" so it's completely unenforceable and therefore do= esn't
belong in a protocol specification / IDR draft.

If we want to instruct operators to do something, it SHOULD be done in a RFC1998-like BCP/GROW document and I'd be happy to contribute some
wording which seeks to make that happen when the draft is submitted to
GROW for adoption as a WG subject.

Best regards,
Martijn Schmidt

On 10/21/2016 12:13 AM, Jakob Heitz (jheitz) wrote:
> In addition, to deal with the values for the GA field, we will replace=
>
>=C2=A0 =C2=A0 The Global Administrator field is intended to allow diffe= rent
>=C2=A0 =C2=A0 Autonomous Systems to define Large BGP Communities withou= t collision.
>
> with
>
>=C2=A0 =C2=A0A Large Community that
>=C2=A0 =C2=A0is intended to be sent to multiple ASes SHOULD contain an = ASN
>=C2=A0 =C2=A0in the Global Administrator field. The ASN SHOULD be one t= hat
>=C2=A0 =C2=A0is assigned to the entity
>=C2=A0 =C2=A0that defines the meaning of the rest of the Large Communit= y.
>=C2=A0 =C2=A0This allows a route to carry multiple Large Communities, t= he meaning
>=C2=A0 =C2=A0of each being defined by different independent entities. >
> Thanks,
> Jakob.
>
>
>> -----Original Message-----
>> From: Idr [mailto:idr-boun= ces@ietf.org] On Behalf Of Job Snijders
>> Sent: Thursday, October 20, 2016 3:00 PM
>> To: Jeffrey Haas <jhaas@pfrc.= org>
>> Cc: heasley <heas@shrubbe= ry.net>; IETF IDR WG <idr@ietf.or= g>; Sue Hares <shares@ndzh.com= >
>> Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03= .txt (10/17/2016 to 10/31/2016)
>>
>> Hi working group,
>>
>> On Tue, Oct 18, 2016 at 04:38:00PM -0400, Jeffrey Haas wrote:
>>>> On Oct 18, 2016, at 3:15 PM, Job Snijders <job@ntt.net> wrote:
>>>>
>>>>> Part of the idea behind reserving 65535:*:* was to res= erve a space that
>>>>> could later be used for well-knowns, if that was desir= ed - but to not
>>>>> spend time now arguing about details of what well-know= ns are necessary.
>>>>>
>>>>> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserv= ed ASNs.
>>>> Jeff argues that a justification should be added. Maybe so= meone can
>>>> pitch in one or two sentences that explain why these are r= eserved?
>>> That's certainly part of it.=C2=A0 While I think many peop= le can see the
>>> reason why you might want to do such a reservation, to do so y= ou
>>> should have a practical reason in the document.
>>>
>>> For the 65535:*:* case, for symmetry with RFC 1997, you'd = probably
>>> want to note that if it's used for that symmetry that eith= er the
>>> existing well known community registry is used at IANA or that= a new
>>> one would need to be created.=C2=A0 Alternatively, you just sa= y the work is
>>> expected and defer to a future document.
>>>
>>> Note by doing this, you're setting up some expectations ab= out
>>> translation of communities from one space to another.=C2=A0 FW= IW, I don't
>>> recommend this and simply suggest that you recommend *not* usi= ng these
>>> for common use in case someone decides that they want to do so= .=C2=A0 I
>>> know your organization and others such as Deutsche Telecom hav= e some
>>> thoughts about what translation infrastructure might look like= , and
>>> such mechanisms would have impact.
>>>
>>> With regard to the 0: and max-uint32: cases, after dealing wit= h the
>>> headaches associated with helping with documents such as the a= s0 and
>>> RFC 7300 and putting in some restrictions in the configuration= ...
>>> followed by having to take them away, I'm very reluctant t= o put in
>>> anything beyond "we think it's a bad idea to use thes= e, so pretty
>>> please don't"
>> After some off-list back and forth with John Heasley, Adam Chappel= l,
>> Jeff Haas and the authors, we came up with the following text to a= ddress
>> the above raised concern.
>>
>> This will be part of -04.
>>
>> """"
>> 5.=C2=A0 Reserved Large BGP Community values
>>
>>=C2=A0 =C2=A0 The following Global Administrator values are reserve= d: 0 (the first
>>=C2=A0 =C2=A0 ASN) [RFC7607], 65535 (UINT_MAX) and 4294967295 (the = last ASN)
>>=C2=A0 =C2=A0 [RFC7300].=C2=A0 Operators SHOULD NOT use these Globa= l Administrator
>>=C2=A0 =C2=A0 values.
>>
>>=C2=A0 =C2=A0 Although this document does not define any Special-Us= e Large BGP
>>=C2=A0 =C2=A0 Communities, the Global Administrator values specifie= d above could be
>>=C2=A0 =C2=A0 used if there is a future need for them.
>> """
>>
>> A preview of the -03 / -04 diff is available here:
>>
>> https://htmlpreview.github.io/?https://github.com= /large-bgp-communities/large-bgp-communities/blob/master/draft-
>> ietf-idr-large-community-04-from-3.diff.html
>>
>> Kind regards,
>>
>> Job
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr=
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--94eb2c031b985588e7053f61e4cb-- From nobody Fri Oct 21 08:50:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239AD129646 for ; Fri, 21 Oct 2016 08:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 TsmZHFwxefdx for ; Fri, 21 Oct 2016 08:50:01 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [81.209.183.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD411295AC for ; Fri, 21 Oct 2016 08:50:01 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 8F4237891A; Fri, 21 Oct 2016 17:49:59 +0200 (CEST) Date: Fri, 21 Oct 2016 17:49:58 +0200 From: Peter Hessler To: Robert Raszuk Message-ID: <20161021154958.GR27221@gir.theapt.org> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 15:50:02 -0000 On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk wrote: :Hi Martijn, : :> Secondly, there's literally no way for the vendor to check whether an :> ASN belongs to "the entity that defines the meaning of the rest of the :> Large Community" : :Why not ? : :If you do not make those 4 octets configurable by spec and always fill it :with AS number defined in your BGP instance you will have assurance it :is ASN of the entity that defines the rest 8 octets of the LC as otherwise :you will likely not establish any EBGP sessions to your peers. : :So there is very easy way to enforce it today in any BGP implementation. Say I am AS 1234, and I want to control AS 5678. My transit ISP is AS 9876. If I set local-as 1234 peer-as 9876 set large-community 5678:666:1 How is the implementation supposed to know to allow it? Limitations in the implementation completely defeat the purpose of this spec. :However the question is should it be enforced at all ? : MUST NOT is a very important part of this spec, and is enforced a few times in the document. :Best, :R. : -- The moving cursor writes, and having written, blinks on. From nobody Fri Oct 21 09:02:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59060129636 for ; Fri, 21 Oct 2016 09:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=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 eWs-N4uqxBXO for ; Fri, 21 Oct 2016 09:02:12 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCC8129648 for ; Fri, 21 Oct 2016 09:02:11 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 8502758FFB; Fri, 21 Oct 2016 16:02:11 +0000 (UTC) Date: Fri, 21 Oct 2016 16:02:11 +0000 From: heasley To: Robert Raszuk Message-ID: <20161021160211.GH7773@shrubbery.net> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: heasley , IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 16:02:17 -0000 Fri, Oct 21, 2016 at 05:42:37PM +0200, Robert Raszuk: > Hi Martijn, > > > Secondly, there's literally no way for the vendor to check whether an > > ASN belongs to "the entity that defines the meaning of the rest of the > > Large Community" > > Why not ? Because to determine if the contents is really something defined by the GA in the community, the device would need a list of communities that the GA uses, that list would need a signature and all the infrastructure to verify that signature....and ultimately, what would the point be anyway? > If you do not make those 4 octets configurable by spec and always fill it > with AS number defined in your BGP instance you will have assurance it > is ASN of the entity that defines the rest 8 octets of the LC as otherwise > you will likely not establish any EBGP sessions to your peers. BECAUSE IT IS NOT A ONE-WAY OR ONLY ONE-HOP THING. THE AUTONOMOUS SYSTEM ITSELF MIGHT SET THE COMMUNITY AS A TAG OR ANOTHER AUTONOMOUS SYSTEM MIGHT SET IT TO SIGNAL ANOTHER AUTONOMOUS SYSTEM TO DO SOMETHING AND THAT AUTONOMOUS SYSTEM MAY BE 1 OR MORE AUTONOMOUS SYSTEM HOPS AWAY. Eg: 2914:1001 Ashburn, VA | set by ntt 2914:450 96 customer fallback | received from a customer a customer might use 2914:450, or a customer of a customer, or a customer of a customer of a customer .... Utimately, the so-called Global Administrator field has the same storage size as an 4-octet ASN, operators will likely use it as such, but as far as the protocol, it need not be. It can be any 4-octet value as far as the protocol is concerned. Just as BGP RID is 4-octets and is just a number as far as the protocol is concerned, but operators typically use an IP address on the device as the RID. > So there is very easy way to enforce it today in any BGP implementation. > > However the question is should it be enforced at all ? > > Best, > R. > > > > > > > > > > > On Fri, Oct 21, 2016 at 5:19 PM, i3D.net - Martijn Schmidt < > martijnschmidt@i3d.net> wrote: > > > Hello Jakob, > > > > I think we need to ask ourselves whether the new wording is really > > relevant to implementors. The answer here appears to be that it's not, > > because the draft states "Implementations MUST allow the operator to > > specify any value for the Global Administrator field." and no amount of > > SHOULD will override the MUST. > > > > Secondly, there's literally no way for the vendor to check whether an > > ASN belongs to "the entity that defines the meaning of the rest of the > > Large Community" so it's completely unenforceable and therefore doesn't > > belong in a protocol specification / IDR draft. > > > > If we want to instruct operators to do something, it SHOULD be done in a > > RFC1998-like BCP/GROW document and I'd be happy to contribute some > > wording which seeks to make that happen when the draft is submitted to > > GROW for adoption as a WG subject. > > > > Best regards, > > Martijn Schmidt > > > > On 10/21/2016 12:13 AM, Jakob Heitz (jheitz) wrote: > > > In addition, to deal with the values for the GA field, we will replace > > > > > > The Global Administrator field is intended to allow different > > > Autonomous Systems to define Large BGP Communities without collision. > > > > > > with > > > > > > A Large Community that > > > is intended to be sent to multiple ASes SHOULD contain an ASN > > > in the Global Administrator field. The ASN SHOULD be one that > > > is assigned to the entity > > > that defines the meaning of the rest of the Large Community. > > > This allows a route to carry multiple Large Communities, the meaning > > > of each being defined by different independent entities. > > > > > > Thanks, > > > Jakob. > > > > > > > > >> -----Original Message----- > > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders > > >> Sent: Thursday, October 20, 2016 3:00 PM > > >> To: Jeffrey Haas > > >> Cc: heasley ; IETF IDR WG ; Sue > > Hares > > >> Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt > > (10/17/2016 to 10/31/2016) > > >> > > >> Hi working group, > > >> > > >> On Tue, Oct 18, 2016 at 04:38:00PM -0400, Jeffrey Haas wrote: > > >>>> On Oct 18, 2016, at 3:15 PM, Job Snijders wrote: > > >>>> > > >>>>> Part of the idea behind reserving 65535:*:* was to reserve a space > > that > > >>>>> could later be used for well-knowns, if that was desired - but to not > > >>>>> spend time now arguing about details of what well-knowns are > > necessary. > > >>>>> > > >>>>> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs. > > >>>> Jeff argues that a justification should be added. Maybe someone can > > >>>> pitch in one or two sentences that explain why these are reserved? > > >>> That's certainly part of it. While I think many people can see the > > >>> reason why you might want to do such a reservation, to do so you > > >>> should have a practical reason in the document. > > >>> > > >>> For the 65535:*:* case, for symmetry with RFC 1997, you'd probably > > >>> want to note that if it's used for that symmetry that either the > > >>> existing well known community registry is used at IANA or that a new > > >>> one would need to be created. Alternatively, you just say the work is > > >>> expected and defer to a future document. > > >>> > > >>> Note by doing this, you're setting up some expectations about > > >>> translation of communities from one space to another. FWIW, I don't > > >>> recommend this and simply suggest that you recommend *not* using these > > >>> for common use in case someone decides that they want to do so. I > > >>> know your organization and others such as Deutsche Telecom have some > > >>> thoughts about what translation infrastructure might look like, and > > >>> such mechanisms would have impact. > > >>> > > >>> With regard to the 0: and max-uint32: cases, after dealing with the > > >>> headaches associated with helping with documents such as the as0 and > > >>> RFC 7300 and putting in some restrictions in the configuration... > > >>> followed by having to take them away, I'm very reluctant to put in > > >>> anything beyond "we think it's a bad idea to use these, so pretty > > >>> please don't" > > >> After some off-list back and forth with John Heasley, Adam Chappell, > > >> Jeff Haas and the authors, we came up with the following text to address > > >> the above raised concern. > > >> > > >> This will be part of -04. > > >> > > >> """" > > >> 5. Reserved Large BGP Community values > > >> > > >> The following Global Administrator values are reserved: 0 (the first > > >> ASN) [RFC7607], 65535 (UINT_MAX) and 4294967295 (the last ASN) > > >> [RFC7300]. Operators SHOULD NOT use these Global Administrator > > >> values. > > >> > > >> Although this document does not define any Special-Use Large BGP > > >> Communities, the Global Administrator values specified above could be > > >> used if there is a future need for them. > > >> """ > > >> > > >> A preview of the -03 / -04 diff is available here: > > >> > > >> https://htmlpreview.github.io/?https://github.com/large-bgp- > > communities/large-bgp-communities/blob/master/draft- > > >> ietf-idr-large-community-04-from-3.diff.html > > >> > > >> Kind regards, > > >> > > >> Job > > >> > > >> _______________________________________________ > > >> Idr mailing list > > >> Idr@ietf.org > > >> https://www.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > > > Idr mailing list > > > Idr@ietf.org > > > https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Oct 21 09:03:16 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C561B129667 for ; Fri, 21 Oct 2016 09:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PNd7QiSmL0o9 for ; Fri, 21 Oct 2016 09:03:13 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6328129655 for ; Fri, 21 Oct 2016 09:03:12 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id c78so421209wme.0 for ; Fri, 21 Oct 2016 09:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4SQME5bzbuOEKldHxQSLx8+cBsZKhenOjQol7FeLLiY=; b=d6BfErBxJDXL2C+5ljRPCofAkP/STLcgreLZqtclJyV+zatdbhurFQEFPwvnK77wyB iU898/aJTm0DIVhNj9P0DzdoIO78T9TuuKfLbb4Vyu/rEyPb93N51aQ5jCRDgToW8XmZ 4+JWBSxFiHbgas9QYxREuddbz5vj6aH5sjcmh/uJaD+NlcLbBxmo1b+kpcV0wtZ5cyoI 8gVtf7cFm+ou9en3YqXUcm4FmT5m4CCNKkP0E89IgeMvP+4tdKxOdIFDka6cTVZJvxQf LZ4yElw9V8QbeFa97CAJVKGn7hsZ5zJ9/iWT3xK6WEDCYOQxttUBeAxmjPo92vm2w3Q0 i0cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4SQME5bzbuOEKldHxQSLx8+cBsZKhenOjQol7FeLLiY=; b=iXt9xHpDJwu20wJexwP1gJsoateLWQHAJFrXNji6rHb2dfS+cX6ID8JREoeznmiA2U +hvOPS01eVNs4jWBTT0v+e3Rq141PLlWhPr69dK33ne2jOj2s4HJzox5S/EJZjiTJKcs St3Gt61oEexC1vQhw9mjdvlNd58o7grDmi5gJ3ThfOtDo0apBXQFNoYiLuyRsfo8SnTv QVnZrioIm84Lppnlu7QL8nY7Cam5i4c8XczJrE02V7WjzhYYjvShP/deReNSe41b0bpQ PsJ2vnnLvTpESubbX8KOLrW8E6vJlfIwZikB1jsm26gVAQ5U9czv8hBG0+1QVZ3VnS1F XSCw== X-Gm-Message-State: ABUngvdL49Jc9O12dDHdGI3qJ32XAR7IVy7lw8BkhUPhw4zQyxtniPVy6tz1nHu5B+ENvqJsZZgp2ywPhWxSFQ== X-Received: by 10.194.94.232 with SMTP id df8mr1289355wjb.227.1477065791344; Fri, 21 Oct 2016 09:03:11 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Fri, 21 Oct 2016 09:03:09 -0700 (PDT) In-Reply-To: <20161021154958.GR27221@gir.theapt.org> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> From: Robert Raszuk Date: Fri, 21 Oct 2016 18:03:09 +0200 X-Google-Sender-Auth: Oyf8y2TXyt0zvcYr6Bbezmhdgjw Message-ID: To: Peter Hessler Content-Type: multipart/alternative; boundary=047d7bb03aaecd9583053f622d4c Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 16:03:15 -0000 --047d7bb03aaecd9583053f622d4c Content-Type: text/plain; charset=UTF-8 Peter, Who you control (who is the target of LC - can be expressed in the second 4 octets). And as such at least original discussions were about it. So if you inject a large community it would have format: SRC_ASN:DST_ASN:ACTION In your specific case it would be: 1234:5678:ACTION The comment was made that there is no way for implementation to insert valid SRC_ASN .. well it clearly is. But I am not suggesting spec should enforce it as it does limit use cases for LC by not allowing to overload first 4 octets. On the other hand it does provide more responsibility to whoever is injecting LCs so does improve on BGP clarity and stability from protocol point of view. Fixing on meaning on first 4 octets also provides very good tool to policy filtering rules as you know what to expect there. For example you may have policy allowing to pass any LC where first 4 octets contain any ASN also listed in your AS_PATH - otherwise drop it. That may effectively help to support LC global deployment much easier including the N-hops away destinations. Thx, r. On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler wrote: > On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk wrote: > :Hi Martijn, > : > :> Secondly, there's literally no way for the vendor to check whether an > :> ASN belongs to "the entity that defines the meaning of the rest of the > :> Large Community" > : > :Why not ? > : > :If you do not make those 4 octets configurable by spec and always fill it > :with AS number defined in your BGP instance you will have assurance it > :is ASN of the entity that defines the rest 8 octets of the LC as otherwise > :you will likely not establish any EBGP sessions to your peers. > : > :So there is very easy way to enforce it today in any BGP implementation. > > Say I am AS 1234, and I want to control AS 5678. My transit ISP is AS > 9876. > > If I set > > local-as 1234 > peer-as 9876 > set large-community 5678:666:1 > > How is the implementation supposed to know to allow it? > > Limitations in the implementation completely defeat the purpose of this > spec. > > > :However the question is should it be enforced at all ? > : > > MUST NOT is a very important part of this spec, and is enforced a few > times in the document. > > > :Best, > :R. > : > > > > > -- > The moving cursor writes, and having written, blinks on. > --047d7bb03aaecd9583053f622d4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Peter,

Who you control (who is the target of LC - can be expr= essed in the second 4 octets). And as such at least original discussions we= re about it.=C2=A0

So = if you inject a large community it would have format: SRC_ASN:DST_ASN:ACTIO= N

In your specific cas= e it would be: 1234:5678:ACTION

The comment was made that there is no way for implementation to i= nsert valid SRC_ASN .. well it clearly is.

But I am not suggesting spec should enforce it as it d= oes limit use cases for LC by not allowing to overload first 4 octets. On t= he other hand it does provide more responsibility to whoever is injecting L= Cs so does improve on BGP clarity and stability from protocol point of view= .

Fixing on meaning on= first 4 octets also provides very good tool to policy filtering rules as y= ou know what to expect there. For example you may have policy allowing to p= ass any LC where first 4 octets contain any ASN also listed in your AS_PATH= - otherwise drop it. That may effectively help to support LC global deploy= ment much easier including the N-hops away destinations.=C2=A0

Thx,
r.


On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler <phe= ssler@theapt.org> wrote:
On= 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk wrote:
:Hi Martijn,
:
:> Secondly, there's literally no way for the vendor to check whethe= r an
:> ASN belongs to "the entity that defines the meaning of the rest = of the
:> Large Community"
:
:Why not ?
:
:If you do not make those 4 octets configurable by spec and always fill it<= br> :with AS number defined in your BGP instance you will have assurance it
:is ASN of the entity that defines the rest 8 octets of the LC as otherwise=
:you will likely not establish any EBGP sessions to your peers.
:
:So there is very easy way to enforce it today in any BGP implementation.
Say I am AS 1234, and I want to control AS 5678.=C2=A0 My transit IS= P is AS
9876.

If I set

local-as 1234
peer-as 9876
set large-community 5678:666:1

How is the implementation supposed to know to allow it?

Limitations in the implementation completely defeat the purpose of this
spec.


:However the question is should it be enforced at all ?
:

MUST NOT is a very important part of this spec, and is enforced a few
times in the document.


:Best,
:R.
:




--
The moving cursor writes, and having written, blinks on.

--047d7bb03aaecd9583053f622d4c-- From nobody Fri Oct 21 09:20:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A775812965F for ; Fri, 21 Oct 2016 09:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 hR1GpeLCA5aT for ; Fri, 21 Oct 2016 09:20:20 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:470:1f0b:8b2::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C76129664 for ; Fri, 21 Oct 2016 09:20:19 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 37AC57891A; Fri, 21 Oct 2016 18:20:18 +0200 (CEST) Date: Fri, 21 Oct 2016 18:20:16 +0200 From: Peter Hessler To: Robert Raszuk Message-ID: <20161021162016.GS27221@gir.theapt.org> References: <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 16:20:21 -0000 Hi Robert On 2016 Oct 21 (Fri) at 18:03:09 +0200 (+0200), Robert Raszuk wrote: :Peter, : :Who you control (who is the target of LC - can be expressed in the second 4 :octets). And as such at least original discussions were about it. : :So if you inject a large community it would have format: :SRC_ASN:DST_ASN:ACTION : Ahh, I see the misunderstanding. The GA field is normally the ASN of the _entity defining that namespace_. aka, DEFINING_ASN:ACTION:DST_ASN. Sec 1 To address these shortcomings, this document defines a Large BGP Communities attribute encoded as one or more twelve-octet values, each consisting of a four-octet ASN and two four-octet operator- defined values, each of which can be used to denote properties or actions significant to that ASN. Sec 2: Global Administrator: A four-octet namespace identifier. This SHOULD be an Autonomous System Number. ... The Global Administrator field is intended to allow different Autonomous Systems to define Large BGP Communities without collision. To me, that means that 5678 has defined some values that they want me to use. The LD1 and LD2 values of them are opaque, and are defined by the operator who defined them. Critically, not by the one who sent it. :In your specific case it would be: 1234:5678:ACTION : :The comment was made that there is no way for implementation to insert :valid SRC_ASN .. well it clearly is. : :But I am not suggesting spec should enforce it as it does limit use cases :for LC by not allowing to overload first 4 octets. On the other hand it :does provide more responsibility to whoever is injecting LCs so does :improve on BGP clarity and stability from protocol point of view. : :Fixing on meaning on first 4 octets also provides very good tool to policy :filtering rules as you know what to expect there. For example you may have :policy allowing to pass any LC where first 4 octets contain any ASN also :listed in your AS_PATH - otherwise drop it. That may effectively help to :support LC global deployment much easier including the N-hops away :destinations. : :Thx, :r. : : :On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler wrote: : :> On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk wrote: :> :Hi Martijn, :> : :> :> Secondly, there's literally no way for the vendor to check whether an :> :> ASN belongs to "the entity that defines the meaning of the rest of the :> :> Large Community" :> : :> :Why not ? :> : :> :If you do not make those 4 octets configurable by spec and always fill it :> :with AS number defined in your BGP instance you will have assurance it :> :is ASN of the entity that defines the rest 8 octets of the LC as otherwise :> :you will likely not establish any EBGP sessions to your peers. :> : :> :So there is very easy way to enforce it today in any BGP implementation. :> :> Say I am AS 1234, and I want to control AS 5678. My transit ISP is AS :> 9876. :> :> If I set :> :> local-as 1234 :> peer-as 9876 :> set large-community 5678:666:1 :> :> How is the implementation supposed to know to allow it? :> :> Limitations in the implementation completely defeat the purpose of this :> spec. :> :> :> :However the question is should it be enforced at all ? :> : :> :> MUST NOT is a very important part of this spec, and is enforced a few :> times in the document. :> :> :> :Best, :> :R. :> : :> :> :> :> :> -- :> The moving cursor writes, and having written, blinks on. :> :_______________________________________________ :Idr mailing list :Idr@ietf.org :https://www.ietf.org/mailman/listinfo/idr -- Rules: (1) The boss is always right. (2) When the boss is wrong, refer to rule 1. From nobody Fri Oct 21 09:21:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F23012965F for ; Fri, 21 Oct 2016 09:21:56 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5mllSjAecAq5 for ; Fri, 21 Oct 2016 09:21:53 -0700 (PDT) Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B991297CD for ; Fri, 21 Oct 2016 09:21:51 -0700 (PDT) X-Footer: aTNkLm5s Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Fri, 21 Oct 2016 18:21:47 +0200 To: Robert Raszuk , Peter Hessler References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> From: "i3D.net - Martijn Schmidt" Organization: i3D.net Message-ID: <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> Date: Fri, 21 Oct 2016 18:21:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4EB5B720F67DE0BFB6E17689" Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 16:21:56 -0000 This is a multi-part message in MIME format. --------------4EB5B720F67DE0BFB6E17689 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi Robert, I think you're missing the point. Peter already explained that not every ASN we're trying to signal is necessarily a direct neighbor. So you've suggested to take a look at the BGP table instead to see if the ASN appears in any AS_PATH which is in the table. But many routers participating in the DFZ don't carry a full table, only a default route, so that information is not available to them. Nevertheless operators of those default-only networks frequently send communities to their upstream for inbound routing manipulation (prepends, localpref, RTBH, etc) to achieve a variety of goals; your suggestion would severely limit the draft's usefulness. Summarizing, any restrictions which can not be enforced don't belong in the IDR document because they're irrelevant to implementors. Arguing about it doesn't change the fact that such recommendations belong in a BCP/GROW document. It is that simple. Best regards, Martijn On 10/21/2016 06:03 PM, Robert Raszuk wrote: > Peter, > > Who you control (who is the target of LC - can be expressed in the > second 4 octets). And as such at least original discussions were about > it. > > So if you inject a large community it would have format: > SRC_ASN:DST_ASN:ACTION > > In your specific case it would be: 1234:5678:ACTION > > The comment was made that there is no way for implementation to insert > valid SRC_ASN .. well it clearly is. > > But I am not suggesting spec should enforce it as it does limit use > cases for LC by not allowing to overload first 4 octets. On the other > hand it does provide more responsibility to whoever is injecting LCs > so does improve on BGP clarity and stability from protocol point of view. > > Fixing on meaning on first 4 octets also provides very good tool to > policy filtering rules as you know what to expect there. For example > you may have policy allowing to pass any LC where first 4 octets > contain any ASN also listed in your AS_PATH - otherwise drop it. That > may effectively help to support LC global deployment much easier > including the N-hops away destinations. > > Thx, > r. > > > On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler > wrote: > > On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk wrote: > :Hi Martijn, > : > :> Secondly, there's literally no way for the vendor to check > whether an > :> ASN belongs to "the entity that defines the meaning of the rest > of the > :> Large Community" > : > :Why not ? > : > :If you do not make those 4 octets configurable by spec and always > fill it > :with AS number defined in your BGP instance you will have > assurance it > :is ASN of the entity that defines the rest 8 octets of the LC as > otherwise > :you will likely not establish any EBGP sessions to your peers. > : > :So there is very easy way to enforce it today in any BGP > implementation. > > Say I am AS 1234, and I want to control AS 5678. My transit ISP is AS > 9876. > > If I set > > local-as 1234 > peer-as 9876 > set large-community 5678:666:1 > > How is the implementation supposed to know to allow it? > > Limitations in the implementation completely defeat the purpose of > this > spec. > > > :However the question is should it be enforced at all ? > : > > MUST NOT is a very important part of this spec, and is enforced a few > times in the document. > > > :Best, > :R. > : > > > > > -- > The moving cursor writes, and having written, blinks on. > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- Met vriendelijke groet / Kindest regards, Martijn Schmidt i3D.net performance hosting *Martijn Schmidt | Network Architect* Email: martijnschmidt@i3d.net | Tel: +31 10 8900070 *i3D.net B.V. | Global Backbone AS49544* Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands VAT: NL 8202.63.886.B01 Website | Case Studies | LinkedIn --------------4EB5B720F67DE0BFB6E17689 Content-Type: multipart/related; boundary="------------6533AB4ACC4414E8CB9437CC" --------------6533AB4ACC4414E8CB9437CC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Robert,

I think you're missing the point. Peter already explained that not every ASN we're trying to signal is necessarily a direct neighbor. So you've suggested to take a look at the BGP table instead to see if the ASN appears in any AS_PATH which is in the table. But many routers participating in the DFZ don't carry a full table, only a default route, so that information is not available to them. Nevertheless operators of those default-only networks frequently send communities to their upstream for inbound routing manipulation (prepends, localpref, RTBH, etc) to achieve a variety of goals; your suggestion would severely limit the draft's usefulness.

Summarizing, any restrictions which can not be enforced don't belong in the IDR document because they're irrelevant to implementors. Arguing about it doesn't change the fact that such recommendations belong in a BCP/GROW document. It is that simple.

Best regards,
Martijn

On 10/21/2016 06:03 PM, Robert Raszuk wrote:
Peter,

Who you control (who is the target of LC - can be expressed in the second 4 octets). And as such at least original discussions were about it. 

So if you inject a large community it would have format: SRC_ASN:DST_ASN:ACTION

In your specific case it would be: 1234:5678:ACTION

The comment was made that there is no way for implementation to insert valid SRC_ASN .. well it clearly is.

But I am not suggesting spec should enforce it as it does limit use cases for LC by not allowing to overload first 4 octets. On the other hand it does provide more responsibility to whoever is injecting LCs so does improve on BGP clarity and stability from protocol point of view.

Fixing on meaning on first 4 octets also provides very good tool to policy filtering rules as you know what to expect there. For example you may have policy allowing to pass any LC where first 4 octets contain any ASN also listed in your AS_PATH - otherwise drop it. That may effectively help to support LC global deployment much easier including the N-hops away destinations. 

Thx,
r.


On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler <phessler@theapt.org> wrote:
On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk wrote:
:Hi Martijn,
:
:> Secondly, there's literally no way for the vendor to check whether an
:> ASN belongs to "the entity that defines the meaning of the rest of the
:> Large Community"
:
:Why not ?
:
:If you do not make those 4 octets configurable by spec and always fill it
:with AS number defined in your BGP instance you will have assurance it
:is ASN of the entity that defines the rest 8 octets of the LC as otherwise
:you will likely not establish any EBGP sessions to your peers.
:
:So there is very easy way to enforce it today in any BGP implementation.

Say I am AS 1234, and I want to control AS 5678.  My transit ISP is AS
9876.

If I set

local-as 1234
peer-as 9876
set large-community 5678:666:1

How is the implementation supposed to know to allow it?

Limitations in the implementation completely defeat the purpose of this
spec.


:However the question is should it be enforced at all ?
:

MUST NOT is a very important part of this spec, and is enforced a few
times in the document.


:Best,
:R.
:




--
The moving cursor writes, and having written, blinks on.



_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--
Met vriendelijke groet / Kindest regards,
Martijn Schmidt


i3D.net performance hosting
Martijn Schmidt | Network Architect
Email: martijnschmidt@i3d.net | Tel: +31 10 8900070

i3D.net B.V. | Global Backbone AS49544
Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands
VAT: NL 8202.63.886.B01

Website | Case Studies | LinkedIn

--------------6533AB4ACC4414E8CB9437CC Content-Type: image/png; name="i3Dlogo-email.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="i3Dlogo-email.png" iVBORw0KGgoAAAANSUhEUgAAAOkAAACCCAMAAACU2h9IAAAAGXRFWHRTb2Z0d2FyZQBBZG9i ZSBJbWFnZVJlYWR5ccllPAAAA0xpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tl dCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1l dGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUu Ni1jMTMyIDc5LjE1OTI4NCwgMjAxNi8wNC8xOS0xMzoxMzo0MCAgICAgICAgIj4gPHJkZjpS REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgt bnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9u cy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6MEM3NkQ1 NTY3NkE4MTFFNkI0OTI5NERBQkYxNEIxQUEiIHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6 MEM3NkQ1NTU3NkE4MTFFNkI0OTI5NERBQkYxNEIxQUEiIHhtcDpDcmVhdG9yVG9vbD0iQWRv YmUgUGhvdG9zaG9wIENDIDIwMTUuNSAoV2luZG93cykiPiA8eG1wTU06RGVyaXZlZEZyb20g c3RSZWY6aW5zdGFuY2VJRD0iYWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOmYwMGZmMDc1LTc2YTUt MTFlNi1iZDIzLWJhYTI4MGRmODBkYyIgc3RSZWY6ZG9jdW1lbnRJRD0iYWRvYmU6ZG9jaWQ6 cGhvdG9zaG9wOmYwMGZmMDc1LTc2YTUtMTFlNi1iZDIzLWJhYTI4MGRmODBkYyIvPiA8L3Jk ZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0i ciI/Pu9aRCwAAABgUExURf7+/uuxsufn5+ONj9nZ2fPz86qqq5SUlWNjZHt7fM/Pz7i4uFZW V4aGh0FBQsPDw0pKS/TU1T8/QN93efv29ttmaW9vcNU+Q/nq6vHIydhTV/bf4OijpNIjKkBA Qf///zh9ticAAAfaSURBVHja7Nxro3ssAABw5n4dj+x66Pt/ywddFEr6m5mtN8fZWvVDqYQB vyUYP+lP+rnSug+hIA4I3cCPs7pOszjwopMoLb+eDll8SVz7Hfs0rf8z1KVhkg1K7rvOIikK cWLvWhpOFj9zwWJpEy72bqUgER6hUENap56xT+lJUvbU1ZA2Z76zR+kplhba1ZFuS1WUOvFM oSMdaX0xdicN5sqcnXSktbc3abT48ChKU3tfUiNWKHSkI62DfUkjpebF0JHW9luk5z44y4sd akmTt0gFcexx9cqymTLz0hiHLB03ZWBHUm9QNq/toYPzsD3ODKGUHm7D9jLZqfBm6eD4nETV 156XTvRBvP1IAXfKpSfhwXaVpNBO39L6Kkht4SFwMmFFlUgH3ZB4P9JIfFXghze+ovTMnwpg N1JX2OwMdkKsKHV46Wk3Uq42XiQndmqoSWH8jsZXQZqI24/B0XEUpf5OpYG4S2MIz0Mp5sJ9 eX6D1O4DUJLC9EOl02WTSbOf9OBS58OlkceESCYFHy6VBU6awuNKDa3e4CdKHeGo5GjSUDjM OZrUFRb5YFKD86TOcaX8oO0CDyu1M/HU9pGkwOWhsXEw6Tlqg+sG2YK7FR8p9dVusBxXGjtf Io1P8DukgQO/QhpHBvwKqX+ajXaUY5q560odnwR8wyBC/7V71PPHoY3l+pNh5/XUGY6O3H6a KhDcovamLwnrt72jlUXrSC/7k9Y+eIUUD492JR1OGq4jxd/tSzr4xUpS741St50LTQJ/tDbD f4U0FkjTjAmdFG+TywEOa4zaQBSrr9LRlqLbAmNpMDMt6646Encuyqt09KXRHqQQxItX6SyW JruQDiZBFVfpLJN2Mxnvl/Jzg6qrdBZJu933fumgbQ9eIXX3IY1ecl8GSzNq2oGUX7uSrSsN 6ArKHUgHa1eMVaVeTH67AynUW6WjKPVIh3ArKXCYACYTXnedA5GeSe3fSrr5ig4idVI8cju8 FCdynpLOnGSfJiUVVTZqCw4hDfHI7fhSgJI/HV+KI0ZfIEXEZA/S+rVSG8+cbyTdfCVzL8UP 1CUjaRyQ4K4oVV6dXq+0Or2X4r0cb9RzcEXjFe0nDlL5EweMNBpGfKl09adIwpmnSBjpaVOp +MkgoPdkUDLzZBAj5U70149lUtFj0qs87XWRSr0tpYNS9zeGz+lrnuBjpedNpaOnMtssjTDR eCoTnhSeymSlbOv1eun4SdssjtNFT9riW9RxpvKkLStlexkbzK6oPBC/4tPTnNTbVOqqFDnW eyI+nJGGm0rB695ycIEzUiPbUqrymgN/vTdXcFKmT7+F1LgsLfK/vI3EmVq4stV874veMEPX gdhoYBJOSO0paT+WaYK96sy2nS07NkrSfl3lmd1fvLRv+WXrHFacw7clR1X3TVB9x1ImTTaW Qkf45iC9t3vVCdNnkEmjraVNcabf2OY5UEPqcznIpKftpdA4B8NOoN5b+LJkkL5MStPaUNp2 Is4eXouUxpdk+ZsV68wP3HDU15VKvfWlzD01+QvGjNH9kFGtFgRxgn2uxuCOC2DKBCbSNMb5 ghkpPHL4SX/Sn/Qn3am06kJpNm10RQLZfFhty00+NZvtm3WtrtYN8jGKZqtoUzPRryHMK/IR +SX6ApglziwnyRaoIM1W3v/p8+k2u2zMqv8JitZu38ZJS6VNHDCWVtUVcNLbFX1642MUBEg3 ulI9iNSi0pJmJpUy+Tyv5BfTUhMnDfqkZ6TNTyak1R8ntfCmxcfogM8mtQcnrYi0Arg4Zp+W VMrkU9BfTEutcdJiaQ5Bk3RJMqP5gqL9dPAxypGP0ZXmTlj04JKid991XzQfW93BKTope6Jx 0j4fQDZLNhYjfeCkS5J0KZWifIdSeO9NkNQ+8iUbo8D78kmlTb4Fgyc7vudIpUw+/aZAWoFR 0hrSfFaa91ILuck5W1q0JWoq3L9Ki6IQSe+bS8u2rlxRjObgWiZticq2EmtKb7he8LF66aNp J7aVFu1fq/3TxmgOrnlHVaZts6pBcfI8V5W2jRzTnI6kFmpfuNZEQ9o1HVIpitE2NO1xK9o/ FWp6zT7ys5oojqrU7JvnKWnzNVgipW0vafa7T28luVzhFmckxTGKLse2wqB2ub1KdDHwZb05 p29TUvaiQC8hA2l3xaFHdSRt0mXaTXo9V7ueFky+JZBIaYwmg+YrE3R/KnSRAa0PlaYtrKkt 7boEhDqSNmf330Jp30dipXc4J70jWLNvrbw7UVGMKzrSqDT3Cp/WOlJEtURS0jaoSkm/Nx/m m0vqKY1RdJW8NFFdbzpz3e76o9dRwHS9ltZTQjUFUpNPerbt5ZJh66klbZFwjFZatG0sbnjy 7lPanpHenc5VBk0qPXAnekL6XEO6pI/UHsEr6pB2xkdRlOTXcGrHK7e9pomyuU1L4XUN6YLr KcKYKKc/emoDejrrSvnDOyG1tpbmjLRgKjEzWnuN1HyFdDSWYaSAgV3pgAbTSXGYAYfiWAaW ZBMIpM9qOExSkvKN5EjKj085aVdfAGlqH1iKe4GkOBrjU5OLNiGF1yXjU1UpP+fASws6ZMn7 uZaCnE6P4cSA6pwD/sn1KZQWw+kMDSmo8CiE9ii5eSQao8DNUEEvcX9Y+iBSS3seCVgPsjkt NRXnkeC3hJ/0J/1Jf9Kf9Cd9XfhfgAEA6npi4QQJPOEAAAAASUVORK5CYII= --------------6533AB4ACC4414E8CB9437CC-- --------------4EB5B720F67DE0BFB6E17689-- From nobody Fri Oct 21 09:29:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98273129531 for ; Fri, 21 Oct 2016 09:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GAB9DmnExnQb for ; Fri, 21 Oct 2016 09:29:51 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326E0129413 for ; Fri, 21 Oct 2016 09:29:50 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id c78so25865wme.0 for ; Fri, 21 Oct 2016 09:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Y/0YSwmN1SAApcC791FRtNEr8qkAGvj/05DHHF1kh58=; b=PB5hujPWdpU/MpPTaUZkydkiAxSIuwdoPdYLAu8e2DjrRtlQu5hxcCjNPFtBcRi/P5 zaKkWALoj7HzsDM/dshpVOzR4uZ5BXifEDfvGyKV2yI0ZWjXQ93vMoJoWgZS3bkLrbHw imzbRP36zmZ/bkf8HUt1pDU+Bu1G2gTz35g0dbof79dXxyMYjmjLvAwVzRolFBvtoQao jNIGsAGdoFtz/Z5lTF/P8rNShYMtOaafCaic6mmvyFxC+K4xSSe6PnzUqHmP65o4LTGL m8S7wTeORvlPtDsQ/Z3IuDsOHiiLQsVpwL5lz+iJLmyf72CX4DC3d4mSLyvYyufGMWkg g8VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Y/0YSwmN1SAApcC791FRtNEr8qkAGvj/05DHHF1kh58=; b=CCqDwtVYg4jyfw+gQAG3Wo/5mLEz+U12BDG3haWbqg5c8eH847qHS0u4h88KBz4l5B Dd4yJCFhz4tCU/AmB9Xrv1VtW43ilYzV0neO+6P1yJtkE2n4lKbmoKS6GyoOo9Wl2258 3FO/zufjbQ8xy0Z+f2yns4KwoAqgEzVR7pOH4FvZsir21VdZN5Ty/xx+eRPI9Qrw5iPz ZlsqHwq4GQUrP5jIBut6dI8kokmjVJLokmpx4DSxdYC633Ph10fJ5MVyGC+mBVOHwdtF 2xVU4Az6bzg+n+yMSWzyg5FktkBZLl3uu88DuRnha7YnHGSZdzeRbhbhwKvPzefhSDjQ uJSQ== X-Gm-Message-State: AA6/9RlM3cGeEqBSaSvtWPgfL33dkSqJlaLQcULMrl+8qxRFEcBU+faU9c/IcDxG4TelripcXZ6/tGwxtvLobg== X-Received: by 10.28.163.196 with SMTP id m187mr10464015wme.73.1477067388697; Fri, 21 Oct 2016 09:29:48 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Fri, 21 Oct 2016 09:29:46 -0700 (PDT) In-Reply-To: <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> From: Robert Raszuk Date: Fri, 21 Oct 2016 18:29:46 +0200 X-Google-Sender-Auth: H5-94HhHuErYKcdHOA38fho3lqU Message-ID: To: "i3D.net - Martijn Schmidt" Content-Type: multipart/related; boundary=001a114cd9a203b390053f628d1c Archived-At: Cc: IETF IDR WG , Peter Hessler Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 16:29:53 -0000 --001a114cd9a203b390053f628d1c Content-Type: multipart/alternative; boundary=001a114cd9a203b38c053f628d1b --001a114cd9a203b38c053f628d1b Content-Type: text/plain; charset=UTF-8 Martijn, > I think you're missing the point. I don't think it's me :) > Peter already explained that not every ASN we're trying to signal is necessarily a direct neighbor. I never made any such assumption. > So you've suggested to take a look at the BGP table instead to see if the ASN appears in any AS_PATH which is in the table. Nope ... not at all. The policy example was nothing to do with BGP table. If I am receiving BGP_UPDATE it comes with AS_PATH and may contain LC. So if I want very simple policy to filter trash of LCs I can set it to match first 4 octets to any ASN present in the same UPDATE MSG AS_PATH attribute. If it there I do not drop LC. For stub ASes we could treat their AS_NUMBERS in LCs exactly in the same way we treat them in AS_PATH today. Cheers, R. On Fri, Oct 21, 2016 at 6:21 PM, i3D.net - Martijn Schmidt < martijnschmidt@i3d.net> wrote: > Hi Robert, > > I think you're missing the point. Peter already explained that not every > ASN we're trying to signal is necessarily a direct neighbor. So you've > suggested to take a look at the BGP table instead to see if the ASN appears > in any AS_PATH which is in the table. But many routers participating in the > DFZ don't carry a full table, only a default route, so that information is > not available to them. Nevertheless operators of those default-only > networks frequently send communities to their upstream for inbound routing > manipulation (prepends, localpref, RTBH, etc) to achieve a variety of > goals; your suggestion would severely limit the draft's usefulness. > > Summarizing, any restrictions which can not be enforced don't belong in > the IDR document because they're irrelevant to implementors. Arguing about > it doesn't change the fact that such recommendations belong in a BCP/GROW > document. It is that simple. > > Best regards, > Martijn > > > On 10/21/2016 06:03 PM, Robert Raszuk wrote: > > Peter, > > Who you control (who is the target of LC - can be expressed in the second > 4 octets). And as such at least original discussions were about it. > > So if you inject a large community it would have format: > SRC_ASN:DST_ASN:ACTION > > In your specific case it would be: 1234:5678:ACTION > > The comment was made that there is no way for implementation to insert > valid SRC_ASN .. well it clearly is. > > But I am not suggesting spec should enforce it as it does limit use cases > for LC by not allowing to overload first 4 octets. On the other hand it > does provide more responsibility to whoever is injecting LCs so does > improve on BGP clarity and stability from protocol point of view. > > Fixing on meaning on first 4 octets also provides very good tool to policy > filtering rules as you know what to expect there. For example you may have > policy allowing to pass any LC where first 4 octets contain any ASN also > listed in your AS_PATH - otherwise drop it. That may effectively help to > support LC global deployment much easier including the N-hops away > destinations. > > Thx, > r. > > > On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler > wrote: > >> On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk wrote: >> :Hi Martijn, >> : >> :> Secondly, there's literally no way for the vendor to check whether an >> :> ASN belongs to "the entity that defines the meaning of the rest of the >> :> Large Community" >> : >> :Why not ? >> : >> :If you do not make those 4 octets configurable by spec and always fill it >> :with AS number defined in your BGP instance you will have assurance it >> :is ASN of the entity that defines the rest 8 octets of the LC as >> otherwise >> :you will likely not establish any EBGP sessions to your peers. >> : >> :So there is very easy way to enforce it today in any BGP implementation. >> >> Say I am AS 1234, and I want to control AS 5678. My transit ISP is AS >> 9876. >> >> If I set >> >> local-as 1234 >> peer-as 9876 >> set large-community 5678:666:1 >> >> How is the implementation supposed to know to allow it? >> >> Limitations in the implementation completely defeat the purpose of this >> spec. >> >> >> :However the question is should it be enforced at all ? >> : >> >> MUST NOT is a very important part of this spec, and is enforced a few >> times in the document. >> >> >> :Best, >> :R. >> : >> >> >> >> >> -- >> The moving cursor writes, and having written, blinks on. >> > > > > _______________________________________________ > Idr mailing listIdr@ietf.orghttps://www.ietf.org/mailman/listinfo/idr > > > -- > Met vriendelijke groet / Kindest regards, > Martijn Schmidt > > > [image: i3D.net performance hosting] > *Martijn Schmidt | Network Architect* > Email: martijnschmidt@i3d.net | Tel: +31 10 > 8900070 > > *i3D.net B.V. | Global Backbone AS49544* > Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands > VAT: NL 8202.63.886.B01 > > Website > > | Case Studies > > | LinkedIn > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a114cd9a203b38c053f628d1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martijn,

>=C2=A0I think you're missing the point.

I don't think it's me :)
=
> Peter already explained that not every ASN we&#= 39;re trying to signal is necessarily a direct neighbor.=C2=A0
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
I never made any such assumption.=C2=A0<= /div>

>=C2=A0So you've suggested to take a loo= k at the BGP table instead to see if the ASN appears in any AS_PATH which i= s in the table.=C2=A0


<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">Nope ... not at all.=C2=A0

T= he policy example was nothing to do with BGP table. If I am receiving BGP_U= PDATE it comes with AS_PATH and may contain LC. So if I want very simple po= licy to filter trash of LCs I can set it to match first 4 octets to any ASN= present in the same UPDATE MSG AS_PATH attribute. If it there I do not dro= p LC.=C2=A0

For stub ASes we could treat their AS_NUM= BERS in LCs exactly in the same way we treat them in AS_PATH today.=C2=A0

Cheers,
R.




On = Fri, Oct 21, 2016 at 6:21 PM, i3D.net - Martijn Schmidt &= lt;martijnschmi= dt@i3d.net> wrote:
=20 =20 =20
Hi Robert,

I think you're missing the point. Peter already explained that not every ASN we're trying to signal is necessarily a direct neighbor. So you've suggested to take a look at the BGP table instead to see if the ASN appears in any AS_PATH which is in the table. But many routers participating in the DFZ don't carry a full table, only a default route, so that information is not available to them. Nevertheless operators of those default-only networks frequently send communities to their upstream for inbound routing manipulation (prepends, localpref, RTBH, etc) to achieve a variety of goals; your suggestion would severely limit the draft's usefulness.

Summarizing, any restrictions which can not be enforced don't belon= g in the IDR document because they're irrelevant to implementors. Arguing about it doesn't change the fact that such recommendations belong in a BCP/GROW document. It is that simple.

Best regards,
Martijn


On 10/21/2016 06:03= PM, Robert Raszuk wrote:
Peter,

Who you control (who is the target of LC - can be expressed in the second 4 octets). And as such at least original discussions were about it.=C2=A0

So if you inject a large community it would have format: SRC_ASN:DST_ASN:ACTION

In your specific case it would be: 1234:5678:ACTION

The comment was made that there is no way for implementation to insert valid SRC_ASN .. well it clearly is.

But I am not suggesting spec should enforce it as it does limit use cases for LC by not allowing to overload first 4 octets. On the other hand it does provide more responsibility to whoever is injecting LCs so does improve on BGP clarity and stability from protocol point of view.

Fixing on meaning on first 4 octets also provides very good tool to policy filtering rules as you know what to expect there. For example you may have policy allowing to pass any LC where first 4 octets contain any ASN also listed in your AS_PATH - otherwise drop it. That may effectively help to support LC global deployment much easier including the N-hops away destinations.=C2=A0

Thx,
r.


On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler <phessler@theapt.org> wrote:
On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk wrote: :Hi Martijn,
:
:> Secondly, there's literally no way for the vendor t= o check whether an
:> ASN belongs to "the entity that defines the meanin= g of the rest of the
:> Large Community"
:
:Why not ?
:
:If you do not make those 4 octets configurable by spec and always fill it
:with AS number defined in your BGP instance you will have assurance it
:is ASN of the entity that defines the rest 8 octets of the LC as otherwise
:you will likely not establish any EBGP sessions to your peers.
:
:So there is very easy way to enforce it today in any BGP implementation.

Say I am AS 1234, and I want to control AS 5678.=C2=A0 M= y transit ISP is AS
9876.

If I set

local-as 1234
peer-as 9876
set large-community 5678:666:1

How is the implementation supposed to know to allow it?

Limitations in the implementation completely defeat the purpose of this
spec.


:However the question is should it be enforced at all ?
:

MUST NOT is a very important part of this spec, and is enforced a few
times in the document.


:Best,
:R.
:




--
The moving cursor writes, and having written, blinks on. 



______________________________=
_________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mail=
man/listinfo/idr

--
Met vriendelijke groet / Kindest regards,
Martijn Schmidt


3D"i3D.n=
Martijn Schmidt | Network Architect
Email: martijnschmidt@i3d.net | Tel: +31 10 8900070

i3D.net B.V. | Global Backbone AS49544
Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands
VAT: NL 8202.63.886.B01

Website | Case Studies | LinkedIn


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--001a114cd9a203b38c053f628d1b-- --001a114cd9a203b390053f628d1c Content-Type: image/png; name="i3Dlogo-email.png" Content-Disposition: inline; filename="i3Dlogo-email.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f06d242e5a926ba8_0.0.1.1 iVBORw0KGgoAAAANSUhEUgAAAOkAAACCCAMAAACU2h9IAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAAA0xpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdp bj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6 eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuNi1jMTMyIDc5LjE1 OTI4NCwgMjAxNi8wNC8xOS0xMzoxMzo0MCAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJo dHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVz b3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1N OkRvY3VtZW50SUQ9InhtcC5kaWQ6MEM3NkQ1NTY3NkE4MTFFNkI0OTI5NERBQkYxNEIxQUEiIHht cE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6MEM3NkQ1NTU3NkE4MTFFNkI0OTI5NERBQkYxNEIxQUEi IHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENDIDIwMTUuNSAoV2luZG93cykiPiA8 eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0iYWRvYmU6ZG9jaWQ6cGhvdG9zaG9w OmYwMGZmMDc1LTc2YTUtMTFlNi1iZDIzLWJhYTI4MGRmODBkYyIgc3RSZWY6ZG9jdW1lbnRJRD0i YWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOmYwMGZmMDc1LTc2YTUtMTFlNi1iZDIzLWJhYTI4MGRmODBk YyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0 IGVuZD0iciI/Pu9aRCwAAABgUExURf7+/uuxsufn5+ONj9nZ2fPz86qqq5SUlWNjZHt7fM/Pz7i4 uFZWV4aGh0FBQsPDw0pKS/TU1T8/QN93efv29ttmaW9vcNU+Q/nq6vHIydhTV/bf4OijpNIjKkBA Qf///zh9ticAAAfaSURBVHja7Nxro3ssAABw5n4dj+x66Pt/ywddFEr6m5mtN8fZWvVDqYQBvyUY P+lP+rnSug+hIA4I3cCPs7pOszjwopMoLb+eDll8SVz7Hfs0rf8z1KVhkg1K7rvOIikKcWLvWhpO Fj9zwWJpEy72bqUgER6hUENap56xT+lJUvbU1ZA2Z76zR+kplhba1ZFuS1WUOvFMoSMdaX0xdicN 5sqcnXSktbc3abT48ChKU3tfUiNWKHSkI62DfUkjpebF0JHW9luk5z44y4sdakmTt0gFcexx9cqy mTLz0hiHLB03ZWBHUm9QNq/toYPzsD3ODKGUHm7D9jLZqfBm6eD4nETV156XTvRBvP1IAXfKpSfh wXaVpNBO39L6Kkht4SFwMmFFlUgH3ZB4P9JIfFXghze+ovTMnwpgN1JX2OwMdkKsKHV46Wk3Uq42 XiQndmqoSWH8jsZXQZqI24/B0XEUpf5OpYG4S2MIz0Mp5sJ9eX6D1O4DUJLC9EOl02WTSbOf9OBS 58OlkceESCYFHy6VBU6awuNKDa3e4CdKHeGo5GjSUDjMOZrUFRb5YFKD86TOcaX8oO0CDyu1M/HU 9pGkwOWhsXEw6Tlqg+sG2YK7FR8p9dVusBxXGjtfIo1P8DukgQO/QhpHBvwKqX+ajXaUY5q560od nwR8wyBC/7V71PPHoY3l+pNh5/XUGY6O3H6aKhDcovamLwnrt72jlUXrSC/7k9Y+eIUUD492JR1O Gq4jxd/tSzr4xUpS741St50LTQJ/tDbDf4U0FkjTjAmdFG+TywEOa4zaQBSrr9LRlqLbAmNpMDMt 6646Encuyqt09KXRHqQQxItX6SyWJruQDiZBFVfpLJN2Mxnvl/Jzg6qrdBZJu933fumgbQ9eIXX3 IY1ecl8GSzNq2oGUX7uSrSsN6ArKHUgHa1eMVaVeTH67AynUW6WjKPVIh3ArKXCYACYTXnedA5Ge Se3fSrr5ig4idVI8cju8FCdynpLOnGSfJiUVVTZqCw4hDfHI7fhSgJI/HV+KI0ZfIEXEZA/S+rVS G8+cbyTdfCVzL8UP1CUjaRyQ4K4oVV6dXq+0Or2X4r0cb9RzcEXjFe0nDlL5EweMNBpGfKl09adI wpmnSBjpaVOp+MkgoPdkUDLzZBAj5U70149lUtFj0qs87XWRSr0tpYNS9zeGz+lrnuBjpedNpaOn MtssjTDReCoTnhSeymSlbOv1eun4SdssjtNFT9riW9RxpvKkLStlexkbzK6oPBC/4tPTnNTbVOqq FDnWeyI+nJGGm0rB695ycIEzUiPbUqrymgN/vTdXcFKmT7+F1LgsLfK/vI3EmVq4stV874veMEPX gdhoYBJOSO0paT+WaYK96sy2nS07NkrSfl3lmd1fvLRv+WXrHFacw7clR1X3TVB9x1ImTTaWQkf4 5iC9t3vVCdNnkEmjraVNcabf2OY5UEPqcznIpKftpdA4B8NOoN5b+LJkkL5MStPaUNp2Is4eXouU xpdk+ZsV68wP3HDU15VKvfWlzD01+QvGjNH9kFGtFgRxgn2uxuCOC2DKBCbSNMb5ghkpPHL4SX/S n/Qn3am06kJpNm10RQLZfFhty00+NZvtm3WtrtYN8jGKZqtoUzPRryHMK/IR+SX6ApglziwnyRao IM1W3v/p8+k2u2zMqv8JitZu38ZJS6VNHDCWVtUVcNLbFX1642MUBEg3ulI9iNSi0pJmJpUy+Tyv 5BfTUhMnDfqkZ6TNTyak1R8ntfCmxcfogM8mtQcnrYi0Arg4Zp+WVMrkU9BfTEutcdJiaQ5Bk3RJ MqP5gqL9dPAxypGP0ZXmTlj04JKid991XzQfW93BKTope6Jx0j4fQDZLNhYjfeCkS5J0KZWifIdS eO9NkNQ+8iUbo8D78kmlTb4Fgyc7vudIpUw+/aZAWoFR0hrSfFaa91ILuck5W1q0JWoq3L9Ki6IQ Se+bS8u2rlxRjObgWiZticq2EmtKb7he8LF66aNpJ7aVFu1fq/3TxmgOrnlHVaZts6pBcfI8V5W2 jRzTnI6kFmpfuNZEQ9o1HVIpitE2NO1xK9o/FWp6zT7ys5oojqrU7JvnKWnzNVgipW0vafa7T28l uVzhFmckxTGKLse2wqB2ub1KdDHwZb05p29TUvaiQC8hA2l3xaFHdSRt0mXaTXo9V7ueFky+JZBI aYwmg+YrE3R/KnSRAa0PlaYtrKkt7boEhDqSNmf330Jp30dipXc4J70jWLNvrbw7UVGMKzrSqDT3 Cp/WOlJEtURS0jaoSkm/Nx/mm0vqKY1RdJW8NFFdbzpz3e76o9dRwHS9ltZTQjUFUpNPerbt5ZJh 66klbZFwjFZatG0sbnjy7lPanpHenc5VBk0qPXAnekL6XEO6pI/UHsEr6pB2xkdRlOTXcGrHK7e9 pomyuU1L4XUN6YLrKcKYKKc/emoDejrrSvnDOyG1tpbmjLRgKjEzWnuN1HyFdDSWYaSAgV3pgAbT SXGYAYfiWAaWZBMIpM9qOExSkvKN5EjKj085aVdfAGlqH1iKe4GkOBrjU5OLNiGF1yXjU1UpP+fA Sws6ZMn7uZaCnE6P4cSA6pwD/sn1KZQWw+kMDSmo8CiE9ii5eSQao8DNUEEvcX9Y+iBSS3seCVgP sjktNRXnkeC3hJ/0J/1Jf9Kf9Cd9XfhfgAEA6npi4QQJPOEAAAAASUVORK5CYII= --001a114cd9a203b390053f628d1c-- From nobody Fri Oct 21 09:42:51 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F286E1295EC for ; Fri, 21 Oct 2016 09:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 xdcDwvkLO4oO for ; Fri, 21 Oct 2016 09:42:47 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D2C1293FF for ; Fri, 21 Oct 2016 09:42:46 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id c78so5061156wme.0 for ; Fri, 21 Oct 2016 09:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=kR5ZMf/HWl17dbjKMEspJGO0NK0XVbOo43MUtGWK+Ek=; b=AjloXdndn7buT3YGjH3b0JSKLNMJs5SDo5v/MGdrdae+DpOS7lGhHNFJit2C+eVv+6 3uDNB2sI9k02z8t2rO0JrhYz9CR1RKzI+xv2M2aArTbUqASoGcb6+H78MVj5MmOCveb4 fx0sHo/n3josoYyoWGN+DL0oU37seXW3QOYfI59eGZL6y5rmGjyetc8XVjPt2S7frrcT wJy94NLW6mi7YggvfCa635ywvlneQoJyQfhBCfYqz0qPkgCUcuTDsIKQraKKTsXgXXOD AcmXyZgzxaJcfJ4n+j/vhgXlUhCVjN1Af/48Usj1QmRvlw8+qnh59B+06GNEN0/8TXnN rftQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=kR5ZMf/HWl17dbjKMEspJGO0NK0XVbOo43MUtGWK+Ek=; b=CQBVG/PdEDecxzlwp0ld57CvL5JCVqSUPCUE7xJgoBR79SIzgAIqbRHAcm/c5vIMen /bQTXH1Tym0Vc+Omri0gqZwB2fmjgqH9v9rOAAF88f10Y8QiOc4fVnSwh2ot/x4uEweE pMBZIwryk1UjE7UlDToShMTW/uAe8EW0sJJfVZUsGTQeNXRLz8yKHGBf7xcXkn+RiQnW +ZiYZuarigOJYhLG2hDYFvmPNGIxeTiidKFQQUznm9m4VPvE1MUjsboIaT+9p6IfkEKQ m+Inua4afRTdAv5C8dxjQtoPYBxJr/bUnH4Az7X3Iah+pTbRGYPuJmqdtviccF0jynf5 l6XQ== X-Gm-Message-State: ABUngvdU8kv5GFE1Vse1SPJic2QJ9H6JHiFQudiPMU9TbaOS9DW9e8F7nReFlkeCUoZ9HA== X-Received: by 10.194.23.66 with SMTP id k2mr1466908wjf.108.1477068165476; Fri, 21 Oct 2016 09:42:45 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:6005:541c:1498:4975]) by smtp.gmail.com with ESMTPSA id 1sm5001846wmk.22.2016.10.21.09.42.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Oct 2016 09:42:44 -0700 (PDT) Date: Fri, 21 Oct 2016 18:42:41 +0200 From: Job Snijders To: Robert Raszuk Message-ID: <20161021164241.GC32387@Vurt.local> References: <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: IETF IDR WG , Peter Hessler Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 16:42:49 -0000 On Fri, Oct 21, 2016 at 06:29:46PM +0200, Robert Raszuk wrote: > The policy example was nothing to do with BGP table. If I am receiving > BGP_UPDATE it comes with AS_PATH and may contain LC. So if I want very > simple policy to filter trash of LCs I can set it to match first 4 > octets to any ASN present in the same UPDATE MSG AS_PATH attribute. If > it there I do not drop LC. A clever trick, but not a good fit for Large BGP Communities. Large BGP Communities are opaque, by definition and design. We want routing policy in which networks can send 2914:X:Y to us, and we can send 2914:A:B to them - very much like RFC 1997 communities. The Global Administator field does not necessarily contain the ASN of the sending party. Kind regards, Job From nobody Fri Oct 21 09:49:56 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3932D129436 for ; Fri, 21 Oct 2016 09:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WwVT0cs7fWkL for ; Fri, 21 Oct 2016 09:49:53 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22049129485 for ; Fri, 21 Oct 2016 09:49:53 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id d199so366120wmd.1 for ; Fri, 21 Oct 2016 09:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mBEqviNs0xRHIyF6zOAg/24UcBbv7OyVD3JWpA/vn34=; b=ZFlJZarZX8MXgGBGddSoJHomJ+f0WdkQXJPx8F37/+o+ja9TzAAtYUb9cxRPNbhL2+ PkP2gru/TJKhq++AQJErCRpmFrNse3URk1TGKHMt4vSEWn5MUrv2gAKHVLXBYtvamJ4D cgj77cjEPbwW2FHsMtZTxXlxmQnlw4QABiUy/HMeisJnjRvzI+/ifWBDZu4pug1Ghnh9 jsAtySeWvFWGSBfnoG2ScCUMPTSXNY35L74g48I1Hv0IsJGDg9ARePyT8OjcvSVB/VKF EHdpVcbgix1nO5sEXsyGDh2F5Se2vWNalfbOFBLhizCkgMjO3nL8z3XEwoqxY/3HNad9 Tdhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mBEqviNs0xRHIyF6zOAg/24UcBbv7OyVD3JWpA/vn34=; b=TpwnEIJe0gSSUEorlF5/u8Qoawsw9VaDtqz1Ekmn/GCEyeUpfbny/nZvB0R2WdI6dq UCbWJPaIpG/Kyq2IxdEpcGf5lD7/Y9ik1copqjrp/pn44kE/PEbdRTs+LaAQK7WwSlSI ce/vgpQz066DFhowt3istigihT0248yFh1kwCSKUNveCpz/JBswaJs1sWMSbqV8X2lP7 zMbbLcleoQp7iw7qdKGKg1zHYIk41+EWqgOdGIxt/aiydMEAE6+waf7Kv1DTNj4UFaJf fdHMzmlwDIhZkc5apbb11w5bHnDdI/ypXPHZL6tTg90OjLztWoct/mlo2u1S38344r0s Dv8A== X-Gm-Message-State: ABUngvdgdhGNLvHeR6sPHUZCf/ZpDEWMofoWlFsbGXuTWaOFEJ+ekYAeEcIWkokphhf7Iu34NFHTPRSemAYSQw== X-Received: by 10.195.13.107 with SMTP id ex11mr1446664wjd.99.1477068591527; Fri, 21 Oct 2016 09:49:51 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Fri, 21 Oct 2016 09:49:49 -0700 (PDT) In-Reply-To: <20161021164241.GC32387@Vurt.local> References: <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> From: Robert Raszuk Date: Fri, 21 Oct 2016 18:49:49 +0200 X-Google-Sender-Auth: 9XGLB1USStoG3eVOL7RnaTuYEoE Message-ID: To: Job Snijders Content-Type: multipart/alternative; boundary=047d7bfcedbeb4fe6d053f62d4e8 Archived-At: Cc: IETF IDR WG , Peter Hessler Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 16:49:55 -0000 --047d7bfcedbeb4fe6d053f62d4e8 Content-Type: text/plain; charset=UTF-8 Hey Job, That's what I thought ... but if so I do not get why there are so many discussions of any MUSTs/SHOULDs/MAYs operators are expected to follow on in the fields LCs provides. If they are opaque that means there is zero structure in place and everyone is free to put whatever he/she likes in it .. even hex encoded Morse ( https://goo.gl/rHcGeV) We either allow all opaque and free style or we structure fields such that for example they may be used in simple parametrized BGP in/out policy example I provided. And the excuses type "oh we can not structure it as there is no way to insert valid ASN" are wrong as there is a way as proven :) Cheers, R. On Fri, Oct 21, 2016 at 6:42 PM, Job Snijders wrote: > On Fri, Oct 21, 2016 at 06:29:46PM +0200, Robert Raszuk wrote: > > The policy example was nothing to do with BGP table. If I am receiving > > BGP_UPDATE it comes with AS_PATH and may contain LC. So if I want very > > simple policy to filter trash of LCs I can set it to match first 4 > > octets to any ASN present in the same UPDATE MSG AS_PATH attribute. If > > it there I do not drop LC. > > A clever trick, but not a good fit for Large BGP Communities. Large BGP > Communities are opaque, by definition and design. > > We want routing policy in which networks can send 2914:X:Y to us, and we > can send 2914:A:B to them - very much like RFC 1997 communities. The > Global Administator field does not necessarily contain the ASN of the > sending party. > > Kind regards, > > Job > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7bfcedbeb4fe6d053f62d4e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Job,

That's what I thought ... but if so I do not get= why there are so many discussions of any MUSTs/SHOULDs/MAYs operators are = expected to follow on in the fields LCs provides.=C2=A0

If they are opaque that means there is ze= ro structure in place and everyone is free to put whatever he/she likes in = it .. even hex encoded Morse (https://goo= .gl/rHcGeV)

We eit= her allow all opaque and free style or we structure fields such that for ex= ample they may be used in simple parametrized BGP in/out policy example I p= rovided.=C2=A0

And the= excuses type "oh we can not structure it as there is no way to insert= valid ASN" are wrong as there is a way as proven :)

Cheers,
R.



On Fri, Oct 21, 2016 at 6= :42 PM, Job Snijders <job@instituut.net> wrote:
On Fri, Oct 21, 2016 at 06:29:46PM += 0200, Robert Raszuk wrote:
> The policy example was nothing to do with BGP table. If I am receiving=
> BGP_UPDATE it comes with AS_PATH and may contain LC. So if I want very=
> simple policy to filter trash of LCs I can set it to match first 4
> octets to any ASN present in the same UPDATE MSG AS_PATH attribute. If=
> it there I do not drop LC.

A clever trick, but not a good fit for Large BGP Communities. Large = BGP
Communities are opaque, by definition and design.

We want routing policy in which networks can send 2914:X:Y to us, and we can send 2914:A:B to them - very much like RFC 1997 communities. The
Global Administator field does not necessarily contain the ASN of the
sending party.

Kind regards,

Job

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--047d7bfcedbeb4fe6d053f62d4e8-- From nobody Fri Oct 21 10:03:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7563F129522 for ; Fri, 21 Oct 2016 10:03:46 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 v-CxuoHWLum6 for ; Fri, 21 Oct 2016 10:03:44 -0700 (PDT) Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B1312944D for ; Fri, 21 Oct 2016 10:03:43 -0700 (PDT) X-Footer: aTNkLm5s Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Fri, 21 Oct 2016 19:03:37 +0200 To: Robert Raszuk References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> From: "i3D.net - Martijn Schmidt" Message-ID: Date: Fri, 21 Oct 2016 19:03:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------66B14E4A2CFEC51A753F2932" Archived-At: Cc: IETF IDR WG , Peter Hessler Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 17:03:46 -0000 This is a multi-part message in MIME format. --------------66B14E4A2CFEC51A753F2932 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hey Robert, I see that you stated the first field would be filled in automatically by the "local-as" value defined in your BGP config. That means we'll be back to two user-customizable fields, so action communities sent between ASN's are effectively going to collide again and we're back to the same old RFC1997 problem. It's not an option. I'll get back to the other part of your message in a minute, so I can include the discussion you've already had with Job. Best regards, Martijn On 10/21/2016 06:29 PM, Robert Raszuk wrote: > Martijn, > > > I think you're missing the point. > > I don't think it's me :) > > > Peter already explained that not every ASN we're trying to signal is > necessarily a direct neighbor. > > I never made any such assumption. > > > So you've suggested to take a look at the BGP table instead to see if > the ASN appears in any AS_PATH which is in the table. > > > Nope ... not at all. > > The policy example was nothing to do with BGP table. If I am receiving > BGP_UPDATE it comes with AS_PATH and may contain LC. So if I want very > simple policy to filter trash of LCs I can set it to match first 4 > octets to any ASN present in the same UPDATE MSG AS_PATH attribute. If > it there I do not drop LC. > > For stub ASes we could treat their AS_NUMBERS in LCs exactly in the > same way we treat them in AS_PATH today. > > Cheers, > R. > > > > > > On Fri, Oct 21, 2016 at 6:21 PM, i3D.net - Martijn Schmidt > > wrote: > > Hi Robert, > > I think you're missing the point. Peter already explained that not > every ASN we're trying to signal is necessarily a direct neighbor. > So you've suggested to take a look at the BGP table instead to see > if the ASN appears in any AS_PATH which is in the table. But many > routers participating in the DFZ don't carry a full table, only a > default route, so that information is not available to them. > Nevertheless operators of those default-only networks frequently > send communities to their upstream for inbound routing > manipulation (prepends, localpref, RTBH, etc) to achieve a variety > of goals; your suggestion would severely limit the draft's usefulness. > > Summarizing, any restrictions which can not be enforced don't > belong in the IDR document because they're irrelevant to > implementors. Arguing about it doesn't change the fact that such > recommendations belong in a BCP/GROW document. It is that simple. > > Best regards, > Martijn > > > On 10/21/2016 06:03 PM, Robert Raszuk wrote: >> Peter, >> >> Who you control (who is the target of LC - can be expressed in >> the second 4 octets). And as such at least original discussions >> were about it. >> >> So if you inject a large community it would have format: >> SRC_ASN:DST_ASN:ACTION >> >> In your specific case it would be: 1234:5678:ACTION >> >> The comment was made that there is no way for implementation to >> insert valid SRC_ASN .. well it clearly is. >> >> But I am not suggesting spec should enforce it as it does limit >> use cases for LC by not allowing to overload first 4 octets. On >> the other hand it does provide more responsibility to whoever is >> injecting LCs so does improve on BGP clarity and stability from >> protocol point of view. >> >> Fixing on meaning on first 4 octets also provides very good tool >> to policy filtering rules as you know what to expect there. For >> example you may have policy allowing to pass any LC where first 4 >> octets contain any ASN also listed in your AS_PATH - otherwise >> drop it. That may effectively help to support LC global >> deployment much easier including the N-hops away destinations. >> >> Thx, >> r. >> >> >> On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler >> > wrote: >> >> On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk >> wrote: >> :Hi Martijn, >> : >> :> Secondly, there's literally no way for the vendor to check >> whether an >> :> ASN belongs to "the entity that defines the meaning of the >> rest of the >> :> Large Community" >> : >> :Why not ? >> : >> :If you do not make those 4 octets configurable by spec and >> always fill it >> :with AS number defined in your BGP instance you will have >> assurance it >> :is ASN of the entity that defines the rest 8 octets of the >> LC as otherwise >> :you will likely not establish any EBGP sessions to your peers. >> : >> :So there is very easy way to enforce it today in any BGP >> implementation. >> >> Say I am AS 1234, and I want to control AS 5678. My transit >> ISP is AS >> 9876. >> >> If I set >> >> local-as 1234 >> peer-as 9876 >> set large-community 5678:666:1 >> >> How is the implementation supposed to know to allow it? >> >> Limitations in the implementation completely defeat the >> purpose of this >> spec. >> >> >> :However the question is should it be enforced at all ? >> : >> >> MUST NOT is a very important part of this spec, and is >> enforced a few >> times in the document. >> >> >> :Best, >> :R. >> : >> >> >> >> >> -- >> The moving cursor writes, and having written, blinks on. >> >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > -- > Met vriendelijke groet / Kindest regards, Martijn Schmidt > i3D.net performance hosting > *Martijn Schmidt | Network Architect* Email: > martijnschmidt@i3d.net | Tel: > +31 10 8900070 *i3D.net B.V. | Global > Backbone AS49544* Van Nelleweg 1, 3044 BC Rotterdam, The > Netherlands VAT: NL 8202.63.886.B01 Website > > | Case Studies > > | LinkedIn > > > _______________________________________________ Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --------------66B14E4A2CFEC51A753F2932 Content-Type: multipart/related; boundary="------------166901CAB9127E9061433916" --------------166901CAB9127E9061433916 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hey Robert,

I see that you stated the first field would be filled in automatically by the "local-as" value defined in your BGP config. That means we'll be back to two user-customizable fields, so action communities sent between ASN's are effectively going to collide again and we're back to the same old RFC1997 problem. It's not an option.

I'll get back to the other part of your message in a minute, so I can include the discussion you've already had with Job.

Best regards,
Martijn


On 10/21/2016 06:29 PM, Robert Raszuk wrote:
Martijn,

> I think you're missing the point.

I don't think it's me :)

> Peter already explained that not every ASN we're trying to signal is necessarily a direct neighbor. 

I never made any such assumption. 

> So you've suggested to take a look at the BGP table instead to see if the ASN appears in any AS_PATH which is in the table. 


Nope ... not at all. 

The policy example was nothing to do with BGP table. If I am receiving BGP_UPDATE it comes with AS_PATH and may contain LC. So if I want very simple policy to filter trash of LCs I can set it to match first 4 octets to any ASN present in the same UPDATE MSG AS_PATH attribute. If it there I do not drop LC. 

For stub ASes we could treat their AS_NUMBERS in LCs exactly in the same way we treat them in AS_PATH today. 

Cheers,
R.





On Fri, Oct 21, 2016 at 6:21 PM, i3D.net - Martijn Schmidt <martijnschmidt@i3d.net> wrote:
Hi Robert,

I think you're missing the point. Peter already explained that not every ASN we're trying to signal is necessarily a direct neighbor. So you've suggested to take a look at the BGP table instead to see if the ASN appears in any AS_PATH which is in the table. But many routers participating in the DFZ don't carry a full table, only a default route, so that information is not available to them. Nevertheless operators of those default-only networks frequently send communities to their upstream for inbound routing manipulation (prepends, localpref, RTBH, etc) to achieve a variety of goals; your suggestion would severely limit the draft's usefulness.

Summarizing, any restrictions which can not be enforced don't belong in the IDR document because they're irrelevant to implementors. Arguing about it doesn't change the fact that such recommendations belong in a BCP/GROW document. It is that simple.

Best regards,
Martijn


On 10/21/2016 06:03 PM, Robert Raszuk wrote:
Peter,

Who you control (who is the target of LC - can be expressed in the second 4 octets). And as such at least original discussions were about it. 

So if you inject a large community it would have format: SRC_ASN:DST_ASN:ACTION

In your specific case it would be: 1234:5678:ACTION

The comment was made that there is no way for implementation to insert valid SRC_ASN .. well it clearly is.

But I am not suggesting spec should enforce it as it does limit use cases for LC by not allowing to overload first 4 octets. On the other hand it does provide more responsibility to whoever is injecting LCs so does improve on BGP clarity and stability from protocol point of view.

Fixing on meaning on first 4 octets also provides very good tool to policy filtering rules as you know what to expect there. For example you may have policy allowing to pass any LC where first 4 octets contain any ASN also listed in your AS_PATH - otherwise drop it. That may effectively help to support LC global deployment much easier including the N-hops away destinations. 

Thx,
r.


On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler <phessler@theapt.org> wrote:
On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk wrote:
:Hi Martijn,
:
:> Secondly, there's literally no way for the vendor to check whether an
:> ASN belongs to "the entity that defines the meaning of the rest of the
:> Large Community"
:
:Why not ?
:
:If you do not make those 4 octets configurable by spec and always fill it
:with AS number defined in your BGP instance you will have assurance it
:is ASN of the entity that defines the rest 8 octets of the LC as otherwise
:you will likely not establish any EBGP sessions to your peers.
:
:So there is very easy way to enforce it today in any BGP implementation.

Say I am AS 1234, and I want to control AS 5678.  My transit ISP is AS
9876.

If I set

local-as 1234
peer-as 9876
set large-community 5678:666:1

How is the implementation supposed to know to allow it?

Limitations in the implementation completely defeat the purpose of this
spec.


:However the question is should it be enforced at all ?
:

MUST NOT is a very important part of this spec, and is enforced a few
times in the document.


:Best,
:R.
:




--
The moving cursor writes, and having written, blinks on.



_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--
Met vriendelijke groet / Kindest regards, Martijn Schmidt
i3D.net performance hosting
Martijn Schmidt | Network Architect Email: martijnschmidt@i3d.net | Tel: +31 10 8900070 i3D.net B.V. | Global Backbone AS49544 Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands VAT: NL 8202.63.886.B01 Website | Case Studies | LinkedIn
_______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
--------------166901CAB9127E9061433916 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAOkAAACCCAMAAACU2h9IAAAAGXRFWHRTb2Z0d2FyZQBBZG9i ZSBJbWFnZVJlYWR5ccllPAAAA0xpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tl dCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1l dGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUu Ni1jMTMyIDc5LjE1OTI4NCwgMjAxNi8wNC8xOS0xMzoxMzo0MCAgICAgICAgIj4gPHJkZjpS REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgt bnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9u cy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6MEM3NkQ1 NTY3NkE4MTFFNkI0OTI5NERBQkYxNEIxQUEiIHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6 MEM3NkQ1NTU3NkE4MTFFNkI0OTI5NERBQkYxNEIxQUEiIHhtcDpDcmVhdG9yVG9vbD0iQWRv YmUgUGhvdG9zaG9wIENDIDIwMTUuNSAoV2luZG93cykiPiA8eG1wTU06RGVyaXZlZEZyb20g c3RSZWY6aW5zdGFuY2VJRD0iYWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOmYwMGZmMDc1LTc2YTUt MTFlNi1iZDIzLWJhYTI4MGRmODBkYyIgc3RSZWY6ZG9jdW1lbnRJRD0iYWRvYmU6ZG9jaWQ6 cGhvdG9zaG9wOmYwMGZmMDc1LTc2YTUtMTFlNi1iZDIzLWJhYTI4MGRmODBkYyIvPiA8L3Jk ZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0i ciI/Pu9aRCwAAABgUExURf7+/uuxsufn5+ONj9nZ2fPz86qqq5SUlWNjZHt7fM/Pz7i4uFZW V4aGh0FBQsPDw0pKS/TU1T8/QN93efv29ttmaW9vcNU+Q/nq6vHIydhTV/bf4OijpNIjKkBA Qf///zh9ticAAAfaSURBVHja7Nxro3ssAABw5n4dj+x66Pt/ywddFEr6m5mtN8fZWvVDqYQB vyUYP+lP+rnSug+hIA4I3cCPs7pOszjwopMoLb+eDll8SVz7Hfs0rf8z1KVhkg1K7rvOIikK cWLvWhpOFj9zwWJpEy72bqUgER6hUENap56xT+lJUvbU1ZA2Z76zR+kplhba1ZFuS1WUOvFM oSMdaX0xdicN5sqcnXSktbc3abT48ChKU3tfUiNWKHSkI62DfUkjpebF0JHW9luk5z44y4sd akmTt0gFcexx9cqymTLz0hiHLB03ZWBHUm9QNq/toYPzsD3ODKGUHm7D9jLZqfBm6eD4nETV 156XTvRBvP1IAXfKpSfhwXaVpNBO39L6Kkht4SFwMmFFlUgH3ZB4P9JIfFXghze+ovTMnwpg N1JX2OwMdkKsKHV46Wk3Uq42XiQndmqoSWH8jsZXQZqI24/B0XEUpf5OpYG4S2MIz0Mp5sJ9 eX6D1O4DUJLC9EOl02WTSbOf9OBS58OlkceESCYFHy6VBU6awuNKDa3e4CdKHeGo5GjSUDjM OZrUFRb5YFKD86TOcaX8oO0CDyu1M/HU9pGkwOWhsXEw6Tlqg+sG2YK7FR8p9dVusBxXGjtf Io1P8DukgQO/QhpHBvwKqX+ajXaUY5q560odnwR8wyBC/7V71PPHoY3l+pNh5/XUGY6O3H6a KhDcovamLwnrt72jlUXrSC/7k9Y+eIUUD492JR1OGq4jxd/tSzr4xUpS741St50LTQJ/tDbD f4U0FkjTjAmdFG+TywEOa4zaQBSrr9LRlqLbAmNpMDMt6646Encuyqt09KXRHqQQxItX6SyW JruQDiZBFVfpLJN2Mxnvl/Jzg6qrdBZJu933fumgbQ9eIXX3IY1ecl8GSzNq2oGUX7uSrSsN 6ArKHUgHa1eMVaVeTH67AynUW6WjKPVIh3ArKXCYACYTXnedA5GeSe3fSrr5ig4idVI8cju8 FCdynpLOnGSfJiUVVTZqCw4hDfHI7fhSgJI/HV+KI0ZfIEXEZA/S+rVSG8+cbyTdfCVzL8UP 1CUjaRyQ4K4oVV6dXq+0Or2X4r0cb9RzcEXjFe0nDlL5EweMNBpGfKl09adIwpmnSBjpaVOp +MkgoPdkUDLzZBAj5U70149lUtFj0qs87XWRSr0tpYNS9zeGz+lrnuBjpedNpaOnMtssjTDR eCoTnhSeymSlbOv1eun4SdssjtNFT9riW9RxpvKkLStlexkbzK6oPBC/4tPTnNTbVOqqFDnW eyI+nJGGm0rB695ycIEzUiPbUqrymgN/vTdXcFKmT7+F1LgsLfK/vI3EmVq4stV874veMEPX gdhoYBJOSO0paT+WaYK96sy2nS07NkrSfl3lmd1fvLRv+WXrHFacw7clR1X3TVB9x1ImTTaW Qkf45iC9t3vVCdNnkEmjraVNcabf2OY5UEPqcznIpKftpdA4B8NOoN5b+LJkkL5MStPaUNp2 Is4eXouUxpdk+ZsV68wP3HDU15VKvfWlzD01+QvGjNH9kFGtFgRxgn2uxuCOC2DKBCbSNMb5 ghkpPHL4SX/Sn/Qn3am06kJpNm10RQLZfFhty00+NZvtm3WtrtYN8jGKZqtoUzPRryHMK/IR +SX6ApglziwnyRaoIM1W3v/p8+k2u2zMqv8JitZu38ZJS6VNHDCWVtUVcNLbFX1642MUBEg3 ulI9iNSi0pJmJpUy+Tyv5BfTUhMnDfqkZ6TNTyak1R8ntfCmxcfogM8mtQcnrYi0Arg4Zp+W VMrkU9BfTEutcdJiaQ5Bk3RJMqP5gqL9dPAxypGP0ZXmTlj04JKid991XzQfW93BKTope6Jx 0j4fQDZLNhYjfeCkS5J0KZWifIdSeO9NkNQ+8iUbo8D78kmlTb4Fgyc7vudIpUw+/aZAWoFR 0hrSfFaa91ILuck5W1q0JWoq3L9Ki6IQSe+bS8u2rlxRjObgWiZticq2EmtKb7he8LF66aNp J7aVFu1fq/3TxmgOrnlHVaZts6pBcfI8V5W2jRzTnI6kFmpfuNZEQ9o1HVIpitE2NO1xK9o/ FWp6zT7ys5oojqrU7JvnKWnzNVgipW0vafa7T28luVzhFmckxTGKLse2wqB2ub1KdDHwZb05 p29TUvaiQC8hA2l3xaFHdSRt0mXaTXo9V7ueFky+JZBIaYwmg+YrE3R/KnSRAa0PlaYtrKkt 7boEhDqSNmf330Jp30dipXc4J70jWLNvrbw7UVGMKzrSqDT3Cp/WOlJEtURS0jaoSkm/Nx/m m0vqKY1RdJW8NFFdbzpz3e76o9dRwHS9ltZTQjUFUpNPerbt5ZJh66klbZFwjFZatG0sbnjy 7lPanpHenc5VBk0qPXAnekL6XEO6pI/UHsEr6pB2xkdRlOTXcGrHK7e9pomyuU1L4XUN6YLr KcKYKKc/emoDejrrSvnDOyG1tpbmjLRgKjEzWnuN1HyFdDSWYaSAgV3pgAbTSXGYAYfiWAaW ZBMIpM9qOExSkvKN5EjKj085aVdfAGlqH1iKe4GkOBrjU5OLNiGF1yXjU1UpP+fASws6ZMn7 uZaCnE6P4cSA6pwD/sn1KZQWw+kMDSmo8CiE9ii5eSQao8DNUEEvcX9Y+iBSS3seCVgPsjkt NRXnkeC3hJ/0J/1Jf9Kf9Cd9XfhfgAEA6npi4QQJPOEAAAAASUVORK5CYII= --------------166901CAB9127E9061433916-- --------------66B14E4A2CFEC51A753F2932-- From nobody Fri Oct 21 11:01:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08872129470 for ; Fri, 21 Oct 2016 11:01:54 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lndno8X1qVSa for ; Fri, 21 Oct 2016 11:01:47 -0700 (PDT) Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B87127058 for ; Fri, 21 Oct 2016 11:01:45 -0700 (PDT) X-Footer: aTNkLm5s Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for idr@ietf.org; Fri, 21 Oct 2016 20:01:40 +0200 To: idr@ietf.org References: <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> From: "i3D.net - Martijn Schmidt" Message-ID: <711ba725-7304-5122-cfb2-2a40c2d76ca9@i3d.net> Date: Fri, 21 Oct 2016 20:01:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B7C30382FEC6680A8D48940D" Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 18:01:54 -0000 This is a multi-part message in MIME format. --------------B7C30382FEC6680A8D48940D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi Robert, Briefly continuing the earlier discussion for originating routers - stub networks which exclusively receive a default route from my full table router don't have complete AS_PATH information. That means the device won't be able to determine whether or not the configured GA field corresponds to an ASN in the DFZ. If we decide (on a protocol level) to filter the LC information on the receiving LC-speaking BGP router instead of the originating router you'd limit the transitivity and therefore the usefulness of the Large Community feature. Let's say that AS65500 wants to send a community via AS49544 to AS2914. Upon receipt of the BGP_UPDATE, the AS49544 router will check the Large Community attribute and notice that 2914:x:y is attached while AS2914 is not in the AS_PATH. It would then have to strip the Large Community and AS2914 would never receive the Large Community attribute. Simply stating that "implementations MUST allow the operator to specify any value for the Global Administrator field" is the correct way forward, the suggested SHOULD wording either can't be enforced by vendor-side checks (and therefore belongs in a BCP/GROW document), or is - in the way you've suggested it - in direct conflict with the intended use of the Global Administrator field. Best regards, Martijn On 10/21/2016 06:49 PM, Robert Raszuk wrote: > Hey Job, > > That's what I thought ... but if so I do not get why there are so many > discussions of any MUSTs/SHOULDs/MAYs operators are expected to follow > on in the fields LCs provides. > > If they are opaque that means there is zero structure in place and > everyone is free to put whatever he/she likes in it .. even hex > encoded Morse (https://goo.gl/rHcGeV) > > We either allow all opaque and free style or we structure fields such > that for example they may be used in simple parametrized BGP in/out > policy example I provided. > > And the excuses type "oh we can not structure it as there is no way to > insert valid ASN" are wrong as there is a way as proven :) > > Cheers, > R. > > > > On Fri, Oct 21, 2016 at 6:42 PM, Job Snijders > wrote: > > On Fri, Oct 21, 2016 at 06:29:46PM +0200, Robert Raszuk wrote: > > The policy example was nothing to do with BGP table. If I am > receiving > > BGP_UPDATE it comes with AS_PATH and may contain LC. So if I > want very > > simple policy to filter trash of LCs I can set it to match first 4 > > octets to any ASN present in the same UPDATE MSG AS_PATH > attribute. If > > it there I do not drop LC. > > A clever trick, but not a good fit for Large BGP Communities. > Large BGP > Communities are opaque, by definition and design. > > We want routing policy in which networks can send 2914:X:Y to us, > and we > can send 2914:A:B to them - very much like RFC 1997 communities. The > Global Administator field does not necessarily contain the ASN of the > sending party. > > Kind regards, > > Job > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------B7C30382FEC6680A8D48940D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Robert,

Briefly continuing the earlier discussion for originating routers - stub networks which exclusively receive a default route from my full table router don't have complete AS_PATH information. That means the device won't be able to determine whether or not the configured GA field corresponds to an ASN in the DFZ.

If we decide (on a protocol level) to filter the LC information on the receiving LC-speaking BGP router instead of the originating router you'd limit the transitivity and therefore the usefulness of the Large Community feature. Let's say that AS65500 wants to send a community via AS49544 to AS2914. Upon receipt of the BGP_UPDATE, the AS49544 router will check the Large Community attribute and notice that 2914:x:y is attached while AS2914 is not in the AS_PATH. It would then have to strip the Large Community and AS2914 would never receive the Large Community attribute.

Simply stating that "implementations MUST allow the operator to specify any value for the Global Administrator field" is the correct way forward, the suggested SHOULD wording either can't be enforced by vendor-side checks (and therefore belongs in a BCP/GROW document), or is - in the way you've suggested it - in direct conflict with the intended use of the Global Administrator field.

Best regards,
Martijn

On 10/21/2016 06:49 PM, Robert Raszuk wrote:

Hey Job,

That's what I thought ... but if so I do not get why there are so many discussions of any MUSTs/SHOULDs/MAYs operators are expected to follow on in the fields LCs provides. 

If they are opaque that means there is zero structure in place and everyone is free to put whatever he/she likes in it .. even hex encoded Morse (https://goo.gl/rHcGeV)

We either allow all opaque and free style or we structure fields such that for example they may be used in simple parametrized BGP in/out policy example I provided. 

And the excuses type "oh we can not structure it as there is no way to insert valid ASN" are wrong as there is a way as proven :)

Cheers,
R.



On Fri, Oct 21, 2016 at 6:42 PM, Job Snijders <job@instituut.net> wrote:
On Fri, Oct 21, 2016 at 06:29:46PM +0200, Robert Raszuk wrote:
> The policy example was nothing to do with BGP table. If I am receiving
> BGP_UPDATE it comes with AS_PATH and may contain LC. So if I want very
> simple policy to filter trash of LCs I can set it to match first 4
> octets to any ASN present in the same UPDATE MSG AS_PATH attribute. If
> it there I do not drop LC.

A clever trick, but not a good fit for Large BGP Communities. Large BGP
Communities are opaque, by definition and design.

We want routing policy in which networks can send 2914:X:Y to us, and we
can send 2914:A:B to them - very much like RFC 1997 communities. The
Global Administator field does not necessarily contain the ASN of the
sending party.

Kind regards,

Job

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr



_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--------------B7C30382FEC6680A8D48940D-- From nobody Fri Oct 21 11:55:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D821296F7 for ; Fri, 21 Oct 2016 11:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qiOqXkFy8SXH for ; Fri, 21 Oct 2016 11:55:19 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8971294C6 for ; Fri, 21 Oct 2016 11:55:19 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id f193so1328345wmg.0 for ; Fri, 21 Oct 2016 11:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dZFgyg+DsbJO9nVZaV1zIdTQYkoRdGWrKoJ3/gAwBtA=; b=a7JfeGEdZVZuN/KtXo0Y/cARy2Dcv46Q6vFoIw5G4ZeiVcx1s5rfjSy0hvcPuvQXR3 PEUJX+7vullujaqtnImZgKrgDSRVMJp9x56HswegXApmtO7agRusqYIXuAryXb+lkBJI 6r5LwYySMjjYzBro3elD3abr+D2D9Qxc7eCtjz+qOeALjGOc5IoiBieuHgX1kT4X04QH sd3CF5G4DJDx5ZwYdipLMdFc1lwi4UgZB8oStj2sCY5irmDXvQjCtXRKLHtGv2xTKp6s V4+3hVjvuBLayiCNqmijKrLz6Lt4JA9AzgMG+K86vam0M+2oov05LvhVXB2dIF98M4IA ai/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dZFgyg+DsbJO9nVZaV1zIdTQYkoRdGWrKoJ3/gAwBtA=; b=ESrm3kkKiSyy2H/xvhJ/m34d9D21W+UlGss94/JqkwuNALW95SjTNt4coCQU/tVCcN cnpwzBdpFKk7Q1iWCYH0Gb5b6Tq6gfhhgZKLSNkHAUt9Sua5DNk3mAgkejmnlxNpFAEw SiPE8RERxDIzpxYRXnHH1sBDI9HPuyy/0LvbHaMcVVZNs5+SjTwG3jtF5W5x5rdDClMa 4If1ltqZ86JU85u+HKpm/dDkIqQLq8Ier2gUsxpoo7ivVa1ihuS8mvtGsXJUh1nZDhdh EaWZU+BmfN+NCq3e0fXUvFHH2YjaKDxyvmM7rFBDvySWTBL7F1QHgdLABpJQn7ckGqJa rKXg== X-Gm-Message-State: ABUngvdfHuGn8uuR9yKqK/JsTicbuMRnt+GK7BFlFeh0xpFVRwWddz6pMAvVss5ZUkCq69cqFUM9NgWG98EN1g== X-Received: by 10.194.94.232 with SMTP id df8mr1859176wjb.227.1477076117627; Fri, 21 Oct 2016 11:55:17 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Fri, 21 Oct 2016 11:55:15 -0700 (PDT) In-Reply-To: <711ba725-7304-5122-cfb2-2a40c2d76ca9@i3d.net> References: <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <711ba725-7304-5122-cfb2-2a40c2d76ca9@i3d.net> From: Robert Raszuk Date: Fri, 21 Oct 2016 20:55:15 +0200 X-Google-Sender-Auth: BnfdU7UjvkgBNGcJxYL_EFnPgX0 Message-ID: To: "i3D.net - Martijn Schmidt" Content-Type: multipart/alternative; boundary=047d7bb03aae4c27fa053f649534 Archived-At: Cc: idr wg Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 18:55:23 -0000 --047d7bb03aae4c27fa053f649534 Content-Type: text/plain; charset=UTF-8 Martijn, First I think you need to know that all original authors of LC agreed that the proposal does not solve the community values overload issue. If you and others were sold on something different then perhaps there is some disconnect. That is also why some time back I proposed for LCs to have 4x4octets such that today's necessity to overload 1997 can be relaxed. For stub networks if they get only default route there is no issue as they will not be getting any LCs. For ASes which use private_ASes as I already mentioned it is trivial to treat it in the same way as it is treated in the AS_PATH today. Basically you would replace your customer private AS with your public AS both in the AS_PATH and in the first 4 octets of LC. To conclude ... There is simply two ways -A- your 3x4 octets are completely unstructured and you use them as it seems fit or -B- It is structured and draft/rfc specifies what goes into first 4 octets (say SRC_ASN) and what goes into second 4 octets (say TARGET-ASN) leaving rest for ACTION+PARAMETERS Rgs, r. On Fri, Oct 21, 2016 at 8:01 PM, i3D.net - Martijn Schmidt < martijnschmidt@i3d.net> wrote: > Hi Robert, > > Briefly continuing the earlier discussion for originating routers - stub > networks which exclusively receive a default route from my full table > router don't have complete AS_PATH information. That means the device won't > be able to determine whether or not the configured GA field corresponds to > an ASN in the DFZ. > > If we decide (on a protocol level) to filter the LC information on the > receiving LC-speaking BGP router instead of the originating router you'd > limit the transitivity and therefore the usefulness of the Large Community > feature. Let's say that AS65500 wants to send a community via AS49544 to > AS2914. Upon receipt of the BGP_UPDATE, the AS49544 router will check the > Large Community attribute and notice that 2914:x:y is attached while AS2914 > is not in the AS_PATH. It would then have to strip the Large Community and > AS2914 would never receive the Large Community attribute. > > Simply stating that "implementations MUST allow the operator to specify > any value for the Global Administrator field" is the correct way forward, > the suggested SHOULD wording either can't be enforced by vendor-side checks > (and therefore belongs in a BCP/GROW document), or is - in the way you've > suggested it - in direct conflict with the intended use of the Global > Administrator field. > > Best regards, > Martijn > > On 10/21/2016 06:49 PM, Robert Raszuk wrote: > > Hey Job, > > That's what I thought ... but if so I do not get why there are so many > discussions of any MUSTs/SHOULDs/MAYs operators are expected to follow on > in the fields LCs provides. > > If they are opaque that means there is zero structure in place and > everyone is free to put whatever he/she likes in it .. even hex encoded > Morse (https://goo.gl/rHcGeV) > > We either allow all opaque and free style or we structure fields such that > for example they may be used in simple parametrized BGP in/out policy > example I provided. > > And the excuses type "oh we can not structure it as there is no way to > insert valid ASN" are wrong as there is a way as proven :) > > Cheers, > R. > > > > On Fri, Oct 21, 2016 at 6:42 PM, Job Snijders wrote: > >> On Fri, Oct 21, 2016 at 06:29:46PM +0200, Robert Raszuk wrote: >> > The policy example was nothing to do with BGP table. If I am receiving >> > BGP_UPDATE it comes with AS_PATH and may contain LC. So if I want very >> > simple policy to filter trash of LCs I can set it to match first 4 >> > octets to any ASN present in the same UPDATE MSG AS_PATH attribute. If >> > it there I do not drop LC. >> >> A clever trick, but not a good fit for Large BGP Communities. Large BGP >> Communities are opaque, by definition and design. >> >> We want routing policy in which networks can send 2914:X:Y to us, and we >> can send 2914:A:B to them - very much like RFC 1997 communities. The >> Global Administator field does not necessarily contain the ASN of the >> sending party. >> >> Kind regards, >> >> Job >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > > > _______________________________________________ > Idr mailing listIdr@ietf.orghttps://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --047d7bb03aae4c27fa053f649534 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martijn,

First I think you need to know that all original aut= hors of LC agreed that the proposal does not solve the community values ove= rload issue. If you and others were sold on something different then perhap= s there is some disconnect. That is also why some time back I proposed for = LCs to have 4x4octets such that today's necessity to overload 1997 can = be relaxed.=C2=A0

For = stub networks if they get only default route there is no issue as they will= not be getting any LCs.=C2=A0

For ASes which use private_ASes as I already mentioned it is trivi= al to treat it in the same way as it is treated in the AS_PATH today. Basic= ally you would replace your customer private AS with your public AS both in= the AS_PATH and in the first 4 octets of LC.

<= /div>
To conclude ...

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">There is simply two ways=C2=A0
-A- your 3x4 octets are completely unstructured = and you use them as it seems fit=C2=A0

or=C2=A0

-B- It is structured and draft/rfc specifies what goes into first 4 oct= ets (say SRC_ASN) and what goes into second 4 octets (say TARGET-ASN) leavi= ng rest for ACTION+PARAMETERS

Rgs,
r.=C2=A0


On = Fri, Oct 21, 2016 at 8:01 PM, i3D.net - Martijn Schmidt &= lt;martijnschmi= dt@i3d.net> wrote:
=20 =20 =20

Hi Robert,

Briefly continuing the earlier discussion for originating routers - stub networks which exclusively receive a default route from my full table router don't have complete AS_PATH information. That means the device won't be able to determine whether or not the configured GA field corresponds to an ASN in the DFZ.

If we decide (on a protocol level) to filter the LC information on the receiving LC-speaking BGP router instead of the originating router you'd limit the transitivity and therefore the usefulness of the Large Community feature. Let's say that AS65500 wants to send a community via AS49544 to AS2914. Upon receipt of the BGP_UPDATE, the AS49544 router will check the Large Community attribute and notice that 2914:x:y is attached while AS2914 is not in the AS_PATH. It would then have to strip the Large Community and AS2914 would never receive the Large Community attribute.

Simply stating that "implementations MUST allow the operator to specify any value for the Global Administrator field" is the correct way forward, the suggested SHOULD wording either can't be enforced by vendor-side checks (and therefore belongs in a BCP/GROW document), or is - in the way you've suggested it - in direct conflict with the intended use of the Global Administrator field.

Best regards,
Martijn

On 10/21/2016 06:49 PM, Robert Raszuk wrote:

Hey Job,

That's what I thought ... but if so I do not get why there are so many discussions of any MUSTs/SHOULDs/MAYs operators are expected to follow on in the fields LCs provides.=C2=A0

If they are opaque that means there is zero structure in place and everyone is free to put whatever he/she likes in it .. even hex encoded Morse (https://goo.gl/rHcGeV)

We either allow all opaque and free style or we structure fields such that for example they may be used in simple parametrized BGP in/out policy example I provided.=C2=A0

And the excuses type "oh we can not structure it as there is no way to insert valid ASN" are wrong as there is a way as prov= en :)

Cheers,
R.



On Fri, Oct 21, 2016 at 6:42 PM, Job Snijders <job@instituut.net> wrote:
On Fri, Oct 21, 2016 at 06:2= 9:46PM +0200, Robert Raszuk wrote:
> The policy example was nothing to do with BGP table. If I am receiving
> BGP_UPDATE it comes with AS_PATH and may contain LC. So if I want very
> simple policy to filter trash of LCs I can set it to match first 4
> octets to any ASN present in the same UPDATE MSG AS_PATH attribute. If
> it there I do not drop LC.

A clever trick, but not a good fit for Large BGP Communities. Large BGP
Communities are opaque, by definition and design.

We want routing policy in which networks can send 2914:X:Y to us, and we
can send 2914:A:B to them - very much like RFC 1997 communities. The
Global Administator field does not necessarily contain the ASN of the
sending party.

Kind regards,

Job

_______________________________________________
Idr mailing list
Idr@ietf.= org
https://www.ietf.org/mailman/listinf= o/idr



_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mail=
man/listinfo/idr


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--047d7bb03aae4c27fa053f649534-- From nobody Fri Oct 21 12:30:15 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B12129584 for ; Fri, 21 Oct 2016 12:30:14 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 x8YCyLym7t7k for ; Fri, 21 Oct 2016 12:30:11 -0700 (PDT) Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38EFA12946B for ; Fri, 21 Oct 2016 12:30:10 -0700 (PDT) X-Footer: aTNkLm5s Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Fri, 21 Oct 2016 21:30:06 +0200 To: Robert Raszuk References: <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <711ba725-7304-5122-cfb2-2a40c2d76ca9@i3d.net> From: "i3D.net - Martijn Schmidt" Message-ID: Date: Fri, 21 Oct 2016 21:29:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------617B844939519B362E69EAA9" Archived-At: Cc: idr wg Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 19:30:14 -0000 This is a multi-part message in MIME format. --------------617B844939519B362E69EAA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Robert, I haven't been "sold" on anything, I'm perfectly aware of the collision issues I encountered while implementing RFC1997-based communities in our real-world network and the protocol outlined in this draft alleviates them. Of course stub networks can't *receive* LC's, but they can still *transmit* them on the prefixes which they announce to the DFZ via non-stub networks. The private AS which I mentioned in my previous message was just an example so I wouldn't have to name a random real-world network, but please feel free to replace every mention of AS65500 with AS3333 if that makes it easier to understand the argument. The same principle applies. What operators want from their vendors are three completely opaque 4-octet fields, which is exactly what this draft specifies. Please let operators worry about their own filtering policies (or lack thereof) and leave such recommendations to the BCP/GROW document. Best regards, Martijn On 10/21/2016 08:55 PM, Robert Raszuk wrote: > Martijn, > > First I think you need to know that all original authors of LC agreed > that the proposal does not solve the community values overload issue. > If you and others were sold on something different then perhaps there > is some disconnect. That is also why some time back I proposed for LCs > to have 4x4octets such that today's necessity to overload 1997 can be > relaxed. > > For stub networks if they get only default route there is no issue as > they will not be getting any LCs. > > For ASes which use private_ASes as I already mentioned it is trivial > to treat it in the same way as it is treated in the AS_PATH today. > Basically you would replace your customer private AS with your public > AS both in the AS_PATH and in the first 4 octets of LC. > > To conclude ... > > There is simply two ways > > -A- your 3x4 octets are completely unstructured and you use them as it > seems fit > > or > > -B- It is structured and draft/rfc specifies what goes into first 4 > octets (say SRC_ASN) and what goes into second 4 octets (say > TARGET-ASN) leaving rest for ACTION+PARAMETERS > > Rgs, > r. > > > On Fri, Oct 21, 2016 at 8:01 PM, i3D.net - Martijn Schmidt > > wrote: > > Hi Robert, > > Briefly continuing the earlier discussion for originating routers > - stub networks which exclusively receive a default route from my > full table router don't have complete AS_PATH information. That > means the device won't be able to determine whether or not the > configured GA field corresponds to an ASN in the DFZ. > > If we decide (on a protocol level) to filter the LC information on > the receiving LC-speaking BGP router instead of the originating > router you'd limit the transitivity and therefore the usefulness > of the Large Community feature. Let's say that AS65500 wants to > send a community via AS49544 to AS2914. Upon receipt of the > BGP_UPDATE, the AS49544 router will check the Large Community > attribute and notice that 2914:x:y is attached while AS2914 is not > in the AS_PATH. It would then have to strip the Large Community > and AS2914 would never receive the Large Community attribute. > > Simply stating that "implementations MUST allow the operator to > specify any value for the Global Administrator field" is the > correct way forward, the suggested SHOULD wording either can't be > enforced by vendor-side checks (and therefore belongs in a > BCP/GROW document), or is - in the way you've suggested it - in > direct conflict with the intended use of the Global Administrator > field. > > Best regards, > Martijn > > On 10/21/2016 06:49 PM, Robert Raszuk wrote: > >> Hey Job, >> >> That's what I thought ... but if so I do not get why there are so >> many discussions of any MUSTs/SHOULDs/MAYs operators are expected >> to follow on in the fields LCs provides. >> >> If they are opaque that means there is zero structure in place >> and everyone is free to put whatever he/she likes in it .. even >> hex encoded Morse (https://goo.gl/rHcGeV) >> >> We either allow all opaque and free style or we structure fields >> such that for example they may be used in simple parametrized BGP >> in/out policy example I provided. >> >> And the excuses type "oh we can not structure it as there is no >> way to insert valid ASN" are wrong as there is a way as proven :) >> >> Cheers, >> R. >> >> >> >> On Fri, Oct 21, 2016 at 6:42 PM, Job Snijders > > wrote: >> >> On Fri, Oct 21, 2016 at 06:29:46PM +0200, Robert Raszuk wrote: >> > The policy example was nothing to do with BGP table. If I >> am receiving >> > BGP_UPDATE it comes with AS_PATH and may contain LC. So if >> I want very >> > simple policy to filter trash of LCs I can set it to match >> first 4 >> > octets to any ASN present in the same UPDATE MSG AS_PATH >> attribute. If >> > it there I do not drop LC. >> >> A clever trick, but not a good fit for Large BGP Communities. >> Large BGP >> Communities are opaque, by definition and design. >> >> We want routing policy in which networks can send 2914:X:Y to >> us, and we >> can send 2914:A:B to them - very much like RFC 1997 >> communities. The >> Global Administator field does not necessarily contain the >> ASN of the >> sending party. >> >> Kind regards, >> >> Job >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > _______________________________________________ Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --------------617B844939519B362E69EAA9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Robert,

I haven't been "sold" on anything, I'm perfectly aware of the collision issues I encountered while implementing RFC1997-based communities in our real-world network and the protocol outlined in this draft alleviates them.

Of course stub networks can't *receive* LC's, but they can still *transmit* them on the prefixes which they announce to the DFZ via non-stub networks. The private AS which I mentioned in my previous message was just an example so I wouldn't have to name a random real-world network, but please feel free to replace every mention of AS65500 with AS3333 if that makes it easier to understand the argument. The same principle applies.

What operators want from their vendors are three completely opaque 4-octet fields, which is exactly what this draft specifies. Please let operators worry about their own filtering policies (or lack thereof) and leave such recommendations to the BCP/GROW document.

Best regards,
Martijn

On 10/21/2016 08:55 PM, Robert Raszuk wrote:
Martijn,

First I think you need to know that all original authors of LC agreed that the proposal does not solve the community values overload issue. If you and others were sold on something different then perhaps there is some disconnect. That is also why some time back I proposed for LCs to have 4x4octets such that today's necessity to overload 1997 can be relaxed. 

For stub networks if they get only default route there is no issue as they will not be getting any LCs. 

For ASes which use private_ASes as I already mentioned it is trivial to treat it in the same way as it is treated in the AS_PATH today. Basically you would replace your customer private AS with your public AS both in the AS_PATH and in the first 4 octets of LC.

To conclude ...

There is simply two ways 

-A- your 3x4 octets are completely unstructured and you use them as it seems fit 

or 

-B- It is structured and draft/rfc specifies what goes into first 4 octets (say SRC_ASN) and what goes into second 4 octets (say TARGET-ASN) leaving rest for ACTION+PARAMETERS

Rgs,
r. 


On Fri, Oct 21, 2016 at 8:01 PM, i3D.net - Martijn Schmidt <martijnschmidt@i3d.net> wrote:

Hi Robert,

Briefly continuing the earlier discussion for originating routers - stub networks which exclusively receive a default route from my full table router don't have complete AS_PATH information. That means the device won't be able to determine whether or not the configured GA field corresponds to an ASN in the DFZ.

If we decide (on a protocol level) to filter the LC information on the receiving LC-speaking BGP router instead of the originating router you'd limit the transitivity and therefore the usefulness of the Large Community feature. Let's say that AS65500 wants to send a community via AS49544 to AS2914. Upon receipt of the BGP_UPDATE, the AS49544 router will check the Large Community attribute and notice that 2914:x:y is attached while AS2914 is not in the AS_PATH. It would then have to strip the Large Community and AS2914 would never receive the Large Community attribute.

Simply stating that "implementations MUST allow the operator to specify any value for the Global Administrator field" is the correct way forward, the suggested SHOULD wording either can't be enforced by vendor-side checks (and therefore belongs in a BCP/GROW document), or is - in the way you've suggested it - in direct conflict with the intended use of the Global Administrator field.

Best regards,
Martijn

On 10/21/2016 06:49 PM, Robert Raszuk wrote:

Hey Job,

That's what I thought ... but if so I do not get why there are so many discussions of any MUSTs/SHOULDs/MAYs operators are expected to follow on in the fields LCs provides. 

If they are opaque that means there is zero structure in place and everyone is free to put whatever he/she likes in it .. even hex encoded Morse (https://goo.gl/rHcGeV)

We either allow all opaque and free style or we structure fields such that for example they may be used in simple parametrized BGP in/out policy example I provided. 

And the excuses type "oh we can not structure it as there is no way to insert valid ASN" are wrong as there is a way as proven :)

Cheers,
R.



On Fri, Oct 21, 2016 at 6:42 PM, Job Snijders <job@instituut.net> wrote:
On Fri, Oct 21, 2016 at 06:29:46PM +0200, Robert Raszuk wrote:
> The policy example was nothing to do with BGP table. If I am receiving
> BGP_UPDATE it comes with AS_PATH and may contain LC. So if I want very
> simple policy to filter trash of LCs I can set it to match first 4
> octets to any ASN present in the same UPDATE MSG AS_PATH attribute. If
> it there I do not drop LC.

A clever trick, but not a good fit for Large BGP Communities. Large BGP
Communities are opaque, by definition and design.

We want routing policy in which networks can send 2914:X:Y to us, and we
can send 2914:A:B to them - very much like RFC 1997 communities. The
Global Administator field does not necessarily contain the ASN of the
sending party.

Kind regards,

Job

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr



_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
--------------617B844939519B362E69EAA9-- From nobody Fri Oct 21 12:51:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E706129959 for ; Fri, 21 Oct 2016 12:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 P-uIq4_gkJp5 for ; Fri, 21 Oct 2016 12:51:11 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B5F129500 for ; Fri, 21 Oct 2016 12:51:10 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id f193so3980039wmg.0 for ; Fri, 21 Oct 2016 12:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hv6vJViWDayENjsqs+nFeXHx5QzV5WYL8QYODm0K3x4=; b=SdcA+ijGFef0d86+vdXaTcRr60a/ViOoDQf9mvwCWlLL/Dk8YXB5hQMCjmmVTQTcJX JKp9HDp8/o2UAYIhGq+F/n2j8KIO3wDE/UPbYtSFfeHGq9PDKRHzpkS2nzryk41qfjD2 woITDdbIfZSi8wvq8ZCnp8yNfrU66JNaNVdGz9FdVNsX643sEDuQtDTTn3HwxcqbcMjn E8gZt61j+OSaZtd4FrPPw2xNIdNkwAc1r0xU2OMOaqLGHdk+Mu3XFNMkBbySrPiiKrOS LcZ3qP8/QQLWiewTvQa/5dgYKCmtK2X/Yd2ftR2bgGcPt/QdePGgIwjkZ9Ue2oElZzLZ 14Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hv6vJViWDayENjsqs+nFeXHx5QzV5WYL8QYODm0K3x4=; b=m1ioPeYbdQJGqG2aEvCcK8YNIH53O7Z4+z7WDGF8QnH8mWZzb11ky2io1A0WjJMl+I RZB9Q1Sy8DubUOtgBF613iIE/71rdt1kFIjnGdqDCG3Xuaf5sFrZxO+zH8VSl/rf6BO9 VTmrbSN7jD8BqG1k1K0LP21fV/AQRxTas/+exuj3xSS44H/4jF9y7ksTApkPD//zLrV+ 7pkU+74AnAZn/tgCdxEWrGeLjpWquUS4SPbWp1Q8m81vS/xLn1U+O+6FlZ3XQxTDx6JV KaoETRCfBUIpwVwRo3Z4ZbnkLFVsDqyI5PRJPtk6hnPkFdkjn32kJ7ZihlIUP6bYr79t Xv2A== X-Gm-Message-State: AA6/9RkNdx4Gdce2oZaIm4aQlbDf4/fhPOSFYsJHQQ5lDdvyGclL8f7Qbr6bEDSeaN3IRtxBEqAYXC09SYl7ew== X-Received: by 10.28.185.137 with SMTP id j131mr4248204wmf.73.1477079469205; Fri, 21 Oct 2016 12:51:09 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Fri, 21 Oct 2016 12:51:07 -0700 (PDT) In-Reply-To: References: <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <711ba725-7304-5122-cfb2-2a40c2d76ca9@i3d.net> From: Robert Raszuk Date: Fri, 21 Oct 2016 21:51:07 +0200 X-Google-Sender-Auth: SLUu520a0zQKyzWh22bGDlGjz94 Message-ID: To: "i3D.net - Martijn Schmidt" Content-Type: multipart/alternative; boundary=001a1148e560113263053f655d69 Archived-At: Cc: idr wg Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 19:51:12 -0000 --001a1148e560113263053f655d69 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Please let operators worry about their own filtering policies (or lack > thereof) and leave such recommendations to the BCP/GROW document. > =E2=80=8BThis is IETF WG and I find such comment inappropriate. This discus= sion is about extending BGP protocol and we all should be worried how to apply effective policy on something which is being defined here. So triggered by the above let me ask a very simple question. You and others expressed very clearly that LCs should traverse N-ASes and be executed somewhere remotely. Great. Let's also assume that you talk to everyone in the path and convince them to let your LC go through. Question: If you choose to inject LC in the format TARGET_ASN:ACTION:PARAMETER based on what field is anyone in the BGP propagation path supposed to let's your LCs go and stop all other 1000s of LCs injected by anyone else ? Today RFC1997 don't go far as they have no way to apply per their originator permit or deny statements. Thx, R. =E2=80=8B --001a1148e560113263053f655d69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Please let operators worry about their own filter= ing policies (or lack thereof) and leave such recommendations to the BCP/GROW document.

=E2=80=8B= This is IETF WG and I find such comment inappropriate. This discussion is a= bout extending BGP protocol and we all should be worried how to apply effec= tive policy on something which is being defined here.=C2=A0

So triggered by the above let me ask = a very simple question. You and others expressed very clearly that LCs shou= ld traverse N-ASes and be executed somewhere remotely. Great.

Let's also assume that you talk= to everyone in the path and convince them to let your LC go through.=C2=A0=

Question:=C2=A0
=

If you choose to inject LC = in the format TARGET_ASN:ACTION:PARAMETER based on what field is anyone in = the BGP propagation path supposed to let's your LCs go and stop all oth= er 1000s of LCs injected by anyone else ?=C2=A0
Today RFC1997 don't go far as they have no wa= y to apply per their originator permit or deny statements.=C2=A0

Thx,
R.<= /div>






=E2=80=8B

=
=C2=A0
--001a1148e560113263053f655d69-- From nobody Fri Oct 21 13:32:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCFE12969E for ; Fri, 21 Oct 2016 13:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ftqpKpgDBn1G for ; Fri, 21 Oct 2016 13:32:10 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342FF12967D for ; Fri, 21 Oct 2016 13:32:10 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id c78so5176572wme.0 for ; Fri, 21 Oct 2016 13:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6NfBdnR3Gp5zE2Rp+pFO/NKfsSKhWxswfKZfIf7otMQ=; b=TP3vPZUcR8RnYuSDlv/aiyHvbSNOymVMTotws8UY63XZMYawaePKU36lahejlbhB35 GvwSMvie5JRJ1j/WtDumGP9Z8AhPCHxMEdTPinba3uqWD6ijy31KfW6aHGAgwvInpOe0 e/R705PaTlsQZVhotcEcrZkYG+OUwdsZwSvAqDShUponZ2ry5GAKJFPrtzJQZDLXU21D bi3jQN40KgImc6y61hIcGn+5tJ5qd3immAzlcLM6J+zcw7wiTZeCkmGTUE3fTkms2rQ3 BAa34KlGvghouzhDA5xVvAC4P0BlGPkU1KxXL0NS/KoP7sLm5l9Wn7gVDvZPY6TEy50N vPmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6NfBdnR3Gp5zE2Rp+pFO/NKfsSKhWxswfKZfIf7otMQ=; b=S5VhKOgt6S1kbwnwOouphj/FqHioW4zludjIkVpBOr6LUrCgJfJSUfQauKBs1Zb1gz FwFx7bU4lunU4uoWxwRttCNq0+xvMzY/j8Dq+YAbmH/ZHIxnydvAEWZ6h2DoLRhEux/x R47s8i3YjVGBgyw/pjtD3B1KXUOTYtfyqDEWO+NS215zHXgaVP2RD72NJjR7BfJ0wtuu s4Ho3ZC6HVDzNfcruI+Krh0BsmETn4IPnHmcRU9rUuHnEzHYFJqxnXoNgzgAQAOGPEuJ Vuqa7xsRoJmTGRWn0g53sTrEqCp8/xtdYLvUq1WEmAJacqcCKenHmcyIOhRdkQshmxgX GqKQ== X-Gm-Message-State: ABUngvdkXcD8QK/YX2Zj1b2M5l8Ot/k+wk/dSn44oFz/zT9jjwHh1UWyn2g9OLovyQNhOeHsrsReOH8UwMNwGw== X-Received: by 10.194.93.234 with SMTP id cx10mr2245043wjb.140.1477081928627; Fri, 21 Oct 2016 13:32:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.207 with HTTP; Fri, 21 Oct 2016 13:32:06 -0700 (PDT) In-Reply-To: References: <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <711ba725-7304-5122-cfb2-2a40c2d76ca9@i3d.net> From: Brian Dickson Date: Fri, 21 Oct 2016 13:32:06 -0700 Message-ID: To: Robert Raszuk Content-Type: multipart/alternative; boundary=047d7beb9340a901d6053f65efcb Archived-At: Cc: idr wg Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 20:32:11 -0000 --047d7beb9340a901d6053f65efcb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 21, 2016 at 12:51 PM, Robert Raszuk wrote: > > Please let operators worry about their own filtering policies (or lack >> thereof) and leave such recommendations to the BCP/GROW document. >> > =E2=80=8BThis is IETF WG and I find such comment inappropriate. This disc= ussion is > about extending BGP protocol and we all should be worried how to apply > effective policy on something which is being defined here. > > So triggered by the above let me ask a very simple question. You and > others expressed very clearly that LCs should traverse N-ASes and be > executed somewhere remotely. Great. > > Let's also assume that you talk to everyone in the path and convince them > to let your LC go through. > This is not how communities (large or RFC1997) work, generally. The general flow of BGP announcements is; originator -> (0 or more transit hops "upward" toward the DFZ) -> (across 0 or 1 peering connections) -> (0 or more hops "downward" from provider to customer, away from the DFZ) When flowing "upward", if communities are sent, the are generally propagated. AS hops in the middle may add additional communities (large or RFC1997 or both). When crossing a "peer" connection, some filtering and/or evaluation may occur, on either the sending side or the receiving side, or both. When flowing "downward", whether communities are sent AT ALL is typically a local configuration thing, but if they are sent, typically they are sent unmodified. Other than local agreements between peers, or between transit providers and their customers, NO TALKING OCCURS, and it is unreasonable and unscalable to assume or require that activity. > > Question: > > If you choose to inject LC in the format TARGET_ASN:ACTION:PARAMETER base= d > on what field is anyone in the BGP propagation path supposed to let's you= r > LCs go and stop all other 1000s of LCs injected by anyone else ? > (I assume you meant "stomp" not stop.) Based on no field. Everyone in the BGP propagation path is expected to pass it or not, based only on local policy for the incoming or outgoing peering session, and NOT BASED ON THE LC. The exception is when the local ASN of the particular BGP hop, is the TARGET_ASN. The decision by any ASN will generally be one of: - I don't send communities to neighbor X (where X can be upstream transit, downstream client, or peer), so I strip ALL communities (or more correctly, don't send the communities) - I do send communities to neighbor Y (and pass the communities untouched, or with an injection of my own set of configured communities per local policies) - I am TARGET_ASN, and do something special to the specific LC that starts with TARGET_ASN, but DO NOT touch any other LC's attached to the prefix LC are transitive, opaque, and additive; injecting an LC does not "stomp" on any other LC in the sequence of LCs. There is a possibility that the number of LCs exceed the capacity of the UPDATE, in which case something has to happen according to the general RFCs dictating error handling for this prefix. The AS_PATH or AS4_PATH observed on the internet (excluding AS-path padding via AS prepends) is typically on the order of 4-10, including the up, peer, and down hops. This does not reach "1000s", as those are per-prefix counts. > > Today RFC1997 don't go far as they have no way to apply per their > originator permit or deny statements. > Correct, and that is all that is being asked here - parity with RFC1997. There is no requirement or demand for originator -anything-. Brian --047d7beb9340a901d6053f65efcb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 21, 2016 at 12:51 PM, Robert Raszuk <<= a href=3D"mailto:robert@raszuk.net" target=3D"_blank">robert@raszuk.net= > wrote:

=

Ple= ase let operators worry about their own filtering policies (or lack thereof) and leave such recommendations to the BCP/GROW document.

=E2=80=8BThis is IETF WG a= nd I find such comment inappropriate. This discussion is about extending BG= P protocol and we all should be worried how to apply effective policy on so= mething which is being defined here.=C2=A0

So triggered by the above l= et me ask a very simple question. You and others expressed very clearly tha= t LCs should traverse N-ASes and be executed somewhere remotely. Great.
Let's also assume that you talk to everyone in the path and convince = them to let your LC go through.=C2=A0

This is not how communities (large or RFC1997) wor= k, generally.

The general flow of BGP announcement= s is;
originator -> (0 or more transit hops "upward"= toward the DFZ) -> (across 0 or 1 peering connections) -> (0 or more= hops "downward" from provider to customer, away from the DFZ)

When flowing "upward", if communities are = sent, the are generally propagated. AS hops in the middle may add additiona= l communities (large or RFC1997 or both).

When cro= ssing a "peer" connection, some filtering and/or evaluation may o= ccur, on either the sending side or the receiving side, or both.
=
When flowing "downward", whether communities are s= ent AT ALL is typically a local configuration thing, but if they are sent, = typically they are sent unmodified.

Other than loc= al agreements between peers, or between transit providers and their custome= rs, NO TALKING OCCURS, and it is unreasonable and unscalable to assume or r= equire that activity.

=C2=A0

Question:=C2=A0

If you choose to inject LC in the form= at TARGET_ASN:ACTION:PARAMETER based on what field is anyone in the BGP pro= pagation path supposed to let's your LCs go and stop all other 1000s of= LCs injected by anyone else ?=C2=A0

(I assume you meant "stomp" not stop.)

Based on no field. Everyone in the BGP propagation p= ath is expected to pass it or not, based only on local policy for the incom= ing or outgoing peering session, and NOT BASED ON THE LC.
The exc= eption is when the local ASN of the particular BGP hop, is the TARGET_ASN.<= /div>

The decision by any ASN will generally be one of:<= /div>
- I don't send communities to neighbor X (where X can be upst= ream transit, downstream client, or peer), so I strip ALL communities (or m= ore correctly, don't send the communities)
- I do send commun= ities to neighbor Y (and pass the communities untouched, or with an injecti= on of my own set of configured communities per local policies)
- = I am TARGET_ASN, and do something special to the specific LC that starts wi= th TARGET_ASN, but DO NOT touch any other LC's attached to the prefix

LC are transitive, opaque, and additive; injecting = an LC does not "stomp" on any other LC in the sequence of LCs.

There is a possibility that the number of LCs exceed= the capacity of the UPDATE, in which case something has to happen accordin= g to the general RFCs dictating error handling for this prefix.
<= br>
The AS_PATH or AS4_PATH observed on the internet (excluding A= S-path padding via AS prepends) is typically on the order of 4-10, includin= g the up, peer, and down hops. This does not reach "1000s", as th= ose are per-prefix counts.
=C2=A0

Today RFC1997 don't go far as they have no way to apply per their= originator permit or deny statements.=C2=A0
<= /blockquote>

Correct, and that is all that is being aske= d here - parity with RFC1997.

There is no requirem= ent or demand for originator -anything-.

Brian=C2= =A0
--047d7beb9340a901d6053f65efcb-- From nobody Fri Oct 21 14:32:44 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778E912962D for ; Fri, 21 Oct 2016 14:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jakma-org.20150623.gappssmtp.com 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 zMTuk9m_y62g for ; Fri, 21 Oct 2016 14:32:42 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4EF2129416 for ; Fri, 21 Oct 2016 14:32:41 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id f193so8265503wmg.0 for ; Fri, 21 Oct 2016 14:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jakma-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=kxnznu7bMGfQI6OCq6BFw5sWZXvdtTh8jr6IZODFrlc=; b=dZK/npwZxOQJsjmVK05Xt+eDJPjFWrG0vbNCQkVfX7rEHtrMVI0Yqetuxx/v6Q0UkQ GduepgxriTmkaAp3GovzJ7+xAyRLDEoy4t/ZkoOoJpePP6AibnNLi6IwvwmWMuhqHnAT qzmndnWYGMkUJ6+fos/ZE4k260aNcjLWDtK3j/1ekQ0N2mer9L659rksKkJ8fonZA/+C nh9/++3RYZHyfisP6n7qWiT5Z+bCIsjO/wrzMk/T/TYDCyJ9IoVB6ZQvHwmxrFnsd2dS wc4V7doNgJjXwAecgPO8i8dDaupz1DYpDUoJor/9lcesQjqNnIzxqUgcakduUi6OJZDb a/WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=kxnznu7bMGfQI6OCq6BFw5sWZXvdtTh8jr6IZODFrlc=; b=mLAzG6zBnT7/dHzhTxsiXIHSmlQ0/9f/bua0GEKD7HppXN7MuW9BC4vO9TeuxOqKEB XAI8hyZIcr4U0vZTIjfKoEDolrGGiiFbEVpEWb1Iiebu8i0WSOIJh8bRdRQyqKA+5YSs jb7YZXJlWEBHeu5xe0J+35mauvrJlzWMZooMa/mbMTQT05vT45lw8vtO/WDCD+exB0X2 Ac4IrpSxhPmTbe4VVen5m+LzWgunNCK/LSFdQN237/zgYazqMLYmGY2F1Yj01cv1pfIN IyOjX1kWc6tLngDO1MJU5Fum6ddDd2myUAz0lV57+LaM1O1SAdDQKOjakFguKUChbUDt Dmog== X-Gm-Message-State: ABUngvclbYf1xZPj7IPqMAvMx6+FoXGODNQ1KFEDxIxSeGX9CTCJ8+siS52wkDD5Edu+Dw== X-Received: by 10.194.205.1 with SMTP id lc1mr2274339wjc.192.1477085560219; Fri, 21 Oct 2016 14:32:40 -0700 (PDT) Received: from espargaro.jakma.org ([2001:41c8:51:44:feff:ff:fe00:a2c]) by smtp.gmail.com with ESMTPSA id wn5sm4830965wjb.42.2016.10.21.14.32.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Oct 2016 14:32:39 -0700 (PDT) Date: Fri, 21 Oct 2016 22:32:39 +0100 (BST) From: Paul Jakma To: Susan Hares In-Reply-To: <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> Message-ID: References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) X-Snooper: A life spent reading others private email is a sad and wasted one X-NSA: nitrate toxic DNDO hostage al aqsar fluffy jihad DHS cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt mustard gas x-ray british airways hydrogen washington peroxide cool FEMA emergency four lions encryption ricin table pandemic scanner power sleet catalyst injection acetone toluene amatol X-KEYSCORE: The greatest long-term threats to freedom and democracy are based in Langley and Fort Meade and Cheltenham MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: idr@ietf.org, Peter Hessler Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 21:32:43 -0000 On Tue, 18 Oct 2016, Susan Hares wrote: > Do we know which routers are sending path attributes with 20 or 21? I don't know about #20, but Quagga had support for AS_PATHLIMIT for a while. I added it in '07 and removed it from the upstream code in '11. > Sue > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Peter Hessler > Sent: Tuesday, October 18, 2016 1:26 PM > To: idr@ietf.org > Subject: [Idr] Unknown Attributes seen in the wild > > I just did a check of the DFZ, both IPv4 and IPv6, and these are the > unknown/deprecated attributes on paths that I can see. > > 20 Connector Attribute (deprecated) [RFC6037] > 21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit] regards, -- Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: "Look, Daddy, a whale egg!" --Ralph Wiggum Make Room for Lisa (Episode AABF12) From nobody Fri Oct 21 14:44:08 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAE81295EF for ; Fri, 21 Oct 2016 14:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jakma-org.20150623.gappssmtp.com 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 yKy-DhIWPnPU for ; Fri, 21 Oct 2016 14:44:06 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92961295ED for ; Fri, 21 Oct 2016 14:44:05 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id c78so7721967wme.0 for ; Fri, 21 Oct 2016 14:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jakma-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=h8PIykjONl0mmxd1rSDWaGcI9jOL0oT4yF7CrtxOwuY=; b=WDftpkEc6iZC+tolOjb7zL74Ny+lP5x8it8XxxjTurxqEkIUVN1wjt1MMI3kOASnlP mKK1yX3MFXu6a4xnIC21m9Lb+f3UacozVTB3MV0a7fs/KHG23u+BtZhhP1gPLVA1zo52 7bt3EP98/Wr2160fQ0F5h49ZZMDJHZpZKhSSneWvbRLKik+XEhFBXdmk/8eHGwtluYV0 V5b7fQaXlCTrhkgUrsXcYX9nH08ZEy+wtfIAZ84YdOizGYdN9OY3vafGm7eenv1ozyH9 qM4+/dQM4ikR7I1GY2XMJ5BozX5ePltyI6XDT9HulcC8fANmNdkMUfwEx299JwI960RI CmsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=h8PIykjONl0mmxd1rSDWaGcI9jOL0oT4yF7CrtxOwuY=; b=PkvVy3CKHzove3Z6w8YyoVNsr1yFvHfgsDLxne3pBxT8bljXIPVc4wN0p75VnNo32e U2QYjKU7ollMjWprupytaG0BSbKp02oi85DvTY/mPQTRVqSZCE7CnCb7cvEB6eZh6ZaZ ACjhMGncZ1WsMFXQXSF+awRAaiM5ZKdnh5ujl6PcYkzY9WI7oEsaVlLrBNthIUxh2OGe 9bKnE2+t2lN88N6PlW4ijQwJu3J6bNctV31A6/bCRmqhgr5S0uTOWCd56uKkUvgRgqD8 pXBaTwJBSUZ+45zr1m5wKVncu+pwrS5pvyGADoqf4TGWBOf5moJW1OBbzbkDe7q9+czP XeGA== X-Gm-Message-State: AA6/9Rls2Z5AU9tTDDiYGV9EUs+VB2GGoqAf0li4otbAmbVzIK/UrbLfwyBGfylz+yG/2w== X-Received: by 10.28.207.198 with SMTP id f189mr4695683wmg.18.1477086244300; Fri, 21 Oct 2016 14:44:04 -0700 (PDT) Received: from espargaro.jakma.org ([2001:41c8:51:44:feff:ff:fe00:a2c]) by smtp.gmail.com with ESMTPSA id us3sm4889820wjb.32.2016.10.21.14.44.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Oct 2016 14:44:02 -0700 (PDT) Date: Fri, 21 Oct 2016 22:44:02 +0100 (BST) From: Paul Jakma To: "i3D.net - Martijn Schmidt" In-Reply-To: <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> Message-ID: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) X-Snooper: A life spent reading others private email is a sad and wasted one X-NSA: nitrate toxic DNDO hostage al aqsar fluffy jihad DHS cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt mustard gas x-ray british airways hydrogen washington peroxide cool FEMA emergency four lions encryption ricin table pandemic scanner power sleet catalyst injection acetone toluene amatol X-KEYSCORE: The greatest long-term threats to freedom and democracy are based in Langley and Fort Meade and Cheltenham MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IETF IDR WG , Peter Hessler , Robert Raszuk Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 21:44:07 -0000 On Fri, 21 Oct 2016, i3D.net - Martijn Schmidt wrote: > Summarizing, any restrictions which can not be enforced don't belong > in the IDR document because they're irrelevant to implementors. > Arguing about it doesn't change the fact that such recommendations > belong in a BCP/GROW document. It is that simple. Syntax can be in the protocol, without per se strictly enforcing the semantics - which could be defined elsewhere. A protocol document can say some 4-byte data is of type "IPv4 address" and another "ASN" without having to get into what that means - specifying how the type and data are encoded, while leaving the higher level semantics of the type(s) to other documents. If we're going to encode a bunch of different typed things into a field, we might as well as provide a syntax for encoding type information into the field - at least for the obvious types of data we are _certain_ will be put in there. One of the types might well be "opaque data". ;) m.v.g / regards, -- Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: No wonder you're tired! You understood so much today. From nobody Fri Oct 21 15:15:11 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFDB129691 for ; Fri, 21 Oct 2016 15:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 npXTTug_Wr3t for ; Fri, 21 Oct 2016 15:15:08 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3F012968C for ; Fri, 21 Oct 2016 15:15:08 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id f193so2010808wmg.1 for ; Fri, 21 Oct 2016 15:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dIKYAOQ4ny2W3KLzkt6Bs9Q0AtOz+JyhqR3JwVbVdC0=; b=zB2QLWUCohMRgLj881qmk8ANanmBEIK1NnwynrRAQluvhz+cxgch4PrNFM4Izq22zW +6HFK3KjBXQ5nMxcIJc3dUzkhEMujvmVVzGthtQdcnChN7aPko/tiANEoRXMivvRAMiu 1k6P+G1GlvO+Oift7ZOES695FXL19tVKkBk37tT7cA+tpO8T06LC7RFbznyVH7TyiMYG mwB/j1GajRFDr4gzeEVzF1mVSnokduBF+f+eUorqmB4CM26IVV73VUf7r2Ck0o0VkXu1 jsQtZ6zhGAa2JCE3lSJa5aTC1F/XhWiVCiCqakkSO7f/LE2lJsTSS6gfQXHEq13rytOn +F0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dIKYAOQ4ny2W3KLzkt6Bs9Q0AtOz+JyhqR3JwVbVdC0=; b=fEfEuZ/xkgQ+bZTn4yUp1C96F7oQPyw+GtgQymk8kzzSfZgDGFQmDsJSNqkO6slVnx QuVdhUr80VWohhIAlJPCltetzdSkrGRvzOhzK9BH1BgccvzuD2dqDmVr8rrtLShgUUgD VxcRQwIITBc0ovj/StTXxCHAL1QEB0yPLWjvuLrK7+38cFSImsSNqwXh0w3ujPl4dsNU e3daPvAVwaVyq1qUa5r316K8fe5XeYFm12t+DNbbNAlJsH7Q2UUz6QDi2txyHNDixWuq xKPZ7GBvwGwvtaR4x8U6y9nbrVIoWJl9eOii3oacA30y3oYKh5r9dTgwjlqQE6BXVKsG ANNg== X-Gm-Message-State: AA6/9RlrrF06cQIhl1oaTYMLfL3lIWtpDLPgVmqGljaZPuK9Fj9ps6y4vuHuPLbSAMFwysGGBFQONBeeNKen4Q== X-Received: by 10.28.222.70 with SMTP id v67mr4717052wmg.84.1477088106745; Fri, 21 Oct 2016 15:15:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.207 with HTTP; Fri, 21 Oct 2016 15:15:04 -0700 (PDT) In-Reply-To: <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> From: Brian Dickson Date: Fri, 21 Oct 2016 15:15:04 -0700 Message-ID: To: "i3D.net - Martijn Schmidt" Content-Type: multipart/alternative; boundary=001a114b103ce7937b053f675f26 Archived-At: Cc: IETF IDR WG , Peter Hessler , Robert Raszuk Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 22:15:09 -0000 --001a114b103ce7937b053f675f26 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 21, 2016 at 9:21 AM, i3D.net - Martijn Schmidt < martijnschmidt@i3d.net> wrote: > > Summarizing, any restrictions which can not be enforced don't belong in > the IDR document because they're irrelevant to implementors. Arguing about > it doesn't change the fact that such recommendations belong in a BCP/GROW > document. It is that simple. > I'd like to pick a nit with the argument here, as a counter-point to what I think needs to be in the document. There are plenty of IDR-specified things that are not enforced or enforceable, which are nonetheless necessary to define or specify. Those include things such as: - next-hop - router-id - cluster-id - AS-path component(s) [injecting ASNs via prepend mechanisms] - MED Including Global Administrator (with a definition of it as _being_ an ASN), is all that is required -- if necessary, rewording it to not use RFC 2119 language. Like all of those other things, they can be set by operators, and are not able to be enforced without severely restricting operators' activities. Implementors who apply restrictions on those, may encounter resistance from their customers, their sales folks and potential customers, and their customers' peers. Brian --001a114b103ce7937b053f675f26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 21, 2016 at 9:21 AM, i3D.net - Martijn Schmidt <marti= jnschmidt@i3d.net> wrote:
=20 =20 =20

Summarizing, any restrictions which can not be enforced don't belon= g in the IDR document because they're irrelevant to implementors. Arguing about it doesn't change the fact that such recommendations belong in a BCP/GROW document. It is that simple.

I'd like to pick a nit with the argument here, as = a counter-point to what I think needs to be in the document.

=
There are plenty of IDR-specified things that are not enforced o= r enforceable, which are nonetheless necessary to define or specify.
<= div>
Those include things such as:
  • next-hop=
  • router-id
  • cluster-id
  • AS-path component(s) [injecti= ng ASNs via prepend mechanisms]
  • MED
Including Global Admin= istrator (with a definition of it as _being_ an ASN), is all that is requir= ed -- if necessary, rewording it to not use RFC 2119 language.=C2=A0
<= div>
Like all of those other things, they can be set by opera= tors, and are not able to be enforced without severely restricting operator= s' activities.

Implementors who apply restrict= ions on those, may encounter resistance from their customers, their sales f= olks and potential customers, and their customers' peers.

Brian
--001a114b103ce7937b053f675f26-- From nobody Fri Oct 21 15:35:59 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CEB1296AB for ; Fri, 21 Oct 2016 15:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kWM2w3vAWG0A for ; Fri, 21 Oct 2016 15:35:55 -0700 (PDT) Received: from relay.dacor.de (relay.dacor.de [217.24.56.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0E40912968C for ; Fri, 21 Oct 2016 15:35:55 -0700 (PDT) Received: from exchange.dacor.de (astaro1.dacor.de [217.24.48.66]) by relay.dacor.de (Postfix) with ESMTPS id E5B91E3019; Sat, 22 Oct 2016 00:35:53 +0200 (CEST) Received: from ex02.suecdacor.local (192.168.1.16) by ex02.suecdacor.local (192.168.1.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 22 Oct 2016 00:35:53 +0200 Received: from ex02.suecdacor.local ([::1]) by ex02.suecdacor.local ([::1]) with mapi id 15.00.1210.000; Sat, 22 Oct 2016 00:35:52 +0200 From: Julian Seifert To: Robert Raszuk , IETF IDR WG Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) Thread-Index: AdIotF10Qx6LizvwQ9uItB9ryESdDv//9v8AgAFk3oCAAAHRgIAAFxgAgAM7eACAAAPtgIABHqgAgAAGaoCAAI7duw== Date: Fri, 21 Oct 2016 22:35:52 +0000 Message-ID: <1477089344939.73454@dacor.de> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> , In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [88.133.178.43] Content-Type: multipart/alternative; boundary="_000_147708934493973454dacorde_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 22:35:57 -0000 --_000_147708934493973454dacorde_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Robert, I think there is no need to complicate this, in my opinion, simple issue. We need to encode information in an easy way that we can append to = a route. The LC allows us to encode information using 12 Octets which allows us a lo= t of encoding. It's separated into 3 fields which should(!) be used in a certain way but m= ust be allowed to be configured to any* value. Why? Because that's what communities are being= used for already and we simply need a bigger space for that. (*any except those that might be defined as reserved) There might be migration or other scenarios where enforcing the values of s= ome of the fields might make things more complicated than they need to be. = For example when one merged and changed AS-number but doesn't want to chang= e the communities he send or still wants to be able to receive the "old" as-value communities. We currently do not check/enforce values of rfc1997 communities. That is on= ly being done by operator defined policies on the routers and this should stay this way. We want to continue to do that and simply need larger communities so we can= continue doing what we do with 4-Byte AS-Numbers. So there should be 3 fields of 4 Octets = that can be set to any value and can be used on routers in policy definitions - quite simple. There is nothing won by enforcing anything it's only making the issue more = complex than it needs to be. Let me ask, what do we gain by enforcing the restrictions on the values? I think the idea of the draft was to have a tool like we have with rfc1997 = but with larger/more fields to accommodate for 32byte as-numbers. kind regards, Julian --_000_147708934493973454dacorde_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Robert,


I think there is no need to complicate this, in my opinion,&nb= sp;simple issue.

We need <THING> to encode information in an easy way that we can a= ppend to a route.

The LC allows us to encode information using 12 Octets which allows= us a lot of encoding.

It's separated into 3 fields which should(!) be used in a certain way bu= t must be allowed to

be configured to any* value. Why? Because that's what communities a= re being used for already

and we simply need a bigger space for that. 

(*any except those that might be defined as reserved)


There might be migration or other scenarios where enforcing the values of some of the fields might make things more complica= ted than they need to be. For example when one merged and changed AS-number but doesn't want to change the communities he send or

still wants to be able to receive the &= quot;old" as-value communities.

 

We currently do not check/enforce values of rfc1997 communities. Th= at is only being done 

by operator defined policies on the routers and this should stay this wa= y.

We want to continue to do that and simply need larger communities s= o we can continue doing

what we do with 4-Byte AS-Numbers. So there should be 3 fields of 4 Octe= ts that can be set to any value

and can be used on routers in policy definitions - quite simple.


There is nothing won by enforcing anything it's only making the issue mo= re complex than it needs to be.


Let me ask, what do we gain by enforcing the restrictions on the values?=

I think the idea of the draft was to have a tool like we have with rfc19= 97 but 

with larger/more fields to accommodate for 32byte as-numbers. =


kind regards,


 Julian


--_000_147708934493973454dacorde_-- From nobody Fri Oct 21 16:21:12 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 997D012952B; Fri, 21 Oct 2016 16:21:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709206562.28214.12749133546615974824.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:05 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] idr - Requested session has been scheduled for IETF 97 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:05 -0000 Dear John Scudder, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. idr Session 1 (2:30:00) Tuesday, Afternoon Session II 1550-1820 Room Name: Grand Ballroom 3 size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Inter-Domain Routing Area Name: Routing Area Session Requester: John Scudder Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: trill i2rs i2nsf netconf bess sidr netmod rtgwg Second Priority: sdnrg nfvrg teas Third Priority: dots rtgarea Special Requests: I believe our attendee count of 105 last meeting was an undercount -- the room was full to capacity (actually, past capacity) so some people who wanted to attend were turned away. --------------------------------------------------------- From nobody Sat Oct 22 03:39:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED36129553 for ; Sat, 22 Oct 2016 03:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 w33zazvwPclU for ; Sat, 22 Oct 2016 03:39:48 -0700 (PDT) Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B2112954D for ; Sat, 22 Oct 2016 03:39:46 -0700 (PDT) X-Footer: aTNkLm5s Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for idr@ietf.org; Sat, 22 Oct 2016 12:39:41 +0200 References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> Cc: IETF IDR WG From: "i3D.net - Martijn Schmidt" Organization: i3D.net Message-ID: <25cfd19e-cf33-7380-89c0-d11bc6128139@i3d.net> Date: Sat, 22 Oct 2016 12:39:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------266118145461F2B844BD6BA2" Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 10:39:50 -0000 This is a multi-part message in MIME format. --------------266118145461F2B844BD6BA2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Brian, Doesn't the existing wording "The Global Administrator field is intended to allow different Autonomous Systems to define Large BGP Communities without collision." already achieve what you want, if you feel that RFC2119 language is not necessary? Best regards, Martijn On 10/22/2016 12:15 AM, Brian Dickson wrote: > > > On Fri, Oct 21, 2016 at 9:21 AM, i3D.net - Martijn Schmidt > > wrote: > > > Summarizing, any restrictions which can not be enforced don't > belong in the IDR document because they're irrelevant to > implementors. Arguing about it doesn't change the fact that such > recommendations belong in a BCP/GROW document. It is that simple. > > > I'd like to pick a nit with the argument here, as a counter-point to > what I think needs to be in the document. > > There are plenty of IDR-specified things that are not enforced or > enforceable, which are nonetheless necessary to define or specify. > > Those include things such as: > > * next-hop > * router-id > * cluster-id > * AS-path component(s) [injecting ASNs via prepend mechanisms] > * MED > > Including Global Administrator (with a definition of it as _being_ an > ASN), is all that is required -- if necessary, rewording it to not use > RFC 2119 language. > > Like all of those other things, they can be set by operators, and are > not able to be enforced without severely restricting operators' > activities. > > Implementors who apply restrictions on those, may encounter resistance > from their customers, their sales folks and potential customers, and > their customers' peers. > > Brian -- Met vriendelijke groet / Kindest regards, Martijn Schmidt i3D.net performance hosting *Martijn Schmidt | Network Architect* Email: martijnschmidt@i3d.net | Tel: +31 10 8900070 *i3D.net B.V. | Global Backbone AS49544* Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands VAT: NL 8202.63.886.B01 Website | Case Studies | LinkedIn --------------266118145461F2B844BD6BA2 Content-Type: multipart/related; boundary="------------7C9D52219C33F2442FD337EC" --------------7C9D52219C33F2442FD337EC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Brian,

Doesn't the existing wording "The Global Administrator field is intended to allow different Autonomous Systems to define Large BGP Communities without collision." already achieve what you want, if you feel that RFC2119 language is not necessary?

Best regards,
Martijn

On 10/22/2016 12:15 AM, Brian Dickson wrote:


On Fri, Oct 21, 2016 at 9:21 AM, i3D.net - Martijn Schmidt <martijnschmidt@i3d.net> wrote:

Summarizing, any restrictions which can not be enforced don't belong in the IDR document because they're irrelevant to implementors. Arguing about it doesn't change the fact that such recommendations belong in a BCP/GROW document. It is that simple.

I'd like to pick a nit with the argument here, as a counter-point to what I think needs to be in the document.

There are plenty of IDR-specified things that are not enforced or enforceable, which are nonetheless necessary to define or specify.

Those include things such as:
  • next-hop
  • router-id
  • cluster-id
  • AS-path component(s) [injecting ASNs via prepend mechanisms]
  • MED
Including Global Administrator (with a definition of it as _being_ an ASN), is all that is required -- if necessary, rewording it to not use RFC 2119 language. 

Like all of those other things, they can be set by operators, and are not able to be enforced without severely restricting operators' activities.

Implementors who apply restrictions on those, may encounter resistance from their customers, their sales folks and potential customers, and their customers' peers.

Brian

--
Met vriendelijke groet / Kindest regards,
Martijn Schmidt


i3D.net performance hosting
Martijn Schmidt | Network Architect
Email: martijnschmidt@i3d.net | Tel: +31 10 8900070

i3D.net B.V. | Global Backbone AS49544
Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands
VAT: NL 8202.63.886.B01

Website | Case Studies | LinkedIn

--------------7C9D52219C33F2442FD337EC Content-Type: image/png; name="i3Dlogo-email.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="i3Dlogo-email.png" iVBORw0KGgoAAAANSUhEUgAAAOkAAACCCAMAAACU2h9IAAAAGXRFWHRTb2Z0d2FyZQBBZG9i ZSBJbWFnZVJlYWR5ccllPAAAA0xpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tl dCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1l dGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUu Ni1jMTMyIDc5LjE1OTI4NCwgMjAxNi8wNC8xOS0xMzoxMzo0MCAgICAgICAgIj4gPHJkZjpS REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgt bnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9u cy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6MEM3NkQ1 NTY3NkE4MTFFNkI0OTI5NERBQkYxNEIxQUEiIHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6 MEM3NkQ1NTU3NkE4MTFFNkI0OTI5NERBQkYxNEIxQUEiIHhtcDpDcmVhdG9yVG9vbD0iQWRv YmUgUGhvdG9zaG9wIENDIDIwMTUuNSAoV2luZG93cykiPiA8eG1wTU06RGVyaXZlZEZyb20g c3RSZWY6aW5zdGFuY2VJRD0iYWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOmYwMGZmMDc1LTc2YTUt MTFlNi1iZDIzLWJhYTI4MGRmODBkYyIgc3RSZWY6ZG9jdW1lbnRJRD0iYWRvYmU6ZG9jaWQ6 cGhvdG9zaG9wOmYwMGZmMDc1LTc2YTUtMTFlNi1iZDIzLWJhYTI4MGRmODBkYyIvPiA8L3Jk ZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0i ciI/Pu9aRCwAAABgUExURf7+/uuxsufn5+ONj9nZ2fPz86qqq5SUlWNjZHt7fM/Pz7i4uFZW V4aGh0FBQsPDw0pKS/TU1T8/QN93efv29ttmaW9vcNU+Q/nq6vHIydhTV/bf4OijpNIjKkBA Qf///zh9ticAAAfaSURBVHja7Nxro3ssAABw5n4dj+x66Pt/ywddFEr6m5mtN8fZWvVDqYQB vyUYP+lP+rnSug+hIA4I3cCPs7pOszjwopMoLb+eDll8SVz7Hfs0rf8z1KVhkg1K7rvOIikK cWLvWhpOFj9zwWJpEy72bqUgER6hUENap56xT+lJUvbU1ZA2Z76zR+kplhba1ZFuS1WUOvFM oSMdaX0xdicN5sqcnXSktbc3abT48ChKU3tfUiNWKHSkI62DfUkjpebF0JHW9luk5z44y4sd akmTt0gFcexx9cqymTLz0hiHLB03ZWBHUm9QNq/toYPzsD3ODKGUHm7D9jLZqfBm6eD4nETV 156XTvRBvP1IAXfKpSfhwXaVpNBO39L6Kkht4SFwMmFFlUgH3ZB4P9JIfFXghze+ovTMnwpg N1JX2OwMdkKsKHV46Wk3Uq42XiQndmqoSWH8jsZXQZqI24/B0XEUpf5OpYG4S2MIz0Mp5sJ9 eX6D1O4DUJLC9EOl02WTSbOf9OBS58OlkceESCYFHy6VBU6awuNKDa3e4CdKHeGo5GjSUDjM OZrUFRb5YFKD86TOcaX8oO0CDyu1M/HU9pGkwOWhsXEw6Tlqg+sG2YK7FR8p9dVusBxXGjtf Io1P8DukgQO/QhpHBvwKqX+ajXaUY5q560odnwR8wyBC/7V71PPHoY3l+pNh5/XUGY6O3H6a KhDcovamLwnrt72jlUXrSC/7k9Y+eIUUD492JR1OGq4jxd/tSzr4xUpS741St50LTQJ/tDbD f4U0FkjTjAmdFG+TywEOa4zaQBSrr9LRlqLbAmNpMDMt6646Encuyqt09KXRHqQQxItX6SyW JruQDiZBFVfpLJN2Mxnvl/Jzg6qrdBZJu933fumgbQ9eIXX3IY1ecl8GSzNq2oGUX7uSrSsN 6ArKHUgHa1eMVaVeTH67AynUW6WjKPVIh3ArKXCYACYTXnedA5GeSe3fSrr5ig4idVI8cju8 FCdynpLOnGSfJiUVVTZqCw4hDfHI7fhSgJI/HV+KI0ZfIEXEZA/S+rVSG8+cbyTdfCVzL8UP 1CUjaRyQ4K4oVV6dXq+0Or2X4r0cb9RzcEXjFe0nDlL5EweMNBpGfKl09adIwpmnSBjpaVOp +MkgoPdkUDLzZBAj5U70149lUtFj0qs87XWRSr0tpYNS9zeGz+lrnuBjpedNpaOnMtssjTDR eCoTnhSeymSlbOv1eun4SdssjtNFT9riW9RxpvKkLStlexkbzK6oPBC/4tPTnNTbVOqqFDnW eyI+nJGGm0rB695ycIEzUiPbUqrymgN/vTdXcFKmT7+F1LgsLfK/vI3EmVq4stV874veMEPX gdhoYBJOSO0paT+WaYK96sy2nS07NkrSfl3lmd1fvLRv+WXrHFacw7clR1X3TVB9x1ImTTaW Qkf45iC9t3vVCdNnkEmjraVNcabf2OY5UEPqcznIpKftpdA4B8NOoN5b+LJkkL5MStPaUNp2 Is4eXouUxpdk+ZsV68wP3HDU15VKvfWlzD01+QvGjNH9kFGtFgRxgn2uxuCOC2DKBCbSNMb5 ghkpPHL4SX/Sn/Qn3am06kJpNm10RQLZfFhty00+NZvtm3WtrtYN8jGKZqtoUzPRryHMK/IR +SX6ApglziwnyRaoIM1W3v/p8+k2u2zMqv8JitZu38ZJS6VNHDCWVtUVcNLbFX1642MUBEg3 ulI9iNSi0pJmJpUy+Tyv5BfTUhMnDfqkZ6TNTyak1R8ntfCmxcfogM8mtQcnrYi0Arg4Zp+W VMrkU9BfTEutcdJiaQ5Bk3RJMqP5gqL9dPAxypGP0ZXmTlj04JKid991XzQfW93BKTope6Jx 0j4fQDZLNhYjfeCkS5J0KZWifIdSeO9NkNQ+8iUbo8D78kmlTb4Fgyc7vudIpUw+/aZAWoFR 0hrSfFaa91ILuck5W1q0JWoq3L9Ki6IQSe+bS8u2rlxRjObgWiZticq2EmtKb7he8LF66aNp J7aVFu1fq/3TxmgOrnlHVaZts6pBcfI8V5W2jRzTnI6kFmpfuNZEQ9o1HVIpitE2NO1xK9o/ FWp6zT7ys5oojqrU7JvnKWnzNVgipW0vafa7T28luVzhFmckxTGKLse2wqB2ub1KdDHwZb05 p29TUvaiQC8hA2l3xaFHdSRt0mXaTXo9V7ueFky+JZBIaYwmg+YrE3R/KnSRAa0PlaYtrKkt 7boEhDqSNmf330Jp30dipXc4J70jWLNvrbw7UVGMKzrSqDT3Cp/WOlJEtURS0jaoSkm/Nx/m m0vqKY1RdJW8NFFdbzpz3e76o9dRwHS9ltZTQjUFUpNPerbt5ZJh66klbZFwjFZatG0sbnjy 7lPanpHenc5VBk0qPXAnekL6XEO6pI/UHsEr6pB2xkdRlOTXcGrHK7e9pomyuU1L4XUN6YLr KcKYKKc/emoDejrrSvnDOyG1tpbmjLRgKjEzWnuN1HyFdDSWYaSAgV3pgAbTSXGYAYfiWAaW ZBMIpM9qOExSkvKN5EjKj085aVdfAGlqH1iKe4GkOBrjU5OLNiGF1yXjU1UpP+fASws6ZMn7 uZaCnE6P4cSA6pwD/sn1KZQWw+kMDSmo8CiE9ii5eSQao8DNUEEvcX9Y+iBSS3seCVgPsjkt NRXnkeC3hJ/0J/1Jf9Kf9Cd9XfhfgAEA6npi4QQJPOEAAAAASUVORK5CYII= --------------7C9D52219C33F2442FD337EC-- --------------266118145461F2B844BD6BA2-- From nobody Sat Oct 22 03:57:59 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C28C1295EA for ; Sat, 22 Oct 2016 03:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 XgSIbfs31arB for ; Sat, 22 Oct 2016 03:57:56 -0700 (PDT) Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AE6129551 for ; Sat, 22 Oct 2016 03:57:55 -0700 (PDT) X-Footer: aTNkLm5s Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for idr@ietf.org; Sat, 22 Oct 2016 12:57:50 +0200 References: <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <711ba725-7304-5122-cfb2-2a40c2d76ca9@i3d.net> Cc: idr wg From: "i3D.net - Martijn Schmidt" Organization: i3D.net Message-ID: Date: Sat, 22 Oct 2016 12:57:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------33CAEA60E5474577E6C18FE7" Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 10:57:57 -0000 This is a multi-part message in MIME format. --------------33CAEA60E5474577E6C18FE7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Robert, I completely agree that one should be able to filter LC's, but please treat that filtering the way RFC1997 already does today and leave the policy of what (not) to filter up to the operators instead of trying to hard-code policy into the protocol. That is what I said, nothing more, nothing less. Brian has provided an excellent answer to your question, so please consider this as my +1 for his message. Best regards, Martijn On 10/21/2016 09:51 PM, Robert Raszuk wrote: > > Please let operators worry about their own filtering policies (or > lack thereof) and leave such recommendations to the BCP/GROW document. > > ​This is IETF WG and I find such comment inappropriate. This > discussion is about extending BGP protocol and we all should be > worried how to apply effective policy on something which is being > defined here. > > So triggered by the above let me ask a very simple question. You and > others expressed very clearly that LCs should traverse N-ASes and be > executed somewhere remotely. Great. > > Let's also assume that you talk to everyone in the path and convince > them to let your LC go through. > > Question: > > If you choose to inject LC in the format TARGET_ASN:ACTION:PARAMETER > based on what field is anyone in the BGP propagation path supposed to > let's your LCs go and stop all other 1000s of LCs injected by anyone > else ? > > Today RFC1997 don't go far as they have no way to apply per their > originator permit or deny statements. > > Thx, > R. --------------33CAEA60E5474577E6C18FE7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Robert,

I completely agree that one should be able to filter LC's, but please treat that filtering the way RFC1997 already does today and leave the policy of what (not) to filter up to the operators instead of trying to hard-code policy into the protocol. That is what I said, nothing more, nothing less.

Brian has provided an excellent answer to your question, so please consider this as my +1 for his message.

Best regards,
Martijn

On 10/21/2016 09:51 PM, Robert Raszuk wrote:

Please let operators worry about their own filtering policies (or lack thereof) and leave such recommendations to the BCP/GROW document.

​This is IETF WG and I find such comment inappropriate. This discussion is about extending BGP protocol and we all should be worried how to apply effective policy on something which is being defined here. 

So triggered by the above let me ask a very simple question. You and others expressed very clearly that LCs should traverse N-ASes and be executed somewhere remotely. Great.

Let's also assume that you talk to everyone in the path and convince them to let your LC go through. 

Question: 

If you choose to inject LC in the format TARGET_ASN:ACTION:PARAMETER based on what field is anyone in the BGP propagation path supposed to let's your LCs go and stop all other 1000s of LCs injected by anyone else ? 

Today RFC1997 don't go far as they have no way to apply per their originator permit or deny statements. 

Thx,
R.
--------------33CAEA60E5474577E6C18FE7-- From nobody Sat Oct 22 05:27:44 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED7D1297E4 for ; Sat, 22 Oct 2016 05:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.031 X-Spam-Level: X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=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 gm4vOdBMlrpO for ; Sat, 22 Oct 2016 05:27:40 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 2FEBD1297B8 for ; Sat, 22 Oct 2016 05:27:39 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 927CA60F0D for ; Sat, 22 Oct 2016 14:27:36 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 38938602AF; Sat, 22 Oct 2016 14:27:36 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 1BD7D32BF2; Sat, 22 Oct 2016 14:27:36 +0200 (CEST) Date: Sat, 22 Oct 2016 14:27:35 +0200 From: Gert Doering To: Robert Raszuk Message-ID: <20161022122735.GC79185@Space.Net> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> 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.6.1 (2016-04-27) Archived-At: Cc: heasley , IETF IDR WG , Sue Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 12:27:42 -0000 Hi, On Fri, Oct 21, 2016 at 05:42:37PM +0200, Robert Raszuk wrote: > > Secondly, there's literally no way for the vendor to check whether an > > ASN belongs to "the entity that defines the meaning of the rest of the > > Large Community" > > Why not ? > > If you do not make those 4 octets configurable by spec and always fill it > with AS number defined in your BGP instance you will have assurance it > is ASN of the entity that defines the rest 8 octets of the LC as otherwise > you will likely not establish any EBGP sessions to your peers. But that is only half the intended usage of communities - one is "I tag it with :" to signal something to my own routers or my customers. The other one is "I tag it with :", and there is no way for my router to validate that "" is indeed the one who defined "". So, how exactly is the vendor to check variant B? (And if you do not understand what people use communities for, today, maybe you should not be argueing these points, sorry) > So there is very easy way to enforce it today in any BGP implementation. No. 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 Sat Oct 22 05:34:30 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AC9129458 for ; Sat, 22 Oct 2016 05:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.031 X-Spam-Level: X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=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 oDStq7x5Gtue for ; Sat, 22 Oct 2016 05:34:26 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.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 1858A129427 for ; Sat, 22 Oct 2016 05:34:25 -0700 (PDT) X-Original-To: idr@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 65B7C60997 for ; Sat, 22 Oct 2016 14:34:24 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 2270C602AF; Sat, 22 Oct 2016 14:34:24 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 1307832C1A; Sat, 22 Oct 2016 14:34:24 +0200 (CEST) Date: Sat, 22 Oct 2016 14:34:23 +0200 From: Gert Doering To: Job Snijders Message-ID: <20161022123423.GD79185@Space.Net> References: <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161021164241.GC32387@Vurt.local> X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: IETF IDR WG , Peter Hessler , Robert Raszuk Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 12:34:28 -0000 Hi, On Fri, Oct 21, 2016 at 06:42:41PM +0200, Job Snijders wrote: > We want routing policy in which networks can send 2914:X:Y to us, and we > can send 2914:A:B to them - very much like RFC 1997 communities. The > Global Administator field does not necessarily contain the ASN of the > sending party. And this is, just to repeat the obvious, *intentional* and *very useful*. Gert Doering -- Operator who understands BGP -- 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 Sat Oct 22 06:53:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F7D1295F0 for ; Sat, 22 Oct 2016 06:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5nrc07kKDoQs for ; Sat, 22 Oct 2016 06:53:09 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E9C312943D for ; Sat, 22 Oct 2016 06:53:09 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id c78so31034728wme.0 for ; Sat, 22 Oct 2016 06:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=O7Y5d4Y95xDC4wlsSj3vMoXYYW+9J3LyVFSAkips5ps=; b=HLgCwoGhqOOdbo39+W1JSJCtNz/QR2t4Wb6ylA28z/9LwGg3+fYNjInDHpSFCurei7 CeWMOF4e8WvbGpysvnb2KOIPLSDJ5Lhk6SH702eVpaxXyn7ep5A2HztQXWix3s3L9dX+ QRolSbevlR9GQm0JnNam2UYtTTinh8qRtf+P3m9TRaAKeYJ1JsHc9MYH4sX6sjFXS9Ir mjziEHFOT/PGWmM1b7FtgXkWX2jPbCojeKs4A7oxOxT0b9cf5xrjoOpudPqFt8fwidXd +siaBD12hxFVnWmJMiPY2ZJD4c/p7WTvMXvvhVXm2nDPOR8oHYbZC18MdGGicbpoidas OOdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=O7Y5d4Y95xDC4wlsSj3vMoXYYW+9J3LyVFSAkips5ps=; b=WLmNWPuNviq2hRxoIp6onx6Je+hr2qOCnb1QjbJG89KyAVVdzUUySiolqBoln+EiQE VxfB02CQLrU/2kiequvR8uLGE/3h1EsfOPtycB1XNvAoWjbTvS4/RSydtQDfW87tj7C7 4n1HNmmJmyF79rA4/1FsVj13jz/MkRZzkbZAw8hjS2NYxl3ArGzm4Ztsn03PRiUNRaQt lYjasHsd+gv9O3hCZoCGRCGz/eeHMBiT+vwg79evtc/hB1p0gAKWszi0hs+GixQwukoi JiHN9pnwJz6TjRId6VJuAWRH5jmVktGa6RxitQK9NXOX94Rm6RhSRLeYsi4LtyHU8rf6 AeRg== X-Gm-Message-State: ABUngve8JWEbM8Re9I02ta+8hIg2U/cO9pqaelJVd/LfDfNzuB9zqu930aAb7rBstzbnYcAwz5OOdIIk7V6Rog== X-Received: by 10.194.94.232 with SMTP id df8mr4529490wjb.227.1477144387911; Sat, 22 Oct 2016 06:53:07 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Sat, 22 Oct 2016 06:53:05 -0700 (PDT) Received: by 10.80.182.155 with HTTP; Sat, 22 Oct 2016 06:53:05 -0700 (PDT) In-Reply-To: <20161022122735.GC79185@Space.Net> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161022122735.GC79185@Space.Net> From: Robert Raszuk Date: Sat, 22 Oct 2016 15:53:05 +0200 X-Google-Sender-Auth: csHpKRbQaSOvond-AeL1yIA6-ps Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=047d7bb03aae8603fc053f747a19 Archived-At: Cc: heasley , IETF IDR WG , Susan Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 13:53:11 -0000 --047d7bb03aae8603fc053f747a19 Content-Type: text/plain; charset=UTF-8 You are mixing SRC_ASN with TARGET_ASN in the same field. Yes RFC1997 works like that but here we have opportunity to improve it. Thx R. On Oct 22, 2016 2:27 PM, "Gert Doering" wrote: > Hi, > > On Fri, Oct 21, 2016 at 05:42:37PM +0200, Robert Raszuk wrote: > > > Secondly, there's literally no way for the vendor to check whether an > > > ASN belongs to "the entity that defines the meaning of the rest of the > > > Large Community" > > > > Why not ? > > > > If you do not make those 4 octets configurable by spec and always fill it > > with AS number defined in your BGP instance you will have assurance it > > is ASN of the entity that defines the rest 8 octets of the LC as > otherwise > > you will likely not establish any EBGP sessions to your peers. > > But that is only half the intended usage of communities - one is > "I tag it with :" to signal something to my own > routers or my customers. > > The other one is "I tag it with :", and there is > no way for my router to validate that "" is indeed the one > who defined "". > > So, how exactly is the vendor to check variant B? > > (And if you do not understand what people use communities for, today, > maybe you should not be argueing these points, sorry) > > > So there is very easy way to enforce it today in any BGP implementation. > > No. > > 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 > --047d7bb03aae8603fc053f747a19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

You are mixing SRC_ASN with TARGET_ASN in the same field.

Yes RFC1997 works like that but here we have opportunity to = improve it.

Thx
R.


On Oct 22, 2016 2= :27 PM, "Gert Doering" <gert= @space.net> wrote:
Hi,

On Fri, Oct 21, 2016 at 05:42:37PM +0200, Robert Raszuk wrote:
> > Secondly, there's literally no way for the vendor to check wh= ether an
> > ASN belongs to "the entity that defines the meaning of the r= est of the
> > Large Community"
>
> Why not ?
>
> If you do not make those 4 octets configurable by spec and always fill= it
> with AS number defined in your BGP instance you will have assurance it=
> is ASN of the entity that defines the rest 8 octets of the LC as other= wise
> you will likely not establish any EBGP sessions to your peers.

But that is only half the intended usage of communities - one is
"I tag it with <myas>:<some meaning>" to signal somet= hing to my own
routers or my customers.

The other one is "I tag it with <jobs as>:<some meaning>&q= uot;, and there is
no way for my router to validate that "<jobs as>" is indeed= the one
who defined "<some meaning>".

So, how exactly is the vendor to check variant B?

(And if you do not understand what people use communities for, today,
maybe you should not be argueing these points, sorry)

> So there is very easy way to enforce it today in any BGP implementatio= n.

No.

Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.:= DE813185279
--047d7bb03aae8603fc053f747a19-- From nobody Sat Oct 22 07:11:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDE8129665 for ; Sat, 22 Oct 2016 07:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 Bn2Bx_8-A5bd for ; Sat, 22 Oct 2016 07:11:20 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0098.outbound.protection.outlook.com [104.47.40.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C341C12943D for ; Sat, 22 Oct 2016 07:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ets54fzt3OUDq6j5B24RlqxnzViy0I/oBk/lCPD8Lr8=; b=Y52LrZvPRxEaePqL4NuC/jlwLC5Hsoho5AL8/5spuoTwBN9byiOsQJQgfaMvvN1RflWUablIf+uT7/fh36FzR0r6qRqEIlLKPp9JQlNsr1DDvOsywVj4MaSO7/sg5gHBqVSy4Yc9ObJddSkjYxkBkXE+u7yhU3UvvBwLj/djhrM= Received: from CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) by CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Sat, 22 Oct 2016 14:11:19 +0000 Received: from CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) by CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) with mapi id 15.01.0679.006; Sat, 22 Oct 2016 14:11:19 +0000 From: John Scudder To: Robert Raszuk Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) Thread-Index: AQHSLF+rFZx4XPdf1UmaMSzslCIymKC0fnqAgAAFGBc= Date: Sat, 22 Oct 2016 14:11:19 +0000 Message-ID: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161022122735.GC79185@Space.Net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [75.151.14.9] x-ms-office365-filtering-correlation-id: 298c4d20-4e4f-4c54-6092-08d3fa854b8f x-microsoft-exchange-diagnostics: 1; CY1PR05MB2507; 7:65z01UaI0hLgUCNjzm5S1DJtm5iGQfHrQxP1yV8gMu4jk9houlB6zyc6rS4zzj1dR3DYOla8cnNh02tBLDpXxOK02zbrv4xPRtE8fwFLxL3Ng5BwHIQYYaojBTS4DhpNP3fIbLFGgC3GsqrMaMUFWZt+yvPT1NQ0JVzqCn75JOcs1jfcB4eqXgtq0UioBTZaEE9PApNdy7MJ1BqAfBT4+gc6eZexk1xV9Y+jV/JCJG2yO0N9CMrCijWfITRshEEr+mN4ew2gzvGXSbEs0iBmu33QV3g+P/L/0cfP0PsNKlrLkQzVMFiJbFtxiDby79/+4iSKFFwO/l4BBJ81pocE/3ohf9U0iKan2Fgvyqq3wBw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2507; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507; x-forefront-prvs: 01039C93E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(199003)(5423002)(377454003)(189002)(106356001)(92566002)(33656002)(19580395003)(99286002)(8936002)(10400500002)(19580405001)(230783001)(15975445007)(122556002)(7736002)(5660300001)(2900100001)(7906003)(106116001)(110136003)(11100500001)(97736004)(7846002)(4326007)(5002640100001)(2906002)(77096005)(66066001)(105586002)(54356999)(6116002)(3280700002)(3660700001)(93886004)(586003)(83716003)(76176999)(3846002)(6916009)(86362001)(36756003)(2950100002)(82746002)(102836003)(189998001)(81156014)(81166006)(68736007)(8676002)(16236675004)(87936001)(50986999)(19617315012)(101416001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:CY1PR05MB2507.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D6D63A9E3AF240F7B3FB923BEC0EBB8Fjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2016 14:11:19.2972 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Cc: EXT - heas , IETF IDR WG , Susan Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 14:11:23 -0000 --_000_D6D63A9E3AF240F7B3FB923BEC0EBB8Fjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert, "Yes RFC1997 works like that but here we have opportunity to improve it." When the working group accepted the draft as a work item, I think it was pr= etty clear from the extensive conversation at that time, that the intent wa= s to replicate RFC 1997, not to improve it. In fact, improving it was an ex= plicit nongoal if I remember right. One might argue that was a bad goal hav= e, and I think you did make that argument at the time, but the working grou= p consensus was otherwise. Of course, consensus can shift over time, and WGLC is a good time to test w= hether such a shift has occurred, so I don't think it's inappropriate for y= ou to have raised the question again. However, at this point it appears to = me that consensus has not changed. If you feel further conversation would be productive, I don't mean to forec= lose on that, but I thought it might be helpful to provide an update about = where it appears to me the consensus is trending at present. --John On Oct 22, 2016, at 9:53 AM, Robert Raszuk > wrote: You are mixing SRC_ASN with TARGET_ASN in the same field. Yes RFC1997 works like that but here we have opportunity to improve it. Thx R. On Oct 22, 2016 2:27 PM, "Gert Doering" > wrote: Hi, On Fri, Oct 21, 2016 at 05:42:37PM +0200, Robert Raszuk wrote: > > Secondly, there's literally no way for the vendor to check whether an > > ASN belongs to "the entity that defines the meaning of the rest of the > > Large Community" > > Why not ? > > If you do not make those 4 octets configurable by spec and always fill it > with AS number defined in your BGP instance you will have assurance it > is ASN of the entity that defines the rest 8 octets of the LC as otherwis= e > you will likely not establish any EBGP sessions to your peers. But that is only half the intended usage of communities - one is "I tag it with :" to signal something to my own routers or my customers. The other one is "I tag it with :", and there is no way for my router to validate that "" is indeed the one who defined "". So, how exactly is the vendor to check variant B? (And if you do not understand what people use communities for, today, maybe you should not be argueing these points, sorry) > So there is very easy way to enforce it today in any BGP implementation. No. 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_D6D63A9E3AF240F7B3FB923BEC0EBB8Fjunipernet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Robert,

"Yes RF= C1997 works like that but here we have opportunity to improve it."

When the working group accepted the draft as a work item, I think it w= as pretty clear from the extensive conversation at that time, that the inte= nt was to replicate RFC 1997, not to improve it. In fact, improving it was = an explicit nongoal if I remember right. One might argue that was a bad goal have, and I think you did make = that argument at the time, but the working group consensus was otherwise.

Of course, consensus can shift over time, and WGLC is a good time to t= est whether such a shift has occurred, so I don't think it's inappropriate = for you to have raised the question again. However, at this point it appear= s to me that consensus has not changed.

If you feel further conversation would be productive, I don't mean to = foreclose on that, but I thought it might be helpful to provide an update a= bout where it appears to me the consensus is trending at present.

--John

On Oct 22, 2016, at 9:53 AM, Robert Raszuk <robert@raszuk.net> wrote:

You are mixing SRC_ASN with TARGET_ASN in the same field.

Yes RFC1997 works like that but here we have opportunity to = improve it.

Thx
R.


On Oct 22, 2016 2:27 PM, "Gert Doering"= ; <gert@space.net> wrote:
Hi,

On Fri, Oct 21, 2016 at 05:42:37PM +0200, Robert Raszuk wrote:
> > Secondly, there's literally no way for the vendor to check whethe= r an
> > ASN belongs to "the entity that defines the meaning of the r= est of the
> > Large Community"
>
> Why not ?
>
> If you do not make those 4 octets configurable by spec and always fill= it
> with AS number defined in your BGP instance you will have assurance it=
> is ASN of the entity that defines the rest 8 octets of the LC as other= wise
> you will likely not establish any EBGP sessions to your peers.

But that is only half the intended usage of communities - one is
"I tag it with <myas>:<some meaning>" to signal somet= hing to my own
routers or my customers.

The other one is "I tag it with <jobs as>:<some meaning>&q= uot;, and there is
no way for my router to validate that "<jobs as>" is indeed= the one
who defined "<some meaning>".

So, how exactly is the vendor to check variant B?

(And if you do not understand what people use communities for, today,
maybe you should not be argueing these points, sorry)

> So there is very easy way to enforce it today in any BGP implementatio= n.

No.

Gert Doering
        -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG                  &= nbsp;     Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen                &nb= sp;  HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-Id= Nr.: DE813185279
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
--_000_D6D63A9E3AF240F7B3FB923BEC0EBB8Fjunipernet_-- From nobody Sat Oct 22 09:07:56 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46DB129567 for ; Sat, 22 Oct 2016 09:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 sETE5Ye55gtA for ; Sat, 22 Oct 2016 09:07:53 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C2712945D for ; Sat, 22 Oct 2016 09:07:53 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id b80so34329700wme.1 for ; Sat, 22 Oct 2016 09:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QuNHIdLkZu5bQC5NtbPz3vUaS4bxSQC8UnN+zfeW5aE=; b=o7YTxAX3wzaYsConT/2/knKB9PaEhIRA7j6yHryI9sGPh6HSbJdWgO8kJwZQkEbrOh cnDFnXD+TzdhK+dPDEGflLpONMlFcMUNHI0JtfMU2QPgOy/gBmXES38q+be3yZeAIdOh 1icS41dl9J4H+++kNlfjkKLlz/0ZdQcm0PL7mUFjcTlUBgh3w7081x/B3X3r4F3WhCWg Q5rqmEWgz4oU8Dnmv66g1odgQyL+4alB1Km2DjCBrDZSUc2YEA34FrKbNaC1RrAhvIv5 FLnsJ58wezma9ODi8JZr3gF/Z16vlKJ0T2Cj7eUT39m72WVIuzCp+obEiun4i/mOWDy+ BnXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QuNHIdLkZu5bQC5NtbPz3vUaS4bxSQC8UnN+zfeW5aE=; b=SbzgBTSSfmWAPTpDA/c9++/igJzdLgTvk8RD2rfgHLWiMB3PV9mfEIC4Nh4+iC7ds0 rzJOPkW0qy7hW8RlC0mg7E7bNpsB0O4/gRHVVqv+E8HLHnI3ZK4jGLX3NkGFzCW4S4ad tPHfZqg7xlSKHiiGzJM70cC/Q2ph0dQUE2PB9Q76yRqkhOdQBYtyQNKsbD5XkDbWlgEi uIRGUioZYo/kO0dAQg6g+ZiaJ0h39a0yklt4v7CSZRbxOAl4SYamh3wwkePUuRvXoT61 ggie62+5tznUvEg1OvkXewSbNHXNlB51schmUseVFdTuFfjF5At9eEg+8Xo5MVBhvTu4 S5YQ== X-Gm-Message-State: AA6/9RnfmSstg9T/A5J/RZDRpLITm38Xx98Jv8cYnccNZ41R6ogqWaU0lMIge9HAd/MjZthTnpv+NIAwp1l/5A== X-Received: by 10.28.167.148 with SMTP id q142mr15197222wme.17.1477152471628; Sat, 22 Oct 2016 09:07:51 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Sat, 22 Oct 2016 09:07:48 -0700 (PDT) In-Reply-To: References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161022122735.GC79185@Space.Net> From: Robert Raszuk Date: Sat, 22 Oct 2016 18:07:48 +0200 X-Google-Sender-Auth: NoNpPltM7fvYjt32fX-ojpV-YEA Message-ID: To: John Scudder , Susan Hares Content-Type: multipart/alternative; boundary=001a114ba91e59c0d5053f765c29 Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 16:07:55 -0000 --001a114ba91e59c0d5053f765c29 Content-Type: text/plain; charset=UTF-8 Hi John, Thank you for your message. As I have indicated in one of the resent emails I also was under complete impression that Large Communites are to be completely unstructured with full freedom given to those who are to use them. And that is regardless if I would agree with that or not. However recently there was number of emails exchanged (excluding any of my own messages) enforcing use of ASN within one of the fields of LCs (without even defining which field would that be or what that ASN is meant to indicate). Moreover authors of LC took number of actions to accomodate such requests in the text of the draft. That was the reason why within last few days I brought back suggestion to specify meaning of first 4 octets to indicate the src asn. In addition I also replied to claims that technically it is impossible to make sure that LC is send with valid src ASN. And while GROW may define BCP of any sort unless the protocol spec mandates so no implementation will support it nor policy can be delivered which automates such validation/filtering. RFC1997 was defined 20 years ago and via those two decades internet has changed significantly. In my opinion today BGP protocol should not allow anonymous injection of free style messages into BGP UPDATE MSG without having built in mechanism to determine who is the original author of it nor without having structured fields to simplify creation and maintenance of eBGP policies. So for the reasons stated above (as well as those discussed before) I do not support progressing this draft to RFC in the current form. (And I completely realize that my opinion is just for the record here and folks used to RFC1997 style of communities will push it through as well as vendors who like to have customers will support it :). Best regards, Robert. On Sat, Oct 22, 2016 at 4:11 PM, John Scudder wrote: > Robert, > > "Yes RFC1997 works like that but here we have opportunity to improve it." > > When the working group accepted the draft as a work item, I think it was > pretty clear from the extensive conversation at that time, that the intent > was to replicate RFC 1997, not to improve it. In fact, improving it was an > explicit nongoal if I remember right. One might argue that was a bad goal > have, and I think you did make that argument at the time, but the working > group consensus was otherwise. > > Of course, consensus can shift over time, and WGLC is a good time to test > whether such a shift has occurred, so I don't think it's inappropriate for > you to have raised the question again. However, at this point it appears to > me that consensus has not changed. > > If you feel further conversation would be productive, I don't mean to > foreclose on that, but I thought it might be helpful to provide an update > about where it appears to me the consensus is trending at present. > > --John > > On Oct 22, 2016, at 9:53 AM, Robert Raszuk wrote: > > You are mixing SRC_ASN with TARGET_ASN in the same field. > > Yes RFC1997 works like that but here we have opportunity to improve it. > > Thx > R. > > On Oct 22, 2016 2:27 PM, "Gert Doering" wrote: > >> Hi, >> >> On Fri, Oct 21, 2016 at 05:42:37PM +0200, Robert Raszuk wrote: >> > > Secondly, there's literally no way for the vendor to check whether an >> > > ASN belongs to "the entity that defines the meaning of the rest of the >> > > Large Community" >> > >> > Why not ? >> > >> > If you do not make those 4 octets configurable by spec and always fill >> it >> > with AS number defined in your BGP instance you will have assurance it >> > is ASN of the entity that defines the rest 8 octets of the LC as >> otherwise >> > you will likely not establish any EBGP sessions to your peers. >> >> But that is only half the intended usage of communities - one is >> "I tag it with :" to signal something to my own >> routers or my customers. >> >> The other one is "I tag it with :", and there is >> no way for my router to validate that "" is indeed the one >> who defined "". >> >> So, how exactly is the vendor to check variant B? >> >> (And if you do not understand what people use communities for, today, >> maybe you should not be argueing these points, sorry) >> >> > So there is very easy way to enforce it today in any BGP implementation. >> >> No. >> >> 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 >> > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a114ba91e59c0d5053f765c29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

Thank you for your message.=C2=A0

As I have indicated in one of the resent= emails I also was under complete impression that Large Communites are to b= e completely unstructured with full freedom given to those who are to use t= hem. And that is regardless if I would agree with that or not.=C2=A0
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
However recently there was n= umber of emails exchanged (excluding any of my own messages) enforcing use = of ASN within one of the fields of LCs (without even defining which field w= ould that be or what that ASN is meant to indicate). Moreover authors of LC= took number of actions to accomodate such requests in the text of the draf= t.=C2=A0

That was the = reason why within last few days I brought back suggestion to specify meanin= g of first 4 octets to indicate the src asn. In addition I also replied to = claims that technically it is impossible to make sure that LC is send with = valid src ASN.=C2=A0

A= nd while GROW may define BCP of any sort unless the protocol spec mandates = so no implementation will support it nor policy can be delivered which auto= mates such validation/filtering.=C2=A0

RFC1997 was defined 20 years ago and via those two dec= ades internet has changed significantly. In my opinion today BGP protocol s= hould not allow anonymous injection of free style messages into BGP UPDATE = MSG without having built in mechanism to determine who is the original auth= or of it nor without having structured fields to simplify creation and main= tenance of eBGP policies.=C2=A0

So for the reasons stated above (as well as those discussed befor= e) I do not support progressing this draft to RFC in the current form.=C2= =A0

(And I completely = realize that my opinion is just for the record here and folks used to RFC19= 97 style of communities will push it through as well as vendors who like to= have customers will support it :).

Best regards,
Robert.



On Sat, Oct 22, 2016 at 4:11 PM, John = Scudder <jgs@juniper.net> wrote:
Robert,

"Yes RFC1997= works like that but here we have opportunity to improve it."

When the working group accepted the draft as a work item, I thi= nk it was pretty clear from the extensive conversation at that time, that t= he intent was to replicate RFC 1997, not to improve it. In fact, improving = it was an explicit nongoal if I remember right. One might argue that was a bad goal have, and I think you did make = that argument at the time, but the working group consensus was otherwise.

Of course, consensus can shift over time, and WGLC is a good time to t= est whether such a shift has occurred, so I don't think it's inappr= opriate for you to have raised the question again. However, at this point i= t appears to me that consensus has not changed.

If you feel further conversation would be productive, I don't mean= to foreclose on that, but I thought it might be helpful to provide an upda= te about where it appears to me the consensus is trending at present.

--John

On Oct 22, 2016, at 9:53 AM, Robert Raszuk <robert@raszuk.net> wrote:

You are mixing SRC_ASN with TARGET_ASN in the same field.

Yes RFC1997 works like that but here we have opportunity to = improve it.

Thx
R.


On Oct 22, 2016 2:27 PM, "Gert Doering"= ; <gert@space.net> wrote:
Hi,

On Fri, Oct 21, 2016 at 05:42:37PM +0200, Robert Raszuk wrote:
> > Secondly, there's literally no way for the vendor to check wh= ether an
> > ASN belongs to "the entity that defines the meaning of the r= est of the
> > Large Community"
>
> Why not ?
>
> If you do not make those 4 octets configurable by spec and always fill= it
> with AS number defined in your BGP instance you will have assurance it=
> is ASN of the entity that defines the rest 8 octets of the LC as other= wise
> you will likely not establish any EBGP sessions to your peers.

But that is only half the intended usage of communities - one is
"I tag it with <myas>:<some meaning>" to signal somet= hing to my own
routers or my customers.

The other one is "I tag it with <jobs as>:<some meaning>&q= uot;, and there is
no way for my router to validate that "<jobs as>" is indeed= the one
who defined "<some meaning>".

So, how exactly is the vendor to check variant B?

(And if you do not understand what people use communities for, today,
maybe you should not be argueing these points, sorry)

> So there is very easy way to enforce it today in any BGP implementatio= n.

No.

Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0USt-IdNr.: DE813185279
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--001a114ba91e59c0d5053f765c29-- From nobody Sat Oct 22 11:59:16 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AA2129655 for ; Sat, 22 Oct 2016 11:59:14 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6Pmr8Pyo4ix6 for ; Sat, 22 Oct 2016 11:59:13 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D8A129654 for ; Sat, 22 Oct 2016 11:59:13 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id f193so6331250wmg.1 for ; Sat, 22 Oct 2016 11:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Es5slW5R+4BxxuauYt4BWd2783qcTpavhFFUY5HQNZo=; b=FAxh0WhZ9g4FCw0EZxlN023k0yLzfQgZrATDVuMa/XdwgyvVmwAOTs2XTxcfzjotjv m1XjY/4kM5xKJRCsDIU1EFyp3fVxyXMhd2nvREX2DP1i6cFTfgL3sumPsQc4ry1MXulg IHCXyyoGnR+HuVYYhoxQY89Sb4QRn+A/EH7KSwmw1amiY/hg8RZQWD5hNpZROotuCIhT jgx1NDzaR06Z9+7vMalBdTHdb9AMufLSSdLCk1BCqw9xom4wbQpvXak5NmpB37X93rkP swUjN1Kvk8SkvJD5Tlf/miFgwbOke2w7FNBf20AD6huB+IGvy7OKTyMsZVxvATbTu3TF 8A1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Es5slW5R+4BxxuauYt4BWd2783qcTpavhFFUY5HQNZo=; b=Uuemaf3MXVO2zQPWa2eE/8QciwctXPIcbO8jkyuHItBf/Lkjh6t5T/ju19C1nKPjXj LGu/4Rwx8Ic/7wEyOUYHd05+ZDoFDQQCBduXJ+Fm4db/GZJAPszhLmm/YL5Y1gYt7l3B zx+JREKMa5OZ3O3haA3tEQXe3Xx1Kqkm5AWcpzz0izPe4dCFc6z8Ph1tgH3AdAfGAOZT 1vVS03B+6J61y1cP95a6CRGzHPv3zCrWkYkAHSfRt6HYvTueqav9asmLH4V12VUExMxA eHwHityH6gUFbrh6IyrcHOnQJNnEqmhZEK0UohYRP3oRJMtOX9PF6VYvbKvj05xvUysS ZRgQ== X-Gm-Message-State: AA6/9RkoTWcaQPtTEdNORgfpRcoxRgsc+NyLVdg4vz+zsXKX0ST+kUG92ht7bL3EBcDuC7LdlbC1jh8kCcfWsA== X-Received: by 10.28.21.67 with SMTP id 64mr8204925wmv.133.1477162751828; Sat, 22 Oct 2016 11:59:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.143.203 with HTTP; Sat, 22 Oct 2016 11:58:50 -0700 (PDT) In-Reply-To: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> From: Richard Hartmann Date: Sat, 22 Oct 2016 20:58:50 +0200 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 18:59:14 -0000 On Mon, Oct 17, 2016 at 10:27 PM, Susan Hares wrote: > This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt. (10/17 > to 10/31). Please comment if draft-ietf-idr-large-community-03.txt is > ready for publication. Looks good to me, +1. Richard From nobody Sat Oct 22 14:48:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B851126D74 for ; Sat, 22 Oct 2016 14:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fV3HMD6PgSzF for ; Sat, 22 Oct 2016 14:48:22 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E19A1294E3 for ; Sat, 22 Oct 2016 14:48:21 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id 128so76315009pfz.0 for ; Sat, 22 Oct 2016 14:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1/3D2P2uySLsv7xWQWfg9FCh9dSrnqHptK5MfncAY7I=; b=Mo0nG0W9L5sKjkNPB+4cr7gUEjiKutiJotkE9KhnBmf2UqOPyuGR88Hb+P4IJ7i++2 CioVA6BANT7N5A8Hrdt6ijCAgNYukBYe0mzo923nZ4nKP9QzhkrInEFP/wtYkTzUkr1Z OJ1/Q6b1bDDxbm/tsoFyfE0GomyRKEmGYZHeKYt0HRpgh+u7Yo7kA6JqoTSymSrKRnAN VHsB6dPoluMgUetlt+rUGkHNQwsSDQgWFAVPgvwmHkAwDUD1krjw79RMN2xYP7dQQPvD ZoM6AV2sGICHzJPXPxdPOssyO03wRIOmX8fwgiuh3ixgnFG9rHo9CvxE4aA7tArTh0vo ITGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1/3D2P2uySLsv7xWQWfg9FCh9dSrnqHptK5MfncAY7I=; b=PTsW6zxeip5maMoOeP/u0ztgv2WaD2fTW7XXqYiX5AxXWnpQSw+qQeIvv+gxIjC7Zt 2zQKfzNUlT+fasmLRT08LsoVCEnhyV8Xk0KSohWajdeJfLl2a6hmkH54JtKEjOVlZImh gmd1wBoYFGsFetIPCflLQ7dqDONkb130jTDffKA3gWbjv1iuWVQ9ppAQvoyATLDG3NRf 8Nfivk/2xGY290BYvAUmiz499AUUPP8mRaw8fwuLKd0qNumzeD5oFM2E/ugzwfOMS1Op N6DjGOvs6IEr+ITMhzAgZOTlaPpZSONK9iCk6z7m3oGgR2K2VH5JycDuOecbw5s/FdYB iAyg== X-Gm-Message-State: ABUngvdp1PBPbRZsJ85Boj4aloblIIuYob8vp4bfikUkUZTrre/j1ITAXWZ0JlKzts2PMg== X-Received: by 10.99.167.75 with SMTP id w11mr11927427pgo.16.1477172900803; Sat, 22 Oct 2016 14:48:20 -0700 (PDT) Received: from [192.168.5.105] (c-73-92-109-167.hsd1.ca.comcast.net. [73.92.109.167]) by smtp.gmail.com with ESMTPSA id uh10sm14413224pab.5.2016.10.22.14.48.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 22 Oct 2016 14:48:18 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-363C285B-6143-4ECC-ADD5-44613191DB0B Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (14A456) In-Reply-To: <25cfd19e-cf33-7380-89c0-d11bc6128139@i3d.net> Date: Sat, 22 Oct 2016 14:48:16 -0700 Content-Transfer-Encoding: 7bit Message-Id: <0EADF517-72CF-47DA-B9D4-69B3CACE02E5@gmail.com> References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <25cfd19e-cf33-7380-89c0-d11bc6128139@i3d.net> To: "i3D.net - Martijn Schmidt" Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 21:48:25 -0000 --Apple-Mail-363C285B-6143-4ECC-ADD5-44613191DB0B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, Martin, My concern is that there are differences between the language in the introdu= ction, in the main body, and in the additional text. Similar to the difference between a newspaper headline and the article conte= nt, if there is any disconnect, which takes precedence? I'd like every place it's used, for the GA=3D=3DASN to be crystal clear. If it were the other way around (intro wrong or unclear, main definition rig= ht), I would be fine with it. IMHO the only place it actually needs to be fixed is where I initially indic= ated. Either works: no 2119 language and "is an ASN", or use of "MUST". Brian Sent from my iPhone > On Oct 22, 2016, at 3:39 AM, i3D.net - Martijn Schmidt wrote: >=20 > Hi Brian, >=20 > Doesn't the existing wording "The Global Administrator field is intended t= o allow different Autonomous Systems to define Large BGP Communities without= collision." already achieve what you want, if you feel that RFC2119 languag= e is not necessary? >=20 > Best regards, > Martijn >=20 >> On 10/22/2016 12:15 AM, Brian Dickson wrote: >>=20 >>=20 >>> On Fri, Oct 21, 2016 at 9:21 AM, i3D.net - Martijn Schmidt wrote: >>>=20 >>> Summarizing, any restrictions which can not be enforced don't belong in t= he IDR document because they're irrelevant to implementors. Arguing about it= doesn't change the fact that such recommendations belong in a BCP/GROW docu= ment. It is that simple. >>=20 >> I'd like to pick a nit with the argument here, as a counter-point to what= I think needs to be in the document. >>=20 >> There are plenty of IDR-specified things that are not enforced or enforce= able, which are nonetheless necessary to define or specify. >>=20 >> Those include things such as: >> next-hop >> router-id >> cluster-id >> AS-path component(s) [injecting ASNs via prepend mechanisms] >> MED >> Including Global Administrator (with a definition of it as _being_ an ASN= ), is all that is required -- if necessary, rewording it to not use RFC 2119= language.=20 >>=20 >> Like all of those other things, they can be set by operators, and are not= able to be enforced without severely restricting operators' activities. >>=20 >> Implementors who apply restrictions on those, may encounter resistance fr= om their customers, their sales folks and potential customers, and their cus= tomers' peers. >>=20 >> Brian >=20 > --=20 > Met vriendelijke groet / Kindest regards,=20 > Martijn Schmidt >=20 >=20 > =09 > Martijn Schmidt | Network Architect > Email: martijnschmidt@i3d.net | Tel: +31 10 8900070 >=20 > i3D.net B.V. | Global Backbone AS49544 > Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands > VAT: NL 8202.63.886.B01 >=20 > Website | Case Studies | LinkedIn >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail-363C285B-6143-4ECC-ADD5-44613191DB0B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi, Martin,

My concern is that there a= re differences between the language in the introduction, in the main body, a= nd in the additional text.

Similar to the difference between a newspaper he= adline and the article content, if there is any disconnect, which takes prec= edence?

I'd like every place it's used, for the GA=3D=3DASN to be crystal c= lear.

If it were the other way around (intro wrong or unclear, main definit= ion right), I would be fine with it.
IMHO the only place it actually needs t= o be fixed is where I initially indicated.
Either works: no 2119 language and "is an ASN", or use of "MUST".

Brian<= br>
Sent from my iPhone

On Oct 22, 2016, at 3:39 AM, i3D.net - Martijn Schmidt <martijnschmidt@i3d.net> wrote:

=20 =20 =20 Hi Brian,

Doesn't the existing wording "The Global Administrator field is intended to allow different Autonomous Systems to define Large BGP Communities without collision." already achieve what you want, if you feel that RFC2119 language is not necessary?

Best regards,
Martijn

On 10/22/2016 12:15 AM, Brian Dickson wrote:


On Fri, Oct 21, 2016 at 9:21 AM, i3D.net - Martijn Schmidt <martijnschmidt@i3d.net> wrote:

Summarizing, any restrictions which can not be enforced don't belong in the IDR document because they're irrelevant to implementors. Arguing about it doesn't change the fact that such recommendations belong in a BCP/GROW document. It is that simple.

I'd like to pick a nit with the argument here, as a counter-point to what I think needs to be in the document.

There are plenty of IDR-specified things that are not enforced or enforceable, which are nonetheless necessary to define or specify.

Those include things such as:
  • next-hop
  • router-id
  • cluster-id
  • AS-path component(s) [injecting ASNs via prepend mechanisms]
  • MED
Including Global Administrator (with a definition of it as _being_ an ASN), is all that is required -- if necessary, rewording it to not use RFC 2119 language. 

Like all of those other things, they can be set by operators, and are not able to be enforced without severely restricting operators' activities.

Implementors who apply restrictions on those, may encounter resistance from their customers, their sales folks and potential customers, and their customers' peers.
=

Brian

--
Met vriendelijke groet / Kindest regards,
Martijn Schmidt


<i3Dlogo-email.png>
Martijn Schmidt | Network Architect
Email: martijnsc= hmidt@i3d.net | Tel: +31 10 8900070

i3D.net B.V. | Global Back= bone AS49544
Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands
VAT: NL 8202.63.886.B01

Website | Case Studies | LinkedIn

=20
____________________= ___________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/lis= tinfo/idr
= --Apple-Mail-363C285B-6143-4ECC-ADD5-44613191DB0B-- From nobody Sun Oct 23 16:35:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C358D129440 for ; Sun, 23 Oct 2016 16:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.653 X-Spam-Level: X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3uTK4kAxTn22 for ; Sun, 23 Oct 2016 16:35:53 -0700 (PDT) Received: from sidehack.sat.gweep.net (sidehack.sat.gweep.net [72.93.233.150]) by ietfa.amsl.com (Postfix) with SMTP id BAFE4126CD8 for ; Sun, 23 Oct 2016 16:35:52 -0700 (PDT) Received: (qmail 77061 invoked by uid 524); 23 Oct 2016 19:34:31 -0400 Date: Sun, 23 Oct 2016 19:34:31 -0400 From: Joe Provo To: IETF IDR WG Message-ID: <20161023233431.GA76131@gweep.net> References: <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <20161022123423.GD79185@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161022123423.GD79185@Space.Net> X-PGP-Key: http://www.gweep.net/~crimson/pgp.txt X-Disclaimer: "I'm the only one foolish enough to claim these opinions." Organization: Russell Street UN*X Consultations - If we don't do it, you don't need it. X-Do-Not-Email-Here: whinging@place.rsuc.gweep.net User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jzp-idr@rsuc.gweep.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 23:35:56 -0000 On Sat, Oct 22, 2016 at 02:34:23PM +0200, Gert Doering wrote: > Hi, > > On Fri, Oct 21, 2016 at 06:42:41PM +0200, Job Snijders wrote: > > We want routing policy in which networks can send 2914:X:Y to us, and we > > can send 2914:A:B to them - very much like RFC 1997 communities. The > > Global Administator field does not necessarily contain the ASN of the > > sending party. > > And this is, just to repeat the obvious, *intentional* and *very useful*. > > Gert Doering > -- Operator who understands BGP I'm just Yet Another Operator, but this, a thousand times. Parity for the poor devils stuck with 32b ASNs is all we need - no "enforcement" nor mandatory values. That can and should be the work of other, more comprehensive drafts for structured signalling methods. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG From nobody Mon Oct 24 05:11:38 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C811296AA; Mon, 24 Oct 2016 05:11:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147731109728.15491.8021189919462668205.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2016 05:11:37 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-large-community-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 12:11:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Large BGP Communities Authors : Jakob Heitz Job Snijders Keyur Patel Ignas Bagdonas Adam Simpson Nick Hilliard Filename : draft-ietf-idr-large-community-04.txt Pages : 9 Date : 2016-10-24 Abstract: This document describes the Large BGP Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use in four-octet ASNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-large-community-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 24 05:20:56 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA06129514 for ; Mon, 24 Oct 2016 05:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=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 BYn9a7PZQu3x for ; Mon, 24 Oct 2016 05:20:53 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EACE129459 for ; Mon, 24 Oct 2016 05:20:53 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.86.225; From: "Susan Hares" To: Date: Mon, 24 Oct 2016 08:18:56 -0400 Message-ID: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1D84_01D22DCF.47D5A670" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdIt7WzqvhUzKEQ4QuObgT18xFaIJQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 12:20:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1D84_01D22DCF.47D5A670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR Working group: Thank you for your input on the question of whether Large communities should be reassigned another attribute number due to Huawei squatting on attribute 30. The WG consensus is that the IDR WG wishes to have IANA deprecate attribute 30, and reassign large communities another attribute number for its early allocation. Alvaro should request a new attribute number for wide communities. If wide communities implementers request an early allocation, the WG consensus was unclear. Therefore, the code point of 129 is deprecated for now. The full discussion on this point is at: https://www.ietf.org/mail-archive/web/idr/current/msg16556.html The following other attributes were seen in the wild with the comments we saw: # BGP function Reference ---- ----------------------------------------------- --------------- 20 Connector Attribute (deprecated) [RFC6037] 21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit, unknown] 30 (deprecated) [variant of draft-ietf-tunnel-encaps, Huawei router] 129 (deprecated) [draft-ietf-idr-wide-bgp-communities, Huawei router] Attribute AS Attribute Observed ----------- -------------------------------- 20 AS 22742 (Peter Hessler) 21 AS 14706, AS 11720, AS 22490 https://www.ietf.org/mail-archive/web/idr/current/msg16583.html 30 - in trials reported by Job 129 - self-reported by Huawei Sue Hares ------=_NextPart_000_1D84_01D22DCF.47D5A670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR = Working group:

 

Thank you = for your input on the question of whether Large communities should be = reassigned another attribute number due to Huawei squatting on attribute = 30.  The WG consensus is that the IDR WG wishes to have IANA = deprecate attribute 30, and reassign large communities another attribute = number for its early allocation.    

 

Alvaro = should request a new attribute number for wide communities. =

 

If wide communities implementers request an early = allocation, the WG consensus was unclear.  Therefore,  the = code point of 129 is deprecated for now.  The full discussion on = this point is at:

 

= https://www.ietf.org/mail-archive/web/idr/current/msg16556.html<= /o:p>

 

The following other attributes were seen in the wild = with the comments we saw:

 

#        BGP = function           = ;            =             &= nbsp;  Reference

----    = -----------------------------------------------   = ---------------

20     Connector Attribute = (deprecated)   [RFC6037] 

21      AS_PATHLIMIT = (deprecated)    =        [draft-ietf-idr-as-pathlimit, = unknown]

30     = (deprecated)          &= nbsp;           &n= bsp;         =        [variant of = draft-ietf-tunnel-encaps, Huawei router]

129   (deprecated) =             &= nbsp;           &n= bsp;           &nb= sp; [draft-ietf-idr-wide-bgp-communities, Huawei router] =

 

Attribute  AS Attribute Observed   =             &= nbsp;           

-----------   = --------------------------------

20         = ;  AS 22742  (Peter Hessler) =             &= nbsp;          

21 =           AS 14706, AS = 11720, AS 22490

         &= nbsp;       = https://www.ietf.org/mail-archive/web/idr/current/msg16583.html<= /o:p>

 

30   -  in trials reported by Job =

129 -  self-reported by Huawei =

 

Sue Hares

------=_NextPart_000_1D84_01D22DCF.47D5A670-- From nobody Mon Oct 24 05:21:40 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B67B1293F3 for ; Mon, 24 Oct 2016 05:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 1uZ6MMhJSuPd for ; Mon, 24 Oct 2016 05:21:33 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 79B5E129541 for ; Mon, 24 Oct 2016 05:21:31 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1byeFp-0004AD-C9 (job@us.ntt.net); Mon, 24 Oct 2016 12:21:31 +0000 Date: Mon, 24 Oct 2016 14:21:19 +0200 From: Job Snijders To: idr@ietf.org Message-ID: <20161024122119.GJ1074@Vurt.local> References: <147731109728.15491.8021189919462668205.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147731109728.15491.8021189919462668205.idtracker@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 12:21:38 -0000 Dear working group, The chairs requested that the authors post the latest state of the draft reflecting upon last week's discussion and changes in order to progress obtaining a fresh (hopefully unused) BGP Path attribute codepoint. ChangeLog -03 -> -04: o Reword the ordering paragraph (Jussi Peltola, Markus Hauschild) o Reword 'decimal numbers' -> 'integers in decimal notation' (Kristian Larsson) o Remove word 'usually' in context of RFC1997 paragraph (Petch) o Remove 'bytes' word from error handling (Julian Seifert) o Rework the reserved values (Nick, Job, Jeff, Adam Chappell) Kind regards, Job On Mon, Oct 24, 2016 at 05:11:37AM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing of the IETF. > > Title : Large BGP Communities > Authors : Jakob Heitz > Job Snijders > Keyur Patel > Ignas Bagdonas > Adam Simpson > Nick Hilliard > Filename : draft-ietf-idr-large-community-04.txt > Pages : 9 > Date : 2016-10-24 > > Abstract: > This document describes the Large BGP Communities attribute, an > extension to BGP-4. This attribute provides a mechanism to signal > opaque information within separate namespaces to aid in routing > management. The attribute is suitable for use in four-octet ASNs. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-large-community-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Oct 24 07:07:47 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B746312964C for ; Mon, 24 Oct 2016 07:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ihTHDDx2x89T for ; Mon, 24 Oct 2016 07:07:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DFDCD1296DF for ; Mon, 24 Oct 2016 07:07:33 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B1E911E337; Mon, 24 Oct 2016 10:09:51 -0400 (EDT) Date: Mon, 24 Oct 2016 10:09:51 -0400 From: Jeffrey Haas To: Job Snijders Message-ID: <20161024140951.GA32009@pfrc.org> References: <147731109728.15491.8021189919462668205.idtracker@ietfa.amsl.com> <20161024122119.GJ1074@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161024122119.GJ1074@Vurt.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 14:07:46 -0000 On Mon, Oct 24, 2016 at 02:21:19PM +0200, Job Snijders wrote: > Dear working group, > > The chairs requested that the authors post the latest state of the draft > reflecting upon last week's discussion and changes in order to progress > obtaining a fresh (hopefully unused) BGP Path attribute codepoint. > > ChangeLog -03 -> -04: > > o Reword the ordering paragraph (Jussi Peltola, Markus Hauschild) > o Reword 'decimal numbers' -> 'integers in decimal notation' (Kristian Larsson) > o Remove word 'usually' in context of RFC1997 paragraph (Petch) > o Remove 'bytes' word from error handling (Julian Seifert) > o Rework the reserved values (Nick, Job, Jeff, Adam Chappell) I believe the above work improved the document. Particularly, it clears my final comment/concern about the reservation strategy documented in the draft. Ship it! -- Jeff From nobody Mon Oct 24 08:10:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5351294BE for ; Mon, 24 Oct 2016 08:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 24Ulw-lKXD64 for ; Mon, 24 Oct 2016 08:10:44 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4311295AD for ; Mon, 24 Oct 2016 08:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8614; q=dns/txt; s=iport; t=1477321837; x=1478531437; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BVkOtwm/64Y/4ow/5XZd5LmZOB38tMBptRuwcTaSr5c=; b=VGZT55lFRV/8GIxt3h705kjCktBE6LIGc61xYC9zi/eV9jv6DwF9dGDO X2qkqBSWxdevKp1iSD5COJObfLPKKxzKa9HyVZXNcUe1u4Y8S5uHLMhgz GTsBhevLxmgElIO43x4CNsAAzbhBss0kuYBvnMpHOUsHd8Mthsrp/y+Em g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AQBGIw5Y/49dJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnQ2AQEBAQEdWH0HjS2mJYUWggeGIQIagUk/FAECAQEBAQEBAWIohGM?= =?us-ascii?q?CBCNWEAIBCA4tBAMCAgIwFBEBAQQBDQWIUrRsjGUBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEchj2BfQiCUIdLLIIvBZQ3hV0BkBKBboRtiSeRBgEeNl6DSIE6codBgQA?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.31,542,1473120000"; d="scan'208,217";a="163179066" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2016 15:10:36 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u9OFAaQl030452 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Oct 2016 15:10:36 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Oct 2016 10:10:36 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Mon, 24 Oct 2016 10:10:36 -0500 From: "Alvaro Retana (aretana)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) Thread-Index: AdIt7WzqvhUzKEQ4QuObgT18xFaIJQAI7oKA Date: Mon, 24 Oct 2016 15:10:36 +0000 Message-ID: References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> In-Reply-To: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_BB691724BAA34E628700E9B530DC2ECBciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 15:10:48 -0000 --_000_BB691724BAA34E628700E9B530DC2ECBciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VlOg0KDQpIaSEgIFRoYW5rcyBmb3IgdGhlIHN1bW1hcnkhDQoNCkkgdGhpbmsgeW91IG1lYW50 IOKAnHJlcXVlc3QgYSBuZXcgYXR0cmlidXRlIG51bWJlciBmb3IgKmxhcmdlKiBjb21tdW5pdGll c+KAnSBiZWxvdy4NCg0KUGxlYXNlIGZvbGxvdyB0aGUgcHJvY2VzcyBpbiByZmM3MTIwOiB5b3Ug c2VuZCBtZSB0aGUgZm9ybWFsIHJlcXVlc3QsIEkgYXBwcm92ZSwgYW5kIHRoZW4geW91IChDaGFp cnMpIHJlcXVlc3QgdGhlIGFsbG9jYXRpb24gZnJvbSBJQU5BLiAgTm93IHRoYXQgLTA0IHdhcyBw dWJsaXNoZWQgd2Ugc2hvdWxkIGJlIHJlYWR5IHRvIGdvLiAgV2Ugc2hvdWxkIGJlIGFibGUgdG8g aW5jbHVkZSB0aGUgMiBkZXByZWNhdGVkIHZhbHVlcyBpbiB0aGUgc2FtZSByZXF1ZXN0Lg0KDQpU aGFua3MhDQoNCkFsdmFyby4NCg0KT24gMTAvMjQvMTYsIDg6MTggQU0sICJTdXNhbiBIYXJlcyIg PHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4gd3JvdGU6DQoNClRoYW5r IHlvdSBmb3IgeW91ciBpbnB1dCBvbiB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciBMYXJnZSBjb21t dW5pdGllcyBzaG91bGQgYmUgcmVhc3NpZ25lZCBhbm90aGVyIGF0dHJpYnV0ZSBudW1iZXIgZHVl IHRvIEh1YXdlaSBzcXVhdHRpbmcgb24gYXR0cmlidXRlIDMwLiAgVGhlIFdHIGNvbnNlbnN1cyBp cyB0aGF0IHRoZSBJRFIgV0cgd2lzaGVzIHRvIGhhdmUgSUFOQSBkZXByZWNhdGUgYXR0cmlidXRl IDMwLCBhbmQgcmVhc3NpZ24gbGFyZ2UgY29tbXVuaXRpZXMgYW5vdGhlciBhdHRyaWJ1dGUgbnVt YmVyIGZvciBpdHMgZWFybHkgYWxsb2NhdGlvbi4NCg0KQWx2YXJvIHNob3VsZCByZXF1ZXN0IGEg bmV3IGF0dHJpYnV0ZSBudW1iZXIgZm9yIHdpZGUgY29tbXVuaXRpZXMuDQoNCg== --_000_BB691724BAA34E628700E9B530DC2ECBciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <70E7A75327D9914BB80BC232D75A2DA1@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTph cHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsN Cglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5tc29JbnMN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPlN1ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSEmbmJzcDsgVGhh bmtzIGZvciB0aGUgc3VtbWFyeSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5JIHRoaW5rIHlv dSBtZWFudCDigJxyZXF1ZXN0IGEgbmV3IGF0dHJpYnV0ZSBudW1iZXIgZm9yICpsYXJnZSogY29t bXVuaXRpZXPigJ0gYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+UGxlYXNlIGZvbGxv dyB0aGUgcHJvY2VzcyBpbiByZmM3MTIwOiB5b3Ugc2VuZCBtZSB0aGUgZm9ybWFsIHJlcXVlc3Qs IEkgYXBwcm92ZSwgYW5kIHRoZW4geW91IChDaGFpcnMpIHJlcXVlc3QgdGhlIGFsbG9jYXRpb24g ZnJvbSBJQU5BLiZuYnNwOyBOb3cgdGhhdCAtMDQgd2FzIHB1Ymxpc2hlZCB3ZSBzaG91bGQgYmUg cmVhZHkgdG8NCiBnby4mbmJzcDsgV2Ugc2hvdWxkIGJlIGFibGUgdG8gaW5jbHVkZSB0aGUgMiBk ZXByZWNhdGVkIHZhbHVlcyBpbiB0aGUgc2FtZSByZXF1ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5BbHZhcm8uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0 REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjpibGFjayI+T24gMTAvMjQvMTYsIDg6MTggQU0sICZxdW90O1N1c2FuIEhhcmVzJnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29y cGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+VGhhbmsgeW91IGZvciB5 b3VyIGlucHV0IG9uIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIExhcmdlIGNvbW11bml0aWVzIHNo b3VsZCBiZSByZWFzc2lnbmVkIGFub3RoZXIgYXR0cmlidXRlIG51bWJlciBkdWUgdG8gSHVhd2Vp IHNxdWF0dGluZyBvbiBhdHRyaWJ1dGUgMzAuJm5ic3A7IFRoZSBXRyBjb25zZW5zdXMgaXMgdGhh dCB0aGUgSURSIFdHDQogd2lzaGVzIHRvIGhhdmUgSUFOQSBkZXByZWNhdGUgYXR0cmlidXRlIDMw LCBhbmQgcmVhc3NpZ24gbGFyZ2UgY29tbXVuaXRpZXMgYW5vdGhlciBhdHRyaWJ1dGUgbnVtYmVy IGZvciBpdHMgZWFybHkgYWxsb2NhdGlvbi4gJm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lk b3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29s b3I6YmxhY2siPkFsdmFybyBzaG91bGQgcmVxdWVzdCBhIG5ldyBhdHRyaWJ1dGUgbnVtYmVyIGZv ciB3aWRlIGNvbW11bml0aWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4 dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BB691724BAA34E628700E9B530DC2ECBciscocom_-- From nobody Mon Oct 24 08:20:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D421296DE for ; Mon, 24 Oct 2016 08:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=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 8Speg29nkTCV for ; Mon, 24 Oct 2016 08:20:04 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2EC1295AF for ; Mon, 24 Oct 2016 08:20:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.86.225; From: "Susan Hares" To: "'Alvaro Retana \(aretana\)'" , References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> In-Reply-To: Date: Mon, 24 Oct 2016 11:18:16 -0400 Message-ID: <4e8d01d22e09$d8b83560$8a28a020$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4E8E_01D22DE8.51A731A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHyXzELtvEK7ey7qrjSIoZokRYvKAKG+OCuoGMdclA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 15:20:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_4E8E_01D22DE8.51A731A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, I meant request a new attribute number for large communities.=20 =20 Sue=20 =20 From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]=20 Sent: Monday, October 24, 2016 11:11 AM To: Susan Hares; idr@ietf.org Cc: 'John G. Scudder' Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) = was squatted on - Let's get a new attribute number (1 week WG call = (10/18 to 10/25) =20 Sue: =20 Hi! Thanks for the summary! =20 I think you meant =E2=80=9Crequest a new attribute number for *large* = communities=E2=80=9D below. =20 Please follow the process in rfc7120: you send me the formal request, I = approve, and then you (Chairs) request the allocation from IANA. Now = that -04 was published we should be ready to go. We should be able to = include the 2 deprecated values in the same request. =20 Thanks! =20 Alvaro. =20 On 10/24/16, 8:18 AM, "Susan Hares" wrote: =20 Thank you for your input on the question of whether Large communities = should be reassigned another attribute number due to Huawei squatting on = attribute 30. The WG consensus is that the IDR WG wishes to have IANA = deprecate attribute 30, and reassign large communities another attribute = number for its early allocation. =20 =20 Alvaro should request a new attribute number for wide communities. =20 ------=_NextPart_000_4E8E_01D22DE8.51A731A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Yes, I meant request a new attribute number for large communities. =

 

Sue

 

From:= = Alvaro Retana (aretana) [mailto:aretana@cisco.com]
Sent: = Monday, October 24, 2016 11:11 AM
To: Susan Hares; = idr@ietf.org
Cc: 'John G. Scudder'
Subject: Re: = [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on = - Let's get a new attribute number (1 week WG call (10/18 to = 10/25)

 

Sue:

 =

Hi!  = Thanks for the summary!

 =

I think = you meant =E2=80=9Crequest a new attribute number for *large* = communities=E2=80=9D below.

 =

Please = follow the process in rfc7120: you send me the formal request, I = approve, and then you (Chairs) request the allocation from IANA.  = Now that -04 was published we should be ready to go.  We should be = able to include the 2 deprecated values in the same = request.

 =

Thanks!

 =

Alvaro.

 =

On 10/24/16, = 8:18 AM, "Susan Hares" <shares@ndzh.com> = wrote:

 

Thank you for your input on the question of whether Large communities = should be reassigned another attribute number due to Huawei squatting on = attribute 30.  The WG consensus is that the IDR WG wishes to have = IANA deprecate attribute 30, and reassign large communities another = attribute number for its early allocation. =    

 

Alvaro should request a new attribute number for wide = communities.

 

------=_NextPart_000_4E8E_01D22DE8.51A731A0-- From nobody Mon Oct 24 10:11:02 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5018012944B for ; Mon, 24 Oct 2016 10:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 XLVLxClp13Km for ; Mon, 24 Oct 2016 10:10:59 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0103.outbound.protection.outlook.com [104.47.32.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40AA01295D7 for ; Mon, 24 Oct 2016 10:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J0fg7FCG/LeSULs1yoVLvuiiQZCyXP8modXNBpqTnlE=; b=lGlR+G4qVQ/6EwDZyUcJCyL2xMgBVZGPVomhvI1HRe8ps4RlTI54O0JotBZwR6u15hrmMVzd1ln6AhksuVQIj5BmbSySwu1WGR5lR48emP4S7o8tOXuNrALbCG5S5dam8+ZDI/cwG0rM9a/O9I+H1t99JlOJbgXzNrKFvhoa4Jo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from kconry-sslvpn-nc.jnpr.net (66.129.241.14) by CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Mon, 24 Oct 2016 17:10:57 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <20161023233431.GA76131@gweep.net> Date: Mon, 24 Oct 2016 13:10:52 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <20161022123423.GD79185@Space.Net> <20161023233431.GA76131@gweep.net> To: IETF IDR WG X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BLUPR13CA0051.namprd13.prod.outlook.com (10.160.82.22) To CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) X-MS-Office365-Filtering-Correlation-Id: b9daa926-9e0f-472d-a825-08d3fc30b8d7 X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 2:D/PYjQA+zHCB/U94RU581ZbHdtHp1gk5OjVzIOZVIPL/3dhee6sCsXupIveJqZmf6mkxH228gttj6jFaJKIj3j4V7xmOQ/gZvs1sC+jErYwKsGdBrg7LwpT6kzxCwf5M5CsBhk9gijHtpt9rfYceYvVdU8e2i0uLyFL7M7SYYIdKKMBAP5hHgyMPySCm0fV2lmcj3xnHGwuVbiWEzpcOVQ==; 3:eFhkgon+QoRoWMib8Et3Bs52+OTjFqL8w/tOTwXyxls5q7jZtNM7WILh2G9Xl+XMacJ4YVA/62WzT3KvEe2U0toPGxDfhafNtAggmSOAPDpMfmhgPYtjxnrVg14vdQhfIPVwae7Xkppo8NmspB/DxA==; 25:eFx1+mUJnLi6faZLWSD8B470b20vFwngtOKXw8BMDY0tQql38c9gl3Jte4htdiyQf/VafWl1MbWdtihqmVgH3KNmu4E5+GbwqWfWMDtVuDWCpsgqms2LtM1SAULxNHOPtLdRygFS4Hs/hX/xDMc2/qLkScMdfy7zzxmjDKHeT0+IeEp7/509uvlGKl28oNV0f9KFSl3/vFy4Aru18RaazdjX04rIhjXKhw0djRz9GE0nyZWfcmo1+NF4JD6zWpSXy+lYr827+BG+oqEr7SmV1tzYj/zJFtR2npsOcr3OLa/7TtTyBK2rKn/j1wBBliGkIkD+vug25iigZdbJlTx4Auq8pDf6YD+LBj1A/Q7evuYP7UZzCtRe6UOrO0kZLc03WpjZKW3v7/Dv1YWX0rzrJEEeFbzpFLMlp2t21vMFTSbVHM/1F0adNFHBhF/XiHKz X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 31:cj7NwFgd2v69EOhhSQYeq/pzQJ3gZ8e9J5ShD4pGLvIi2FYXIRIqCAs5ojcxxjwf4qRM34yoPOxrmhoKES2fc60WCsBk/WviXxurjqcyWzn9DHG/VyMyfErdw37uRSRxWeFmCeGA/EZuTlzPv4T3fXrw4xrnyyT2VeVJgjWYww6t8mCA5JMNlIgnVwlxFc1v8DQLEtMz8W5oEuwbhqc22dvXxERCWmzOLmqqlvCpV89y9OlrBsoJUAlIczLHlwHHnpOJViqDRwcpxUEoP6O38w==; 20:xE/SWgaSfWoG9cmpoKoBLUWyWYn3WhjeCX7svLyPRKq5OzXnV99d5KeVzqod7vK7OrVSor0ufFi8cYQQBeCYq7Yv0S2LvGf73N2c9oe2/DU12hbz49CRXPoSWC5hhxfuM4NmRo2nzvQEEhYc0Li9Dt0gYh13NcJ97kF3HUkKgwGiOa45WMG5IS6pOM4FuQJcKAyJRE5J+3aMl9kQOPcTIrFJ6LjZiIHo1hSEPG+ZBPhHMY5SFhMAMhJfboImYItDyfs3npX+YJwyw+iF+bx2bJoyBnPqJPTEeM2fKh2E1/tpalGiAxwdh3WabXgxlMpNCNLdjbSRyVNPbuGsntMWy+Z7ZcHekmvkjVJbJhaKtmxYWhX3frEsrTI6QAfUl6nR5mPatysy5bdyUvWf5uoDcO5jo4wvs/5nJj2032AiG6IisrD7tgPpVG8WsCpbFjk9NcQyzdxajz3P8wBBRE9qp6GDIN4k+cYQqVZNU/vzMCrwiL1UBg14eUqCPZ4qN9QaQ8tLO49fd850UuwzLGH8DynhfJu7VilZ2KScpIS9nYTzNmOtGqCbT+8o0GZIEBqGQ4B4teDl9fhBphj13i0BW+pICRMJ0l04jJACaPtEyL0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CO2PR05MB2502; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 4:XtT6nC8C0c9LNzenxxr7wQUnu2P/QdiJqeso+IxTnwgO0smV1Ccf0z4MvHdKt/Hn+s0e7u/fWPl3rF1zvhPiCrye6b1609+qkS2MEFj/VWmJTcysUDcoJ90mAOlI+zjgIJ810nH0Is7CBzj/77W6p2VsgXlWXrkm+FVOLpGiwmLT5BCJdV1g4mna9Yyn6aPbFGVszJbelwZ/NCXIi/p0H5yLTxn/PytqLag2O84DmaYQahYGec9SRAzAt2dYSVxHhA5xL6UhYwPDmqiRFZqSwwiCyRIdTg2Y+mMwq7Z6FZqTsxMY/nqEnldceMu/cG5gJoyfLND1/ujYq4gsxB1Nv0nH2EDWBpyiDRPdHekXbWBsr8VF9XyAmxBzG05yPrbmmq/Gt7qieTlCatJUrPgn82JI6t4OKUy3A05ThgQRfLodT2fx9Ykur/xSJXSBpPKiIqYuBndNc21kflUEka7Exg== X-Forefront-PRVS: 0105DAA385 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(53754006)(5423002)(199003)(189002)(50986999)(7736002)(47776003)(97736004)(42186005)(2950100002)(97756001)(2906002)(107886002)(50226002)(57306001)(53416004)(6916009)(50466002)(189998001)(101416001)(92566002)(68736007)(76176999)(230783001)(46406003)(106356001)(5660300001)(6666003)(561944003)(105586002)(110136003)(33656002)(93886004)(66066001)(23726003)(8676002)(8746002)(305945005)(81166006)(81156014)(83716003)(82746002)(3846002)(6116002)(586003)(7846002)(36756003)(77096005)(69596002)(86362001)(450100001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2502; H:kconry-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2502; 23:BJ4bZ4HjnLSd58NmauubbUElxQxrHCaqTsVDoaE0V?= =?us-ascii?Q?ODtA2By0fWqk9lEk+fiMpr6G/CaeZuZ8qq4u44GWTV//F60kGN6FWZTRRKwr?= =?us-ascii?Q?6zMkBkROWqsqhiiHLjBuPxaltk4SZ4bb1/gXmJHqBZ3vacKI/9IxYjCpebSw?= =?us-ascii?Q?0qkWJDZoA1sdKLEA8Yz24fjJKqFnwXoEk21H70EdjzxhW9ijxAC89pxr6Gg0?= =?us-ascii?Q?ngnJbbnxIP8HlkidbtNxwc13XZZWfGN/J8ZLAO6mf+ZFjEaosJo/4V0nR0tV?= =?us-ascii?Q?ktLICTIYuoN66BInIIX1HoM1SMYT2z2RSiu6li1MgZk0IBMLJu5Jj3SQp0a+?= =?us-ascii?Q?4r4hjz5K6dkriymS1vfw8eKPFNUYVfz9v3PrdPZWWqCwVMt9h4xG9fD6eTcG?= =?us-ascii?Q?EiP3v8jWQauAQjUR2qi5AC7e+MPnYFM70ZXfUWYqHFTaVm+xdZnIInvpbWh9?= =?us-ascii?Q?mo077CNxY3zRfkUg2t0WQ77dyN7Qhn4mMk3SMPpRfEmW2rnMP9KrpKoK50up?= =?us-ascii?Q?+lXhh7HFpZiGldfQzyUn/kh4xJn0XHN/DfPrnbphYPVmyN5H7ke++EX0Ty4w?= =?us-ascii?Q?1oc/NU5cRzWTpQXDTQ665yNXo1w7LMFLFdKzStG+s2FWn2vqsE2BV0yDQcUB?= =?us-ascii?Q?vm+Zy3FaLYXfAfBsHVpxlSmlH22RzhFG6+oovFBKzWYurBQgqGYmdel+Zbpu?= =?us-ascii?Q?65RqRIg5tvNgHP2myEKCVW+2e9Xc/04JfohUYTySw8jSOZW08k6KTPaJ6dBo?= =?us-ascii?Q?g3T1j84jBmdc0wYeuaAHPcltcSK9TMcXS92LMI9oqLUPXz0861xPtiVefw1M?= =?us-ascii?Q?yD6KujPSsWIIbJnd9/chWwLYj2OyA3l5vpwrP/oAEfnw48qXiG858zAcXAGL?= =?us-ascii?Q?Zm1s7PmJXSwlQ9K5rI4P62I7bACcYwP24qTykslfR7AQKJxeq1gXDrSxcCOh?= =?us-ascii?Q?sUDwUjUs4jInC+CKL+wJa4vIRIkTL3+T1apvM+LWjNU0ZlcP9CbomSabej6q?= =?us-ascii?Q?MMx2SFXSf2lijbZEiM/cDqhtbu5GlDwhnbgkci9I3UvubTfq9M8WHoogz1dy?= =?us-ascii?Q?WhnIxIYkm2J4Ck27m0dsQ8uqNufvFgUoZpIP/KLk6Q4Kcp8w9K2fQLgLfk1+?= =?us-ascii?Q?/xhblyobGvDsn2fdsZu7530pC+YKY6MtOuwMf5l+eboqmE7bG7skhfK5MHSp?= =?us-ascii?Q?jyv9fHv3iT3/l+OutKqQOpKCVeCZveSM6slBDwH99w2bjhpA4EcItuIkvGQM?= =?us-ascii?Q?hs91+3bAmEztF/kPB5IJ2RswAwLoB4KE9F+Whx/i4xCyBK41xd8Z2BdejKQe?= =?us-ascii?Q?P9TuhLhebqo+h/nuT1DPWQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 6:O6+iYe5s0Pyu1we6N8jInO7rSSxs0RnawFPdP3gKbkeswLCkG+xoKzK1ozhOEXDvPUlnF2RUlTCiWgMarOQY5QFXdLIkSm0lQpRn04SaX9y+Vd4sf7qgubhc7sKmh6JDlSd76nlnjhZH4uuX+PlepXbx8tEtzOtcKsMEz7k8q3bzixkmqriXa0pn27UvoYZRDXMhvkJgYsGQ/qSMvvMWohdC/AYE2Pa+z7iKiKdHxr7T4N+DbGGoDsAbbCVBv5q6QHciN6Nqjx1cW8tKRLxzmlemUdTkKaF1TAH15ocUIkzMohOGvKBGskFplXiV5Izdk7ecRE6wlpGUSmhwg5Hi3IrVdZu0GQ6rSNniTyWOWP8=; 5:7956wp+kfYVFR+OVjbz5VPa+Y9U1ig+EAgny08GURbyKNUeKGjKaGB35Zp7IVJ1ipQ1cNkCWWGOPs4f1enp2BoR4HMyF3czZjP7u6CWFVKb2F5tRDF+WSzYvq61vVfCJhPEhRySqgqwLNAtm7ckoOw==; 24:nyJt9F5p4JXTODtWQYs35w8VdQOqtW8VAJXi/IVMhU5BNxBy6aihyuRY4GXck3v4SfT1L3Ofcdkq1hLTXLZMaXRrbWSOnufnpl/X5lch5g8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 7:fvkvy6ri1yXXqqLzu2x/Ed9ToOUsQ51eDO7LujNMuNKtjdZ2M3kjYeldcY2Av4RJ6I5UcJPyNkrecUCylLZpIZw+18SEQdfWbkoaMEN7nOPyJB6zwAU0Gk/U0CBFcpqMG4R8A5NuKxlXIAx0RQN7kPMNJ63w/QSiMFDwdSyYgfXjBW1Ydr8k5JKIn4eglvQRki+fX3paG2Cqqf4bc2XD+CwwYNsl16TKpQE4AdX9q964ywVta3cxKpmAJAiK45slO944mUCTrEcvZ3SkdHFgTeUBbPGF3vbRwoxu7A7Te6zw0JQcZJryvs3q1hQt332NPREbGtGQvMdctU6aFipLE0bCVdDGba8ksD4ET+O0K7U= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2016 17:10:57.5199 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2502 Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 17:11:01 -0000 Hi Everybody, There has been a fair amount of debate about this sentence in the draft: " Global Administrator: A four-octet namespace identifier. This SHOULD be an Autonomous System Number." Many of the objections can be summed up by saying "I can't program a = router to enforce this rule". This is true, but as Brian has pointed = out, it's hardly the first example of such a thing in a BGP spec. = (Indeed, RFC 1997 says the equivalent community field "shall be encoded = using an autonomous system number" but of course provides no enforcement = mechanism.) Other objections seem to be pursuing the question of whether it might be = possible to revise the proposal to make the rule enforceable. Whether or = not this is possible in principle seems beside the point since it would = violate the "small and simple" 1997-equivalent goal of the proposal that = was part of the consensus when the WG accepted it.=20 After reviewing the mailing list discussion to date, it's the chairs' = sense that consensus is trending towards keeping the text as written. As = always, if you disagree with that consensus and feel you have something = new to add to the discussion, please do. Thanks, --John and Sue= From nobody Mon Oct 24 10:50:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0687C12987B for ; Mon, 24 Oct 2016 10:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 V6n1ckbKcLuX for ; Mon, 24 Oct 2016 10:50:44 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD571296DC for ; Mon, 24 Oct 2016 10:50:44 -0700 (PDT) Received: from www.lamehost.it (unknown [80.76.80.23]) (Authenticated sender: marco@lamehost.it) by seele.lamehost.it (Postfix) with ESMTPSA id ED0AE746D1; Mon, 24 Oct 2016 19:50:40 +0200 (CEST) Mime-Version: 1.0 Date: Mon, 24 Oct 2016 17:50:40 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <8650a0bcec9c95f3b1f1df5c447a401d@www.lamehost.it> X-Mailer: RainLoop/1.10.3.151 From: marco@lamehost.it To: "John G. Scudder" , "IETF IDR WG" In-Reply-To: References: <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <20161022123423.GD79185@Space.Net> <20161023233431.GA76131@gweep.net> X-Originating-IP: 37.130.210.2 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Mon, 24 Oct 2016 19:50:41 +0200 (CEST) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Mon, 24 Oct 2016 19:50:41 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.99.2 at seele X-Virus-Status: Clean Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 17:50:46 -0000 October 24, 2016 7:11 PM, "John G. Scudder" wrote:=0A> = Hi Everybody,=0A> =0A> There has been a fair amount of debate about this = sentence in the draft:=0A> =0A> " Global Administrator: A four-octet name= space identifier. This=0A> SHOULD be an Autonomous System Number."=0A> = =0A> Many of the objections can be summed up by saying "I can't program a= router to enforce this rule".=0A> This is true, but as Brian has pointed= out, it's hardly the first example of such a thing in a BGP=0A> spec. (I= ndeed, RFC 1997 says the equivalent community field "shall be encoded usi= ng an autonomous=0A> system number" but of course provides no enforcement= mechanism.)=0A> =0A> Other objections seem to be pursuing the question o= f whether it might be possible to revise the=0A> proposal to make the rul= e enforceable. Whether or not this is possible in principle seems beside= =0A> the point since it would violate the "small and simple" 1997-equival= ent goal of the proposal that=0A> was part of the consensus when the WG a= ccepted it. =0A> =0A> After reviewing the mailing list discussion to date= , it's the chairs' sense that consensus is=0A> trending towards keeping t= he text as written. As always, if you disagree with that consensus and=0A= > feel you have something new to add to the discussion, please do.=0A> = =0A> Thanks,=0A=0AHello John,=0A=0AI have to admit that there is a tenden= cy to put on paper rules that have relied on common sense for ages.=0AThi= ng that, most of the times, clashes with the goals to be as flexible and = as "small and simple" as possible.=0A=0AI agree with you that we should k= eep the text as written and *if needed* discuss the operational details o= n GROW.=0A=0ARegards From nobody Mon Oct 24 11:08:22 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3689312997E for ; Mon, 24 Oct 2016 11:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 mE-Y4-r326a9 for ; Mon, 24 Oct 2016 11:08:19 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B0D1293DA for ; Mon, 24 Oct 2016 11:08:19 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id E57D058EB3; Mon, 24 Oct 2016 18:08:18 +0000 (UTC) Date: Mon, 24 Oct 2016 18:08:18 +0000 From: heasley To: Robert Raszuk Message-ID: <20161024180818.GL86859@shrubbery.net> References: <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161022122735.GC79185@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: heasley , IETF IDR WG , Susan Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 18:08:20 -0000 Sat, Oct 22, 2016 at 03:53:05PM +0200, Robert Raszuk: > You are mixing SRC_ASN with TARGET_ASN in the same field. I want to point-out that by forcing the first field to be "src_asn" as you are suggesting, would make one intended use of -large- not possible, for ASN1 to tell ASN2 to do something with a route as it applies to ASN3. eg: ASN2:ASN3:action, ie: apply "action" (such as prepend) defined by ASN2 to ASN1's route when advertised to ASN3. > Yes RFC1997 works like that but here we have opportunity to improve it. We have improved it. From nobody Mon Oct 24 11:17:54 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19DB12953E for ; Mon, 24 Oct 2016 11:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kCQvh8PHEfgX for ; Mon, 24 Oct 2016 11:17:52 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040B31293E9 for ; Mon, 24 Oct 2016 11:17:52 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id b80so118969016wme.1 for ; Mon, 24 Oct 2016 11:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IHlukAxqgaINA7k8rz4v6IX1cGvfPDwVwamRYwAqpnA=; b=YRlnhROLav2ifN6AxbGw7UMlUZTT0UIc+/cDVbKR4rPrzD/JxVDGJ+mUwDBrn5cmKZ 9dEDnYHGpYKG+uUS/vQKMqi9lLJoK3+qrZS0FpwShHvHJGyC2NhN8cfmdEzmqhNnXcGb BWtuo+BVtMKeWQDZxhXXFIDW1tw/8yJ7su2AK7Uze75njHecMrjQ2+S+AQSAYfSjkD9I S81hU5kLG8/S7JsJYA1d78lM0ayMzt0cWsFvs8h+Xg+kC9i4I2m6NHeXRFJof3qi8yJV 7DLBS15mf9myIrIbpNvVpUP0LZruPq5W22vWs+NfcO8HPiCCCp0xPL9jaK5gvBOc0GHb sOFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=IHlukAxqgaINA7k8rz4v6IX1cGvfPDwVwamRYwAqpnA=; b=ZTEwgRuuYEhQo5/chIhcDlw0RlFxjEip4GDIqFWTmS/GEjNKbLUFPE7Gt76Ip9fu9a hDVEEs0wdfGN8HDaEbHBMo322Q2Lb2eGCFoTbkRNdjh2FUz22F0uhfqcpy0vKvnXeqV5 0jk1viI5yE0nCvmOoN/EtLKf4znOajrneyoYABFbPVuUrrzfCgmiEUEg+NWTyF9ato90 KMDspJTfJX8a5AOKqEzM8585Z2merznWbAtLiucKCUXCLmL9drboVREUDi7SSl8wjG5m v/NdrKDlDUzuVOc0MfumhzDtrs3s/ec0SxAzCp/Y/ipYukVwUlD5rwp36biFQMtBwp0S AF5w== X-Gm-Message-State: AA6/9RnTzDVAzeX9Kad7xuchpdeLWNEse8hXUuurkUs7HyawRdzdEX4uc02rLbuV4IMQYf2Qrks1xBrH8x8AQg== X-Received: by 10.28.46.15 with SMTP id u15mr24184472wmu.61.1477333070550; Mon, 24 Oct 2016 11:17:50 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.182.155 with HTTP; Mon, 24 Oct 2016 11:17:48 -0700 (PDT) Received: by 10.80.182.155 with HTTP; Mon, 24 Oct 2016 11:17:48 -0700 (PDT) In-Reply-To: <20161024180818.GL86859@shrubbery.net> References: <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161022122735.GC79185@Space.Net> <20161024180818.GL86859@shrubbery.net> From: Robert Raszuk Date: Mon, 24 Oct 2016 20:17:48 +0200 X-Google-Sender-Auth: FfCTEWrLs47zFr0K1ug_GQ_3C7M Message-ID: To: heasley Content-Type: multipart/alternative; boundary=001a1142532ce29b44053fa06859 Archived-At: Cc: IETF IDR WG , Susan Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 18:17:54 -0000 --001a1142532ce29b44053fa06859 Content-Type: text/plain; charset=UTF-8 You still could do that. You overload last octet with exact action you need just like you do today with 1997. Three sets of 4 octets with no semantics still requires curret way to advertise what action given community means at any target ASN. Best, R Ps. Besides adding 4 more octets to leave current LC as is just to be able to avoid anonymous injections seems to me like very little price as compared with befit. But I guess am alone with that point of view here. On Oct 24, 2016 2:08 PM, "heasley" wrote: > Sat, Oct 22, 2016 at 03:53:05PM +0200, Robert Raszuk: > > You are mixing SRC_ASN with TARGET_ASN in the same field. > > I want to point-out that by forcing the first field to be "src_asn" as > you are suggesting, would make one intended use of -large- not possible, > for ASN1 to tell ASN2 to do something with a route as it applies to ASN3. > eg: ASN2:ASN3:action, ie: apply "action" (such as prepend) defined by ASN2 > to ASN1's route when advertised to ASN3. > > > Yes RFC1997 works like that but here we have opportunity to improve it. > > We have improved it. > --001a1142532ce29b44053fa06859 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

You still could do that.

You overload last octet with exact action you need just like= you do today with 1997.

Three sets of 4 octets with no semantics still requires curr= et way to advertise what action given community means at any target ASN.

Best,
R

Ps. Besides adding 4 more octets to leave current LC as is j= ust to be able to avoid anonymous injections seems to me like very little p= rice as compared with befit. But I guess am alone with that point of view h= ere.


On Oct 24, 2016 2= :08 PM, "heasley" <heas@= shrubbery.net> wrote:
Sat, Oct 22, 2016 at 03:53:05PM +0200, Robert Raszuk:
> You are mixing SRC_ASN with TARGET_ASN in the same field.

I want to point-out that by forcing the first field to be "src_asn&quo= t; as
you are suggesting, would make one intended use of -large- not possible, for ASN1 to tell ASN2 to do something with a route as it applies to ASN3. eg: ASN2:ASN3:action, ie: apply "action" (such as prepend) define= d by ASN2
to ASN1's route when advertised to ASN3.

> Yes RFC1997 works like that but here we have opportunity to improve it= .

We have improved it.
--001a1142532ce29b44053fa06859-- From nobody Mon Oct 24 11:19:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF78E1298CE for ; Mon, 24 Oct 2016 11:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 qEi7XIuwhVFc for ; Mon, 24 Oct 2016 11:19:24 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73CB129973 for ; Mon, 24 Oct 2016 11:19:24 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 955EA58F12; Mon, 24 Oct 2016 18:19:24 +0000 (UTC) Date: Mon, 24 Oct 2016 18:19:24 +0000 From: heasley To: Robert Raszuk Message-ID: <20161024181924.GN86859@shrubbery.net> References: <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161022122735.GC79185@Space.Net> <20161024180818.GL86859@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: heasley , IETF IDR WG , Susan Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 18:19:26 -0000 Mon, Oct 24, 2016 at 08:17:48PM +0200, Robert Raszuk: > You still could do that. > > You overload last octet with exact action you need just like you do today > with 1997. Please review the threads associated with -large- to re-discover why that is not acceptable. > Three sets of 4 octets with no semantics still requires curret way to > advertise what action given community means at any target ASN. > > Best, > R > > Ps. Besides adding 4 more octets to leave current LC as is just to be able > to avoid anonymous injections seems to me like very little price as > compared with befit. But I guess am alone with that point of view here. > > On Oct 24, 2016 2:08 PM, "heasley" wrote: > > > Sat, Oct 22, 2016 at 03:53:05PM +0200, Robert Raszuk: > > > You are mixing SRC_ASN with TARGET_ASN in the same field. > > > > I want to point-out that by forcing the first field to be "src_asn" as > > you are suggesting, would make one intended use of -large- not possible, > > for ASN1 to tell ASN2 to do something with a route as it applies to ASN3. > > eg: ASN2:ASN3:action, ie: apply "action" (such as prepend) defined by ASN2 > > to ASN1's route when advertised to ASN3. > > > > > Yes RFC1997 works like that but here we have opportunity to improve it. > > > > We have improved it. > > From nobody Mon Oct 24 12:11:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE151299BB for ; Mon, 24 Oct 2016 12:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 qPM9Ay-Yxqq9 for ; Mon, 24 Oct 2016 12:11:33 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234831299B4 for ; Mon, 24 Oct 2016 12:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2851; q=dns/txt; s=iport; t=1477336293; x=1478545893; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+cWLABf8VpAINaQ+J5OdHs/EnCeOB+a0Yz2cXjwF2xE=; b=SNXSYLg52fC5i9x0T1psoOa8Pui60m+V9JwQFr5MPNIkxwnkZE/sEz41 GALTLN4KZSEHuFF0IiUrIz61Zt4aW6QTl6t2UoNzN2nF4TbJzJ81wZ5gm +wI/wB9THtyymAEkQigXyEFdKiICZBwUITaCs11qPoY9qdJiGBL9cLrgs g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAQCkXA5Y/4UNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoBAQEBAR1YfQcBjSyWfJQ/ggccC4V6AoFoPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRiAQEBBAEBATc0CwwEAgEIEQQBAQEeCQcnCxQJCAIEAQ0FCAyIPg7BPwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARcFhj2DUIEFiiYFmhQBkAuBdYRtiACBJ4p2ghC?= =?us-ascii?q?EAAEeNl6DER8YgTpyh0EBfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,543,1473120000"; d="scan'208";a="338988838" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Oct 2016 19:11:29 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u9OJBS5q001820 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Oct 2016 19:11:28 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Oct 2016 14:11:28 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 24 Oct 2016 14:11:28 -0500 From: "Jakob Heitz (jheitz)" To: heasley , Robert Raszuk Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) Thread-Index: AdIotF10Qx6LizvwQ9uItB9ryESdDgANiv0AACybzYAAADoegAAC4vMAAGdvEAAAChhMkAAaOlQAAADNMIAAK3rfgAAC/G6AAG1/BQAAAFTwAAAADk4AAAnd70A= Date: Mon, 24 Oct 2016 19:11:28 +0000 Message-ID: References: <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <20161022122735.GC79185@Space.Net> <20161024180818.GL86859@shrubbery.net> <20161024181924.GN86859@shrubbery.net> In-Reply-To: <20161024181924.GN86859@shrubbery.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF IDR WG , Susan Hares Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 19:11:35 -0000 This draft provides a 12 byte community. The meaning of the 12 bytes is to be defined by mutual agreement between th= e sender and the receiver. In many cases, a community is confined to within a single AS or between two= ASes. In that case, no further specification from the IETF is necessary. In the case that a community stays attached to a route while it is propagat= ed to multiple ASes, we need to specify a little more. For this case, we recommend that the first 4 bytes contain the ASN that is = assigned to the entity that defines the meaning of the other 8 bytes. In this way, multiple entities can attach communities to the same route wit= hout conflict. There is no source ASN and no target ASN, just the namespace ASN. I say "entity" and not AS, because an entity that is assigned an ASN does n= ot necessarily use the ASN to construct an AS. Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of heasley > Sent: Monday, October 24, 2016 11:19 AM > To: Robert Raszuk > Cc: heasley ; IETF IDR WG ; Susan Hares= > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/= 2016 to 10/31/2016) >=20 > Mon, Oct 24, 2016 at 08:17:48PM +0200, Robert Raszuk: > > You still could do that. > > > > You overload last octet with exact action you need just like you do tod= ay > > with 1997. >=20 > Please review the threads associated with -large- to re-discover why that > is not acceptable. >=20 > > Three sets of 4 octets with no semantics still requires curret way to > > advertise what action given community means at any target ASN. > > > > Best, > > R > > > > Ps. Besides adding 4 more octets to leave current LC as is just to be a= ble > > to avoid anonymous injections seems to me like very little price as > > compared with befit. But I guess am alone with that point of view here. > > > > On Oct 24, 2016 2:08 PM, "heasley" wrote: > > > > > Sat, Oct 22, 2016 at 03:53:05PM +0200, Robert Raszuk: > > > > You are mixing SRC_ASN with TARGET_ASN in the same field. > > > > > > I want to point-out that by forcing the first field to be "src_asn" a= s > > > you are suggesting, would make one intended use of -large- not possib= le, > > > for ASN1 to tell ASN2 to do something with a route as it applies to A= SN3. > > > eg: ASN2:ASN3:action, ie: apply "action" (such as prepend) defined by= ASN2 > > > to ASN1's route when advertised to ASN3. > > > > > > > Yes RFC1997 works like that but here we have opportunity to improve= it. > > > > > > We have improved it. > > > >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Oct 24 12:47:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889461293F4 for ; Mon, 24 Oct 2016 12:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 aCfyHPGtwL8x for ; Mon, 24 Oct 2016 12:47:11 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE5B1299C0 for ; Mon, 24 Oct 2016 12:47:10 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id d199so6338010wmd.0 for ; Mon, 24 Oct 2016 12:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MJw7wptmZH5e1OB4uRNxXegiFnuHxDfV4b820aV1yfA=; b=QwC32oCNWA4NJ41ATnVrE1e6Q+b0BmQ85CdGECgscZXufEutUoF58wF1irR8aTubw3 OMSA8Jo7ympyFtMoNQQiLozg7A84iTGQ5+mZ0Ud3IXGpdtTQvYbE5AfnNknr/zQ2azhP n4a2d3jO68pN9PaG/yHgrY4gO730Ibff1inoa3CfUuDFE6m6dkaytktG3qCu4pr5vKaR CtqcUhj1rjMASkkqCuKwbuWBOlg3/w7PMVF1RrhSMTzjYDGXE+lM6RnllrEAO2Wq9Rcl LJTazAilHt0VisJIInRMsw97iLIDGMXv4MWvbcxNyy9vRBLMBxzqSmKjoOnRMH675hK8 40Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MJw7wptmZH5e1OB4uRNxXegiFnuHxDfV4b820aV1yfA=; b=D5hUt/jNr2yg6HJuZxekW6qeZFvVYIB00J43yZxTXPdCkxWkr66beWFToMcxFja+ZM iUGrU8eZhcDsc7ikyo2BS7LTa9Ulg++X+GesWJlFaHkEEapCZMyBz/goLv99Cn4Buv1m 2zeR+wRRiHqCRjzxYVEdq7mxmZiq8bw2S40KF+5rzJl99HyNVtulxdmw6r92bIUCHmGD s5NYAbAXzthZOckV9MSDmWvw0RdVe1ntYzwLh1A0THSiJU468flB8QbUoMCaMjtgzHDE CQ40nNyowoQ8x/6o9D/nUir2wTxeDathX0yFdpjK5Ph5mOFd5pqZIMKxZlRy27yAhOKh VXRg== X-Gm-Message-State: ABUngvfKxaDcYN6wvx/0Gr9k8CgcqVqBJTsozBk1yTzzROsG+DRyIewcJirKSE/whUqWzk+dD5NjquXq6dK5NA== X-Received: by 10.194.74.5 with SMTP id p5mr15368080wjv.92.1477338429146; Mon, 24 Oct 2016 12:47:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.207 with HTTP; Mon, 24 Oct 2016 12:47:07 -0700 (PDT) In-Reply-To: References: <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <20161022123423.GD79185@Space.Net> <20161023233431.GA76131@gweep.net> From: Brian Dickson Date: Mon, 24 Oct 2016 12:47:07 -0700 Message-ID: To: "John G. Scudder" Content-Type: multipart/alternative; boundary=047d7bd9111a484c2e053fa1a8db Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 19:47:12 -0000 --047d7bd9111a484c2e053fa1a8db Content-Type: text/plain; charset=UTF-8 On Mon, Oct 24, 2016 at 10:10 AM, John G. Scudder wrote: > Hi Everybody, > > There has been a fair amount of debate about this sentence in the draft: > > " Global Administrator: A four-octet namespace identifier. This > SHOULD be an Autonomous System Number." > > [...] if you disagree with that consensus and feel you have something new > to add to the discussion, please do. > I agree with the consensus sentiment, and only have suggestions for making that sentiment clearer. I think some recent discussion here has helped identify the corner cases/nuances, which I think can inform that wording. Here's a first cut at a suggested changes, and rationale: [Replace all instances of "Global Administrator" with "Global Administrator ASN" and/or GA_ASN.] "Global Administrator ASN: a four-octet namespace identifier. The namespace is under exclusive control of the Global Administrator of the ASN. There is no requirement that this namespace be used only within this ASN." Feel free to remove words or rephrase to shorten or improve clarity. Brian --047d7bd9111a484c2e053fa1a8db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 24, 2016 at 10:10 AM, John G. Scudder <= ;jgs@juniper.net&g= t; wrote:
Hi Everybody,

There has been a fair amount of debate about this sentence in the draft:
"=C2=A0 =C2=A0Global Administrator:=C2=A0 A four-octet namespace ident= ifier.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0SHOULD be an Autonomous System Number."

[...] if you disagree with that consensus and feel you have some= thing new to add to the discussion, please do.

I agree with the consensus sentiment, and only have suggestions for= making that sentiment clearer.

I think some recen= t discussion here has helped identify the corner cases/nuances, which I thi= nk can inform that wording.

Here's a first cut= at a suggested changes, and rationale:

[Replace a= ll instances of "Global Administrator" with "Global Administ= rator ASN" and/or GA_ASN.]

"Global Admin= istrator ASN: a four-octet namespace identifier.=C2=A0 The namespace is und= er exclusive control of the Global Administrator of the ASN. There is no re= quirement that this namespace be used only within this ASN."

Feel free to remove words or rephrase to shorten or improve= clarity.

Brian
--047d7bd9111a484c2e053fa1a8db-- From nobody Tue Oct 25 04:10:20 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DA61294E3 for ; Tue, 25 Oct 2016 04:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4M4AOvRNRLvJ for ; Tue, 25 Oct 2016 04:10:17 -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 A505F1294B9 for ; Tue, 25 Oct 2016 04:10:16 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u9PBAD5Q017690 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Oct 2016 12:10:13 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local Message-ID: <580F3D94.6050900@foobar.org> Date: Tue, 25 Oct 2016 13:10:12 +0200 From: Nick Hilliard User-Agent: Postbox 5.0.5 (Macintosh/20161020) MIME-Version: 1.0 To: Brian Dickson References: <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <20161022123423.GD79185@Space.Net> <20161023233431.GA76131@gweep.net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 11:10:18 -0000 Brian Dickson wrote: > I agree with the consensus sentiment, and only have suggestions for > making that sentiment clearer. > > I think some recent discussion here has helped identify the corner > cases/nuances, which I think can inform that wording. > > Here's a first cut at a suggested changes, and rationale: > > [Replace all instances of "Global Administrator" with "Global > Administrator ASN" and/or GA_ASN.] > > "Global Administrator ASN: a four-octet namespace identifier. The > namespace is under exclusive control of the Global Administrator of > the ASN. There is no requirement that this namespace be used only > within this ASN." The sentiment in your suggestion is to harden the association between the term "Global Administrator" and "ASN". This isn't making things clearer: it's proposing to change the meaning of what's currently in the draft, in a direction which has already been discussed. Nick From nobody Tue Oct 25 05:29:19 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B1412946B; Tue, 25 Oct 2016 05:29:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147739855486.15274.12971112004095282551.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2016 05:29:14 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 12:29:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Applying BGP flowspec rules on a specific interface set Authors : Stephane Litkowski Adam Simpson Keyur Patel Jeff Haas Lucy Yong Filename : draft-ietf-idr-flowspec-interfaceset-02.txt Pages : 14 Date : 2016-10-25 Abstract: BGP flowspec is an extension to BGP that allows for the dissemination of traffic flow specification rules. The primary application of this extension is DDoS mitigation where the flowspec rules are applied in most cases to all peering routers of the network. This document will present another use case of BGP flowspec where flow specifications are used to maintain some access control lists at network boundary. BGP flowspec is a very efficient distributing machinery that can help in saving OPEX while deploying/updating ACLs. This new application requires flow specification rules to be applied only on a specific subset of interfaces and in a specific direction. The current specification of BGP flowspec ([RFC5575]) introduces the notion of flow specification (which describes the matching criterion) and traffic filtering actions. The flow specification is encoded as part of the NLRI while the traffic filtering actions are encoded as extended communities. The combination of a flow specification and one or more actions is known as a flow specification rule. [RFC5575] does not detail where the flow specification rules need to be applied. Besides the flow specification and traffic filtering actions, this document introduces the notion of traffic filtering scope in order to drive where a particular rule must be applied. In particular, this document introduces the "interface-set" traffic filtering scope that could be used in parallel of traffic filtering actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers about groups of interfaces where the rule must be applied. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-interfaceset/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-interfaceset-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 25 08:01:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AE01296A9 for ; Tue, 25 Oct 2016 08:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=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 sOVXgUYi1Fi0 for ; Tue, 25 Oct 2016 08:00:59 -0700 (PDT) Received: from gerbil.cluepon.net (cluepon.net [204.93.176.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8048D129480 for ; Tue, 25 Oct 2016 08:00:45 -0700 (PDT) Received: from gerbil.cluepon.net (ras@localhost [127.0.0.1]) by gerbil.cluepon.net (8.14.8/8.14.4) with ESMTP id u9PF0iwl057099 for ; Tue, 25 Oct 2016 10:00:44 -0500 (CDT) (envelope-from ras@gerbil.cluepon.net) Received: (from ras@localhost) by gerbil.cluepon.net (8.14.8/8.14.8/Submit) id u9PF0i2I057098 for idr@ietf.org; Tue, 25 Oct 2016 10:00:44 -0500 (CDT) (envelope-from ras) Date: Tue, 25 Oct 2016 10:00:44 -0500 From: Richard A Steenbergen To: IETF IDR WG Message-ID: <20161025150044.GI94714@gerbil.cluepon.net> References: <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <20161022123423.GD79185@Space.Net> <20161023233431.GA76131@gweep.net> <580F3D94.6050900@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <580F3D94.6050900@foobar.org> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 15:01:01 -0000 Hello, As a network operator, and a listed author on the "competing" wide BGP communities draft, I'd like to make a few comments. At the time I originally got involved in helping to create a "better" BGP community implementation (around 2010, IIRC), we were facing the rather serious problem that when 16-bit ASNs ran out, there was no good mechanism for 32-bit speakers to use BGP communities in the way we've all come to know and love on the Internet. Quite frankly, my involvement with that draft wasn't because I in any way considered it to be the best solution, but because I thought we needed to do SOMETHING, and I didn't want to see something that had zero ACTUAL operator vetting get rolled out. I got very busy with other things in life (being the CTO of a Tier 1, launching a new startup, etc), so admittedly this issue fell off my radar (and as an owner of many 16-bit ASNs, it was never really something that affected me personally anyways :P), but I am absolutely appalled to see that the state of affairs has not changed since then. This is disgraceful in a way that only the IETF is capable of delivering, and I feel very sorry for the poor networks who are trying to get off the ground today in a 32-bit ASN world with issues like this still outstanding. Having reviewed the current state of both proposals, I am now a firm supporter of the large communities draft, and wish to remove my support and authorship from the wide communities draft. This is the simple, effective, and not overly convoluted solution we need, and I'm glad that someone is actually taking the time and energy to get it fixed once and for all. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From nobody Tue Oct 25 09:55:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694AE129577 for ; Tue, 25 Oct 2016 09:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6hS5pHtwMgBH for ; Tue, 25 Oct 2016 09:55:45 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) by ietfa.amsl.com (Postfix) with ESMTP id 81829129557 for ; Tue, 25 Oct 2016 09:55:45 -0700 (PDT) Received: from [85.158.136.83] by server-1.bemta-5.messagelabs.com id 00/20-19721-09E8F085; Tue, 25 Oct 2016 16:55:44 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRWlGSWpSXmKPExsUSsELzi+6EPv4 Igz/PWS1e3X7G5MDosWTJT6YAxijWzLyk/IoE1ox3OycwFpzkq+jqfc/awLiBr4uRi0NI4ACT RMvdaSwQzlpGia3rm4EcTg42ASOJCev2A9kcHCICihIrPyWDmMICLhIdnXIgFSICrhKPbx1mh bD1JBqOnWIEsVkEVCUuth1iArF5Bewlmme/BLMZBWQlvjSuZgaxmQXEJW49mQ8WlxAQkFiy5z wzhC0q8fLxP7CZokAzP91ezQIRV5C4uKCLDeQEZgFNifW79CHG2Eos/LGXFcJWlJjS/ZAdYq2 gxMmZT1gmMArPQrJtFkL3LCTds5B0z0LSvYCRdRWjRnFqUVlqka6hkV5SUWZ6RkluYmaOrqGB qV5uanFxYnpqTmJSsV5yfu4mRmBEMADBDsa+Wc6HGCU5mJREeV17+COE+JLyUyozEosz4otKc 1KLDzHKcHAoSfAK9wLlBItS01Mr0jJzgLEJk5bg4FES4TUASfMWFyTmFmemQ6ROMSpKifPeBp kpAJLIKM2Da4Olg0uMslLCvIxAhwjxFKQW5WaWoMq/YhTnYFQS5vUEGc+TmVcCN/0V0GImoMW C8Twgi0sSEVJSDYzc1auvP/6S8zNX+/6pYuYFP993unp4Wr95USj9x+BD//bjez/2Fr8u+u3V /6XtwoqCuFcTftXKJvB7n9H1t4z58uTTdue0rUs0pD7uMJ/72zi03UfxocI658I3TVttW+YUL 18nv01PsD9xj6Iux6Pvh/eerw+VVP8d2eJgodw7WXODzLzfHzYosRRnJBpqMRcVJwIAxuktPw IDAAA= X-Env-Sender: david.freedman@uk.clara.net X-Msg-Ref: server-9.tower-36.messagelabs.com!1477414544!65811131!1 X-Originating-IP: [80.168.41.244] X-StarScan-Received: X-StarScan-Version: 9.0.13; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7079 invoked from network); 25 Oct 2016 16:55:44 -0000 Received: from staff02.mail.eu.clara.net (HELO staff02.mail.eu.clara.net) (80.168.41.244) by server-9.tower-36.messagelabs.com with SMTP; 25 Oct 2016 16:55:44 -0000 Received: from [80.168.41.252] (port=2343 helo=SRVGREXCAS02.claranet.local) by staff02.mail.eu.clara.net (staff02.mail.eu.clara.net [80.168.41.244]:25) with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1bz50p-0001tY-9X for idr@ietf.org (return-path ); Tue, 25 Oct 2016 16:55:43 +0000 Received: from SRVGREXMB01.claranet.local ([fe80::64bc:5d10:5203:a830]) by SRVGREXCAS02.claranet.local ([::1]) with mapi id 14.03.0319.002; Tue, 25 Oct 2016 17:53:32 +0100 From: David Freedman To: "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-04.txt Thread-Index: AQHSLuBRsPkuD2mF3UePF3Sqj1Od7w== Date: Tue, 25 Oct 2016 16:53:32 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-originating-ip: [172.26.6.254] Content-Type: text/plain; charset="utf-8" Content-ID: <50A5B9DE2FFA63449BEE8A340EA24556@claranet.local> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 16:55:47 -0000 QXBvbG9naWVzIGZvciB0aGUgdWx0cmEtbGF0ZS1sYXN0LW1pbnV0ZSBpbnB1dCwgYnV0IEkgd2Fz IGRpc2N1c3NpbmcgdGhpcyB3aXRoIEpvYiBvZmZsaXN0IGFuZCB3ZSBmZWx0IGl0IHNob3VsZCBi ZSBzZWVuIGJ5IGxpc3QgcGFydGljaXBhbnRzLgoKTXkgcG9pbnQgd2FzIGFib3V0IFJGQzE5OTcg cGFyaXR5IGFuZCB0aGUgbGVuZ3RoIHZhbGlkYXRpb24uIAoKICIgQSBMYXJnZSBCR1AgQ29tbXVu aXRpZXMgYXR0cmlidXRlIHdpdGggYSBsZW5ndGggb2YgemVybyBNVVNUIGJlIGlnbm9yZWQgdXBv biByZWNlaXB0IGFuZCByZW1vdmVkIHdoZW4gc2VuZGluZy4iIAoKTGF0ZXIgd29yZGluZyBoZXJl IGhhcyBiZWVuIGRpc2N1c3NlZCB0byBiZSBhbWVuZGVkIChJIHVuZGVyc3RhbmQpIHRvOgoKIiBB IExhcmdlIEJHUCBDb21tdW5pdGllcyBhdHRyaWJ1dGUgd2l0aCBhIGxlbmd0aCBvZiB6ZXJvIE1V U1QgTk9UIGJlIHNlbnQgYW5kIE1VU1QgYmUgaWdub3JlZCB1cG9uIHJlY2VpcHQuIgoKV2VsbCwg SSB3YW50ZWQgdG8gcG9pbnQgb3V0LCB0aGF0IFJGQzE5OTcgd2FzIG9mIGNvdXJzZSB1cGRhdGVk IGJ5IFJGQzc2MDYuCgpJbiAoNzYwNiksIHRoZSBmb2xsb3dpbmcgdHdvIGNvbW1lbnRzIGFyZSBt YWRlOgoKIiBGb3IgYWxsIHBhdGggYXR0cmlidXRlcyBvdGhlciB0aGFuIHRob3NlIHNwZWNpZmll ZCBhcyBoYXZpbmcgYW4gYXR0cmlidXRlIGxlbmd0aCB0aGF0IG1heSBiZSB6ZXJvLCBpdCBTSEFM TCBiZSBjb25zaWRlcmVkIGEgc3ludGF4IGVycm9yIGZvciB0aGUgYXR0cmlidXRlIHRvIGhhdmUg YSBsZW5ndGggb2YgemVyby4iIAoKQW5kIAoKIiBUaGUgZXJyb3IgaGFuZGxpbmcgb2YgW1JGQzE5 OTddIGlzIHJldmlzZWQgYXMgZm9sbG93czogVGhlIENvbW11bml0eSBhdHRyaWJ1dGUgU0hBTEwg YmUgY29uc2lkZXJlZCBtYWxmb3JtZWQgaWYgaXRzIGxlbmd0aCBpcyBub3QgYSBub24temVybyBt dWx0aXBsZSBvZiA0IiAKClNvIHJlYWxseSwgaWYgeW91IGFwcGx5IFJGQzc2MDYgdG8gUkZDMTk5 NyB5b3UgaGF2ZSBsb3N0IHBhcml0eSBpZiB5b3UgYWNjZXB0IGEgemVybyBsZW5ndGggY29tbXVu aXR5IChldmVuIGlmIHlvdSBqdXN0IGlnbm9yZSBpdCkuIAoKTXkgc3VnZ2VzdGlvbiBoZXJlIGlz IGp1c3QgdG8gZHJvcCB0aGUgcGFzc2l2ZSByZWNlaXZlIHRvbGVyYW5jZSBvZiB0aGUgemVybyBs ZW5ndGggbGFyZ2Vjb21tLCBzaW5jZSBpdCBzZWVtcyBvdXQgb2YgcGxhY2UgKGV2ZW4gaWYgaXQg aXMgaGFybWxlc3MpLiAKYW5kIGxldCBpdCBiZSBjb25zaWRlcmVkIG1hbGZvcm1lZCBhbmQgaGFu ZGxlZCBieSBSRkM3NjA2LiAKClRob3VnaHRzPyAKCkRhdmUuIAoK From nobody Tue Oct 25 09:57:29 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687DD129484 for ; Tue, 25 Oct 2016 09:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 zfG6Es64pAwv for ; Tue, 25 Oct 2016 09:57:25 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0131.outbound.protection.outlook.com [104.47.2.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C836912983F for ; Tue, 25 Oct 2016 09:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oXCHHs82tQyrsyy/pNTSRq/EyxIju+T2T6NlSHeHhxw=; b=deZ5dm96G+REPx7sTp9Qif+6UcSBpPgKLbC10B5P+n4V02XXXxVNKA0KKyk0y3lMmI1FgxazFeEpntMaoh6lAlbwKpBuKn5k5CPsLimfbcuBwac9I2aZuUe2mahBUpoAzfC2ahUwWCEviG2orprHrYmVAJTy0ae60u2hQ7xr9dQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Tue, 25 Oct 2016 16:57:20 +0000 Message-ID: <014c01d22ee0$7cf44160$4001a8c0@gateway.2wire.net> From: t.petch To: Nick Hilliard , Brian Dickson References: <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <20161022123423.GD79185@Space.Net> <20161023233431.GA76131@gweep.net> <580F3D94.6050900@foobar.org> Date: Tue, 25 Oct 2016 17:54:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.135.210.62] X-ClientProxiedBy: HE1PR06CA0057.eurprd06.prod.outlook.com (10.164.28.153) To HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) X-MS-Office365-Filtering-Correlation-Id: 7ac6af4a-c7da-4e3c-842d-08d3fcf7fbfe X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 2:GqmTghzaRllB9tuBUiOXyrdYPXl5ZsqBq5coZlMBZNgifexni9fmK8loIOYtQhoNQvbTBHelyyMwqWbRgcxp/anbG7IrAeXF3BCgIsfXspjl2J4ZdMhz7zdK+7WKByYmCrGgeK0WgxCAzIOLUIqbPmVcEU+d+Hj3DnXIxOtjU8aEFgPVBK3+sxbv46q/8pb2i0AQId3nLkdQdxVURhe/aw==; 3:VdBySIF0DeE7wpieXh50BVzVITeTzaUfuPCmJB/h2XLUyUwmLMJlB+7k17GuVILXlfeVzJ65p65qKoL6aIR5KbRLUv07M+dbBCS8EVn1Yaw8fQgFqXR49Dg1bGQaC6Ec7/hxO1MRAnLprx6F99Py+g==; 25:29YuR4qeTs/mkpam3ZSr0qpdUU0K4xTOMxzWQTDjBRj6MjqCvwrE/6KTHTQjp1b6FRN6GBQl1/1ZHw3xJaIcu+wxVObP+PrV+wMJVBeh0LtQpUY974GSHOblrhemyi4aRjLwVbMMSc90u3cD7ggymigWmnmoP7/fzE+qmmfhF5eZSwcZrnknQ4d5WEStNyb3pTN3hxrhZRTDmHHKRvrfX38KsZuPDVg81s4b3/jn6QzvP7pO6gnOaDIw7jnt8iZ9g+E63f58gc7roNQe+2Lyxu/Jbh1jTaG8Tdc91OoaFn5nAaflS5diS8qQ96pzFXnHu0tj+AVEGOKQLNNUw0CyVvEPI30yxyvMHNg2aTi82d2aDNRIxXaXKoWt0vzgC/S9bDH+moI4rviIKBXVA0Oo99IltRQWLdc4Lxq/m6+iJFXszqNMH/oEBNyueOMFjyu0 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 31:jDmnbpBcaLHPsemAGxbdhgn7YxpRNsz1IR2OcI0Erd2lBrcWToNXS4Zh3T1b2V69aLoeHXeVVjnveT9M3bQ7o+VdOInvBRTSPDbTf7Go5KgBuy5PZIT27Ky+RMKywz3atPoHrjSe3c1KbN8f7NDcQ2cPN7BrFU6TMulJVkz3xQ6/QnbHpdJ2asVWz9Z49OHEDkr0fmprs3ZLSVaUIaeUyI4E3cNSrlYUKOEG7Qia+bMBJK0iiO7UtJ0iFo6b8hYdVgt2PG6lAlUAEddighFLyBKEuNcZ/3s2lEvKj5/BiR4=; 4:/auukRRIcvDFIdXdd9weuyb//0YsAxFxIVkGLOeWdTL21jjybrv4NQUozRZZdQ8EzP1EMXk+VYKi76eP67CJg8acoS8CgwnFJW418lO0MRtAhM96O6XvhsgTlB2/BNoYgBbjYiSEsxCheWNqMg8xu7HtADKcEvhz56dOlSV8O2mu12FRQGox4DfZ+cDl5zB5jyUR/qk7N0isEFQcu5c+ou/JmD/TuSrJBT8DGnk8p28tQi1bdznydEa/jsqim0Zqu2shDLEddSFt7hb7xGz7VEUGNrDX002cs4TWOjpIyvGwXI0Lftn+znNRNZjpMYY50+/k2eHTmFtV27U4zQOc5K+7UKaH+m0Rtk5Knj42lmtiPsze6eK7ESPBNLPYVFaCZgMoK8pVm9bADOR0IkCXgtmymZxn85i2MKxmmho6A2WCCOAN7uhtnDr3pqH/07rv X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3002; X-Forefront-PRVS: 01068D0A20 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(377454003)(24454002)(13464003)(5423002)(199003)(81166006)(9686002)(61296003)(84392002)(4326007)(5660300001)(105586002)(7846002)(19580395003)(97736004)(14496001)(101416001)(7736002)(68736007)(81156014)(44736004)(4720700003)(106356001)(5001770100001)(116806002)(86362001)(3846002)(1456003)(6116002)(8676002)(1556002)(42186005)(230783001)(92566002)(2906002)(44716002)(23756003)(62236002)(50226002)(33646002)(93886004)(189998001)(77096005)(50466002)(586003)(47776003)(19580405001)(81686999)(76176999)(230700001)(305945005)(50986999)(81816999)(66066001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3002; 23:H64fNz+kSc9f90jwQR3D/5WtYPmYWMfeo7aMg?= =?iso-8859-1?Q?3vrAzP+w3kQ3XhY9hSMRAsuLLgwZdXkAO/ivaWnPenueAKK8aphFiOofwU?= =?iso-8859-1?Q?+vb5RD8nY1ZM5cCm+SmX78vTW526s4fi9Vy9pMaANCHmCF9jyaIDfQgXW0?= =?iso-8859-1?Q?LyQ8XXhWHz4xkZ+3/EyaGN4zSGCub3kElTZ/CztuEHF+Q3Uqvb1yg4Ef71?= =?iso-8859-1?Q?JBLYVa2/by+X0eAeAIS4yH8DXN6lrGEGDCRLMfJr6hf5nSQrOk2Ect1Zah?= =?iso-8859-1?Q?gDII+nh0jwraCcIpn9DFkKZyII5alRtDRn0dkZyZS/lFo8xRYvzPtbm59k?= =?iso-8859-1?Q?iIFxxfJD2ITbMMIL4Zr1bN3tilq1R+aWJFIqQ9nFSf5jPj09B8ZNw430Wc?= =?iso-8859-1?Q?EViE3CVTBod1qPvsx6+ZD948+Ef7y+6xhXg4iHTHgUDgfYxkfSOSGOcDmt?= =?iso-8859-1?Q?L4YCd2pAtagT89cySVPvDYXGW7s86EyX/N18H1m6241pfkfUHD9XLJK9i1?= =?iso-8859-1?Q?e+VdChIG70vAZoVLr6dvo6CSvo0mOgrzA6HTUDfUZ5yTkit+PY2O6a+V/u?= =?iso-8859-1?Q?sfsSEzvh45N/849qCMmMF81y6WpIuGe0jaC6Sm0pJY2jKNAnrWjH+gB8aE?= =?iso-8859-1?Q?cMLugulYyq8N3n3uYIqB6EWefeo1n29peE7TsGYQc6GYvdiW8QpathM3FQ?= =?iso-8859-1?Q?13sB0RjgjBCWlaopKMWQUu2/MsHU8CBlYpIuDZ8vG+GAm+MsIDnlixJ9wx?= =?iso-8859-1?Q?jS7trddBvsK/GYe0LZzingaQjPFUAyJahSrcq4otHpGfe1NhNwQ/wJvG9u?= =?iso-8859-1?Q?lHkPn5DOxk67+dwiSxUYnBjQgFEZPk8uj5cgKOIE1KJ9+Mkgh8JS/yRNLA?= =?iso-8859-1?Q?L5wGl2qrE2mdOvV2E8DLB9R/jxzkUABG1rPygqdDAUuf+9fbHwGfdAjvMX?= =?iso-8859-1?Q?aEHFZwxlAnXnp3ezHnee7OkZB19jLwRu9+5YlZK9VvH0RHfTAINqVpapBw?= =?iso-8859-1?Q?BPgA1A9ZH59tWozMFsOvSjcWlVH/jT0SQyTU/LxiFlWeJRwbi7FYayuQMg?= =?iso-8859-1?Q?Eh3pHv7/4cUolqkPGJei98Ma6/u719UxaLyTy/PWQY1A/Fq+XkwLf3oD0Q?= =?iso-8859-1?Q?x0hP5ZYNG/bhT+kZJMIthKkuAhzDeNpGSyaIz6I9du6OnGLttP+oQhXP5c?= =?iso-8859-1?Q?Uqn5EPK4FN9cf07xjp4n49x4HhQ6O2s27XNe7UUn2vP5q4l1inMOTG8agb?= =?iso-8859-1?Q?WgqxLN3k/il6Fvmt6s6UbLqhUbQ/vBVwnTdrPIIZ1rzUzBvuyS8Ish7+Jy?= =?iso-8859-1?Q?ggVinYzYvMVkuVsk2W/oAitA1WGTcaTXbP6AP33sLXZVEI+0tkbM5GonJY?= =?iso-8859-1?Q?lztvlGx1pBO4yaVD75gTPm5u3yyCaN0jq23CWfkxv68a+FHNTd9dQ6+1IJ?= =?iso-8859-1?Q?9qKcbPABOcWOVn3pOiQ3Eok44AE7f1PFtS9P2Ij8F7Wcvuv+qMC2XN5of+?= =?iso-8859-1?Q?59woGVmqZB3RKe6rzmrHs8=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:F/5KLcGBPhim2B40Sm3Sdrvwl0JIQUGdV671M4KwdSg61OcRTb76JKQeyLo/Z7AOaQZ6ZMEkbSdlb4TnRVVcOrxqFEeFmk/NPRKgfj5nxVn3XtEpG/9pv4s7EA0nkER0oAxqhKy04PG8n/cINvlrS+fx+uTAxI+0XHnbAeTVNPi/G/HIZGcyX+XbBxLTNSsTzmQjEh4yoVqFGkxs61t6o/zD0WK1bKwlKT/+GqX6ZRwyieEeZeSrUOQD38ojt03qKDFDlJxsC8Dob7WhLPy7JlmHRpJuVGi3LfdgOeI0S+JcU7wUhCJIlOKybdlvvlZt; 5:B+Lbj3Glinr/vsvblc1A9ySldsn0DP0mJrIIvcaPnKfNmgxTzjkjcglDT/ERvu0tcYiPui9sHD43Ov8pegcNVdrDjDp0z55MrO2HemmySiarXrmbmiugXYs0uYmvGGb6o8m9V7f+TmjBef8E5ou/fg==; 24:YnJ3UyX+96Vc2vQsniHf+7CLQbFvmVz1hNVq982z9r4Ii6x9tMJtZnMqOB8e55/ztde43bIVd9UxtAYWb40ppz0jeY3dib9ay2nkTmTeEAs=; 7:t2uEVz9m4KSgaIBhxXK4/OMBIa/4ex5Z/IMN9h00OV6/fS4Bx8Ehz68xFp/JfLizAuaZFLSW6bdbEn3CWA+6UrGsGdT0DwshN65Y9iRXRWkxtHxrcI6zf+DqU/BH3j855tLrjlqwaQTzT2rnoHe+8yMq8XaT1WbnLVDTFnW1NqESWjdu2mg/iXqJLl8e+9l/wv9DyNmqqSgnHZUMoXbvQGlbCrZ0yrIiIdneA5y0+koSzLBdgdOGuIBLQ6XZZd89WRoK79dtRlK8PD6HW7+mkblQwoaP27ho6AZ4j+3y2swABqxGHVAoNMsXGGLviw0FDl/zW+QuSQbAvysN8YEcqtq04XXCVYNqooFinB+ikPY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2016 16:57:20.0121 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 16:57:27 -0000 ----- Original Message ----- From: "Nick Hilliard" Sent: Tuesday, October 25, 2016 12:10 PM > Brian Dickson wrote: > > I agree with the consensus sentiment, and only have suggestions for > > making that sentiment clearer. > > > > I think some recent discussion here has helped identify the corner > > cases/nuances, which I think can inform that wording. > > > > Here's a first cut at a suggested changes, and rationale: > > > > [Replace all instances of "Global Administrator" with "Global > > Administrator ASN" and/or GA_ASN.] > > > > "Global Administrator ASN: a four-octet namespace identifier. The > > namespace is under exclusive control of the Global Administrator of > > the ASN. There is no requirement that this namespace be used only > > within this ASN." > > The sentiment in your suggestion is to harden the association between > the term "Global Administrator" and "ASN". This isn't making things > clearer: it's proposing to change the meaning of what's currently in the > draft, in a direction which has already been discussed. Which in turn is seems to be taking us away from the aim of this work, as stated recently by John, namely, "When the working group accepted the draft as a work item, I think it was pretty clear from the extensive conversation at that time, that the intent was to replicate RFC 1997, not to improve it. " The freedom to put anything you feel like putting in the first field is not replicating RFC 1997, it is a significant (IMHO) change and the sense I get is that many here want that as an 'improvement'. For me, it is a hazard to the Internet, not an improvement (which is why I oppose it). I am with Brian on this. Tom Petch > > Nick > From nobody Tue Oct 25 12:41:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D5B1299B5 for ; Tue, 25 Oct 2016 12:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 25arlhC-FixZ for ; Tue, 25 Oct 2016 12:41:53 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507D01299AC for ; Tue, 25 Oct 2016 12:41:53 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id c78so43521850wme.0 for ; Tue, 25 Oct 2016 12:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PfygExtnOg1ymSVAvQnxkpPR1x2GYas0oOCAcFS4DbM=; b=gXvq7oD2C5GcK4DYpguT+YPq/dj1dmTUZJJczFz3mPXsOBnFRMi/7zjihPWLZ1r3pw /MdFPMWTy8BV7sQykKMOMW3d08V79oVtw+t4XK8gM4Jl0EW1DA9Fe7s8kUBWfnpcJRgX pKwnFW41w4QzI2gOb3PAcUeUXM3mPM9C3UzPVBZZyWo3bPIClqnvaQJeY62ahNe2G0kX VCsF2qm+45ailGZyKK773mcvzODHWrFFpjpGqQSXcFDEMqMx0nnvfBogIqjgK7RkIXaP JDR5kuikIWELeYRGZ5OZy3mMHk5KefjUNTZKISPhks6aCjDMyhZVRW5wG2/PFnoeu6ql SYFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PfygExtnOg1ymSVAvQnxkpPR1x2GYas0oOCAcFS4DbM=; b=LFpb8Y+yc01xCcXdZ0SH2yvNaQqKPvuW7JARo1hyM9mHHONbc53ZNLKGlhyxxqMkvO njPlC/HxFNgXrGrlQTSC81MLeXrxLo6wJJPCMnD8mN5uWXCxXRHbat+WhRNEC8AUjlj2 ogU2ELERIQPePAT6RxyYQhaIUfEJEcYCNa+KySd+as+IFqgIPXpy1FAeSfVv2we+HhtP QLCY3QuI44aV2/ZEJSNWI1406KkjJwSN26qgcagBdNU19GAZW7T7SZGH5eb3AIzP15P1 idnpGz1GcyK1vEfZr3dqorFO5c/1xOU22IN9s+fFc9F21d9BAYJbyCxgvQ137kzYU6D0 2c1Q== X-Gm-Message-State: ABUngvewYRDqB7TlQrOTkL3bJPqphIR1Isst8K6hZ1NpiRoIuYNr+SVHOzyrAUc64Ij3gXzxHDtIME892VSu7g== X-Received: by 10.194.150.132 with SMTP id ui4mr5325851wjb.92.1477424511476; Tue, 25 Oct 2016 12:41:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.207 with HTTP; Tue, 25 Oct 2016 12:41:50 -0700 (PDT) In-Reply-To: <580F3D94.6050900@foobar.org> References: <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <20161022123423.GD79185@Space.Net> <20161023233431.GA76131@gweep.net> <580F3D94.6050900@foobar.org> From: Brian Dickson Date: Tue, 25 Oct 2016 12:41:50 -0700 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=089e0122840a306869053fb5b349 Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 19:41:55 -0000 --089e0122840a306869053fb5b349 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 25, 2016 at 4:10 AM, Nick Hilliard wrote: > Brian Dickson wrote: > > I agree with the consensus sentiment, and only have suggestions for > > making that sentiment clearer. > > > > I think some recent discussion here has helped identify the corner > > cases/nuances, which I think can inform that wording. > > > > Here's a first cut at a suggested changes, and rationale: > > > > [Replace all instances of "Global Administrator" with "Global > > Administrator ASN" and/or GA_ASN.] > > > > "Global Administrator ASN: a four-octet namespace identifier. The > > namespace is under exclusive control of the Global Administrator of > > the ASN. There is no requirement that this namespace be used only > > within this ASN." > > The sentiment in your suggestion is to harden the association between > the term "Global Administrator" and "ASN". This isn't making things > clearer: it's proposing to change the meaning of what's currently in the > draft, in a direction which has already been discussed. > > Actually, no. What I am proposing, is to make the document internally consistent. The last paragraph of section 1 (Introduction) reads as follows: To address these shortcomings, this document defines a Large BGP Communities attribute encoded as one or more twelve-octet values, each consisting of a four-octet ASN and two four-octet operator- defined values, each of which can be used to denote properties or actions significant to that ASN Making the field descriptions and wording in section 2 agree with this, is the intent. Since there has been no disagreement on the introduction, and in fact that the introduction was offered as proof that there was no need to change the wording (to which I disagree), I was suggesting the changes that move toward the general understanding conveyed in the introduction. I have also asked if anyone can come up with a specific counter-example, where a value other than an ASN would be legitimately be used in the first 4 octets. Is it the case that any ASN owner gets to exclusively define the LC for their ASN? If not, then this is not accurately documented in the proposed standard, and it also fails to achieve parity with RFC1997. If it is the case (exclusive ASN->LC definitions), it would behoove us to say so. None of the above implies any need to enforce anything, on the part of implementations. It does not need to be any stronger than making the definitions consistent with the Introduction. IMHO, that is what my wording accomplishes, and is the reason for proposing wording changes. Brian P.S. In case it isn't clear: ASN->Global Administrator is 1:1 Global Administrator -> ASN is 1:many (where "many" includes "1" as the degenerate case). Which GA_ASN value is actively used by GA, is entirely up to GA. Who can use the LCs defined by GA is "anyone". Whose LC announcements are honored by GA (and/or third parties) is up to GA (or those third parties). Example of hypothetical use case: A group of GAs agree to define amongst themselves, a special-purpose LC. In order to simplify the situation, they agree to use GA_ASN_1:X:Y as the LC. (X and Y are a single set of fixed values.) This avoids replicating the same functionality with different values GA_ASN_N:X:Y, and simplifies the operator's processing of the LC. The LC may be common knowledge, but is likely only accepted by the ASNs within the group of GAs, when received from each other. The LC is used by multiple ASNs, but is only defined by the owner of GA_ASN_1. So, the binding of "exclusive" is on "definition of LC value->semantic mappings", but is not exclusive in the use by sending or receiving ASNs. All of this detail is stuff that will (I expect) end up in the GROW document. However, the IDR document needs to have support in its definitions, for those nuances. Simply weakening the definition to "SHOULD", IMHO places undue restrictions on the intended GROW document. I have yet to see anyone give a single use case that requires "SHOULD" rather than "MUST". Brian --089e0122840a306869053fb5b349 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 25, 2016 at 4:10 AM, Nick Hilliard <nick@foobar.org><= /span> wrote:
Brian Dickson wrote:
> I agree with the consensus sentiment, and only have suggestions for > making that sentiment clearer.
>
> I think some recent discussion here has helped identify the corner
> cases/nuances, which I think can inform that wording.
>
> Here's a first cut at a suggested changes, and rationale:
>
> [Replace all instances of "Global Administrator" with "= Global
> Administrator ASN" and/or GA_ASN.]
>
> "Global Administrator ASN: a four-octet namespace identifier.=C2= =A0 The
> namespace is under exclusive control of the Global Administrator of > the ASN. There is no requirement that this namespace be used only
> within this ASN."

The sentiment in your suggestion is to harden the association betwee= n
the term "Global Administrator" and "ASN".=C2=A0 This i= sn't making things
clearer: it's proposing to change the meaning of what's currently i= n the
draft, in a direction which has already been discussed.



Actually, no.

What I am proposing, is to make the document internally consistent.=

The last paragraph of section 1 (Introduction) re= ads as follows:

To address the=
se shortcomings, this document defines a Large BGP
   Communities attribute encoded as one or more twelve-octet values,
   each consisting of a four-octet ASN and two four-octet operator-
   defined values, each of which can be used to denote properties or
   actions significant to that ASN
=

=C2=A0Making= the field descriptions and wording in section 2 agree with this, is the in= tent.

Since there has been no disagreement on the = introduction, and in fact that the
introduction was offered as pr= oof that there was no need to change
the wording (to which I disa= gree), I was suggesting the changes that move toward
the general = understanding conveyed in the introduction.

I have= also asked if anyone can come up with a specific counter-example, where a = value
other than an ASN would be legitimately be used in the firs= t 4 octets.

Is it the case that any ASN owner gets= to exclusively define the LC for their ASN?

If no= t, then this is not accurately documented in the proposed standard, and it = also
fails to achieve parity with RFC1997.

If it is the case (exclusive ASN->LC definitions), it would behoove u= s to say so.

None of the above implies any need to= enforce anything, on the part of implementations.

It does not need to be any stronger than making the definitions consistent= with the Introduction.
IMHO, that is what my wording accomplishe= s, and is the reason for proposing wording changes.

Brian

P.S. In case it isn't clear:

ASN->Global Administrator is 1:1

Global Administrator -> ASN is 1:many (where "many" includes= "1" as the degenerate case).

Which GA_A= SN value is actively used by GA, is entirely up to GA.

=
Who can use the LCs defined by GA is "anyone".
Whose LC announcements are honored by GA (and/or third parties)= is up to GA (or those third parties).

Example of = hypothetical use case:
A group of GAs agree to define amongst the= mselves, a special-purpose LC.
In order to simplify the situation= , they agree to use GA_ASN_1:X:Y as the LC.
(X and Y are a single= set of fixed values.)

This avoids replicating the= same functionality with different values GA_ASN_N:X:Y,
and simpl= ifies the operator's processing of the LC.

The= LC may be common knowledge, but is likely only accepted by the ASNs within=
the group of GAs, when received from each other.

<= /div>
The LC is used by multiple ASNs, but is only defined by the owner= of GA_ASN_1.

So, the binding of "exclusive&q= uot; is on "definition of LC value->semantic mappings",
<= div>but is not exclusive in the use by sending or receiving ASNs.

All of this detail is stuff that will (I expect) end up in = the GROW document.

However, the IDR document needs= to have support in its definitions, for those nuances.

Simply weakening the definition to "SHOULD", IMHO places un= due restrictions on the intended
GROW document.

I have yet to see anyone give a single use case that requires "= ;SHOULD" rather than "MUST".

Brian<= /div>



--089e0122840a306869053fb5b349-- From nobody Tue Oct 25 12:48:02 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACAE129B35 for ; Tue, 25 Oct 2016 12:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 0M1r4BO_EVxl for ; Tue, 25 Oct 2016 12:47:59 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE7F129B31 for ; Tue, 25 Oct 2016 12:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10997; q=dns/txt; s=iport; t=1477424879; x=1478634479; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=RIJDDNxVUe91HkM/pwuttO67sn/pS9Zu8+IsZIgPizM=; b=JnkyqThSHdur8DVdDeH954ji3fmMzef0hvEZ96Hqpf8+C2InFgokMUUS 4Nae3SjBpSnI+PVnMiSmutZ9rFgf92X+NUP9RDWuq+/EI6VJjplQSWUzQ edxpvTvjXIbNFZdwUfHdkhcaJccNFgQBSEM9uvXXkerKYmd66qEPrQIc1 M=; X-Files: ATT00001.txt : 124 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAQBgtg9Y/4YNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnM8AQEBAQEdWH0HjS6Wfo8phRaCBxwBCoV6AoFzPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRiAQEBBAEBAWsXBAIBCAQNBAEBKAcCJQsUCQgCBAESCAYGiD8OwXQBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEOCQWGPYRVhBkRAYV7BZQ4hV4Bg0CBeXCJZoF1jhW?= =?us-ascii?q?HGYVvhAABHjZegxQcgVJyAYVjDRcHgQKBAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,399,1473120000"; d="txt'?scan'208,217";a="166679795" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Oct 2016 19:47:58 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u9PJlwUt015423 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Oct 2016 19:47:58 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Oct 2016 14:47:58 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Tue, 25 Oct 2016 14:47:58 -0500 From: "Jakob Heitz (jheitz)" To: David Freedman , "idr@ietf.org" , Jeff Haas Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-04.txt Thread-Index: AQHSLuBR7U5ooZIeUkC8tSq3UeWjJ6C5kdSg Date: Tue, 25 Oct 2016 19:47:57 +0000 Message-ID: <47bd6edaf74a40dfaa474eba7b043c5f@XCH-ALN-014.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.152.148] Content-Type: multipart/mixed; boundary="_002_47bd6edaf74a40dfaa474eba7b043c5fXCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 19:48:01 -0000 --_002_47bd6edaf74a40dfaa474eba7b043c5fXCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We added that as a result of Jeff Haas's email attached. It actually makes sense. However, if we want to keep parity with https://tools.ietf.org/html/rfc7606= #section-7.8 it's no big deal for me. Jeff? Thanks, Jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of David Freedman > Sent: Tuesday, October 25, 2016 9:54 AM > To: idr@ietf.org > Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-04.txt >=20 > Apologies for the ultra-late-last-minute input, but I was discussing this= with Job offlist and we felt it should be > seen by list participants. >=20 > My point was about RFC1997 parity and the length validation. >=20 > " A Large BGP Communities attribute with a length of zero MUST be ignore= d upon receipt and removed when sending." >=20 > Later wording here has been discussed to be amended (I understand) to: >=20 > " A Large BGP Communities attribute with a length of zero MUST NOT be sen= t and MUST be ignored upon receipt." >=20 > Well, I wanted to point out, that RFC1997 was of course updated by RFC760= 6. >=20 > In (7606), the following two comments are made: >=20 > " For all path attributes other than those specified as having an attribu= te length that may be zero, it SHALL be > considered a syntax error for the attribute to have a length of zero." >=20 > And >=20 > " The error handling of [RFC1997] is revised as follows: The Community at= tribute SHALL be considered malformed if > its length is not a non-zero multiple of 4" >=20 > So really, if you apply RFC7606 to RFC1997 you have lost parity if you ac= cept a zero length community (even if you > just ignore it). >=20 > My suggestion here is just to drop the passive receive tolerance of the z= ero length largecomm, since it seems out of > place (even if it is harmless). > and let it be considered malformed and handled by RFC7606. >=20 > Thoughts? >=20 > Dave. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --_002_47bd6edaf74a40dfaa474eba7b043c5fXCHALN014ciscocom_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Tue, 25 Oct 2016 19:47:57 GMT"; modification-date="Tue, 25 Oct 2016 19:47:57 GMT" Received: from xch-rtp-011.cisco.com (64.101.220.151) by xch-aln-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Mailbox Transport; Wed, 21 Sep 2016 16:04:52 -0500 Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Sep 2016 17:04:51 -0400 Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Sep 2016 17:04:50 -0400 Received: from rcdn-iport-5.cisco.com (173.37.86.76) by mail.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 21 Sep 2016 17:04:48 -0400 Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Sep 2016 21:04:44 +0000 Received: from alln-inbound-e.cisco.com (alln-inbound-e.cisco.com [173.37.147.235]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u8LL4ha3022417 (version=TLSv1/SSLv3 cipher=DHE-RSA-SEED-SHA bits=128 verify=OK); Wed, 21 Sep 2016 21:04:43 GMT Received: from mail.ietf.org ([4.31.198.44]) by alln-inbound-e.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2016 21:04:37 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D988112B808; Wed, 21 Sep 2016 14:04:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9999412B7E3 for ; Wed, 21 Sep 2016 14:04:33 -0700 (PDT) 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 HyheMGTucSqj for ; Wed, 21 Sep 2016 14:04:32 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3492E12B5EC for ; Wed, 21 Sep 2016 14:04:31 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 228C41E332; Wed, 21 Sep 2016 17:05:56 -0400 (EDT) From: Jeffrey Haas To: Randy Bush CC: Interminable Discussion Room Subject: Re: [Idr] draft-heitz-idr-large-community-04.txt Thread-Topic: [Idr] draft-heitz-idr-large-community-04.txt Thread-Index: AQHSFD2KaZY1VdNs80WQTrf+pOLbKaCErseAgAAKzQCAAAk/AA== Sender: Idr Date: Wed, 21 Sep 2016 21:04:30 +0000 Message-ID: <03F9D3CD-19FF-4D9A-A80E-6E32F17AAF86@pfrc.org> References: <20160921195245.GI1101@Vurt.local> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: Content-Language: en-US X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-AuthSource: XCH-RTP-004.cisco.com X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: received-spf: None (alln-inbound-e.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=4.31.198.44; receiver=alln-inbound-e.cisco.com; envelope-from="idr-bounces@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only Content-Type: multipart/mixed; boundary="_004_03F9D3CD19FF4D9AA80E6E32F17AAF86pfrcorg_" MIME-Version: 1.0 --_004_03F9D3CD19FF4D9AA80E6E32F17AAF86pfrcorg_ Content-Type: multipart/alternative; boundary="_000_03F9D3CD19FF4D9AA80E6E32F17AAF86pfrcorg_" --_000_03F9D3CD19FF4D9AA80E6E32F17AAF86pfrcorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sep 21, 2016, at 4:31 PM, Randy Bush > wrote: The attribute consists of a set of Large Communities. a bgp update may contain a large community attribute which is comp= osed of zero or more large communities. or one or more if you insist. ack. zero or one? 1 or more. Implementations may prune empty path attributes (and probably should) wh= en the contents are lists. However, I don't believe we should standardize = sending 0 of these communities as a form of signaling. That said, in the error handling section, it should note that a length o= f zero shall not be treated as a malformed route. -- Jeff --_000_03F9D3CD19FF4D9AA80E6E32F17AAF86pfrcorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 21, 2016, at 4:31 PM, Randy Bush <randy@psg.com> wrote:


The attribute consists of a set of Large Communities.

a bgp update may contain a large community attribute which is composed
of zero or more large communities.  or one or more if you insist.

ack.

zero or one?

1 or more.

Implementations may prune empty path attributes (and probab= ly should) when the contents are lists.  However, I don't believe we s= hould standardize sending 0 of these communities as a form of signaling.

That said, in the error handling section, it should note th= at a length of zero shall not be treated as a malformed route.

-- Jeff

--_000_03F9D3CD19FF4D9AA80E6E32F17AAF86pfrcorg_-- --_004_03F9D3CD19FF4D9AA80E6E32F17AAF86pfrcorg_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=124; creation-date="Wed, 21 Sep 2016 21:04:52 GMT"; modification-date="Wed, 21 Sep 2016 21:04:52 GMT" Content-ID: <55159C7B2734B641B3F55A8C92DDC2F6@emea.cisco.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWls aW5nIGxpc3QNCklkckBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZHINCg== --_004_03F9D3CD19FF4D9AA80E6E32F17AAF86pfrcorg_-- --_002_47bd6edaf74a40dfaa474eba7b043c5fXCHALN014ciscocom_-- From nobody Tue Oct 25 13:22:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B97B1299CD for ; Tue, 25 Oct 2016 13:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RdnNflCJg_gW for ; Tue, 25 Oct 2016 13:22:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F3BB21299BE for ; Tue, 25 Oct 2016 13:22:18 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E91251E337; Tue, 25 Oct 2016 16:24:38 -0400 (EDT) Date: Tue, 25 Oct 2016 16:24:38 -0400 From: Jeffrey Haas To: "Jakob Heitz (jheitz)" Message-ID: <20161025202438.GA23262@pfrc.org> References: <47bd6edaf74a40dfaa474eba7b043c5f@XCH-ALN-014.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47bd6edaf74a40dfaa474eba7b043c5f@XCH-ALN-014.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Jeff Haas , "idr@ietf.org" , David Freedman Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 20:22:20 -0000 Jakob, On Tue, Oct 25, 2016 at 07:47:57PM +0000, Jakob Heitz (jheitz) wrote: > We added that as a result of Jeff Haas's email attached. > > It actually makes sense. > However, if we want to keep parity with https://tools.ietf.org/html/rfc7606#section-7.8 > it's no big deal for me. > > Jeff? Dave's point on specs is, as usual, right on. And I think it's generally reasonable to default to 7606 behaviors. (Which would be one or more.) My disagreement is more a disagreement with 7606's zero-length behaviors with respect to (extended-)communities and the zero length behavior. In that spec, it's a syntax error to receive a length 0 attribute and, as such, you should treat-as-withdraw. However, that seems to contradict the general intent of the spec which is to do error handling behaviors better. Since 0 is semantically clear (no comms), stripping the attribute and continuing seems to be somewhat more graceful than treat-as-withdraw. That said, 7606 reflects WG consensus. It seems wise to keep parity with it. -- Jeff From nobody Tue Oct 25 15:27:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC961295F9 for ; Tue, 25 Oct 2016 15:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 7aq0l3qQyxO3 for ; Tue, 25 Oct 2016 15:27:19 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2604312942F for ; Tue, 25 Oct 2016 15:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12970; q=dns/txt; s=iport; t=1477434438; x=1478644038; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PB/4Xvb292LUuR/oXAC7tQLtFUAIgO3bGLHFPmWO2tc=; b=fJ4RNa1pIJvbu8SweHM9LOImp3KIVuj46FTHJqSC4UeDnwWwAWkHL86v 57LGDWJykBLlSUwLbuj/cpdUq83eCgEX2EDKmVc0OROQbMkBwpBU2fjHp Kmcgb0CuKSxqjanjbAr0oHYM1uDFgd/eDIrHfxopMWu8svDSa8IuaGxfv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwAQAv2w9Y/4kNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnM8AQEBAQEdWH0HjS+Wfo8phRaCByeFegKBdD8UAQIBAQEBAQEBYii?= =?us-ascii?q?EYgEBAQQtXAIBCA4DBAEBJAQHMhQJCAEBBAESCIhLDr9lAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBFwWGPYRVhCoBAVGFKQWIRWSLD4VeAZAPkAqNCIQAAR42XoNIgTp?= =?us-ascii?q?yAYVwgSCBAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,399,1473120000"; d="scan'208,217";a="163742751" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Oct 2016 22:27:18 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u9PMRIN3006139 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Oct 2016 22:27:18 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Oct 2016 17:27:17 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Tue, 25 Oct 2016 17:27:17 -0500 From: "Jakob Heitz (jheitz)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) Thread-Index: AdIt7WzqvhUzKEQ4QuObgT18xFaIJQBIJyAw Date: Tue, 25 Oct 2016 22:27:17 +0000 Message-ID: References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> In-Reply-To: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.152.148] Content-Type: multipart/alternative; boundary="_000_db7a17a288aa4a3288dc6ec8f032b687XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 22:27:20 -0000 --_000_db7a17a288aa4a3288dc6ec8f032b687XCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have discovered that Cisco has used BGP attribute code 31 for an internal experiment in certain NXOS routers, but unfortunately some of the code leaked into production. The code does not send the attribute, but it receives it incorrectly. We are creating patches for the faulty code, but cannot guarantee that all affected routers will be patched. Consequently, we request deprecation of attribute code 31 as well. I apologize on behalf of Cisco for the oversight. Thanks, Jakob. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, October 24, 2016 5:19 AM To: idr@ietf.org Subject: [Idr] BGP Attribute for Large communities (Attribute 30) was squat= ted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) IDR Working group: Thank you for your input on the question of whether Large communities shoul= d be reassigned another attribute number due to Huawei squatting on attribu= te 30. The WG consensus is that the IDR WG wishes to have IANA deprecate a= ttribute 30, and reassign large communities another attribute number for it= s early allocation. Alvaro should request a new attribute number for wide communities. If wide communities implementers request an early allocation, the WG consen= sus was unclear. Therefore, the code point of 129 is deprecated for now. = The full discussion on this point is at: https://www.ietf.org/mail-archive/web/idr/current/msg16556.html The following other attributes were seen in the wild with the comments we s= aw: # BGP function Reference ---- ----------------------------------------------- --------------- 20 Connector Attribute (deprecated) [RFC6037] 21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit, u= nknown] 30 (deprecated) [variant of draft= -ietf-tunnel-encaps, Huawei router] 129 (deprecated) [draft-ietf-idr-wi= de-bgp-communities, Huawei router] Attribute AS Attribute Observed ----------- -------------------------------- 20 AS 22742 (Peter Hessler) 21 AS 14706, AS 11720, AS 22490 https://www.ietf.org/mail-archive/web/idr/current/msg16583= .html 30 - in trials reported by Job 129 - self-reported by Huawei Sue Hares --_000_db7a17a288aa4a3288dc6ec8f032b687XCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have dis= covered that Cisco has used BGP attribute code 31

for an internal experiment in certain = NXOS routers,

but unfortunately some of the code lea= ked into production.

The code does not send the attribute,<= o:p>

but it receives it incorrectly. We are= creating patches for the

faulty code, but cannot guarantee that= all affected routers will

be patched. Consequently, we request d= eprecation of attribute

code 31 as well.

 

I apologize on behalf of Cisco for the= oversight.

 

Thanks,

Jakob.

 

From: Idr [mailto:idr-bounces@ietf.org] On= Behalf Of Susan Hares
Sent: Monday, October 24, 2016 5:19 AM
To: idr@ietf.org
Subject: [Idr] BGP Attribute for Large communities (Attribute 30) wa= s squatted on - Let's get a new attribute number (1 week WG call (10/18 to = 10/25)

 

IDR Working group:

 

Thank you for your input on the question of whether = Large communities should be reassigned another attribute number due to Huaw= ei squatting on attribute 30.  The WG consensus is that the IDR WG wis= hes to have IANA deprecate attribute 30, and reassign large communities another attribute number for its early allo= cation.    

 

Alvaro should request a new attribute number for wid= e communities.

 

If wide communities implementers request an early al= location, the WG consensus was unclear.  Therefore,  the code poi= nt of 129 is deprecated for now.  The full discussion on this point is= at:

 

https://www.ietf.org/mail-archive/web/idr/current/m= sg16556.html

 

The following other attributes were seen in the wild= with the comments we saw:

 

#        BGP func= tion            = ;            &n= bsp;            = ; Reference

----    -----------------------------= ------------------   ---------------

20     Connector Attribute (depr= ecated)   [RFC6037] 

21      AS_PATHLIMIT (depre= cated)           [draft-i= etf-idr-as-pathlimit, unknown]

30     (deprecated)  &= nbsp;           &nbs= p;            &= nbsp;           [variant = of draft-ietf-tunnel-encaps, Huawei router]

129   (deprecated)     = ;            &n= bsp;            = ;         [draft-ietf-idr-wide= -bgp-communities, Huawei router]

 

Attribute  AS Attribute Observed   &n= bsp;            = ;           

-----------   ----------------------------= ----

20        &n= bsp;  AS 22742  (Peter Hessler)      &nb= sp;            =      

21         &= nbsp; AS 14706, AS 11720, AS 22490

        &nbs= p;        https://www.ietf.org/mai= l-archive/web/idr/current/msg16583.html

 

30   -  in trials reported by Job

129 -  self-reported by Huawei

 

Sue Hares

--_000_db7a17a288aa4a3288dc6ec8f032b687XCHALN014ciscocom_-- From nobody Tue Oct 25 18:51:08 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8B41299F1 for ; Tue, 25 Oct 2016 18:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ix4-t11ufhgL for ; Tue, 25 Oct 2016 18:50:52 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B991299F0 for ; Tue, 25 Oct 2016 18:50:46 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id 23so15885520qtp.5 for ; Tue, 25 Oct 2016 18:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6UbYMmD9qdOLcW10lTED58Nth0WEC5pTYM2SUiwhkmk=; b=IxxLSaTTLv6W1utB7Jre7RdFBR+MzmFR6XXo4I8EQueqZg7X5fZ2YNYgbiL+1/Isq5 ACBVTVLGj1eTDIDkn/t6E+vVSaG5+TV04A1HYRLAbT4NUtEg7HRcTk3gSSaE+nrlWsis GP2B7pYn8wDHb8wFZeuUb9gdYkHf02xhTDV4pjjw/lvRPYExCPAFXPmnGf85g2XdUDY1 umOWMKjZwKDsAqfpStbqFRqxteURrXrSGx+MgZagI/bpD4R4zp6/HcknuJAQhk7+39Sl 7hlscPoxKPWcbkxgKcKELLgmnf0ggSlxmoegqXrDi69gHybIgNHLJK7txtwAwq0Bcmvz YrOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6UbYMmD9qdOLcW10lTED58Nth0WEC5pTYM2SUiwhkmk=; b=TIaHuLT3Lt2j46GVNSOeftcKQGszBN8U/BF73z8J2qUa+ZcAjQoNnXM7CikeAKk1Cj Va4hjsZ3mj9Iv7ZkmqRGTP9iqGiWmqyXZZXfjCrM4S3tIh1YwTCgATjL2UJnmOEqK40+ 8prrCvCW45DvYGekdRIXBQdRd3DfbP+JFCLqixKKy0RRwGtSldi5oqvu79Z8bsET1vD/ CSNX7AtGpzowP87goCkNiXE00feIrOyvTSFoykRbZZXRvxphfx1GWIcTl6wLZ/JPQYnS LslZbGKXlxXwKtdwwH78vSuLlCSMwwcav4Oujp1cZcwRZCMXjhn42mkLGjCmi9TiyKJ9 PHgg== X-Gm-Message-State: ABUngvdHrRFxVJ/V1K7nlUuM0uCYYwy1urQlUHGUFDJzfmtYx33DjxJOwoOIHOaD6DoCgPzZOOMAijbPQvsTuw== X-Received: by 10.237.38.68 with SMTP id z62mr22922208qtc.73.1477446645619; Tue, 25 Oct 2016 18:50:45 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.105.244 with HTTP; Tue, 25 Oct 2016 18:50:45 -0700 (PDT) In-Reply-To: References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> From: Christopher Morrow Date: Tue, 25 Oct 2016 21:50:45 -0400 X-Google-Sender-Auth: OrzuC0dumRAroF0AUfGmME174fU Message-ID: To: "Jakob Heitz (jheitz)" Content-Type: multipart/alternative; boundary=94eb2c12299c7ca2e9053fbadafa Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 01:50:56 -0000 --94eb2c12299c7ca2e9053fbadafa Content-Type: text/plain; charset=UTF-8 So, what's the downside to having IANA pick the next available (from the current list, prior to the 2 squatting incidents) value in cases like this? I think it's: "Some routers somewhere do bad things" (or sometimes cause other remote people to do 'bad things' .. where sometimes that other person is 'me') and when that happens: "some people quickly upgrade code to avoid the 'bad things'" (presuming that the code is available, I mean... and I do hope that vendors, all of them, are telling their DE folk: "Hey, don't do this, it's super painful...srsly!") Is that about it? Why don't we just go back to assigning the next available and deal with the problem(s) as they arise? -chris On Tue, Oct 25, 2016 at 6:27 PM, Jakob Heitz (jheitz) wrote: > I have discovered that Cisco has used BGP attribute code 31 > > for an internal experiment in certain NXOS routers, > > but unfortunately some of the code leaked into production. > > The code does not send the attribute, > > but it receives it incorrectly. We are creating patches for the > > faulty code, but cannot guarantee that all affected routers will > > be patched. Consequently, we request deprecation of attribute > > code 31 as well. > > > > I apologize on behalf of Cisco for the oversight. > > > > Thanks, > > Jakob. > > > > *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Susan Hares > *Sent:* Monday, October 24, 2016 5:19 AM > *To:* idr@ietf.org > *Subject:* [Idr] BGP Attribute for Large communities (Attribute 30) was > squatted on - Let's get a new attribute number (1 week WG call (10/18 to > 10/25) > > > > IDR Working group: > > > > Thank you for your input on the question of whether Large communities > should be reassigned another attribute number due to Huawei squatting on > attribute 30. The WG consensus is that the IDR WG wishes to have IANA > deprecate attribute 30, and reassign large communities another attribute > number for its early allocation. > > > > Alvaro should request a new attribute number for wide communities. > > > > If wide communities implementers request an early allocation, the WG > consensus was unclear. Therefore, the code point of 129 is deprecated for > now. The full discussion on this point is at: > > > > https://www.ietf.org/mail-archive/web/idr/current/msg16556.html > > > > The following other attributes were seen in the wild with the comments we > saw: > > > > # BGP function Reference > > ---- ----------------------------------------------- --------------- > > 20 Connector Attribute (deprecated) [RFC6037] > > 21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit, > unknown] > > 30 (deprecated) [variant of > draft-ietf-tunnel-encaps, Huawei router] > > 129 (deprecated) > [draft-ietf-idr-wide-bgp-communities, Huawei router] > > > > Attribute AS Attribute Observed > > ----------- -------------------------------- > > 20 AS 22742 (Peter Hessler) > > 21 AS 14706, AS 11720, AS 22490 > > https://www.ietf.org/mail-archive/web/idr/ > current/msg16583.html > > > > 30 - in trials reported by Job > > 129 - self-reported by Huawei > > > > Sue Hares > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --94eb2c12299c7ca2e9053fbadafa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, what's the downside to having IANA pick the next a= vailable (from the current list, prior to the 2 squatting incidents) value = in cases like this?

I think it's: "Some routers= somewhere do bad things"
=C2=A0 (or sometimes cause other r= emote people to do 'bad things' .. where sometimes that other perso= n is 'me')

and when that happens: "so= me people quickly upgrade code to avoid the 'bad things'"
(presuming that the code is available, I mean... and I do hope that v= endors, all of them, are telling their DE folk: "Hey, don't do thi= s, it's super painful...srsly!")

Is that = about it? Why don't we just go back to assigning the next available and= deal with the problem(s) as they arise?

-chris

On Tue, = Oct 25, 2016 at 6:27 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:

I have discovered that Cisco has used BGP attribute code 31<= /u>

for an internal experiment in certain = NXOS routers,

but unfortunately some of the code lea= ked into production.

The code does not send the attribute,<= u>

but it receives it incorrectly. We are= creating patches for the

faulty code, but cannot guarantee that= all affected routers will

be patched. Consequently, we request d= eprecation of attribute

code 31 as well.<= /p>

=C2=A0

I apologize on behalf of Cisco for the= oversight.

=C2=A0

Thanks,

Jakob.

=C2=A0

=C2=A0

IDR Working group:

=C2=A0

Thank you for your input on the question of whether = Large communities should be reassigned another attribute number due to Huaw= ei squatting on attribute 30.=C2=A0 The WG consensus is that the IDR WG wis= hes to have IANA deprecate attribute 30, and reassign large communities another attribute number for its early allo= cation. =C2=A0=C2=A0=C2=A0

=C2=A0

Alvaro should request a new attribute number for wid= e communities.

=C2=A0

If wide communities implementers request an early al= location, the WG consensus was unclear.=C2=A0 Therefore, =C2=A0the code poi= nt of 129 is deprecated for now.=C2=A0 The full discussion on this point is= at:

=C2=A0

https://www.ietf.org/mail-ar= chive/web/idr/current/msg16556.html

=C2=A0

The following other attributes were seen in the wild= with the comments we saw:

=C2=A0

#=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BGP func= tion=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Reference

----=C2=A0=C2=A0=C2=A0 -----------------------------= ------------------=C2=A0=C2=A0 ---------------

20=C2=A0=C2=A0=C2=A0=C2=A0 Connector Attribute (depr= ecated)=C2=A0 =C2=A0[RFC6037]=C2=A0

21=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0AS_PATHLIMIT (depre= cated)=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[draft-i= etf-idr-as-pathlimit, unknown]

30=C2=A0=C2=A0=C2=A0=C2=A0 (deprecated)=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[v= ariant of draft-ietf-tunnel-encaps, Huawei router]

129=C2=A0 =C2=A0(deprecated) =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[draft-ietf-i= dr-wide-bgp-communities, Huawei router]

=C2=A0

Attribute=C2=A0 AS Attribute Observed=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

-----------=C2=A0=C2=A0 ----------------------------= ----

20=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 AS 22742 =C2=A0(Peter Hessler) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

21 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0AS 14706, AS 11720, AS 22490

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https= ://www.ietf.org/mail-archive/web/idr/current/msg16583.html=

=C2=A0

30=C2=A0=C2=A0 -=C2=A0 in trials reported by Job =

129 -=C2=A0 self-reported by Huawei

=C2=A0

Sue Hares


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--94eb2c12299c7ca2e9053fbadafa-- From nobody Tue Oct 25 21:17:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED6B1293F0 for ; Tue, 25 Oct 2016 21:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 L4WebvNeBSfP for ; Tue, 25 Oct 2016 21:17:21 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 C6DEC129562 for ; Tue, 25 Oct 2016 21:17:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 634A2A2; Wed, 26 Oct 2016 06:17:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1477455438; bh=vjpSNxyrF+7dZJu5OHZOp8uHaIEWXLPTexp4XnNWGug=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=EDFPDayDrG8DtpZkp2NvjiKukjvrNSCzYRCKfCNFFBtgByJw1RzrsoY4Cz7b4YEz3 ker5hmpPXPA4Z/0lZ9s29W0P2JSClXPLBIx6wq9UtSyynWfb0ncu4Hxpx1xT7KcgPW F7O4InQ+nOsW8j7JrXsL1Ey3n5KymzjAZwkFGNMw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5BE2CA1; Wed, 26 Oct 2016 06:17:18 +0200 (CEST) Date: Wed, 26 Oct 2016 06:17:18 +0200 (CEST) From: Mikael Abrahamsson To: Christopher Morrow In-Reply-To: Message-ID: References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.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; charset=US-ASCII; format=flowed Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 04:17:23 -0000 On Tue, 25 Oct 2016, Christopher Morrow wrote: > Is that about it? Why don't we just go back to assigning the next > available and deal with the problem(s) as they arise? Unless you can find someone huge to start announcing prefixes with -large, there is little incentive for people to upgrade their code. So what you're proposed means thereis a "first mover disadvantage", just like it was in the beginning of DNSSEC and IPv6 deployment. If you have connectivity to an ISP, then that's that ISPs problem. If you have connectivity problems to hundreds of ISPs, then that's your problem. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Oct 25 21:49:46 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFD612950A for ; Tue, 25 Oct 2016 21:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 l9bo9ZklWYqb for ; Tue, 25 Oct 2016 21:49:43 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0581E12947A for ; Tue, 25 Oct 2016 21:49:43 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id i34so34289279qkh.6 for ; Tue, 25 Oct 2016 21:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZhbeI0UP2t9ZZafiGtLTW21PK9LTwzkj3aFtEHgp18c=; b=vcG9UWRQryPOsT6M8mL0g6jWNE8+y9KQ7x2arYQyCgysRJRXxl0uNkUpEFEcBd3Ddi gVp98JwAWGES4RHvRftB4c2AzOksUaG0Ppg0im+3TuKD5OgpSertrHjPS8i14hTKetbZ jd+QQuz12WLcncSi0G35d8R69UTph2u6QhWlXDOalMWxOkqU+hPEZNAXxijC7A0gYrp0 nyQ0jmdYZp1QMl4dJlIzcxsn4pQvj9gcxgTO1cEZKaROSfhxOnKxfK0fM28bt8/nuBeV A6VyTHxzoe2V0nQCb5UycE6NyIRfd0RRSXiOrSRr8F38JjAbyZXmturCN+TItedM9y3E MxUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZhbeI0UP2t9ZZafiGtLTW21PK9LTwzkj3aFtEHgp18c=; b=Du1kvwmj53Qo0q143RSsBJwlED8uo9F/lIdZqjCB7Cfyhcs3lmjvRPSBl6V96hJywO 6HLsZ4hnX6tRCQvRHpJsAvYh6vUGg0IdM9MuOtxZ+bTT3aNgjpw2Srg0VX5yaKOb53BK p8HZ9jEeNHg5JLmHFbzNr5jc58+se80jhiJwXnlCfgxOW2pQR0mGdru7pPmTsN40A5Uw CEDTgFSAxh5xYwjiXOxlQgXV+QuKWz/8e96nnd94pt1ZySnWJq8UCx4ilF2nUV8SWA4P j6FsPP4Yy7RgZkeKr6uhMad2j+nuG/k0xanbbhau/ZI2bSD348ZyAf7yyp5t8/6eREw4 WcJA== X-Gm-Message-State: ABUngvdaOX3/gjJ+eMX46/xiirHJ5YaeIfkDnb0Euqo8eaJNevwE1YOBRRBlGmFu3WzZ2jX96v64l/Wz8yNqKQ== X-Received: by 10.55.129.6 with SMTP id c6mr10089507qkd.4.1477457382131; Tue, 25 Oct 2016 21:49:42 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.105.244 with HTTP; Tue, 25 Oct 2016 21:49:41 -0700 (PDT) In-Reply-To: References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> From: Christopher Morrow Date: Wed, 26 Oct 2016 00:49:41 -0400 X-Google-Sender-Auth: gEW3dRt0zi0ES94UNI0oH-wim8g Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=94eb2c05cd806eced3053fbd5a99 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 04:49:45 -0000 --94eb2c05cd806eced3053fbd5a99 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 26, 2016 at 12:17 AM, Mikael Abrahamsson wrote: > On Tue, 25 Oct 2016, Christopher Morrow wrote: > > Is that about it? Why don't we just go back to assigning the next >> available and deal with the problem(s) as they arise? >> > > Unless you can find someone huge to start announcing prefixes with -large, > there is little incentive for people to upgrade their code. > > It sounded (to me) like there were folk at 2-3 large providers looking for this community configuration to be available 'now'. I figured once things hit standard/code/test&deploy we'd would have 2-3 large providers trying to offer this community mapping for their customer's uses. > So what you're proposed means thereis a "first mover disadvantage", just > like it was in the beginning of DNSSEC and IPv6 deployment. > > maybe? I suppose if the provider(s) start offering this option and you as a customer want to use it... you'll find out quickly: "Oops! I should upgrade" (which you'd have to do anyway to take advantage of this community mapping system.. at which point you'd also probably get away from the squat problem). > If you have connectivity to an ISP, then that's that ISPs problem. If you > have connectivity problems to hundreds of ISPs, then that's your problem. > > possibly, yes. > -- > Mikael Abrahamsson email: swmike@swm.pp.se > --94eb2c05cd806eced3053fbd5a99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 26, 2016 at 12:17 AM, Mikael Abrahamsson = <swmike@swm.pp.se<= /a>> wrote:
On= Tue, 25 Oct 2016, Christopher Morrow wrote:

Is that about it? Why don't we just go back to assigning the next avail= able and deal with the problem(s) as they arise?

 Unless you can find someone huge to start announcing prefixes with -large, = there is little incentive for people to upgrade their code.


It sounded (to me) like there were fol= k at 2-3 large providers looking for this community configuration to be ava= ilable 'now'. I figured once things hit standard/code/test&depl= oy we'd would have 2-3 large providers trying to offer this community m= apping for their customer's uses.
=C2=A0
So what you're proposed means thereis a "first mover disadvantage&= quot;, just like it was in the beginning of DNSSEC and IPv6 deployment.


maybe? I suppose if the provider(s) st= art offering this option and you as a customer want to use it... you'll= find out quickly: "Oops! I should upgrade" (which you'd have= to do anyway to take advantage of this community mapping system.. at which= point you'd also probably get away from the squat problem).
= =C2=A0
If you have connectivity to an ISP, then that's that ISPs problem. If y= ou have connectivity problems to hundreds of ISPs, then that's your pro= blem.


possibly, yes.
=C2=A0
--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

--94eb2c05cd806eced3053fbd5a99-- From nobody Tue Oct 25 21:49:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0105D12947A for ; Tue, 25 Oct 2016 21:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.332 X-Spam-Level: X-Spam-Status: No, score=-7.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Rk2SLbSSostW for ; Tue, 25 Oct 2016 21:49:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C0912945C for ; Tue, 25 Oct 2016 21:49:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bzG9m-0002cC-3U; Wed, 26 Oct 2016 04:49:42 +0000 Date: Wed, 26 Oct 2016 13:49:54 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 04:49:46 -0000 > Is that about it? Why don't we just go back to assigning the next > available and deal with the problem(s) as they arise? another reason i think this may be a prudent path is that squatting should not be condoned; the result would be entropic. randy From nobody Tue Oct 25 22:13:45 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A51129467 for ; Tue, 25 Oct 2016 22:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Zx7aFK-iNqqC for ; Tue, 25 Oct 2016 22:13:39 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C4F12952B for ; Tue, 25 Oct 2016 22:13:39 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id i34so34506555qkh.6 for ; Tue, 25 Oct 2016 22:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hu1z9ZSMn6z9vl3VHtJKfcerx1oHDik565klv7YnvVw=; b=Nyes2/I7dbA1sj6Fm3EMLzssT0s68I69LVBRfprWqJ5aOqbAsgWCIWn5LGLzJr3j1P PIr2wmykeJhlojsJuOrhnhtC8TG3pYuzdgr4MvdXoFQDPMlOHRVBFNImaJ1EXf6r/rQm ycQy3ya46uAujcT10CCO/nAkGy//OW4ausL/+/KkdPLyUevbHdsE3gENbaid3VrzSqnY tZiyMpWivFJ92DuJcAObrtcG1y0ndiOaCyiZqsJLBevTkxyxrHr0MBVphDOxu5m3+tg/ Vs8vWnDDLy6dsjXyb+GcTCe6+448WS0P/et+ZTBrZSNYb4NUTO4TteE4nkWKt1KK5ih3 jOPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hu1z9ZSMn6z9vl3VHtJKfcerx1oHDik565klv7YnvVw=; b=ZyiH23LA0AXF9k88I8yaYfe5IZW5/Wh3n6JJZ8nHKk6pImKF2dycT5aRP32YXYjlXF 9KDipJcyR/AD5/QGBTOEwJRGN/92hHWJfEbWSIlFZ1zviOSbTVEQkWwNwakwHFECQIuK rn8YwYvK+nF7WdfStGjO1KhuDZta/bBKaP/rkeI9byNEhwdsqtng9Yb4AM5lf/Jrsf80 zJ0E1d2e3ZzNp7ZKmq3yGGCOUIAY166oFpr3giqur1fRSu7YWIyL9WuJEdH+IYKmOgeh t3qs9Ptb7KZoyTc0L90Xh7cVeRgtP610BfxtP99RVgj9XRqPchQ9MSAEkjeQoY1K7R1L GPkg== X-Gm-Message-State: ABUngve9usdP5nd53+Tyb4Lyl954awhjQLfwoND0ltaQoM4cJLDxhj4Q1Z81IceEdusKsr6pSZ0QLmTA/0/1YA== X-Received: by 10.233.223.132 with SMTP id t126mr24988712qkf.107.1477458818230; Tue, 25 Oct 2016 22:13:38 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.105.244 with HTTP; Tue, 25 Oct 2016 22:13:37 -0700 (PDT) In-Reply-To: References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> From: Christopher Morrow Date: Wed, 26 Oct 2016 01:13:37 -0400 X-Google-Sender-Auth: ra3rcJ8ABKEJBAa0h0w8YOCAQsw Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=94eb2c043d2807f0f6053fbdb0b4 Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 05:13:40 -0000 --94eb2c043d2807f0f6053fbdb0b4 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 26, 2016 at 12:49 AM, Randy Bush wrote: > > Is that about it? Why don't we just go back to assigning the next > > available and deal with the problem(s) as they arise? > > another reason i think this may be a prudent path is that squatting > should not be condoned; the result would be entropic. > > this was my point, sorry for getting a bit lost along the way; "If we keep letting squatting be successful we're boned." --94eb2c043d2807f0f6053fbdb0b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 26, 2016 at 12:49 AM, Randy Bush <randy@psg.com>= wrote:
> Is that abo= ut it? Why don't we just go back to assigning the next
> available and deal with the problem(s) as they arise?

another reason i think this may be a prudent path is that squatting<= br> should not be condoned; the result would be entropic.

<= div>
this was my point, sorry for getting a bit lost along th= e way; "If we keep letting squatting be successful we're boned.&qu= ot; =C2=A0=C2=A0

--94eb2c043d2807f0f6053fbdb0b4-- From nobody Tue Oct 25 22:51:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517B812970A for ; Tue, 25 Oct 2016 22:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 7y-5uN4NWEzV for ; Tue, 25 Oct 2016 22:51:51 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C5D129621 for ; Tue, 25 Oct 2016 22:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15169; q=dns/txt; s=iport; t=1477461111; x=1478670711; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6hK+8rwLwbDBhAbXBZEGDlvABqD7MucceSCwdB4jb/A=; b=XmHGDrgvfEdwmcTsuG3WrYzI0i0d+tFynbCEpZOdsHzaBtnOktX+LE9E 4ptCpB7vI13e2zHn4vwU7/mUrfI9BK9Zu5ZHoKNBEHBo8AdKo/Le6zRo4 Awi1WyByZssup1O3BBj8WhCqKqhmkjEmMDHJFkPnCRTMcKDDIeNo5/tc0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzAQD5QxBY/5xdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnM3AQEBAQEdWH2NNZZ+h16HS4UWggccAQqEIYFaAoF3PxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRiAQEBBAEBAWsLEAIBCBEEAQEkBAchBgEKFAkIAQEEDgWHcEoDFw68G?= =?us-ascii?q?A2DcAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhj2BfYJYgkeBYwEBUYJ6gi8FiEV?= =?us-ascii?q?kiw+FKTUBjAE0RIMeggWNfohuhBqEAAEeNl6CXW+BOnIBhjyCKQEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,549,1473120000"; d="scan'208,217";a="338459597" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2016 05:51:50 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u9Q5poUj001192 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Oct 2016 05:51:50 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Oct 2016 00:51:44 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 26 Oct 2016 00:51:44 -0500 From: "Jakob Heitz (jheitz)" To: Christopher Morrow Thread-Topic: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) Thread-Index: AdIt7WzqvhUzKEQ4QuObgT18xFaIJQBIJyAwABHPSoD//++DIQ== Date: Wed, 26 Oct 2016 05:51:44 +0000 Message-ID: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_677CE346EFED42B68A9F75ABD2B4D6B4ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 05:51:54 -0000 --_000_677CE346EFED42B68A9F75ABD2B4D6B4ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Because then we wouldn't own up to it and innocents would suffer. We would hope we could fix as much of it as possible and hope the rest woul= dn't notice. Actually, the intended purpose of the NXOS line is for the data center, not= the Internet and we can very likely fix all of the deployed ones. However,= users have a right to deploy them wherever they want without notifying us = and they have the right not to apply patches, so I chose to own up to the p= roblem. Honest, we didn't mean it. Sorry. Thanks, Jakob. On Oct 25, 2016, at 6:50 PM, Christopher Morrow > wrote: So, what's the downside to having IANA pick the next available (from the cu= rrent list, prior to the 2 squatting incidents) value in cases like this? I think it's: "Some routers somewhere do bad things" (or sometimes cause other remote people to do 'bad things' .. where somet= imes that other person is 'me') and when that happens: "some people quickly upgrade code to avoid the 'bad = things'" (presuming that the code is available, I mean... and I do hope that vendors= , all of them, are telling their DE folk: "Hey, don't do this, it's super p= ainful...srsly!") Is that about it? Why don't we just go back to assigning the next available= and deal with the problem(s) as they arise? -chris On Tue, Oct 25, 2016 at 6:27 PM, Jakob Heitz (jheitz) > wrote: I have discovered that Cisco has used BGP attribute code 31 for an internal experiment in certain NXOS routers, but unfortunately some of the code leaked into production. The code does not send the attribute, but it receives it incorrectly. We are creating patches for the faulty code, but cannot guarantee that all affected routers will be patched. Consequently, we request deprecation of attribute code 31 as well. I apologize on behalf of Cisco for the oversight. Thanks, Jakob. From: Idr [mailto:idr-bounces@ietf.org] On Beh= alf Of Susan Hares Sent: Monday, October 24, 2016 5:19 AM To: idr@ietf.org Subject: [Idr] BGP Attribute for Large communities (Attribute 30) was squat= ted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) IDR Working group: Thank you for your input on the question of whether Large communities shoul= d be reassigned another attribute number due to Huawei squatting on attribu= te 30. The WG consensus is that the IDR WG wishes to have IANA deprecate a= ttribute 30, and reassign large communities another attribute number for it= s early allocation. Alvaro should request a new attribute number for wide communities. If wide communities implementers request an early allocation, the WG consen= sus was unclear. Therefore, the code point of 129 is deprecated for now. = The full discussion on this point is at: https://www.ietf.org/mail-archive/web/idr/current/msg16556.html The following other attributes were seen in the wild with the comments we s= aw: # BGP function Reference ---- ----------------------------------------------- --------------- 20 Connector Attribute (deprecated) [RFC6037] 21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit, u= nknown] 30 (deprecated) [variant of draft= -ietf-tunnel-encaps, Huawei router] 129 (deprecated) [draft-ietf-idr-wi= de-bgp-communities, Huawei router] Attribute AS Attribute Observed ----------- -------------------------------- 20 AS 22742 (Peter Hessler) 21 AS 14706, AS 11720, AS 22490 https://www.ietf.org/mail-archive/web/idr/current/msg16583= .html 30 - in trials reported by Job 129 - self-reported by Huawei Sue Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_677CE346EFED42B68A9F75ABD2B4D6B4ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Because then we wouldn't own up to it and innocents would suffer.
We would hope we could fix as much of it as = possible and hope the rest wouldn't notice.
Actually, the intended purpose of the NXOS l= ine is for the data center, not the Internet and we can very likely fix all= of the deployed ones. However, users have a right to deploy them wherever = they want without notifying us and they have the right not to apply patches, so I chose to own up to the prob= lem.
Honest, we didn't mean it. Sorry.

Thanks,
Jakob.


On Oct 25, 2016, at 6:50 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:

So, what's the downside to having IANA pick the next avail= able (from the current list, prior to the 2 squatting incidents) value in c= ases like this?

I think it's: "Some routers somewhere do bad things"
  (or sometimes cause other remote people to do 'bad things' .. w= here sometimes that other person is 'me')

and when that happens: "some people quickly upgrade code to avoid= the 'bad things'"
(presuming that the code is available, I mean... and I do hope that ve= ndors, all of them, are telling their DE folk: "Hey, don't do this, it= 's super painful...srsly!")

Is that about it? Why don't we just go back to assigning the next avai= lable and deal with the problem(s) as they arise?

-chris

On Tue, Oct 25, 2016 at 6:27 PM, Jakob Heitz (jh= eitz) <jheitz@cisco.com<= /a>> wrote:

I have discovered that Cisco has used BGP attribute code 31<= /u>

for an internal experiment in certain = NXOS routers,

but unfortunately some of the code lea= ked into production.

The code does not send the attribute,<= u>

but it receives it incorrectly. We are= creating patches for the

faulty code, but cannot guarantee that= all affected routers will

be patched. Consequently, we request d= eprecation of attribute

code 31 as well.<= /p>

 

I apologize on behalf of Cisco for the= oversight.

 

Thanks,

Jakob.

 

 

IDR Working group:

 

Thank you for your input on the question of whether = Large communities should be reassigned another attribute number due to Huaw= ei squatting on attribute 30.  The WG consensus is that the IDR WG wis= hes to have IANA deprecate attribute 30, and reassign large communities another attribute number for its early allo= cation.    

 

Alvaro should request a new attribute number for wid= e communities.

 

If wide communities implementers request an early al= location, the WG consensus was unclear.  Therefore,  the code poi= nt of 129 is deprecated for now.  The full discussion on this point is= at:

 

https://www.ietf.org/mail-ar= chive/web/idr/current/msg16556.html

 

The following other attributes were seen in the wild= with the comments we saw:

 

#        BGP func= tion            = ;           &nb= sp;            =   Reference

----    -----------------------------= ------------------   ---------------

20     Connector Attribute (depr= ecated)   [RFC6037] 

21      AS_PATHLIMIT (depre= cated)           [draft-i= etf-idr-as-pathlimit, unknown]

30     (deprecated)  &= nbsp;           &nbs= p;           &n= bsp;            [var= iant of draft-ietf-tunnel-encaps, Huawei router]

129   (deprecated)     = ;            &n= bsp;            = ;         [draft-ietf-idr= -wide-bgp-communities, Huawei router]

 

Attribute  AS Attribute Observed   &n= bsp;            = ;           <= u>

-----------   ----------------------------= ----

20        &n= bsp;  AS 22742  (Peter Hessler)      &nb= sp;            =      

21         &= nbsp; AS 14706, AS 11720, AS 22490

        &nbs= p;        https:= //www.ietf.org/mail-archive/web/idr/current/msg16583.html<= /u>

 

30   -  in trials reported by Job =

129 -  self-reported by Huawei

 

Sue Hares


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--_000_677CE346EFED42B68A9F75ABD2B4D6B4ciscocom_-- From nobody Wed Oct 26 00:43:44 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CD0129A33 for ; Wed, 26 Oct 2016 00:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XMu8j31anBwG for ; Wed, 26 Oct 2016 00:43:39 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9586F1299FC for ; Wed, 26 Oct 2016 00:43:39 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id n85so18684448pfi.1 for ; Wed, 26 Oct 2016 00:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-transfer-encoding:from:mime-version:date:message-id:subject :references:in-reply-to:to:cc; bh=t5i9X/zAXcV+ELOr6lvQzECpiWo3BiQShwYRoFG0rFQ=; b=XnjJfhBKTY5WnHedG0seSGEwtEOasGl02/TN/Suu5BzZXXy94hod0k0Ko7XYnlnFsw rmO6IrbSVUzuUv5T5psjXHBsK74+qW39VCFIaGk8zl3upgZu1D56sSZDHK+g+S2FTcJw zzwrY5TVi5VYqmdLPzh3sEGsI0HyQdsunIeZ3N1HMVArHgGXJ6aIrds/M8ggztJbjRna E+2SXGk7x6j+SEfnHO9wBkcVd67efQX9tw/uXa0gZBfkSvpl3b2bD1y8cjvOjC7wg3t0 RxjsGuuZE/R1pnaPaZqWgpZqX4XYQXXEI/0xB0+gI2RbGpvqBMdHgmhlngHPlO2lTNoF DYTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :message-id:subject:references:in-reply-to:to:cc; bh=t5i9X/zAXcV+ELOr6lvQzECpiWo3BiQShwYRoFG0rFQ=; b=f8QQGAOmplgKENEhzJ3Nw5Pn+Qml/I7iO/d0HMijhBjglJdB610nULO2FjYoJGXP/a 8XSKXwTHWdeb8UlLQIXLFay5Ng2J1FSWo8gQo+3IPFTWzcU3tmxUbanVSK/nM8ZHlADP 4CYc4PqmeXdxXWYyu99wiO+0Ohvk7lECMzzhftbZMZmdYWUhcIx6JQ8ecvH5pQMQP/kY BACMD5etMp0sSXJp47BRIIY7qTgbn5ruIyMgMeleaONjXlLGnEfmzbJZQl9gjbYWK/Gx bVcROylzu1U1xvTqgvWem5Hl0gCLoSBqb0cPACIdKelOL/09vI/q0LMSI7mwqBHGeN2h IdKg== X-Gm-Message-State: ABUngvdMPd9U2BYZGPphT8W5eiHfihqaiEEFgayS7hGkxgKJwum3ivYBDU0PXZT5L2Wweg== X-Received: by 10.99.123.90 with SMTP id k26mr1368166pgn.153.1477467819162; Wed, 26 Oct 2016 00:43:39 -0700 (PDT) Received: from ?IPv6:2601:646:9100:5d70:6010:468d:d73b:d62b? ([2601:646:9100:5d70:6010:468d:d73b:d62b]) by smtp.gmail.com with ESMTPSA id q23sm1853057pfg.95.2016.10.26.00.43.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 26 Oct 2016 00:43:37 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-121CC894-7EC4-4EFB-AA82-8DD63C392B33 Content-Transfer-Encoding: 7bit From: Brian Dickson Mime-Version: 1.0 (1.0) Date: Wed, 26 Oct 2016 00:43:23 -0700 Message-Id: References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> In-Reply-To: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: iPhone Mail (14A456) Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 07:43:43 -0000 --Apple-Mail-121CC894-7EC4-4EFB-AA82-8DD63C392B33 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Rather than deprecate the two sequential values, why not reserve a small ran= ge which includes those values, for non-permanent reservations for vendor de= velopment use? Say 30-35 inclusive? A fixed range would be not much worse in terms of consumed code points than a= few more squatting incidents. However, it would allow defensive coding agai= nst known bad code points. The idea of temporary reservations by vendors (e.g. For 6 month intervals) w= ould allow easier identification of vendors that leak their test stuff. It w= ould encourage vendors to use the range set aside. And the temporary nature w= ould make deliberate squatting inside that range a doomed effort. Easing the rules for reservations would help the squatting issue generally. T= he easier it is to reserve , the harder it would be to justify squatting. Maybe have another small range for no-reservations use, with no guarantee of= global uniqueness? Maybe re-purpose 129-130 for that? Those code points are already toast, this would give them an alternative use= .=20 Thoughts? Brian Sent from my iPhone > On Oct 25, 2016, at 10:51 PM, Jakob Heitz (jheitz) wrot= e: >=20 > Because then we wouldn't own up to it and innocents would suffer. > We would hope we could fix as much of it as possible and hope the rest wou= ldn't notice. > Actually, the intended purpose of the NXOS line is for the data center, no= t the Internet and we can very likely fix all of the deployed ones. However,= users have a right to deploy them wherever they want without notifying us a= nd they have the right not to apply patches, so I chose to own up to the pro= blem. > Honest, we didn't mean it. Sorry. >=20 > Thanks, > Jakob. >=20 >=20 > On Oct 25, 2016, at 6:50 PM, Christopher Morrow w= rote: >=20 >> So, what's the downside to having IANA pick the next available (from the c= urrent list, prior to the 2 squatting incidents) value in cases like this? >>=20 >> I think it's: "Some routers somewhere do bad things" >> (or sometimes cause other remote people to do 'bad things' .. where som= etimes that other person is 'me') >>=20 >> and when that happens: "some people quickly upgrade code to avoid the 'ba= d things'" >> (presuming that the code is available, I mean... and I do hope that vendo= rs, all of them, are telling their DE folk: "Hey, don't do this, it's super p= ainful...srsly!") >>=20 >> Is that about it? Why don't we just go back to assigning the next availab= le and deal with the problem(s) as they arise? >>=20 >> -chris >>=20 >>> On Tue, Oct 25, 2016 at 6:27 PM, Jakob Heitz (jheitz) = wrote: >>> I have discovered that Cisco has used BGP attribute code 31 >>>=20 >>> for an internal experiment in certain NXOS routers, >>>=20 >>> but unfortunately some of the code leaked into production. >>>=20 >>> The code does not send the attribute, >>>=20 >>> but it receives it incorrectly. We are creating patches for the >>>=20 >>> faulty code, but cannot guarantee that all affected routers will >>>=20 >>> be patched. Consequently, we request deprecation of attribute >>>=20 >>> code 31 as well. >>>=20 >>> =20 >>>=20 >>> I apologize on behalf of Cisco for the oversight. >>>=20 >>> =20 >>>=20 >>> Thanks, >>>=20 >>> Jakob. >>>=20 >>> =20 >>>=20 >>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares >>> Sent: Monday, October 24, 2016 5:19 AM >>> To: idr@ietf.org >>> Subject: [Idr] BGP Attribute for Large communities (Attribute 30) was sq= uatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25= ) >>>=20 >>> =20 >>>=20 >>> IDR Working group: >>>=20 >>> =20 >>>=20 >>> Thank you for your input on the question of whether Large communities sh= ould be reassigned another attribute number due to Huawei squatting on attri= bute 30. The WG consensus is that the IDR WG wishes to have IANA deprecate a= ttribute 30, and reassign large communities another attribute number for its= early allocation. =20 >>>=20 >>> =20 >>>=20 >>> Alvaro should request a new attribute number for wide communities. >>>=20 >>> =20 >>>=20 >>> If wide communities implementers request an early allocation, the WG con= sensus was unclear. Therefore, the code point of 129 is deprecated for now= . The full discussion on this point is at: >>>=20 >>> =20 >>>=20 >>> https://www.ietf.org/mail-archive/web/idr/current/msg16556.html >>>=20 >>> =20 >>>=20 >>> The following other attributes were seen in the wild with the comments w= e saw: >>>=20 >>> =20 >>>=20 >>> # BGP function Reference >>>=20 >>> ---- ----------------------------------------------- --------------= - >>>=20 >>> 20 Connector Attribute (deprecated) [RFC6037]=20 >>>=20 >>> 21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit= , unknown] >>>=20 >>> 30 (deprecated) [variant of dr= aft-ietf-tunnel-encaps, Huawei router] >>>=20 >>> 129 (deprecated) [draft-ietf-idr= -wide-bgp-communities, Huawei router] >>>=20 >>> =20 >>>=20 >>> Attribute AS Attribute Observed =20 >>>=20 >>> ----------- -------------------------------- >>>=20 >>> 20 AS 22742 (Peter Hessler) =20 >>>=20 >>> 21 AS 14706, AS 11720, AS 22490 >>>=20 >>> https://www.ietf.org/mail-archive/web/idr/current/msg16= 583.html >>>=20 >>> =20 >>>=20 >>> 30 - in trials reported by Job >>>=20 >>> 129 - self-reported by Huawei >>>=20 >>> =20 >>>=20 >>> Sue Hares >>>=20 >>>=20 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail-121CC894-7EC4-4EFB-AA82-8DD63C392B33 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Rather than deprecate the two sequential values, why not reserve= a small range which includes those values, for non-permanent reservations f= or vendor development use? Say 30-35 inclusive?

A f= ixed range would be not much worse in terms of consumed code points than a f= ew more squatting incidents. However, it would allow defensive coding agains= t known bad code points.

The idea of temporary reservations by vendors (e.g.= For 6 month intervals) would allow easier identification of vendors that le= ak their test stuff. It would encourage vendors to use the range set aside. A= nd the temporary nature would make deliberate squatting inside that range a d= oomed effort.

Easing the rules for reservations would help the squatting is= sue generally. The easier it is to reserve , the harder it would be to justi= fy squatting.

Maybe have another small range for no-reservations use, with n= o guarantee of global uniqueness? Maybe re-purpose 129-130 for that?

Those c= ode points are already toast, this would give them an alternative use. =

Thoughts?

Brian

Sent from my iPhone

On Oct 25, 2016,= at 10:51 PM, Jakob Heitz (jheitz) <j= heitz@cisco.com> wrote:

=
Because then we wouldn't own up to it and innocents would suffer.
=
We would hope we could fix as much of it as p= ossible and hope the rest wouldn't notice.
Actually, the intended purpose of the NXOS li= ne is for the data center, not the Internet and we can very likely fix all o= f the deployed ones. However, users have a right to deploy them wherever the= y want without notifying us and they have the right not to apply patches, so I chose to own up to the probl= em.
Honest, we didn't mean it. Sorry.

Thanks,
Jakob.


On Oct 25, 2016, at 6:50 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:

So, what's the downside to having IANA pick the next availa= ble (from the current list, prior to the 2 squatting incidents) value in cas= es like this?

I think it's: "Some routers somewhere do bad things"
  (or sometimes cause other remote people to do 'bad things' .. wh= ere sometimes that other person is 'me')

and when that happens: "some people quickly upgrade code to avoid the '= bad things'"
(presuming that the code is available, I mean... and I do hope that ven= dors, all of them, are telling their DE folk: "Hey, don't do this, it's supe= r painful...srsly!")

Is that about it? Why don't we just go back to assigning the next avail= able and deal with the problem(s) as they arise?

-chris

On Tue, Oct 25, 2016 at 6:27 PM, Jakob Heitz (jhe= itz) <jheitz@cisco.com> wrote:

I have discovered that Cisco has used BGP attribute code 31=

for an internal experiment in certain NX= OS routers,

but unfortunately some of the code leake= d into production.

The code does not send the attribute,=

but it receives it incorrectly. We are c= reating patches for the

faulty code, but cannot guarantee that a= ll affected routers will

be patched. Consequently, we request dep= recation of attribute

code 31 as well.

 

I apologize on behalf of Cisco for the o= versight.

 

Thanks,

Jakob.

 

 

IDR Working group:

 

Thank you for your input on the question of whether L= arge communities should be reassigned another attribute number due to Huawei= squatting on attribute 30.  The WG consensus is that the IDR WG wishes= to have IANA deprecate attribute 30, and reassign large communities another attribute number for its early alloc= ation.    

 

Alvaro should request a new attribute number for wide= communities.

 

If wide communities implementers request an early all= ocation, the WG consensus was unclear.  Therefore,  the code point= of 129 is deprecated for now.  The full discussion on this point is at= :

 

https://www.ietf.org/mail-arch= ive/web/idr/current/msg16556.html

 

The following other attributes were seen in the wild w= ith the comments we saw:

 

#        BGP funct= ion            &= nbsp;           =             &nbs= p; Reference

----    ------------------------------= -----------------   ---------------

20     Connector Attribute (depre= cated)   [RFC6037] 

21      AS_PATHLIMIT (deprec= ated)           [draft-iet= f-idr-as-pathlimit, unknown]

30     (deprecated)  &n= bsp;            =             = ;            [variant= of draft-ietf-tunnel-encaps, Huawei router]

129   (deprecated)     =             &nbs= p;            &n= bsp;        [draft-ietf-idr-wid= e-bgp-communities, Huawei router]

 

Attribute  AS Attribute Observed   &nb= sp;            &= nbsp;          <= /u>

-----------   -----------------------------= ---

20        &nb= sp;  AS 22742  (Peter Hessler)       = ;            &nb= sp;    

21         &n= bsp; AS 14706, AS 11720, AS 22490

         = ;        https://w= ww.ietf.org/mail-archive/web/idr/current/msg16583.html<= u>

 

30   -  in trials reported by Job <= /u>

129 -  self-reported by Huawei

 

Sue Hares


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


____________________= ___________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/lis= tinfo/idr
= --Apple-Mail-121CC894-7EC4-4EFB-AA82-8DD63C392B33-- From nobody Wed Oct 26 06:38:41 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A401F12952D for ; Wed, 26 Oct 2016 06:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5sbUguMPcD2Z for ; Wed, 26 Oct 2016 06:38:37 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7A7F1293E1 for ; Wed, 26 Oct 2016 06:38:36 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id w69so6539002qka.4 for ; Wed, 26 Oct 2016 06:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SQ36X7xuAvUWIXVr/Lex+0FRCEPq5riPnD1jgyMgExc=; b=fTv5mTPdCh38QkJrh6f2GopClWs4UPNBlStogqQGRun/yvxNx2l8Ojq+4CLz7RoBus BFg8tUOY2Yb1Ep4BkbCmFmoF0C2rlAcJHscjtC9AuPDxRt19tNFx142Sp4btWJBFfKGR CqjbKS5OQwjPPXjEMsofXLXB++ZyiAXUEO8zfVzLkwSbgO743c0Sofz1cvR0+nZaOekw 3X6Fw7lBBLU2BYQmF725jFZEM6ufqjsOrXfI+mCgRt7lHSWcYazzc7/Py7xg+SVnymKo yspGhqhT4cfeb5P0hpf0O0ZmbOpVcAegLMxbNr3vG+TD2V1OdiW7u5fk7boTqsphYMrp LckQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SQ36X7xuAvUWIXVr/Lex+0FRCEPq5riPnD1jgyMgExc=; b=i+KXD8EvSKtTcxKScnDjnFWLlrBmV8y8N4RAisNnd2oWn/EO6YYPRLK6rrmYslObcQ dHoenlBPZ0RqQzwC17xQjrXaJ8wHFLnkB61x8znkyC2nuUM9HAksHMXD6ftU1upSUwDB udA71HiywDVoqtnTYcBlIbJ3TbLGIpzY4GewewFF+fan+hARUfS/JtnTjp0dRQjzbY7N D+FRD2U72vJUKYR6vytdEGyEoKvbaYebU6zRNse0t0x279JSUkUUWQ1hkKMXkoQdbeuX iIbXmEcx3Q3mhkxyPsx3aPiRw8e5miaeuKSbuT4aDUoBVYLurIJudxFw6YBfKf7PIdLO VpTw== X-Gm-Message-State: ABUngvdbmNpRNVFO/TRbIH8rcvZX5e7vqLYVhvOqMCuQtRYjudES5a519EM6Y7dYD2pwY95DVXZU1evBXJuNpw== X-Received: by 10.55.7.210 with SMTP id 201mr1916901qkh.228.1477489115962; Wed, 26 Oct 2016 06:38:35 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.105.244 with HTTP; Wed, 26 Oct 2016 06:38:35 -0700 (PDT) In-Reply-To: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> From: Christopher Morrow Date: Wed, 26 Oct 2016 09:38:35 -0400 X-Google-Sender-Auth: HIigE1rbs5HjkGZVu4Rcmy85aXs Message-ID: To: "Jakob Heitz (jheitz)" Content-Type: multipart/alternative; boundary=001a11488caeeac10a053fc4bdb6 Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 13:38:39 -0000 --001a11488caeeac10a053fc4bdb6 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 26, 2016 at 1:51 AM, Jakob Heitz (jheitz) wrote: > Because then we wouldn't own up to it and innocents would suffer. > I totally agree that owning up is good here. I imagine that when other squatted values are discovered either in the field or in tests the same: "oops!" email/etc will happen... but I don't want us to end up just excluding forever the squatted attributes/value/numbers, that'll be super painful in very short order. > We would hope we could fix as much of it as possible and hope the rest > wouldn't notice. > Actually, the intended purpose of the NXOS line is for the data center, > not the Internet and we can very likely fix all of the deployed ones. > However, users have a right to deploy them wherever they want without > notifying us and they have the right not to apply patches, so I chose to > own up to the problem. > yup, I think it's nice to see folk stand up and say: "DOH! we screwed up, sorry! we're now making our best effort to fix this, too." thanks! > Honest, we didn't mean it. Sorry. > > Thanks, > Jakob. > > > On Oct 25, 2016, at 6:50 PM, Christopher Morrow > wrote: > > So, what's the downside to having IANA pick the next available (from the > current list, prior to the 2 squatting incidents) value in cases like this? > > I think it's: "Some routers somewhere do bad things" > (or sometimes cause other remote people to do 'bad things' .. where > sometimes that other person is 'me') > > and when that happens: "some people quickly upgrade code to avoid the 'bad > things'" > (presuming that the code is available, I mean... and I do hope that > vendors, all of them, are telling their DE folk: "Hey, don't do this, it's > super painful...srsly!") > > Is that about it? Why don't we just go back to assigning the next > available and deal with the problem(s) as they arise? > > -chris > > On Tue, Oct 25, 2016 at 6:27 PM, Jakob Heitz (jheitz) > wrote: > >> I have discovered that Cisco has used BGP attribute code 31 >> >> for an internal experiment in certain NXOS routers, >> >> but unfortunately some of the code leaked into production. >> >> The code does not send the attribute, >> >> but it receives it incorrectly. We are creating patches for the >> >> faulty code, but cannot guarantee that all affected routers will >> >> be patched. Consequently, we request deprecation of attribute >> >> code 31 as well. >> >> >> >> I apologize on behalf of Cisco for the oversight. >> >> >> >> Thanks, >> >> Jakob. >> >> >> >> *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Susan Hares >> *Sent:* Monday, October 24, 2016 5:19 AM >> *To:* idr@ietf.org >> *Subject:* [Idr] BGP Attribute for Large communities (Attribute 30) was >> squatted on - Let's get a new attribute number (1 week WG call (10/18 to >> 10/25) >> >> >> >> IDR Working group: >> >> >> >> Thank you for your input on the question of whether Large communities >> should be reassigned another attribute number due to Huawei squatting on >> attribute 30. The WG consensus is that the IDR WG wishes to have IANA >> deprecate attribute 30, and reassign large communities another attribute >> number for its early allocation. >> >> >> >> Alvaro should request a new attribute number for wide communities. >> >> >> >> If wide communities implementers request an early allocation, the WG >> consensus was unclear. Therefore, the code point of 129 is deprecated for >> now. The full discussion on this point is at: >> >> >> >> https://www.ietf.org/mail-archive/web/idr/current/msg16556.html >> >> >> >> The following other attributes were seen in the wild with the comments we >> saw: >> >> >> >> # BGP function Reference >> >> ---- ----------------------------------------------- --------------- >> >> 20 Connector Attribute (deprecated) [RFC6037] >> >> 21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit, >> unknown] >> >> 30 (deprecated) [variant of >> draft-ietf-tunnel-encaps, Huawei router] >> >> 129 (deprecated) >> [draft-ietf-idr-wide-bgp-communities, Huawei router] >> >> >> >> Attribute AS Attribute Observed >> >> ----------- -------------------------------- >> >> 20 AS 22742 (Peter Hessler) >> >> 21 AS 14706, AS 11720, AS 22490 >> >> https://www.ietf.org/mail-archive/web/idr/c >> urrent/msg16583.html >> >> >> >> 30 - in trials reported by Job >> >> 129 - self-reported by Huawei >> >> >> >> Sue Hares >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> > --001a11488caeeac10a053fc4bdb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 26, 2016 at 1:51 AM, Jakob Heitz (jheitz) <jheitz@cisco.com= > wrote:
Because then we wouldn't own up to it and innocents would suffer.<= /div>

I totally agree that owning up = is good here.
I imagine that when other squatted values are disco= vered either in the field or in tests the same: "oops!" email/etc= will happen... but I don't want us to end up just excluding forever th= e squatted attributes/value/numbers, that'll be super painful in very s= hort order.
=C2=A0
We would hope we could = fix as much of it as possible and hope the rest wouldn't notice.
Actually, the intended = purpose of the NXOS line is for the data center, not the Internet and we ca= n very likely fix all of the deployed ones. However, users have a right to = deploy them wherever they want without notifying us and they have the right not to apply patches, so I chose to own up to the prob= lem.

yup, I think it's nice= to see folk stand up and say: "DOH! we screwed up, sorry! we're n= ow making our best effort to fix this, too." thanks!
=C2=A0<= /div>
Honest, we didn't m= ean it. Sorry.

Thanks,
Jakob.


On Oct 25, 2016, at 6:50 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote= :

So, what's the downside to having IANA pick the next a= vailable (from the current list, prior to the 2 squatting incidents) value = in cases like this?

I think it's: "Some routers somewhere do bad things"
=C2=A0 (or sometimes cause other remote people to do 'bad things&#= 39; .. where sometimes that other person is 'me')

and when that happens: "some people quickly upgrade code to avoid= the 'bad things'"
(presuming that the code is available, I mean... and I do hope that ve= ndors, all of them, are telling their DE folk: "Hey, don't do this= , it's super painful...srsly!")

Is that about it? Why don't we just go back to assigning the next = available and deal with the problem(s) as they arise?

-chris

On Tue, Oct 25, 2016 at 6:27 PM, Jakob Heitz (jh= eitz) <jheitz@cisco.com<= /a>> wrote:

I have discovered that Cisco has used BGP= attribute code 31

for an internal experiment in certain = NXOS routers,

but unfortunately some of the code lea= ked into production.

The code does not send the attribute,<= u>

but it receives it incorrectly. We are= creating patches for the

faulty code, but cannot guarantee that= all affected routers will

be patched. Consequently, we request d= eprecation of attribute

code 31 as well.<= /p>

=C2=A0

I apologize on behalf of Cisco for the= oversight.

=C2=A0

Thanks,

Jakob.

=C2=A0

=C2=A0

IDR Working group:

=C2=A0

Thank you for your input on the question of whether = Large communities should be reassigned another attribute number due to Huaw= ei squatting on attribute 30.=C2=A0 The WG consensus is that the IDR WG wis= hes to have IANA deprecate attribute 30, and reassign large communities another attribute number for its early allo= cation. =C2=A0=C2=A0=C2=A0

=C2=A0

Alvaro should request a new attribute number for wid= e communities.

=C2=A0

If wide communities implementers request an early al= location, the WG consensus was unclear.=C2=A0 Therefore, =C2=A0the code poi= nt of 129 is deprecated for now.=C2=A0 The full discussion on this point is= at:

=C2=A0

https://www.ietf.org/mail-archive/web/idr/current/msg16556.html

=C2=A0

The following other attributes were seen in the wild= with the comments we saw:

=C2=A0

#=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BGP func= tion=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Reference

----=C2=A0=C2=A0=C2=A0 -----------------------------= ------------------=C2=A0=C2=A0 ---------------

20=C2=A0=C2=A0=C2=A0=C2=A0 Connector Attribute (depr= ecated)=C2=A0 =C2=A0[RFC6037]=C2=A0

21=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0AS_PATHLIMIT (depre= cated)=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[draft-i= etf-idr-as-pathlimit, unknown]

30=C2=A0=C2=A0=C2=A0=C2=A0 (deprecated)=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[v= ariant of draft-ietf-tunnel-encaps, Huawei router]

129=C2=A0 =C2=A0(deprecated) =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[draft-ietf-i= dr-wide-bgp-communities, Huawei router]

=C2=A0

Attribute=C2=A0 AS Attribute Observed=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

-----------=C2=A0=C2=A0 ----------------------------= ----

20=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 AS 22742 =C2=A0(Peter Hessler) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

21 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0AS 14706, AS 11720, AS 22490

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https= ://www.ietf.org/mail-archive/web/idr/current/msg16583.html=

=C2=A0

30=C2=A0=C2=A0 -=C2=A0 in trials reported by Job =

129 -=C2=A0 self-reported by Huawei

=C2=A0

Sue Hares


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr



--001a11488caeeac10a053fc4bdb6-- From nobody Wed Oct 26 08:48:05 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C021296A6 for ; Wed, 26 Oct 2016 08:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 jSiz1DEg7fZr for ; Wed, 26 Oct 2016 08:48:03 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 A48641294EE for ; Wed, 26 Oct 2016 08:48:01 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bzQQp-0000bp-ET (job@us.ntt.net); Wed, 26 Oct 2016 15:48:00 +0000 Date: Wed, 26 Oct 2016 17:47:56 +0200 From: Job Snijders To: Jeffrey Haas Message-ID: <20161026154756.GD1074@Vurt.local> References: <47bd6edaf74a40dfaa474eba7b043c5f@XCH-ALN-014.cisco.com> <20161025202438.GA23262@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161025202438.GA23262@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: Jeff Haas , "idr@ietf.org" , David Freedman Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 15:48:04 -0000 On Tue, Oct 25, 2016 at 04:24:38PM -0400, Jeffrey Haas wrote: > On Tue, Oct 25, 2016 at 07:47:57PM +0000, Jakob Heitz (jheitz) wrote: > > We added that as a result of Jeff Haas's email attached. > > > > It actually makes sense. > > However, if we want to keep parity with https://tools.ietf.org/html/rfc7606#section-7.8 > > it's no big deal for me. > > > > Jeff? > > Dave's point on specs is, as usual, right on. And I think it's generally > reasonable to default to 7606 behaviors. (Which would be one or more.) > > My disagreement is more a disagreement with 7606's zero-length behaviors > with respect to (extended-)communities and the zero length behavior. In > that spec, it's a syntax error to receive a length 0 attribute and, as such, > you should treat-as-withdraw. > > However, that seems to contradict the general intent of the spec which is to > do error handling behaviors better. Since 0 is semantically clear (no > comms), stripping the attribute and continuing seems to be somewhat more > graceful than treat-as-withdraw. > > That said, 7606 reflects WG consensus. It seems wise to keep parity with > it. Thank you gentlemen, I've removed the sentence from the document. Kind regards, Job From nobody Wed Oct 26 09:57:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9726129BE0 for ; Wed, 26 Oct 2016 09:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ubuKsfLxCkOb for ; Wed, 26 Oct 2016 09:57:11 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B23129BDE for ; Wed, 26 Oct 2016 09:57:10 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 9203F58BFC; Wed, 26 Oct 2016 16:57:10 +0000 (UTC) Date: Wed, 26 Oct 2016 16:57:10 +0000 From: heasley To: Brian Dickson Message-ID: <20161026165710.GC58742@shrubbery.net> References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 16:57:12 -0000 Wed, Oct 26, 2016 at 12:43:23AM -0700, Brian Dickson: > Rather than deprecate the two sequential values, why not reserve a small range which includes those values, for non-permanent reservations for vendor development use? Say 30-35 inclusive? isnt this bgp path attribute 255? From nobody Wed Oct 26 10:08:35 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4752129721 for ; Wed, 26 Oct 2016 10:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 12L9ar2soeuZ for ; Wed, 26 Oct 2016 10:08:31 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F90129580 for ; Wed, 26 Oct 2016 10:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=850; q=dns/txt; s=iport; t=1477501710; x=1478711310; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WiqmgiepxDCMoELRo9GYkQ1C8ldrddQ2ROtTtv6nqGo=; b=hUL4E8R1byyLzYQWCZqAcg6qAoF5ZKnhno73nVi+S4KpfoMJ3lyEFrhp EjV9OWShl54UB8eZ527r2k8tKP7XhGA5kZLfXtQfJvWcRolCPfCdAkrIm gvQWgr0jpwjQksREvf1B5lAgCnqyGTkPQSL/GpinE+3uV192bVAICfpGB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBAAk4hBY/40NJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR2BVQcBpCyHXoxhggmGIgKCB0ATAQIBAQEBAQEBYiiEYgE?= =?us-ascii?q?BAQQ6PwwEAgEIEQQBAR8FBAchERQJCAIEAQ0FCIgyAxe8bQ2DbwEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARyGPYRVgkeHXwEEmWE1AYx8gxyQC4hwhBqEAAEgATNeg02?= =?us-ascii?q?BOnIBh1wBgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.31,551,1473120000"; d="scan'208";a="164220655" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Oct 2016 17:08:29 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u9QH8U0u025881 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Oct 2016 17:08:30 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Oct 2016 12:08:29 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 26 Oct 2016 12:08:29 -0500 From: "Jakob Heitz (jheitz)" To: heasley , Brian Dickson Thread-Topic: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) Thread-Index: AdIt7WzqvhUzKEQ4QuObgT18xFaIJQBIJyAwABHPSoD//++DIYAAcwOAgACauQCAAFEEEA== Date: Wed, 26 Oct 2016 17:08:29 +0000 Message-ID: <4ead1ab283c447a6895cf47861446980@XCH-ALN-014.cisco.com> References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <20161026165710.GC58742@shrubbery.net> In-Reply-To: <20161026165710.GC58742@shrubbery.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 17:08:35 -0000 Yes, it is. However, sometimes we have multiple projects going on at the as= me time. Thanks, Jakob. > -----Original Message----- > From: heasley [mailto:heas@shrubbery.net] > Sent: Wednesday, October 26, 2016 9:57 AM > To: Brian Dickson > Cc: Jakob Heitz (jheitz) ; idr@ietf.org; Susan Hares > Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was= squatted on - Let's get a new attribute > number (1 week WG call (10/18 to 10/25) >=20 > Wed, Oct 26, 2016 at 12:43:23AM -0700, Brian Dickson: > > Rather than deprecate the two sequential values, why not reserve a smal= l range which includes those values, for > non-permanent reservations for vendor development use? Say 30-35 inclusiv= e? >=20 > isnt this bgp path attribute 255? From nobody Wed Oct 26 10:13:44 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17541297CF for ; Wed, 26 Oct 2016 10:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 9EMxVqfSmOeb for ; Wed, 26 Oct 2016 10:13:37 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 D0657129580 for ; Wed, 26 Oct 2016 10:13:36 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bzRle-000AMM-DA (job@us.ntt.net); Wed, 26 Oct 2016 17:13:34 +0000 Date: Wed, 26 Oct 2016 19:13:32 +0200 From: Job Snijders To: "Jakob Heitz (jheitz)" Message-ID: <20161026171332.GG1074@Vurt.local> References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <20161026165710.GC58742@shrubbery.net> <4ead1ab283c447a6895cf47861446980@XCH-ALN-014.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ead1ab283c447a6895cf47861446980@XCH-ALN-014.cisco.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: heasley , "idr@ietf.org" , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 17:13:38 -0000 On Wed, Oct 26, 2016 at 05:08:29PM +0000, Jakob Heitz (jheitz) wrote: > Yes, it is. However, sometimes we have multiple projects going on at > the asme time. just like we print money, you can tunnel as much path attributes as you need through 255 right? :) Kind regards, Job From nobody Wed Oct 26 10:24:46 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153A9129841 for ; Wed, 26 Oct 2016 10:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wM-j3zStJERY for ; Wed, 26 Oct 2016 10:24:44 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0827F129A2C for ; Wed, 26 Oct 2016 10:24:44 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id D1B3358D1B; Wed, 26 Oct 2016 17:24:43 +0000 (UTC) Date: Wed, 26 Oct 2016 17:24:43 +0000 From: heasley To: "Jakob Heitz (jheitz)" Message-ID: <20161026172443.GA60712@shrubbery.net> References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <20161026165710.GC58742@shrubbery.net> <4ead1ab283c447a6895cf47861446980@XCH-ALN-014.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ead1ab283c447a6895cf47861446980@XCH-ALN-014.cisco.com> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: heasley , "idr@ietf.org" , Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 17:24:45 -0000 Wed, Oct 26, 2016 at 05:08:29PM +0000, Jakob Heitz (jheitz): > Yes, it is. However, sometimes we have multiple projects going on at the asme time. You develop each on a separate branch, right? so, they could use the same attribute #. i'm poking fun; I dont care if more are reserved. From nobody Wed Oct 26 10:32:18 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E22A129BF0 for ; Wed, 26 Oct 2016 10:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kVnRQvErSBRu for ; Wed, 26 Oct 2016 10:32:14 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 56B7C128B37 for ; Wed, 26 Oct 2016 10:32:14 -0700 (PDT) Received: from www.lamehost.it (unknown [80.76.80.23]) (Authenticated sender: marco@lamehost.it) by seele.lamehost.it (Postfix) with ESMTPSA id BE73F746D1; Wed, 26 Oct 2016 19:32:10 +0200 (CEST) Mime-Version: 1.0 Date: Wed, 26 Oct 2016 17:32:10 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> X-Mailer: RainLoop/1.10.3.151 From: marco@lamehost.it To: "heasley" , "Brian Dickson" In-Reply-To: <20161026165710.GC58742@shrubbery.net> References: <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> X-Originating-IP: 37.130.210.2 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Wed, 26 Oct 2016 19:32:10 +0200 (CEST) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Wed, 26 Oct 2016 19:32:10 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.99.2 at seele X-Virus-Status: Clean Archived-At: Cc: idr@ietf.org, Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 17:32:16 -0000 October 26, 2016 6:57 PM, "heasley" wrote:=0A> Wed, = Oct 26, 2016 at 12:43:23AM -0700, Brian Dickson:=0A> =0A>> Rather than de= precate the two sequential values, why not reserve a small range which in= cludes those=0A>> values, for non-permanent reservations for vendor devel= opment use? Say 30-35 inclusive?=0A> =0A> isnt this bgp path attribute 25= 5?=0A> =0A> _______________________________________________=0A> Idr maili= ng list=0A> Idr@ietf.org=0A> https://www.ietf.org/mailman/listinfo/idr=0A= =0AI was suggesting the same thing out-of-list today.=0AWe should really = assign ~5 values to experimental/development puroposes From nobody Wed Oct 26 12:10:47 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 782A11297AC; Wed, 26 Oct 2016 12:10:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147750904648.2927.9899493365277493754.idtracker@ietfa.amsl.com> Date: Wed, 26 Oct 2016 12:10:46 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-large-community-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 19:10:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Large BGP Communities Authors : Jakob Heitz Job Snijders Keyur Patel Ignas Bagdonas Adam Simpson Nick Hilliard Filename : draft-ietf-idr-large-community-05.txt Pages : 9 Date : 2016-10-26 Abstract: This document describes the Large BGP Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use in four-octet ASNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-large-community-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 26 12:19:01 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D9B129958 for ; Wed, 26 Oct 2016 12:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 F0TYbd7-VjIh for ; Wed, 26 Oct 2016 12:18:58 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 E8751129929 for ; Wed, 26 Oct 2016 12:18:57 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bzTiy-0007DN-PV (job@us.ntt.net); Wed, 26 Oct 2016 19:18:57 +0000 Date: Wed, 26 Oct 2016 21:18:54 +0200 From: Job Snijders To: idr@ietf.org Message-ID: <20161026191854.GD37101@Vurt.local> References: <147750904648.2927.9899493365277493754.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147750904648.2927.9899493365277493754.idtracker@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 19:19:00 -0000 Dear Working Group, ChangeLog: o New Early IANA Allocation! o Reduce ambiguity, UINT_MAX -> UINT16_MAX (John Heasley) o Remove empty attribute error handling sentence, thus default to 7606 (David Freedman, Jeff, Jakob) In a twisted turn of events, this effort has ended up with BGP Path Attribute value 32 - very befitting if you look at the very problem we're trying to solve :-) Kind regards, Job On Wed, Oct 26, 2016 at 12:10:46PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing of the IETF. > > Title : Large BGP Communities > Authors : Jakob Heitz > Job Snijders > Keyur Patel > Ignas Bagdonas > Adam Simpson > Nick Hilliard > Filename : draft-ietf-idr-large-community-05.txt > Pages : 9 > Date : 2016-10-26 > > Abstract: > This document describes the Large BGP Communities attribute, an > extension to BGP-4. This attribute provides a mechanism to signal > opaque information within separate namespaces to aid in routing > management. The attribute is suitable for use in four-octet ASNs. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-large-community-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Oct 26 22:10:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C77B129B29 for ; Wed, 26 Oct 2016 22:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 hXi5I-s3uvMk for ; Wed, 26 Oct 2016 22:10:34 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 B1F6C129B27 for ; Wed, 26 Oct 2016 22:10:34 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 3BDC373B for ; Thu, 27 Oct 2016 05:10:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbIs13In8Ik7 for ; Thu, 27 Oct 2016 00:10:34 -0500 (CDT) Received: from mail-qt0-f198.google.com (mail-qt0-f198.google.com [209.85.216.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 09F746CD for ; Thu, 27 Oct 2016 00:10:33 -0500 (CDT) Received: by mail-qt0-f198.google.com with SMTP id p53so15195431qtp.1 for ; Wed, 26 Oct 2016 22:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MO7IBHJd62kRysl0AKCH14oBgLVppzc1pdwGfhaX0jk=; b=io+ff3QRA/GLrxnRzKzG4wGeAxJwHTeAggHZLOHhyPU8gQEDfYFxFId7nu8hXwJWsY HgEMpnz8VVcuvmLjTw9mzdFY+0aswdrUOP6yvrMWXd0dIXwOU+AueNOSMAZ5hoan7T83 lEwoaCl3qCvxeWN+yg7Shur3ZJVNNvZ3FT9z2Z8Zv2DWwC7Dmo4jU6J0TPjWA1pXrZ9v BqqQijFdo+Buz7OKqgiwpzEUJXIHYh2FLUELFp7KhMCb63YR1mezuYVlgc3OVZcLkBc+ MFLisHCqCz21nETxzESWVLBwNXRKyf5g+22MFu+DRv0gHLZo+RT858FNORxTDGFfyTc5 Yjuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MO7IBHJd62kRysl0AKCH14oBgLVppzc1pdwGfhaX0jk=; b=hMk+e7SYGNqRoa7QtqNPwB7efaLYU2uBHrUaJki0C8J8Qd/6hj5DHfuupLa2PIPVyY aVKFqjxUrXmPlS1/yRudLRj8DSc1T1+eZTXxkaIEGIcAppf2WxyZx5E8kz/XreLrBiQg lwqr2KgSzwTS8+xbsvvJQNZhj5OgupKywWCLWimh07nXGLLYwdu9FPxYN4+cF16i3sA7 EEIOyZhOGuM/9rrWiPA1c1vKeIkjPmM/Nyon4MoonLIcBoqFEFtMhjAIt7AWO6bbk4Oa EooGNyIsYy7G6yRK8UCybZy3fTWxy6bj2iDq0JhhmutB4fzhqLMf5tWVI23Ax1rVm0nk tKkg== X-Gm-Message-State: ABUngvcM40kPdYMyoRO+in8yAp0yxfU2EmawG2DilGvcax7sZ/6s4e63ZB/zETsws2sJMIrxwzTf9kd1trHioyW8E/q64e8VLC5t1oMSgh9cVjkrImUcr3x18JYS0ZmChfcP3AJKIe9e/rlCsw== X-Received: by 10.200.35.229 with SMTP id r34mr4862985qtr.22.1477545033433; Wed, 26 Oct 2016 22:10:33 -0700 (PDT) X-Received: by 10.200.35.229 with SMTP id r34mr4862974qtr.22.1477545033263; Wed, 26 Oct 2016 22:10:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.41.230 with HTTP; Wed, 26 Oct 2016 22:10:32 -0700 (PDT) In-Reply-To: References: <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <20161022123423.GD79185@Space.Net> <20161023233431.GA76131@gweep.net> From: David Farmer Date: Thu, 27 Oct 2016 00:10:32 -0500 Message-ID: To: "John G. Scudder" Content-Type: multipart/alternative; boundary=001a1142bb38d901c1053fd1c24e Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 05:10:36 -0000 --001a1142bb38d901c1053fd1c24e Content-Type: text/plain; charset=UTF-8 On Mon, Oct 24, 2016 at 12:10 PM, John G. Scudder wrote: > Hi Everybody, > > There has been a fair amount of debate about this sentence in the draft: > > " Global Administrator: A four-octet namespace identifier. This > SHOULD be an Autonomous System Number." > > Many of the objections can be summed up by saying "I can't program a > router to enforce this rule". This is true, but as Brian has pointed out, > it's hardly the first example of such a thing in a BGP spec. (Indeed, RFC > 1997 says the equivalent community field "shall be encoded using an > autonomous system number" but of course provides no enforcement mechanism.) > > Other objections seem to be pursuing the question of whether it might be > possible to revise the proposal to make the rule enforceable. Whether or > not this is possible in principle seems beside the point since it would > violate the "small and simple" 1997-equivalent goal of the proposal that > was part of the consensus when the WG accepted it. > > After reviewing the mailing list discussion to date, it's the chairs' > sense that consensus is trending towards keeping the text as written. As > always, if you disagree with that consensus and feel you have something new > to add to the discussion, please do. > > Thanks, > > --John and Sue > I support the consensus as described. However, maybe an alternative to at least partially address some of the concerns is to discuss the consequences of the Global Administrator and Local Data Part fields being used differently than intended. How about something like the following; The Global Administrator field SHOULD be an Autonomous System Number and is intended to allow different Autonomous Systems to define Large BGP Communities without collision. The meaning associated with the Local Data Part fields are locally defined by each Autonomous System. Operational use of Large BGP Communities inconstant with this intent could result in undesired routing behavior. Implementations MUST allow the operator to specify any value for the Global Administrator and Local Data Part fields. Thanks. =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a1142bb38d901c1053fd1c24e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 24, 2016 at 12:10 PM, John G. Scudder <= ;jgs@juniper.net&g= t; wrote:
Hi Ev= erybody,

There has been a fair amount of debate about this sentence in the draft:
"=C2=A0 =C2=A0Global Administrator:=C2=A0 A four-octet namespace ident= ifier.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0SHOULD be an Autonomous System Number."

Many of the objections can be summed up by saying "I can't program= a router to enforce this rule". This is true, but as Brian has pointe= d out, it's hardly the first example of such a thing in a BGP spec. (In= deed, RFC 1997 says the equivalent community field "shall be encoded u= sing an autonomous system number" but of course provides no enforcemen= t mechanism.)

Other objections seem to be pursuing the question of whether it might be po= ssible to revise the proposal to make the rule enforceable. Whether or not = this is possible in principle seems beside the point since it would violate= the "small and simple" 1997-equivalent goal of the proposal that= was part of the consensus when the WG accepted it.

After reviewing the mailing list discussion to date, it's the chairs= 9; sense that consensus is trending towards keeping the text as written. As= always, if you disagree with that consensus and feel you have something ne= w to add to the discussion, please do.

Thanks,

--John and Sue
=C2=A0
I support the consensu= s as described. However, maybe an alternative to at least partially address= some of the concerns is to discuss the consequences of the Global Administ= rator and Local Data Part fields being used differently than intended. How = about something like the following;

=C2=A0 = =C2=A0The Global Administrator field SHOULD be an Autonomous System Number<= /div>
=C2=A0 =C2=A0and is intended to allow different Autonomous System= s to define Large BGP=C2=A0
=C2=A0 =C2=A0Communities without coll= ision. The meaning associated with the Local Data=C2=A0
=C2=A0 = =C2=A0Part fields are locally defined by each Autonomous System.=C2=A0 Oper= ational use
=C2=A0 =C2=A0of Large BGP Communities inconstant with= this intent could result in=C2=A0
=C2=A0 =C2=A0undesired=C2=A0ro= uting behavior. Implementations MUST allow the operator to=C2=A0
= =C2=A0 =C2=A0specify any value for the Global Administrator and Local Data = Part fields.

Thanks.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication Ser= vices
Office of Information Technology
University of Minnesota=C2=A0= =C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626= -0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a1142bb38d901c1053fd1c24e-- From nobody Thu Oct 27 02:20:56 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1431293EB for ; Thu, 27 Oct 2016 02:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 AaEHXgoFDq-j for ; Thu, 27 Oct 2016 02:20:50 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 9F23B129404 for ; Thu, 27 Oct 2016 02:20:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 051F538; Thu, 27 Oct 2016 11:20:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1477560040; bh=+SePI7a4kgFPeO929Y2 fuRCR0MEUFPiEAJuxa7OiWco=; b=ICv48Gy3LQCv0qopjaRK7GzsMbQeCG3RNke T5HWsZ3oaPB/TKQh5VnZmhNhWATWlIooXkwLHakJVVA/pN0XocEjBYqW7xSObR/2 5a5cyEev6cQDjxrNQtoVavoRIgZislSeAHDrj4A3ZQPVuMZ45AH8BZ3oKx/zwNS4 TmZEKDus= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4NC9VM9Xxaaq; Thu, 27 Oct 2016 11:20:40 +0200 (CEST) Received: from [IPv6:2001:67c:64:49:5501:b930:759c:7b09] (unknown [IPv6:2001:67c:64:49:5501:b930:759c:7b09]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id E5EC237; Thu, 27 Oct 2016 11:20:39 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_3E6DFBA1-45E5-45F2-885C-B2E9A8F0FCF1"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Thu, 27 Oct 2016 11:20:38 +0200 In-Reply-To: <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> To: marco@lamehost.it References: <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: heasley , idr@ietf.org, Susan Hares Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 09:20:55 -0000 --Apple-Mail=_3E6DFBA1-45E5-45F2-885C-B2E9A8F0FCF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Op 26 okt. 2016, om 19:32 heeft marco@lamehost.it het volgende = geschreven: > October 26, 2016 6:57 PM, "heasley" wrote: >> Wed, Oct 26, 2016 at 12:43:23AM -0700, Brian Dickson: >>=20 >>> Rather than deprecate the two sequential values, why not reserve a = small range which includes those >>> values, for non-permanent reservations for vendor development use? = Say 30-35 inclusive? >>=20 >> isnt this bgp path attribute 255? >=20 > I was suggesting the same thing out-of-list today. > We should really assign ~5 values to experimental/development = puroposes I think this would be useful both to allow for larger-scale testing of = new attributes, and for vendors to be more easily be able to test = multiple new attributes in-house. Cheers, Sander --Apple-Mail=_3E6DFBA1-45E5-45F2-885C-B2E9A8F0FCF1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSDCCBUQw ggMsoAMCAQICARMwDQYJKoZIhvcNAQEFBQAwdjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFwZWxk b29ybjEVMBMGA1UEChMMU0pNIFN0ZWZmYW5uMR0wGwYDVQQDExRTSk0gU3RlZmZhbm4gUm9vdCBD QTEdMBsGCSqGSIb3DQEJARYOY2FAc3RlZmZhbm4ubmwwHhcNMTUwNTExMDg1MjM1WhcNMTgwODIz MDg1MjM1WjB1MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0g U3RlZmZhbm4xGDAWBgNVBAMTD1NhbmRlciBTdGVmZmFubjEhMB8GCSqGSIb3DQEJARYSc2FuZGVy QHN0ZWZmYW5uLm5sMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9b7oVFaA35FKgKq2dZXbh X1kQl2mgPnaI3OurSyefZ6dyv8JFNM6CAA77kb/Gh5FXVDEJujcRPnE93Lmvmx+82J140WSiTpez 7QY8oBYNDCRP0KksXzwfClZjrG2Afw8S1jH14ymK0HufZ9kEkSWD5WzrxEDSqwnQTyFhsGCrbQID AQABo4IBYDCCAVwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwKwYJYIZIAYb4QgENBB4W HFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMBr5zy4rYkQJ/JeoU3+6lnw Ebd5MIGoBgNVHSMEgaAwgZ2AFOH79lsAHFEBG+6Vrq192mCYPEg6oXqkeDB2MQswCQYDVQQGEwJO TDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNK TSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubIIJALBR3gny oySYMBkGA1UdEgQSMBCBDmNhQHN0ZWZmYW5uLm5sMB0GA1UdEQQWMBSBEnNhbmRlckBzdGVmZmFu bi5ubDALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAFhAYYTBnxV8QzZPT+qs+WLWNRKL 4JQq0dpmSleofioAUrHj8m2BITvJY1pnIY7mdegJXic6+/uCKMAG8FrA6tSNu/hUoTXYMVcUUih5 xZyCWsIFmSBbTuel0nmPvZDayelIwi7GDN0u9IvrmyinSiYJ5jjgiKg3Z1HmMP5t9MR8vpS38bxT WKef8RlACK9jeynmk2U8PFRT+ZVYDW3Us8z4wje+g+q0aEm8UZzoYE245C6aFBqiXS56AN9VcK2C 9Z4wSBnq+I0wRof0BIYIh7V1cFCtz3uhdcbVbfKPHP2GGv69nz/jqSz9hPbIEhC3/kv11FHvIA2x t1scHJOw5DPKaogCtp4BEiOayepZRYo8SCILVTUH07QEP+6D/nLQnNavQT2ClQaSq9ufuD689TvC r5BApB8glktKaPzsiW5gQncIp4GyY593cGkBdh2jPAVpYCyAG96xtY6E0NsjgoghSojeHRfaZOmR iDfaszo4JlIer+VPTcsIl984275cOE/LJcXLSb3AA9AyffEr+6Eszs6HzkfWlzdTedGbqPFhkSlg gBCTZAz/MCT//MVZiDq542xAU8nBpfKWfOyL3oK2PPQAGdpGxFNRzCBngi64n0mB+JrNS44j6WyP qWp2IGSu05o7x6lcUgsjtNmpYvZy4NoyPu4je4+QuzBpFYgCMYICnjCCApoCAQEwezB2MQswCQYD VQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNV BAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubAIB EzAJBgUrDgMCGgUAoIIBeTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjEwMjcwOTIwMzlaMCMGCSqGSIb3DQEJBDEWBBSh/Le2BpFF44ZyVMbAp9Imt9RCLDCBigYJ KwYBBAGCNxAEMX0wezB2MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQK EwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcN AQkBFg5jYUBzdGVmZmFubi5ubAIBEzCBjAYLKoZIhvcNAQkQAgsxfaB7MHYxCzAJBgNVBAYTAk5M MRIwEAYDVQQHEwlBcGVsZG9vcm4xFTATBgNVBAoTDFNKTSBTdGVmZmFubjEdMBsGA1UEAxMUU0pN IFN0ZWZmYW5uIFJvb3QgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQHN0ZWZmYW5uLm5sAgETMA0GCSqG SIb3DQEBAQUABIGAGj03QRsPEk++32kTlG9JE6mxPHED/KeWxHAEnt8fpqq106oir0Jp2Key8NTw 5afk6pPjKGF6ec/J7HLYhPnih+JxvhcuMsWcfZoue8D/7V2lqp4eCtyjk0E84QkzvDv+C9uGjVQy 04xxd5g7AoP3s6Yd8crKIp44X527HRqwNNQAAAAAAAA= --Apple-Mail=_3E6DFBA1-45E5-45F2-885C-B2E9A8F0FCF1-- From nobody Thu Oct 27 02:54:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F441129D18 for ; Thu, 27 Oct 2016 02:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 eiXaFc9rM-dt for ; Thu, 27 Oct 2016 02:54:18 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 12693129D1D for ; Thu, 27 Oct 2016 02:54:17 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bzhNw-000FX2-Pi (job@us.ntt.net); Thu, 27 Oct 2016 09:54:12 +0000 Date: Thu, 27 Oct 2016 11:54:04 +0200 From: Job Snijders To: Sander Steffann Message-ID: <20161027095404.GP37101@Vurt.local> References: <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: heasley , Susan Hares , idr@ietf.org Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 09:54:21 -0000 On Thu, Oct 27, 2016 at 11:20:38AM +0200, Sander Steffann wrote: > Op 26 okt. 2016, om 19:32 heeft marco@lamehost.it het volgende geschreven: > > October 26, 2016 6:57 PM, "heasley" wrote: > >> Wed, Oct 26, 2016 at 12:43:23AM -0700, Brian Dickson: > >> > >>> Rather than deprecate the two sequential values, why not reserve a > >>> small range which includes those values, for non-permanent > >>> reservations for vendor development use? Say 30-35 inclusive? > >> > >> isnt this bgp path attribute 255? > > > > I was suggesting the same thing out-of-list today. > > We should really assign ~5 values to experimental/development puroposes > > I think this would be useful both to allow for larger-scale testing of > new attributes, and for vendors to be more easily be able to test > multiple new attributes in-house. The problem here is that people are not abiding the rules, and offering more codepoints will only work if people abide those rules. I have no confidence that more dev codepoints resolve the issue. Kind regards, Job From nobody Thu Oct 27 03:01:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BC9129D27 for ; Thu, 27 Oct 2016 03:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 HvlSZ1UYIscB for ; Thu, 27 Oct 2016 03:01:29 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 40A76129D1A for ; Thu, 27 Oct 2016 03:01:29 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 15906A2; Thu, 27 Oct 2016 12:01:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1477562487; bh=8NL2PeT1cs7HY4MmfY8afab54yAx2jbY6cWLw/KXJwE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=f7KWsOoa4QJXQs3yg+l0Nr0uOWy9/9n2+imzmg9uU4LR+CaaIUtB/cbqPh/M5B7Pv u6eNCzz6a1NYDFfrgFEAvQjItZKvbDxl7FawjWSDAS5ihJ9NAeJSbnm4Oz2Wc3eKp6 d9jk2Ewke5wumrSLtYc+iVFZkQL6gZteGG5VJ6Bg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0637BA1; Thu, 27 Oct 2016 12:01:27 +0200 (CEST) Date: Thu, 27 Oct 2016 12:01:26 +0200 (CEST) From: Mikael Abrahamsson To: Job Snijders In-Reply-To: <20161027095404.GP37101@Vurt.local> Message-ID: References: <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 10:01:34 -0000 On Thu, 27 Oct 2016, Job Snijders wrote: > The problem here is that people are not abiding the rules, and offering > more codepoints will only work if people abide those rules. I have no > confidence that more dev codepoints resolve the issue. Perhaps we could ask the squatters why they didn't use 255 for their development testing? If this was because they already used 255 for some other project, then it might make sense to have more code points. If it was because they weren't aware of it, then that's a problem and assigning more code points wouldn't help, agreed. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Oct 27 03:14:54 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F54129D24 for ; Thu, 27 Oct 2016 03:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 fcX0f8NArqjL for ; Thu, 27 Oct 2016 03:14:49 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 419EB129447 for ; Thu, 27 Oct 2016 03:05:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id AD3EC37; Thu, 27 Oct 2016 12:05:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1477562706; bh=+GsnEEz525trqw5YSR2 wzTs7JjjFVDLeV42OdZaCT+E=; b=gF4A7tqEiXA8ecey/idXfGiXnAuJKumm048 PR7Wrrqfx4ah1duP4RmHo+Og/8lUNflZCI/Hd4O69gFmy4nKEyhNeW9mCkDmewef P4PEeP/DC8Vl63KEGSrwS59j+kC8secSGTOceyXDOl3bVrmmyAExbFlpAtUHNOnU IV01mcTA= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iEVJfszbjBbK; Thu, 27 Oct 2016 12:05:06 +0200 (CEST) Received: from [IPv6:2001:67c:64:49:c5a7:f1e9:c75f:4e4] (unknown [IPv6:2001:67c:64:49:c5a7:f1e9:c75f:4e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 166DE38; Thu, 27 Oct 2016 12:05:06 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <9C5EBC1C-A97E-4E05-A5F0-E916042FA081@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_6B4A7F02-866C-46DC-A22A-3A2DBD90E51B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Thu, 27 Oct 2016 12:05:05 +0200 In-Reply-To: To: Mikael Abrahamsson References: <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 10:14:52 -0000 --Apple-Mail=_6B4A7F02-866C-46DC-A22A-3A2DBD90E51B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Op 27 okt. 2016, om 12:01 heeft Mikael Abrahamsson = het volgende geschreven: > On Thu, 27 Oct 2016, Job Snijders wrote: >> The problem here is that people are not abiding the rules, and = offering more codepoints will only work if people abide those rules. I = have no confidence that more dev codepoints resolve the issue. >=20 > Perhaps we could ask the squatters why they didn't use 255 for their = development testing? >=20 > If this was because they already used 255 for some other project, then = it might make sense to have more code points. If it was because they = weren't aware of it, then that's a problem and assigning more code = points wouldn't help, agreed. Full agreement Sander --Apple-Mail=_6B4A7F02-866C-46DC-A22A-3A2DBD90E51B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSDCCBUQw ggMsoAMCAQICARMwDQYJKoZIhvcNAQEFBQAwdjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFwZWxk b29ybjEVMBMGA1UEChMMU0pNIFN0ZWZmYW5uMR0wGwYDVQQDExRTSk0gU3RlZmZhbm4gUm9vdCBD QTEdMBsGCSqGSIb3DQEJARYOY2FAc3RlZmZhbm4ubmwwHhcNMTUwNTExMDg1MjM1WhcNMTgwODIz MDg1MjM1WjB1MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0g U3RlZmZhbm4xGDAWBgNVBAMTD1NhbmRlciBTdGVmZmFubjEhMB8GCSqGSIb3DQEJARYSc2FuZGVy QHN0ZWZmYW5uLm5sMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9b7oVFaA35FKgKq2dZXbh X1kQl2mgPnaI3OurSyefZ6dyv8JFNM6CAA77kb/Gh5FXVDEJujcRPnE93Lmvmx+82J140WSiTpez 7QY8oBYNDCRP0KksXzwfClZjrG2Afw8S1jH14ymK0HufZ9kEkSWD5WzrxEDSqwnQTyFhsGCrbQID AQABo4IBYDCCAVwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwKwYJYIZIAYb4QgENBB4W HFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMBr5zy4rYkQJ/JeoU3+6lnw Ebd5MIGoBgNVHSMEgaAwgZ2AFOH79lsAHFEBG+6Vrq192mCYPEg6oXqkeDB2MQswCQYDVQQGEwJO TDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNK TSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubIIJALBR3gny oySYMBkGA1UdEgQSMBCBDmNhQHN0ZWZmYW5uLm5sMB0GA1UdEQQWMBSBEnNhbmRlckBzdGVmZmFu bi5ubDALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAFhAYYTBnxV8QzZPT+qs+WLWNRKL 4JQq0dpmSleofioAUrHj8m2BITvJY1pnIY7mdegJXic6+/uCKMAG8FrA6tSNu/hUoTXYMVcUUih5 xZyCWsIFmSBbTuel0nmPvZDayelIwi7GDN0u9IvrmyinSiYJ5jjgiKg3Z1HmMP5t9MR8vpS38bxT WKef8RlACK9jeynmk2U8PFRT+ZVYDW3Us8z4wje+g+q0aEm8UZzoYE245C6aFBqiXS56AN9VcK2C 9Z4wSBnq+I0wRof0BIYIh7V1cFCtz3uhdcbVbfKPHP2GGv69nz/jqSz9hPbIEhC3/kv11FHvIA2x t1scHJOw5DPKaogCtp4BEiOayepZRYo8SCILVTUH07QEP+6D/nLQnNavQT2ClQaSq9ufuD689TvC r5BApB8glktKaPzsiW5gQncIp4GyY593cGkBdh2jPAVpYCyAG96xtY6E0NsjgoghSojeHRfaZOmR iDfaszo4JlIer+VPTcsIl984275cOE/LJcXLSb3AA9AyffEr+6Eszs6HzkfWlzdTedGbqPFhkSlg gBCTZAz/MCT//MVZiDq542xAU8nBpfKWfOyL3oK2PPQAGdpGxFNRzCBngi64n0mB+JrNS44j6WyP qWp2IGSu05o7x6lcUgsjtNmpYvZy4NoyPu4je4+QuzBpFYgCMYICnjCCApoCAQEwezB2MQswCQYD VQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNV BAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubAIB EzAJBgUrDgMCGgUAoIIBeTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjEwMjcxMDA1MDVaMCMGCSqGSIb3DQEJBDEWBBRbNnVDEb2X8x0EnwyN8HeWw6rtHzCBigYJ KwYBBAGCNxAEMX0wezB2MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQK EwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcN AQkBFg5jYUBzdGVmZmFubi5ubAIBEzCBjAYLKoZIhvcNAQkQAgsxfaB7MHYxCzAJBgNVBAYTAk5M MRIwEAYDVQQHEwlBcGVsZG9vcm4xFTATBgNVBAoTDFNKTSBTdGVmZmFubjEdMBsGA1UEAxMUU0pN IFN0ZWZmYW5uIFJvb3QgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQHN0ZWZmYW5uLm5sAgETMA0GCSqG SIb3DQEBAQUABIGAFUZ2az6zoA69ivJ9PHMIQRl4OFBIeIyX9MYuqlm1UKzyLrz9ALAoJvpW9yxx hr7cbu4z0vjetZ7cAfAw9m2yTwQpi4gkqxfgxQQlyQ7S6cphGdlko9dc8P7qWawQNx4aBS1QCgvM MrdsWUivwnZD26Bco3mClM5Mjw28JSwXgdsAAAAAAAA= --Apple-Mail=_6B4A7F02-866C-46DC-A22A-3A2DBD90E51B-- From nobody Thu Oct 27 03:22:38 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B928712940F for ; Thu, 27 Oct 2016 03:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NcGuQmjIHBMZ for ; Thu, 27 Oct 2016 03:22:31 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4D03A1295C2 for ; Thu, 27 Oct 2016 03:22:31 -0700 (PDT) Received: from www.lamehost.it (unknown [80.76.80.23]) (Authenticated sender: marco@lamehost.it) by seele.lamehost.it (Postfix) with ESMTPSA id 9F5A0746D1; Thu, 27 Oct 2016 12:22:26 +0200 (CEST) Mime-Version: 1.0 Date: Thu, 27 Oct 2016 10:22:26 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <413402e00e4c25dea495842b8e94fa1c@www.lamehost.it> X-Mailer: RainLoop/1.10.3.151 From: marco@lamehost.it To: "Job Snijders" , "Sander Steffann" In-Reply-To: <20161027095404.GP37101@Vurt.local> References: <20161027095404.GP37101@Vurt.local> <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> X-Originating-IP: 195.76.232.154 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Thu, 27 Oct 2016 12:22:26 +0200 (CEST) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Thu, 27 Oct 2016 12:22:26 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.99.2 at seele X-Virus-Status: Clean Archived-At: Cc: heasley , idr@ietf.org, Susan Hares Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 10:22:37 -0000 October 27, 2016 11:54 AM, "Job Snijders" wrote:=0A> On Thu= , Oct 27, 2016 at 11:20:38AM +0200, Sander Steffann wrote:=0A> =0A>> Op 2= 6 okt. 2016, om 19:32 heeft marco@lamehost.it het volgende geschreven:=0A= >> October 26, 2016 6:57 PM, "heasley" wrote:=0A>> W= ed, Oct 26, 2016 at 12:43:23AM -0700, Brian Dickson:=0A>> =0A>> Rather th= an deprecate the two sequential values, why not reserve a=0A>> small rang= e which includes those values, for non-permanent=0A>> reservations for ve= ndor development use? Say 30-35 inclusive?=0A>> =0A>> isnt this bgp path = attribute 255?=0A>> =0A>> I was suggesting the same thing out-of-list tod= ay.=0A>> We should really assign ~5 values to experimental/development pu= roposes=0A>> =0A>> I think this would be useful both to allow for larger-= scale testing of=0A>> new attributes, and for vendors to be more easily b= e able to test=0A>> multiple new attributes in-house.=0A> =0A> The proble= m here is that people are not abiding the rules, and offering=0A> more co= depoints will only work if people abide those rules. I have no=0A> confid= ence that more dev codepoints resolve the issue.=0A> =0A=0AJob,=0A=0AI am= just trying to cope with the status quo.=0AVendors are squatting codepoi= nts for their own purposes, it is obviously is bad and they shouldn't, bu= t they do.=0A=0AI can understand how a single value may not be enough for= large environments with multiple development processes.=0ASo i think tha= t we should try address the "unpleasant" habit of squatting what they sho= uld ask for by giving them enough room to work with.=0A=0AMy *wish* is in= that way vendors will use experimental space in development phase and ge= t back to the community to get an assignment when ready.=0A=0ARegards From nobody Thu Oct 27 03:42:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6004129D5B for ; Thu, 27 Oct 2016 03:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 pI2b_RZ7zGEw for ; Thu, 27 Oct 2016 03:42:12 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0784129D54 for ; Thu, 27 Oct 2016 03:42:11 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id 140so20328878wmv.0 for ; Thu, 27 Oct 2016 03:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=3rc3YVpe+PXuAdS3Rn68PTmlqSgcogK9IOZR2tUaltc=; b=IRxJ4meAFro6gYoo2aY/TDiYId52EaAqzqwNQM4NZHfOE6RyIlNZtxD0xnhoBdfvzn HUVDMB2eaCBM/PEdaEptNGciTrpk0nrfK7fjZEO5LcdBAaDaKlDMNpeBUNkm0xMl1+R6 UqILi0Z9dZIPnvLLU/kpxqBmMMnwqBbT8Za2uVR03kYqPBzGprQSF4Ovob3K4vkiH+GC j+LtwR5kwA7UrWZ7GNYVelsAMKJ7+8J88CZVoMC2Q8FJ5NVP3fqY4otxGyd2H1albbb9 tWNnoxSGGs7iFu8ovXuql9w9mRVJ+dkpCI+qALFTn1W+aIGeZm6+jlQNDn7GIFsmyia+ Co4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3rc3YVpe+PXuAdS3Rn68PTmlqSgcogK9IOZR2tUaltc=; b=StBhlW9ONGCeii+HD+Sk3ik1Rkah+0KBtXY5mZtKshXG3zC6kzif2D5tK8yhM2WdkN QtcdEX81oNYwS4V5QLgz5XjV+6IEb/4YlomB9hukxc8+s3u7Z4/eKfvLn/PtQCSEIj6J 1W7CWYVCTrNmcCwFzxgSopNY6gML/+RRcocZ8+hl3wPtCbnvM2GhbfPjSS24inJA8Ln+ ZGq18XtfhTL9jN4nElsPoWQcz6aQEm9CCb/hI9UzVktEaUe18Htz5b8DBUI6vsx6L8ef D8WzP5NYNmQnvew0UD0zx5Pdh/TLMHBOCJ8tm2hYn0FeirxMLlIjcflJU6R59by1l6yK Xpmg== X-Gm-Message-State: ABUngvfWZ4hvo2wyhNl5c72yIvBKaEMF1DzU3Qk7zmu9TN4OvP59yQKQKph4RuZnaDLH3Q== X-Received: by 10.28.163.196 with SMTP id m187mr12095937wme.73.1477564921093; Thu, 27 Oct 2016 03:42:01 -0700 (PDT) Received: from localhost ([37.130.210.2]) by smtp.gmail.com with ESMTPSA id 132sm2522606wmn.16.2016.10.27.03.41.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Oct 2016 03:42:00 -0700 (PDT) Date: Thu, 27 Oct 2016 12:41:58 +0200 From: Job Snijders To: marco@lamehost.it Message-ID: <20161027104158.GD34682@Vurt.local> References: <20161027095404.GP37101@Vurt.local> <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <413402e00e4c25dea495842b8e94fa1c@www.lamehost.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <413402e00e4c25dea495842b8e94fa1c@www.lamehost.it> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 10:42:13 -0000 On Thu, Oct 27, 2016 at 10:22:26AM +0000, marco@lamehost.it wrote: > >> I was suggesting the same thing out-of-list today. > >> We should really assign ~5 values to experimental/development puroposes > >> > > The problem here is that people are not abiding the rules, and offering > > more codepoints will only work if people abide those rules. I have no > > confidence that more dev codepoints resolve the issue. > > > > I am just trying to cope with the status quo. Vendors are squatting > codepoints for their own purposes, it is obviously is bad and they > shouldn't, but they do. > > I can understand how a single value may not be enough for large > environments with multiple development processes. So i think that we > should try address the "unpleasant" habit of squatting what they > should ask for by giving them enough room to work with. If you can't isolate your features in development branches, something is strange in your development process. This is of course a subjective statement, I'd like to hear from more fulltime implementors what their take on this is. > My *wish* is in that way vendors will use experimental space in > development phase and get back to the community to get an assignment > when ready. If you look at the numbers that have been used so far: 30, 31, 129 - those are all square in the middle. If you have concurrent projects and need multiple bgp path attributes, I'd expect someone to squat on the high numbers: 254, 253, 252, etc - because IANA, obviously is counting upwards. The presence of low (not yet used) squatted codepoints, shows me that the social contract is not followed, so making more rules won't address that. Kind regards, Job From nobody Thu Oct 27 04:36:22 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F86129D7B for ; Thu, 27 Oct 2016 04:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 7dkgiqs0Qcs3 for ; Thu, 27 Oct 2016 04:36:19 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30101.outbound.protection.outlook.com [40.107.3.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC37129CF9 for ; Thu, 27 Oct 2016 04:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UnjJGWLheE5QHtnX2FzpCbEdoyAm4uAKTeFehMLlasc=; b=fgPXbHR/oDoU2tL9ncolPD+CRBuRbyVmgxzUdjq2XbJOBylD+UAMdvqaLD6xE3gUut85PYoTFUzIcfVevSgaqN39wH65SHwsrm8AXOHmqPp6Qh9ZAY/lWihPD6bddoX1D5u5HpPrhTqwvAvGNrTKQ0/0wdwZSPksBfGGAmxUdq8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Thu, 27 Oct 2016 11:36:15 +0000 Message-ID: <011701d23045$f59009e0$4001a8c0@gateway.2wire.net> From: t.petch To: Job Snijders , References: <147750904648.2927.9899493365277493754.idtracker@ietfa.amsl.com> <20161026191854.GD37101@Vurt.local> Date: Thu, 27 Oct 2016 12:31:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.135.210.62] X-ClientProxiedBy: DB5PR0101CA0035.eurprd01.prod.exchangelabs.com (10.165.200.173) To HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) X-MS-Office365-Filtering-Correlation-Id: fc2fb924-edfc-4f97-6930-08d3fe5d760d X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 2:S/Y9PS6JN9dr78ZcRFWsKo1JzujftLJLGHb6DG26i4JCV0jGBgaoVuaQvZVome7S38VHRGcGMLxbmB0PQrBWs221tTfhuLBJy78014osx/XR78bA/GyYVGW2DCVY9L+cCuOeEaNiGFGjRDjlviYrs1Jgbvb0MKrdfTo5FB6HMvT1559SCePhaBRNL4KCTRceAQ3KlGtlUDyL2J8KnpNK8g==; 3:XZTxkhE9rMzWrs+p7+1ygc/J7quCnsdHOBji0IiqFQiKQLK6jRlFHzLjVTrHpC5XDBsBTt8VxNNOtGcUXikt64JpLttFjBEtJWmkHhy9w/vU4tc+tEmA1OE5HsLPwbT5raqh47ZISvavKJryUH3T0A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 25:YM3GZ969y07kwMVqBYd51U0qY7VYORYxS8yhpq9wv3k10tv2+YwuauePg3VJC++QEguAHK2A5q+xSijhL6ufepapXWD2wGA/qDLwh9le6+IszH09rQVAwSpitReWy2jsZcbQhj5AlJHSqXx4cg6ubhrn0iQn9hLP6qCa3zhTNzHvuS+F7EC6nCaIqelmycyrM/phCr/hpyAUB+rcZFz0ZdojCkVjAOC+poEcMTs3X+80OifRRvhsQGPd9VdBkMmpHp3rWd01Vw3L8hrcPcugLMod88JduaI0bFHOA0VLKpfj0tdd37X1KTA44IVo/cruapmnNDwTJJiRQMz7gVR/9m/qYGTXpGRechcR47K+lPgaHN5O1O5v0jTIG3JMkSjhld1Avova45zhsRA+Ox//hp0bnkbhb7nHMrM9cd2l6GvPOBLVYgZ9rRFvwP7i4jcGpxAUi2fjEbfhP8AUTaD64fHkgRH9kcr9YlzgmAv9jBXGIPRIPU39smAmSRQbiiZrkapwyenoAUa+E9GJ+zcGJbsO2pENpFUQvnheqvHj9UYjBQDlbU1jTITaWwGzMg2kvk3/gQml46M5JFS8XTVP58uBRT7nbCHaGnP3sElUzzfD8A8zC9n9DicqRa7NWdseo5IOe4Ob10T0fyYQo56C4wB+qmjXY3e5VxsLEAR8o6Z6iM5bf5wbEGyqBWVJs9hSN2Of7I/VM9agSPfjIg0f/4autkcmT9nktDzxPhrpuus= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 31:XxjahLamlWDWw6A6qjDWEYf+iJtqwbAH5xMEXvmJ9JsGo7ALE4ke9u+PSWKl+RV7UQc1qEQEFq6YZd128ch7JR6TirYrCnZuTi85U3wGsMw9nTJFHnkNqTuWKNCf7q87WDXC/KpU6ZddI1AuMXQ25JxCm9c5k5KD9YIkvIB0dbMLDZ574k1Vt9YTfRIl8l9AbyxePimcOzduKVgPV5BC7OoKRwnIKwG/Af08Fx8R2CG5hpUSeyGwJ811KE6YG2ey; 4:6iB5aEDYYp7E03dxGJm/gMF7/h2uIAKKufQ73yv22sRFp8EHCiHrr30OsEo5flZSyIhQm7w4eznFQgN8tCJmjo5vzPht9yNc45SBGiBjXWK/WebCxi3USjaxyjrkzfTJxGOnR1zpyoDU5JEmfLfR57LdvquvegrU6YpSuGw/CCJdtK7GBpmyVCK40cKtuBtD4E40E/F4sRW6/PTnXlKfP8sjNhsiXlS7qi7T1e3VPg216mzdebcXdKfSgkc588RfOZWwj7cnnuGpjGOXtahKUt52Yp9ICQiIHSpQNykUNiImufM8Y5BqfJLa6Dbay628JdOrWexan4nU2Erw205Xh4bmGlLE9JWObFCOtIrsONcyxGigqCXBjRBDPuimHWh6r1iapZNAK/ZpN0HpIfRJAg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3002; X-Forefront-PRVS: 0108A997B2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(377424004)(377454003)(54534003)(13464003)(189002)(24454002)(50226002)(23756003)(33646002)(189998001)(4001150100001)(2906002)(44716002)(62236002)(50986999)(81686999)(50466002)(305945005)(76176999)(81816999)(586003)(230700001)(66066001)(77096005)(47776003)(19580405001)(7846002)(101416001)(68736007)(14496001)(7736002)(97736004)(107886002)(81156014)(19580395003)(9686002)(5660300001)(84392002)(61296003)(105586002)(81166006)(92566002)(1456003)(42186005)(44736004)(6116002)(4720700003)(6666003)(230783001)(1556002)(8676002)(86362001)(106356001)(5001770100001)(3846002)(116806002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3002; 23:sKClSH+uv5m2IKo4f941hgGZIJmko9zksDaZb?= =?iso-8859-1?Q?0c6l3z9gQsAWWfk0uqFAS4F0ehmH9U3XJ7hn8n4A6cNscRVwwMsiWPxEDe?= =?iso-8859-1?Q?5c4kMv+iNUyxI1m+lpqJPgQpI4KV7BWJNnxWyFU2ztbhH1Hz6jqDLErj4Y?= =?iso-8859-1?Q?9lXEm//yj9lmYNx6awKg+6pB6L+FporQh3ltqBd6hORcIopSJz18S5d8Bl?= =?iso-8859-1?Q?MbvGVvleQc+euR8lk7FP+02ZLr8V6Ns5t0MLv2SVq/rdSBm72PhppYSYtC?= =?iso-8859-1?Q?T41JfJV9Z78WEaUuX14A1ODshfmh89N07K774bAdvSK0GoTLaJWyTwwrSO?= =?iso-8859-1?Q?lTGBQD6BvZNXp/xsQyCAVsQWpOIFs1xYQM+YHdMA9JM9NgWlSbVK7tKcKi?= =?iso-8859-1?Q?aUMr83d3CKHj0jFQgvfvYGhvlu4WL+h461tWWOSVelPk0hw8npM84bmDl+?= =?iso-8859-1?Q?+yzdEf5aesWId4SZUCTcgPBwfonyftBaFTRmK07ehcnlA1mR95NSTuQzq5?= =?iso-8859-1?Q?rHyr4+Boby0sipJTnhBaD/G1eFb2IinWE+vitQm5WZd0pVUbToJevwQrJG?= =?iso-8859-1?Q?GmoMWhb3D4PqYmCvK6KCjv72uEaKh0zBrUKDbWIGkFdhCvlRcSc12m7y1y?= =?iso-8859-1?Q?7Zxw5eV4zy8cHDLlKAO+nyrK1gqCQ2+KMaa8fmb/OgDBsj4+t8fuFi4U0/?= =?iso-8859-1?Q?a/BkXkQpKRZzUts/M1y68bkWw5kGPnvQLOVAD2bbX/RRrkjfo7kTeKZrZj?= =?iso-8859-1?Q?1ELYZaXFYaMAEYkp30Jsa2inc+/YgqAYdb+B9BrdQ6OlLzjzgyMsJ5hOMw?= =?iso-8859-1?Q?bmKmOcem3Q32RTa3SX3xsjRRN7NcJKZ5uXf3OfwHelhrpObuAEgtCCEB9i?= =?iso-8859-1?Q?tinx3b9KaA7eplN6K0oeibyZcfv9RG3QAI9MHtxpDPtj3FOfMwBC6BzCem?= =?iso-8859-1?Q?bMuv6HWq4CHyyMOI1S8xiopA1nCC/lWaOUzv1B6M7z63M2bqAiLqsZCMwL?= =?iso-8859-1?Q?ZMEoZSllQ38nVfT7iRGDSd6VdTPfVLtXQMptX+TuuEiy00y2+SVwwDlIq9?= =?iso-8859-1?Q?lVvPkWsivM3sIWolg7yukv2HG41LG0BGA92OMeA+Np8uSqCcWlozx6tF5J?= =?iso-8859-1?Q?TxoYffrY2sgL6jyrjWmPJC8HidcCHz3mC2DKLAqPTA9D2cdwsH0UET84ZC?= =?iso-8859-1?Q?WsQ82B9iR55fNjNRXJwC9/qbHN5mp5S1x22xfErzx5Y9W9HaZIUQRtEK5/?= =?iso-8859-1?Q?DO3M/ow9OU7A2PyZzAvSao0uFN74rv+PHEX35xJxkNoKC+4AA3QLMhFN6U?= =?iso-8859-1?Q?AH2iRpoFk6vOVE98Awc8OGz27001MvmTjlKZZZDXAFcyOq1RQk+gDpbd+b?= =?iso-8859-1?Q?xUFVqFCUJEtraOrKvEGPh3eAYcSvFcdSLLqi0KMjT93mlvTsq4dHvnsFYY?= =?iso-8859-1?Q?7zi+0saESWCgQmH8jEzdc9Jgw14dlvZqcuD2RKChirH7Z5wt1PQ//Ogc5V?= =?iso-8859-1?Q?bU14wI42+P8HHkMOu03Bntc72oTrYMTngy9xEk4iZHq2t16PtV3wqLVPFD?= =?iso-8859-1?Q?bVduEdTW3YjgLQwtH8lqRdVZzslo=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:GPkWmxm+WSK801SLMqxjl8/JXVCXuXI8wlD9xVjHSCyM1ZDmYi3K6Ud091XECIun/9RErqf69Dl2dI7dYSCphXuW18BA7OLCavoJjlTN7v1Gybj6D7uTUeWPEkOZscdhvEZp78gKONkK7WbMLta6Z+uF8mRbZ3sR99YVnMfn9v3ShKz8Fv2aujZtgc5gJE/1+U2Max6IlZDIXfcE8tAH6a48ZWz0QwMCUIKs5f1vdP94GklLe34ZTYP27lU7wcuozQk4KqQhyq2hlUnPR6z0pAtC7tprHKRbB/fH2KDuV3bJmTAIozlY4BMXkgz1HMqk; 5:a7BrKUcCZkeakLTOMhb7U7hSW6q2vc8zY4yIIuYD8dVfslDvzJF4JErwQI+inJH56g+kfPp01xU2lIObpSw1UbJT3UxMtAwZAy3iTNP/7CIumC05YWtVU4pUYLgDW7wtMobjo/+3hjvXrwNjwyKABA==; 24:8jytQTf7F10eBB9rqzt+Qdh5oZET+TYFribRmjhA/rXC7JkYWQ7upqsytL3Hc1M/DGeNfEEO0FkXXzh/KDr77P+WUVfK5/hc04M1OBuzxTg=; 7:UEcNi2GF5B2Q4TzkD78bTYai4rdeCJuJTSvoiG2Z+sFSEiFfTin6s3a6tyuEDzTuppkRMcj6edrSZQQ5tHthd59fLdLMAypeXeBT/xbd018SyOySij4phiAo3R/dDtZ8gfAyDgI703vt6+xWfxZDaUvo+DYcgCgZd1JDeNeZo8Jhz8Mr0Wb8HDPQ8yi4v9yTV5m9cVZpfJrwr57JzmY1BnVo0+i35QXjKJ5+869lhy9YQpgZASsQzgTBElIhh01/gPvW+7Gy+M2pYIgTcHp1wqzNPuiQjrOugMHp5ETgFTtq8k6H8pTyFzyP2bdApmzHNkpivmlOc+vTFCs7ZBhVwIeMfLUSct8kmHBe+7o3DpE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2016 11:36:15.1002 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 11:36:21 -0000 Job a minor administrative point; the RFC Editor commonly imposes a constraint of five names on the first page, and this list has now grown to six. A common practice is to have just one name on the front, that of the pen-holder, and list the others at the back, differentiating, at the back, between those who have made a major contribution and those who have not. Cutting out one from six may be more problematic:-( Tom Petch --- Original Message ----- From: "Job Snijders" To: Sent: Wednesday, October 26, 2016 8:18 PM > Dear Working Group, > > ChangeLog: > > o New Early IANA Allocation! > o Reduce ambiguity, UINT_MAX -> UINT16_MAX (John Heasley) > o Remove empty attribute error handling sentence, thus default to 7606 (David Freedman, Jeff, Jakob) > > In a twisted turn of events, this effort has ended up with BGP Path > Attribute value 32 - very befitting if you look at the very problem > we're trying to solve :-) > > Kind regards, > > Job > > > On Wed, Oct 26, 2016 at 12:10:46PM -0700, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Inter-Domain Routing of the IETF. > > > > Title : Large BGP Communities > > Authors : Jakob Heitz > > Job Snijders > > Keyur Patel > > Ignas Bagdonas > > Adam Simpson > > Nick Hilliard > > Filename : draft-ietf-idr-large-community-05.txt > > Pages : 9 > > Date : 2016-10-26 > > > > Abstract: > > This document describes the Large BGP Communities attribute, an > > extension to BGP-4. This attribute provides a mechanism to signal > > opaque information within separate namespaces to aid in routing > > management. The attribute is suitable for use in four-octet ASNs. > > > > From nobody Thu Oct 27 04:36:35 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53D7129D7F for ; Thu, 27 Oct 2016 04:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 fBspapQcZgDv for ; Thu, 27 Oct 2016 04:36:20 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30101.outbound.protection.outlook.com [40.107.3.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48BB129D78 for ; Thu, 27 Oct 2016 04:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nirs/6x/kfWer6Y6mKnix9i1isbCXXUdQN13gau4WGk=; b=F8sjuF82JiXz2dVqmkTmrHjndE7JOsQHQ7xxfOJ9Ao+6zn9s5R+e117yXSRe+Dtj18Q+5iXU01zSQ4/on4Cn2+PEknIyjZxQeCwDm1catx+A8V7v1jIo5ZntytjX0ifae04DJs4bb1XhVgp4xRLr3MuTtoYazz5ICxoKVE7PhIs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Thu, 27 Oct 2016 11:36:15 +0000 Message-ID: <011801d23045$f61f78a0$4001a8c0@gateway.2wire.net> From: t.petch To: , Job Snijders References: <20161027095404.GP37101@Vurt.local> <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <413402e00e4c25dea495842b8e94fa1c@www.lamehost.it> Date: Thu, 27 Oct 2016 12:33:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.135.210.62] X-ClientProxiedBy: DB5PR0101CA0035.eurprd01.prod.exchangelabs.com (10.165.200.173) To HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) X-MS-Office365-Filtering-Correlation-Id: 871fa6bf-a99f-4d47-417d-08d3fe5d769f X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 2:AUur/P0SfMgZyXQY/sh1l/vf0AdtplwukdBKp+z6Os9cZILNu2QUNC6iStDHh/JSUU+BNJrqmTQ81w8DjtUCuRTrjnq135H8FClIk6KLl2uqzK3S/dqByMTxYRTcOBNMGfyadfnsALmk/fpNfkw1xg7ygC7dBxuq7PdH5CsueBLQyL98OtEDSYsvoHUd2mxgJoxqpSQpbRag/bmipbTkgA==; 3:1ijZMqeZbJuk/czr/XG+kDYNDlBD4IBNzQRfx19nYEnJfC5OZ29qM8K/utw6DRWd6IZloTZvdVJUpPRLzbXpcUPIx2u28eLJO3esObOhUmHbmcb+CqYrDjNGeAyTdda+BW49JhnW65Wcbckd1tvAqg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 25:PrxQcXtF2leItp92F0QHoSSbIwR9nvymtaIsto5aC8nmqF+UJU2+hYKlhKOu8OaE5TdUOpCy/Xa/LQcUXJ213FK7sIEDuOHeCacqbyjC6jNHDGtbH9u9K1TB5Ha7TX60pbykv6gYIQZp3fBZjw3Bgdne4CxmGostgNOJMOeeDQBKXCUopWeEBa/DTM3/k2j0RjiWoDS85RW0KH7aZQ+nB5pJDXs9LsjBz6P3vp0a304E8sm2A8wIcphVLd2gF3lLFXawJcTnB5Fk+DlEbwWulsSH19rAQGE31TZsyJNpZ90bEGGuOiIeP2ZLM5UfX+T7ZJRRcjRYlqFqV/SSnKu9bkeo3EgFbCWD3P/OTyb3n9lVx13Mwu20/3hHgVHkiZDVpSyl9pMuYYOELSogAQP3Z8KIuDbGG5cD15Zl3WtUcjwba4r9oZChmGL6qcJjsLt9vUD2SWtrcOYBife5tot7YKM3ZN3N1NvjbPzTyYykeABb5eEUZVktAEJtnqD8LIaqPPG0yRjyBlDQkfK7sDsrpv88CDObfjMt+OpBNxBREmR/bK4Em4b2ZkIqDJ9wfUFG2p1sCrMNDwHpY7g74thY3gXsPxD69eh32Wba0AcrygYi/kjI9xwRrkj4yjyIv2ZUfHVVuebs8EhrAyYS4W10cJZXwoRFOlcDGTmBkBZaqo3h+VPS/ayM5E3b8QHcKRpN6/8cL9oh+JMWPcY+DppKj+MDwHxupRP2tUzVXKLUTQsttmFEpeze1A7Yj2C23o/XKz6xsZHW6bYuw6FDLXaSt1/laD8d7FZ6ZsaEPV61Zz+i6XRwD/HCuUJOXqVrQCgjBjCONbefRrIl1et/MQR02JPGnhzLD/VC7yOoxhIoYc1hYzNXCBWmmBKUcUQh7UxK X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 31:zsdh9OFc2YFix7oidBCQdrzmbBFM9l0kjL8QpsHh8EWATVKqneXd64nVTFJl3jgNGFSujHY6F3r+jJHDJgBkyVuJ3+vQlw9JDvJIO4BelnAKyg2q5ppJJzDWoGXsy/p+T+S6teqcoiZB/ocjJ25Hv+TE1vOIMQ79c/OTmnBrvNbCG/8Ho9bLXXypxq89GqkjJBBqVoOGiGdBKGdhgm5olLQNxCPdfbyhV4NFydvWXFgUeCXWM5o4fPxieTbNvIHj; 4:PFgnzQa3nFim11HFLY26x5gGsmmkdbBpnAm37Ugett/cPXM5JhV6q8vUNDJ0zhFOoSE5Z4/gV8LPRv0/y+2pEtmuok4CEI/lLLF1sDgzkC3NO7UsGy0grlGJMO3CTxdPBiVy41UCkF1ApSxkGdSX/tkEa1MDq6IioGkuZznCiitgQBjQsJy6t6h/y1PVjc0kUiJSSlAZmC80dNhsLaRSg0ZIRVAPX/sdbUwfbGsiPQHzaX8ZCl4eE38uUPnNxFVzpiIyBMD1yc8J406bWwR2j4tZrLvvRvtCkQpNy+Bqy9Bcp1KypENiVQT+k94UR7HGDT+N5gG9kjkeYhCCE8YQR1bGYlpmVIGITxG5+u/QMMBYJR2H2RL7AEzFpJmnUlF31e3QJ3crG3IqmaDremZwbg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3002; X-Forefront-PRVS: 0108A997B2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(51444003)(199003)(377454003)(13464003)(189002)(24454002)(50226002)(93886004)(23756003)(15975445007)(33646002)(189998001)(2906002)(44716002)(62236002)(50986999)(81686999)(50466002)(305945005)(76176999)(81816999)(586003)(230700001)(66066001)(77096005)(47776003)(19580405001)(7846002)(101416001)(68736007)(14496001)(7736002)(97736004)(81156014)(19580395003)(4326007)(9686002)(5660300001)(84392002)(61296003)(105586002)(81166006)(92566002)(1456003)(42186005)(44736004)(6116002)(4720700003)(6666003)(1556002)(8676002)(86362001)(106356001)(5001770100001)(3846002)(116806002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3002; 23:Kay2SZ3zcuWp0REpcckWzpYflT2FXG4Pk+SPY?= =?iso-8859-1?Q?Zpd9djVy7hsJHVmZLyFTunzw6XbSEmtOC0P5tOJey2L8x/ZMaEGAU72M4w?= =?iso-8859-1?Q?u3KGUpjkNzAX27ts7gjRKYm1mX/zz4Sv7mM+xCGVtPR4dDM+1MeYxbpfYu?= =?iso-8859-1?Q?V5xvHKQzZuSPOuJx1MAX8CF74iz86LD++nr5iBJX6Z9sUAtiODcL8TRJW2?= =?iso-8859-1?Q?REKAQM3Dt/9rGqbsmPXHqHI2kqDIXynFzAqOllINAqOpGfcc3NFp+KFpUe?= =?iso-8859-1?Q?LfxvOO7u7/ub8n48lcWjeMjMlkN9wg2/B9GvvyMZfu65l+27h3PHUwCXOB?= =?iso-8859-1?Q?fM4JQ9VrX0MTkJQf++q6DsqrYtydB60gcpgR57up/1JfSFxSMNkdfX+fmx?= =?iso-8859-1?Q?OFeKGrVEyXJZGxyHmgqhpWRf8W3ttRhRuh6Gj3e0lbxVn9S+wSoMc1YOHU?= =?iso-8859-1?Q?erzpSn0nUK/LmsU7PSX/f7xuNDNPIIbojzetZk/9mZd3FYHOQEMkHlmcCX?= =?iso-8859-1?Q?N03A60+4QwYoXOKrdmyH+yUuR7zmDaN2MH5dEcHJ+3ugXLKNTokM1OLM7u?= =?iso-8859-1?Q?DzORyMgFstoNkCnolbsExToXar7ckrqzxz7wwvvbZl3UmzAowk2qpA+eQH?= =?iso-8859-1?Q?vjWuJVnKMe0HgkELkDcaqXGZgUA5yajG7QhkxHaWOyVnbeCXJqfBgi6/XC?= =?iso-8859-1?Q?KELgwwHa1nVyUPnuS3K77/IHczmCtT6lgEyZNTL8Avu7GO8cxVRihsm8C4?= =?iso-8859-1?Q?G+jL0bKfr9hqWJ+d7AFzWiG83pCogCaWBO3whlTeuLx4X0fdn3TgtrMDxM?= =?iso-8859-1?Q?Uw1apjhKVYBAxf+bpPGXbEbYBKuaZqgbSH97ZAn8Wfjjt+tkQUCXc93xxk?= =?iso-8859-1?Q?bo0c+mpeOOkmVjMzy040J/cwdP3O13H7LisJhbbwqjup0aED7v4iASINj3?= =?iso-8859-1?Q?boZRRx2fKJLqXnbhMi7NWmi7ZzV2YqF92TxY0MH1BvYHINHS9TcpjPN/i5?= =?iso-8859-1?Q?SgYat5u4AX85nrb5eKnqponvSYkDC4tl3NRzW+uiLhwM3PBgzRwIOstAPA?= =?iso-8859-1?Q?LjHidct5dTmlvAQRbn0nWI3+0AWuKKsAxg7JGbTSss0enV6ZTF7zcXNk51?= =?iso-8859-1?Q?cK7emBKubY6KzzwsL+tB1zcBJlOAKEuIsSMDwuo5Fi3tBfivACtWMYitDC?= =?iso-8859-1?Q?17dwoY04t+BBKZc6cu8Ej+mCm58GAbSoTw9YDHxs4C+bvjoh5brc0q7yOg?= =?iso-8859-1?Q?RZVJbLyoLgIcq3UD53J+dcHBnjgZ0lZwijw4OyNyyzG0SztjZHdm61ruvq?= =?iso-8859-1?Q?vYp40I9tr7ygVWO5KPJ4mVYs/DCTg6zqcN7Xjr4MD6FC+LxB+4PnAuC4uq?= =?iso-8859-1?Q?cwGgQiDCZC2VI02PksOnQFzQVabdCfZe+XlP0SBiqARL/g+GegxPZKfBLu?= =?iso-8859-1?Q?OPEo+oYuvlOVWhUPuoZwQiND9+slWfiJzRVXpjmV7/PmvljhqseJA62PqM?= =?iso-8859-1?Q?DNIoA9xJxr7wCkuZCsdtPwfI3e7WD6Gm31mywIcwQr+4em5BTj8Q+/9Gzu?= =?iso-8859-1?Q?0DLjAGg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:uPAaBtCuZoA6FeKZ4O4xIzG+gBgji2mdd2XcpIldYCg6GsnbE1qbWUMasnz7He2sh4ZLbd+RapSx2oUJhqbcVGim8f5fXj8jqlFcOUijzguM/N6aPOSJ1HdXxjE2DLFQqcotfveAUu2l65dz4aCRxqthGIyauGEZVi0OHopF38mdtzwXYfvp8bZ2zhqtFvqvaDjEBd8535IQdHbZMqUBJ51tk8KKAnOz14GOfXd3brZIwZ5o/VUeGMecbhfBkMefG059RkT30qLXMy2kbz37ruIXOo97E2vPjek5dSVq5cDF6W9/8cKnx/Zsf8ZCFJjZ; 5:o6Qvsp6gmJZfyNw3zh+gdvV27MR8h/74N4QyymTUSEZhrBK5b64s9ZXFIGv8SUvyiMLdUeb2+1FYZiYwhNFXsGshhJfGCHITWjioYnXYOFj6nIP7h+K9/bmXuwW7nNgHFV6NdnWfgKTRzg+jdlfFSQ==; 24:VVNd+dokXxr8xNcLVPiqOLe89udjRnRY+GMLGknITJ20e1GuQ4doQocds9udkyloalYTGR/kk7p699BU1rcMrGgWsMNdDtOAY8xfotK0Feo=; 7:T8HZyVqGonscD4byD12+u2QBjHceQbq7+6GYd6l98/406k4HbP3zIenzf5gS07Ya7ycmwvejDUkG5GYkdLBLLFd1N8z2zsIyqMWGIGOD5aGypAOA8dUq2Y31+IJfDDxnVkavKUGkPQCOr3Bdd+1OdHH2x6W5VxWoRbsO4xXHzAlmmp7Qm9pVcFGoIkSiGuiamIZBItcxzpAzwcR9y3kM1Z3IVNtN56vToHhiIGG1ClxVtDR7MCLs+f2QBBio09OvnI51zRxtG/8e7L97U46KtKqN01GBIU6CREuPf8hynrMAYdYNPJn4fZFPpqdaJihquFYnHtk3oTCYCfzOYN10cAtiY0J6qVejr6fZrYhnHtE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2016 11:36:15.9259 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Cc: idr Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 11:36:24 -0000 ----- Original Message ----- From: Sent: Thursday, October 27, 2016 11:22 AM > October 27, 2016 11:54 AM, "Job Snijders" wrote: > > On Thu, Oct 27, 2016 at 11:20:38AM +0200, Sander Steffann wrote: > > > >> Op 26 okt. 2016, om 19:32 heeft marco@lamehost.it het volgende geschreven: > >> October 26, 2016 6:57 PM, "heasley" wrote: > >> Wed, Oct 26, 2016 at 12:43:23AM -0700, Brian Dickson: > >> > >> Rather than deprecate the two sequential values, why not reserve a > >> small range which includes those values, for non-permanent > >> reservations for vendor development use? Say 30-35 inclusive? > >> > >> isnt this bgp path attribute 255? > >> > >> I was suggesting the same thing out-of-list today. > >> We should really assign ~5 values to experimental/development puroposes > >> > >> I think this would be useful both to allow for larger-scale testing of > >> new attributes, and for vendors to be more easily be able to test > >> multiple new attributes in-house. > > > > The problem here is that people are not abiding the rules, and offering > > more codepoints will only work if people abide those rules. I have no > > confidence that more dev codepoints resolve the issue. > > Job, > > I am just trying to cope with the status quo. > Vendors are squatting codepoints for their own purposes, it is obviously is bad and they shouldn't, but they do. > > I can understand how a single value may not be enough for large environments with multiple development processes. > So i think that we should try address the "unpleasant" habit of squatting what they should ask for by giving them enough room to work with. > > My *wish* is in that way vendors will use experimental space in development phase and get back to the community to get an assignment when ready. Marco This is an issue that has come up many times,for many protocols,in the IETF. The issue that vendors raise is that having got everything tested and working on an experimental code point, everything has to be changed to a standard one and that introduces errors (well, I could write code to minimise the risk of that, but suspect that not all do and even then, there is non-code like documentation that needs fixing). So the IETF introduced early assignment and made it quite easy to use. The issue that vendors raise is that an early allocation early in their process discloses to competitors what they are up to which loses the vendor their commercial advantage. So they squat, and hope that when they are ready to disclose what they have done, then that code point will still be available for use. I think it not a coincidence that the squats are in the 'next available' range and not in some dark corner where noone else will go. This sort of dance has been going on for at least 20 years because there is no good answer and the experimental option remains little used (at least in some registries). Experiments that fail to turn into production code are fine; those that do are problematic. Tom Petch > Regards > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Oct 27 04:44:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C0A129D90 for ; Thu, 27 Oct 2016 04:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 8dKcoxV_56M4 for ; Thu, 27 Oct 2016 04:44:23 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 6BD9D129D8E for ; Thu, 27 Oct 2016 04:44:23 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bzj6b-0009x5-RF (job@us.ntt.net); Thu, 27 Oct 2016 11:44:22 +0000 Date: Thu, 27 Oct 2016 13:44:18 +0200 From: Job Snijders To: "t.petch" Message-ID: <20161027114418.GT37101@Vurt.local> References: <147750904648.2927.9899493365277493754.idtracker@ietfa.amsl.com> <20161026191854.GD37101@Vurt.local> <011701d23045$f59009e0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011701d23045$f59009e0$4001a8c0@gateway.2wire.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 11:44:24 -0000 Hi Tom, On Thu, Oct 27, 2016 at 12:31:32PM +0100, t.petch wrote: > a minor administrative point; the RFC Editor commonly imposes a > constraint of five names on the first page, and this list has now grown > to six. A common practice is to have just one name on the front, that > of the pen-holder, and list the others at the back, differentiating, at > the back, between those who have made a major contribution and those who > have not. Cutting out one from six may be more problematic:-( This is not a problem. Looking at the last 1000 published RFCs, roughly 3% of RFCs have more than 5 authors listed. If anything, it will be something between the RFC Editor and the Authors of this draft. Thanks for your concern! Kind regards, Job From nobody Thu Oct 27 06:08:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADE912949F for ; Thu, 27 Oct 2016 06:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 WA6qRHgb4oPn for ; Thu, 27 Oct 2016 06:08:04 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AEA0129449 for ; Thu, 27 Oct 2016 06:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1660; q=dns/txt; s=iport; t=1477573683; x=1478783283; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TXkZAqLSbbQRWkWE1yeKQt+7yQiPP1EJdEMVbF8qahM=; b=ao1BkDDi4ecnxMGuW9wXSu2YtWFIk6wg6WuIJsHiO1diFKef7FPd+Gzq mBQ6a/TRcEBdy3BQkMIqN4G0MK1qc4D7S76Lj8ahjD3kWVFEWS8sOpwYZ zIoPeNBVmtJ7eJEHtdgCoi0MdCnRJjgD/HUz7IZGwsXT2Hp/P+m4bz/jg 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQBK+xFY/5xdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoBAQEBAR1YfQeNMJZ/lD+CBxwLhXsCGoFjPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRjAQEEAQEBIBE6CxACAQgYAgImAgICJQsVEAIEAQ0FFIhADrJRjHoBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEXBYEHiguER4MEglsBBI5Ki0wBkCGQBI0LhAABHjZ?= =?us-ascii?q?fhQlyh1aBCQEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,404,1473120000"; d="scan'208";a="162597434" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2016 13:08:02 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u9RD82cd014642 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Oct 2016 13:08:02 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Oct 2016 09:08:01 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 27 Oct 2016 09:08:01 -0400 From: "Acee Lindem (acee)" To: Job Snijders , "t.petch" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-05.txt Thread-Index: AQHSL7ywsnz8goa3QkC7xxMNUyw0V6C8LUBfgABFOwD//9RSAA== Date: Thu, 27 Oct 2016 13:08:01 +0000 Message-ID: References: <147750904648.2927.9899493365277493754.idtracker@ietfa.amsl.com> <20161026191854.GD37101@Vurt.local> <011701d23045$f59009e0$4001a8c0@gateway.2wire.net> <20161027114418.GT37101@Vurt.local> In-Reply-To: <20161027114418.GT37101@Vurt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.200] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 13:08:08 -0000 SGkgSm9iLCBUb20sIA0KDQpPbiAxMC8yNy8xNiwgNzo0NCBBTSwgIklkciBvbiBiZWhhbGYgb2Yg Sm9iIFNuaWpkZXJzIg0KPGlkci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqb2JAbnR0 Lm5ldD4gd3JvdGU6DQoNCj5IaSBUb20sDQo+DQo+T24gVGh1LCBPY3QgMjcsIDIwMTYgYXQgMTI6 MzE6MzJQTSArMDEwMCwgdC5wZXRjaCB3cm90ZToNCj4+IGEgbWlub3IgYWRtaW5pc3RyYXRpdmUg cG9pbnQ7IHRoZSBSRkMgRWRpdG9yIGNvbW1vbmx5IGltcG9zZXMgYQ0KPj4gY29uc3RyYWludCBv ZiBmaXZlIG5hbWVzIG9uIHRoZSBmaXJzdCBwYWdlLCBhbmQgdGhpcyBsaXN0IGhhcyBub3cgZ3Jv d24NCj4+IHRvIHNpeC4gIEEgY29tbW9uIHByYWN0aWNlIGlzIHRvIGhhdmUganVzdCBvbmUgbmFt ZSBvbiB0aGUgZnJvbnQsIHRoYXQNCj4+IG9mIHRoZSBwZW4taG9sZGVyLCBhbmQgbGlzdCB0aGUg b3RoZXJzIGF0IHRoZSBiYWNrLCBkaWZmZXJlbnRpYXRpbmcsIGF0DQo+PiB0aGUgYmFjaywgYmV0 d2VlbiB0aG9zZSB3aG8gaGF2ZSBtYWRlIGEgbWFqb3IgY29udHJpYnV0aW9uIGFuZCB0aG9zZSB3 aG8NCj4+IGhhdmUgbm90LiAgQ3V0dGluZyBvdXQgb25lIGZyb20gc2l4IG1heSBiZSBtb3JlIHBy b2JsZW1hdGljOi0oDQo+DQo+VGhpcyBpcyBub3QgYSBwcm9ibGVtLiBMb29raW5nIGF0IHRoZSBs YXN0IDEwMDAgcHVibGlzaGVkIFJGQ3MsIHJvdWdobHkNCj4zJSBvZiBSRkNzIGhhdmUgbW9yZSB0 aGFuIDUgYXV0aG9ycyBsaXN0ZWQuIElmIGFueXRoaW5nLCBpdCB3aWxsIGJlDQo+c29tZXRoaW5n IGJldHdlZW4gdGhlIFJGQyBFZGl0b3IgYW5kIHRoZSBBdXRob3JzIG9mIHRoaXMgZHJhZnQuDQoN Ckkga25vdyB0aGF0IGFzIE9TUEYgY2hhaXIgSeKAmXZlIGFza2VkIGZvciBleGNlcHRpb25zIHRv IHRoaXMgcnVsZSB3aGVuIHdlDQpiZWxpZXZlIGFsbCB0aGUgYXV0aG9ycyBoYXZlIG1hZGUgYSBz dWJzdGFudGl2ZSBjb250cmlidXRpb24uDQoNClRoYW5rcywNCkFjZWUNCg0KDQoNCg0KPg0KPlRo YW5rcyBmb3IgeW91ciBjb25jZXJuIQ0KPg0KPktpbmQgcmVnYXJkcywNCj4NCj5Kb2INCj4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPklkciBtYWls aW5nIGxpc3QNCj5JZHJAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkcg0KDQo= From nobody Thu Oct 27 06:23:17 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D2912949F for ; Thu, 27 Oct 2016 06:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 QJnXJO6PhwCV for ; Thu, 27 Oct 2016 06:23:02 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696E81293EE for ; Thu, 27 Oct 2016 06:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3798; q=dns/txt; s=iport; t=1477574573; x=1478784173; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5oadUH1fFWjgCsZgN7U7LJKE/+M63RTPyhX/FNJ7ET8=; b=O5n4Dy7UmNOaJub2gCK7VJA+wNNxk17CIhxBot95cubgPZWqvMG50aWq X7E1nKGbDDWzwe5W7+InFYIVbJbERKnIgYuzXcFz5VeMk8b8CvR1B2xCQ 8HzSidXueVoOTl7fHEw3STdI5pejpXpKG1zREuW6foZPRN4f4nN+F30m9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQAq/xFY/5JdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoBAQEBAR1YfQeNMJZ/lD+CBxwLhXsCGoFdPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRiAQEBAwEBAQEgEToLEAIBCBgCAiYCAgIlCxUQAgQBDQUUiDgIDrJXjHoBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEXBYEHiguER4MEglsFmhYBkCGQBI0LhAABHjZ?= =?us-ascii?q?fg0+BOnKGKSuBAoEJAQEB?= X-IronPort-AV: E=Sophos;i="5.31,404,1473120000"; d="scan'208";a="340288197" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2016 13:22:52 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u9RDMqGt004308 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Oct 2016 13:22:52 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Oct 2016 09:22:51 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 27 Oct 2016 09:22:51 -0400 From: "Acee Lindem (acee)" To: Job Snijders , "marco@lamehost.it" Thread-Topic: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) Thread-Index: AQHSMDgfTBxv8SJv/02s2RN9AVvwdqC8WqQAgAAFdQD//+niAA== Date: Thu, 27 Oct 2016 13:22:51 +0000 Message-ID: References: <20161027095404.GP37101@Vurt.local> <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <413402e00e4c25dea495842b8e94fa1c@www.lamehost.it> <20161027104158.GD34682@Vurt.local> In-Reply-To: <20161027104158.GD34682@Vurt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.200] Content-Type: text/plain; charset="utf-8" Content-ID: <19CC0BF3F30CE54FBAB1271B9602A6F1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 13:23:14 -0000 SGkgSm9iLCBNYXJjbywgDQoNCk9uIDEwLzI3LzE2LCA2OjQxIEFNLCAiSWRyIG9uIGJlaGFsZiBv ZiBKb2IgU25pamRlcnMiDQo8aWRyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpvYkBp bnN0aXR1dXQubmV0PiB3cm90ZToNCg0KPk9uIFRodSwgT2N0IDI3LCAyMDE2IGF0IDEwOjIyOjI2 QU0gKzAwMDAsIG1hcmNvQGxhbWVob3N0Lml0IHdyb3RlOg0KPj4gPj4gSSB3YXMgc3VnZ2VzdGlu ZyB0aGUgc2FtZSB0aGluZyBvdXQtb2YtbGlzdCB0b2RheS4NCj4+ID4+IFdlIHNob3VsZCByZWFs bHkgYXNzaWduIH41IHZhbHVlcyB0byBleHBlcmltZW50YWwvZGV2ZWxvcG1lbnQNCj4+cHVyb3Bv c2VzDQo+PiA+PiANCj4+ID4gVGhlIHByb2JsZW0gaGVyZSBpcyB0aGF0IHBlb3BsZSBhcmUgbm90 IGFiaWRpbmcgdGhlIHJ1bGVzLCBhbmQNCj4+b2ZmZXJpbmcNCj4+ID4gbW9yZSBjb2RlcG9pbnRz IHdpbGwgb25seSB3b3JrIGlmIHBlb3BsZSBhYmlkZSB0aG9zZSBydWxlcy4gSSBoYXZlIG5vDQo+ PiA+IGNvbmZpZGVuY2UgdGhhdCBtb3JlIGRldiBjb2RlcG9pbnRzIHJlc29sdmUgdGhlIGlzc3Vl Lg0KPj4gPiANCj4+IA0KPj4gSSBhbSBqdXN0IHRyeWluZyB0byBjb3BlIHdpdGggdGhlIHN0YXR1 cyBxdW8uICBWZW5kb3JzIGFyZSBzcXVhdHRpbmcNCj4+IGNvZGVwb2ludHMgZm9yIHRoZWlyIG93 biBwdXJwb3NlcywgaXQgaXMgb2J2aW91c2x5IGlzIGJhZCBhbmQgdGhleQ0KPj4gc2hvdWxkbid0 LCBidXQgdGhleSBkby4NCj4+IA0KPj4gSSBjYW4gdW5kZXJzdGFuZCBob3cgYSBzaW5nbGUgdmFs dWUgbWF5IG5vdCBiZSBlbm91Z2ggZm9yIGxhcmdlDQo+PiBlbnZpcm9ubWVudHMgd2l0aCBtdWx0 aXBsZSBkZXZlbG9wbWVudCBwcm9jZXNzZXMuICBTbyBpIHRoaW5rIHRoYXQgd2UNCj4+IHNob3Vs ZCB0cnkgYWRkcmVzcyB0aGUgInVucGxlYXNhbnQiIGhhYml0IG9mIHNxdWF0dGluZyB3aGF0IHRo ZXkNCj4+IHNob3VsZCBhc2sgZm9yIGJ5IGdpdmluZyB0aGVtIGVub3VnaCByb29tIHRvIHdvcmsg d2l0aC4NCj4NCj5JZiB5b3UgY2FuJ3QgaXNvbGF0ZSB5b3VyIGZlYXR1cmVzIGluIGRldmVsb3Bt ZW50IGJyYW5jaGVzLCBzb21ldGhpbmcgaXMNCj5zdHJhbmdlIGluIHlvdXIgZGV2ZWxvcG1lbnQg cHJvY2Vzcy4gVGhpcyBpcyBvZiBjb3Vyc2UgYSBzdWJqZWN0aXZlDQo+c3RhdGVtZW50LCBJJ2Qg bGlrZSB0byBoZWFyIGZyb20gbW9yZSBmdWxsdGltZSBpbXBsZW1lbnRvcnMgd2hhdCB0aGVpcg0K PnRha2Ugb24gdGhpcyBpcy4NCg0KSW4gb3VyIGNhc2UgKENpc2NvIE5YLU9TKSwgdGhlIGNvZGUg cG9pbnQgd2FzIHVzZWQgZm9yIHRoZSBCR1AgUmVtb3RlIE5leHQNCkhvcCBhdHRyaWJ1dGUgKGRy YWZ0LXZhbmRldmVsZGUtaWRyLXJlbW90ZS1uZXh0LWhvcCkuIFdoZW4gdGhlIGFwcHJvYWNoDQp3 YXMgYWJhbmRvbmVkLCB0aGUgbWlzdGFrZSBtYWRlIHdhcyBub3QgdG8gcmVtb3ZlIHRoZSBhdHRy aWJ1dGUgaGFuZGxpbmcNCmFuZCB2YWxpZGF0aW9uLiBIZW5jZSwgTlgtT1Mgc3dpdGNoZXMgd2ls bCBub3QgcHJvcGFnYXRlIHRoZSAzMSBhdHRyaWJ1dGUNCihhc3N1bWluZyB2YWxpZGF0aW9uIGZh aWx1cmUgYW5kIGFuIG9wdGlvbmFsIHRyYW5zaXRpdmUgYXR0cmlidXRlKS4gQXMgeW91DQp3b3Vs ZCBndWVzcywgdGhpcyBpcyBub3Qgc29tZXRoaW5nIHRoYXQgd291bGQgc2hvdyB1cCBpbiBub3Jt YWwgcmVncmVzc2lvbg0Kb3IgZmVhdHVyZSB0ZXN0aW5nIHNpbmNlIGF0dHJpYnV0ZSAzMSB3YXMg dW5hbGxvY2F0ZWQuIFdlIGRlYmF0ZWQgdGhlDQpzZXZlcml0eSBvZiB0aGlzIHByb2JsZW0gZ2l2 ZW4gTlgtT1PigJlzIFBsYWNlIEluIE5ldHdvcmsgKFBJTikgYnV0IGRlY2lkZWQNCml0IHdhcyBi ZXR0ZXIgdG8gZGlzY2xvc2UgdGhlIHByb2JsZW0uIEFzIEpha29iIGFscmVhZHkgaW5kaWNhdGVk LCB3ZSBhcmUNCnNvcnJ5IGZvciB0aGUgb3ZlcnNpZ2h0Lg0KDQpUaGFua3MsDQpBY2VlICANCg0K DQo+DQo+PiBNeSAqd2lzaCogaXMgaW4gdGhhdCB3YXkgdmVuZG9ycyB3aWxsIHVzZSBleHBlcmlt ZW50YWwgc3BhY2UgaW4NCj4+IGRldmVsb3BtZW50IHBoYXNlIGFuZCBnZXQgYmFjayB0byB0aGUg Y29tbXVuaXR5IHRvIGdldCBhbiBhc3NpZ25tZW50DQo+PiB3aGVuIHJlYWR5Lg0KPg0KPklmIHlv dSBsb29rIGF0IHRoZSBudW1iZXJzIHRoYXQgaGF2ZSBiZWVuIHVzZWQgc28gZmFyOiAzMCwgMzEs IDEyOSAtDQo+dGhvc2UgYXJlIGFsbCBzcXVhcmUgaW4gdGhlIG1pZGRsZS4gSWYgeW91IGhhdmUg Y29uY3VycmVudCBwcm9qZWN0cyBhbmQNCj5uZWVkIG11bHRpcGxlIGJncCBwYXRoIGF0dHJpYnV0 ZXMsIEknZCBleHBlY3Qgc29tZW9uZSB0byBzcXVhdCBvbiB0aGUNCj5oaWdoIG51bWJlcnM6IDI1 NCwgMjUzLCAyNTIsIGV0YyAtIGJlY2F1c2UgSUFOQSwgb2J2aW91c2x5IGlzIGNvdW50aW5nDQo+ dXB3YXJkcy4gVGhlIHByZXNlbmNlIG9mIGxvdyAobm90IHlldCB1c2VkKSBzcXVhdHRlZCBjb2Rl cG9pbnRzLCBzaG93cw0KPm1lIHRoYXQgdGhlIHNvY2lhbCBjb250cmFjdCBpcyBub3QgZm9sbG93 ZWQsIHNvIG1ha2luZyBtb3JlIHJ1bGVzIHdvbid0DQo+YWRkcmVzcyB0aGF0Lg0KPg0KPktpbmQg cmVnYXJkcywNCj4NCj5Kb2INCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPklkciBtYWlsaW5nIGxpc3QNCj5JZHJAaWV0Zi5vcmcNCj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQo= From nobody Thu Oct 27 07:53:32 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EC7129691 for ; Thu, 27 Oct 2016 07:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 eMRQHfbeDRuH for ; Thu, 27 Oct 2016 07:53:26 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA31D129552 for ; Thu, 27 Oct 2016 07:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2094; q=dns/txt; s=iport; t=1477579961; x=1478789561; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=93DwiGQHNmciAWCD3RCwmKIMi4klupcNm0alh1XWXw4=; b=C12S1HOrsW/KvPZKYVYh9olmYm0/B/7Z4xXuo6ZURfG7/dUQR87uU1P3 P1U5s4OKuTbkXfq2ZqU7c3IJRZ3ZCOQmvFXAOu49lzHMLGZ1RqlZD67aL EK2iwj5bu2ALgRfnyoqzzmpEPF0eSf/ZSbikEujlpV8JY/eLTFqfDKmvG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQAKFBJY/51dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoBAQEBAR1YfQeNMJZ/lD+CBx0LhXsCGoFiPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRjAQEEAQEBGgYROgsQAgEIGAICJgICAiULFRACBAENBRSIQA6yf4x5AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBFwWBB4oLhCSDJ4JbAQSOSotMAZAikASNC4QAAR4?= =?us-ascii?q?2X4UJcoYogS6BCQEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,553,1473120000"; d="scan'208";a="162639002" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2016 14:52:40 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u9REqeFJ008891 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Oct 2016 14:52:40 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Oct 2016 10:52:39 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 27 Oct 2016 10:52:39 -0400 From: "Acee Lindem (acee)" To: Job Snijders , "t.petch" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-05.txt Thread-Index: AQHSL7ywsnz8goa3QkC7xxMNUyw0V6C8LUBfgABFOwD//9RSAIAAHTuA Date: Thu, 27 Oct 2016 14:52:39 +0000 Message-ID: References: <147750904648.2927.9899493365277493754.idtracker@ietfa.amsl.com> <20161026191854.GD37101@Vurt.local> <011701d23045$f59009e0$4001a8c0@gateway.2wire.net> <20161027114418.GT37101@Vurt.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.200] Content-Type: text/plain; charset="utf-8" Content-ID: <9C1EFB96D54CDD4D9911CE02B828F78E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 14:53:30 -0000 DQoNCk9uIDEwLzI3LzE2LCA5OjA4IEFNLCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNj by5jb20+IHdyb3RlOg0KDQo+SGkgSm9iLCBUb20sIA0KPg0KPk9uIDEwLzI3LzE2LCA3OjQ0IEFN LCAiSWRyIG9uIGJlaGFsZiBvZiBKb2IgU25pamRlcnMiDQo+PGlkci1ib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZiBqb2JAbnR0Lm5ldD4gd3JvdGU6DQo+DQo+PkhpIFRvbSwNCj4+DQo+Pk9u IFRodSwgT2N0IDI3LCAyMDE2IGF0IDEyOjMxOjMyUE0gKzAxMDAsIHQucGV0Y2ggd3JvdGU6DQo+ Pj4gYSBtaW5vciBhZG1pbmlzdHJhdGl2ZSBwb2ludDsgdGhlIFJGQyBFZGl0b3IgY29tbW9ubHkg aW1wb3NlcyBhDQo+Pj4gY29uc3RyYWludCBvZiBmaXZlIG5hbWVzIG9uIHRoZSBmaXJzdCBwYWdl LCBhbmQgdGhpcyBsaXN0IGhhcyBub3cgZ3Jvd24NCj4+PiB0byBzaXguICBBIGNvbW1vbiBwcmFj dGljZSBpcyB0byBoYXZlIGp1c3Qgb25lIG5hbWUgb24gdGhlIGZyb250LCB0aGF0DQo+Pj4gb2Yg dGhlIHBlbi1ob2xkZXIsIGFuZCBsaXN0IHRoZSBvdGhlcnMgYXQgdGhlIGJhY2ssIGRpZmZlcmVu dGlhdGluZywgYXQNCj4+PiB0aGUgYmFjaywgYmV0d2VlbiB0aG9zZSB3aG8gaGF2ZSBtYWRlIGEg bWFqb3IgY29udHJpYnV0aW9uIGFuZCB0aG9zZQ0KPj4+d2hvDQo+Pj4gaGF2ZSBub3QuICBDdXR0 aW5nIG91dCBvbmUgZnJvbSBzaXggbWF5IGJlIG1vcmUgcHJvYmxlbWF0aWM6LSgNCj4+DQo+PlRo aXMgaXMgbm90IGEgcHJvYmxlbS4gTG9va2luZyBhdCB0aGUgbGFzdCAxMDAwIHB1Ymxpc2hlZCBS RkNzLCByb3VnaGx5DQo+PjMlIG9mIFJGQ3MgaGF2ZSBtb3JlIHRoYW4gNSBhdXRob3JzIGxpc3Rl ZC4gSWYgYW55dGhpbmcsIGl0IHdpbGwgYmUNCj4+c29tZXRoaW5nIGJldHdlZW4gdGhlIFJGQyBF ZGl0b3IgYW5kIHRoZSBBdXRob3JzIG9mIHRoaXMgZHJhZnQuDQo+DQo+SSBrbm93IHRoYXQgYXMg T1NQRiBjaGFpciBJ4oCZdmUgYXNrZWQgZm9yIGV4Y2VwdGlvbnMgdG8gdGhpcyBydWxlIHdoZW4g d2UNCj5iZWxpZXZlIGFsbCB0aGUgYXV0aG9ycyBoYXZlIG1hZGUgYSBzdWJzdGFudGl2ZSBjb250 cmlidXRpb24uDQoNCk5vdGUgdGhhdCBJ4oCZbSBub3QgaW4gYSBwb3NpdGlvbiB0byBtYWtlIHRo ZSBjYWxsIGZvciB0aGlzIGRyYWZ0IGFuZCBvbmx5DQp3YW50ZWQgdG8gcG9pbnQgb3V0IHRoYXQg dGhlIFJGQyBhdXRob3IgbGltaXQgaXMgYSBndWlkZWxpbmUgYXMgb3Bwb3NlZCB0bw0KYSBoYXJk IGFuZCBmYXN0IHJ1bGUuDQoNClRoYW5rcywNCkFjZWUgDQoNCg0KPg0KPlRoYW5rcywNCj5BY2Vl DQo+DQo+DQo+DQo+DQo+Pg0KPj5UaGFua3MgZm9yIHlvdXIgY29uY2VybiENCj4+DQo+PktpbmQg cmVnYXJkcywNCj4+DQo+PkpvYg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+SWRyIG1haWxpbmcgbGlzdA0KPj5JZHJAaWV0Zi5vcmcNCj4+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCj4NCg0K From nobody Thu Oct 27 08:31:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016001294C6 for ; Thu, 27 Oct 2016 08:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 0bWku0P0ifi2 for ; Thu, 27 Oct 2016 08:31:08 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0110.outbound.protection.outlook.com [104.47.41.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC56E1293E1 for ; Thu, 27 Oct 2016 08:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lda9G64fhM3mTcfr+nn840wCtmp6k6tAnPqy6LbAd9Q=; b=P0Esku/oxGqER8NnsarN1KEOUD/x1IR4tmV1VDrOKiTHr49JQmHVmEc16NPAruAX0SPqgZzIQEByP8hp+axJJOgeP0eYaswcn2/RkTDOOBXkPL9vjsz8I5kgfWDKT0E0gGe2Y+SC4uQVaBIUne2NECtg88RKt9SqTUc9W5fFEJE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from kconry-sslvpn-nc.jnpr.net (66.129.241.14) by SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Thu, 27 Oct 2016 15:31:07 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <20161027114418.GT37101@Vurt.local> Date: Thu, 27 Oct 2016 11:31:03 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <95B70AF0-0782-4FBF-BCBC-D50889F56148@juniper.net> References: <147750904648.2927.9899493365277493754.idtracker@ietfa.amsl.com> <20161026191854.GD37101@Vurt.local> <011701d23045$f59009e0$4001a8c0@gateway.2wire.net> <20161027114418.GT37101@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BN6PR1601CA0010.namprd16.prod.outlook.com (10.172.104.148) To SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20) X-MS-Office365-Filtering-Correlation-Id: 1e9df5bd-276e-417a-0ac9-08d3fe7e4582 X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 2:h8HU8U+IoGqzKaEw+mxHwNlMhT+lI85us0nLuZ46QVg/fvxjSAtx6zbGZKl6W5k3UMcRjF2z8frxnaE9xPLH6qS0uLR/b7OayeVrZFhOGWuZM46fDbeTI84W9lp1yU4u2gNQqTdqzmQfRjlSmABarPn/T16s0u+X7MkISDygMx4X4m5beZN9OYMUciAetonh5slCxpFfjZrLPYR9fUjymA==; 3:uQJVVCG8BiIruak3frk8TyUMjW0pztDBMQHyUgMfROWJ6lFXrHbVIAO9hD+f+8j7BjPAjYG9OJaDQh4beLDbCXdKeJwuEXWE5CsWbtwC/AoZDuRRe7Mkg1RI00hP3+mBlEBNZsJb+nRgbpEWCiEsLA==; 25:vabTjrB0nYdx1hZ13rMsafCmqrkU6c9w1tH5tqr1yk+9IQ6lMfwxMbR6iq/O7IfTgnsd7EdtEVkDdp/ZNjCtn1o6CiD0hILoAH93heH7+ZvLaGuIolejprCxi5d/bVQGrJTHcDDFc8JYG1eDYvP9fg2axpQoefUKFopNtLck1xEyOtlUnMnWDXqEZMCL7nbfVeofsNj8z3vmEZN1XCRm1tbJYU7eZx0wkUi+lrfWKQZ4GXq56txNqUFmcarkFSUFG6hKYq+g4j21sv3hExmNdDA1oHGqBkyxnrmejXNTI62D0xo3CgqlRuqff7ZpHv9MIP/env9hIknsFrVQH0r/BdF8/tq+bEIxMcqiM0MvFQW8/6InjJd7OrJ5iFRmJ6MRUdbc8NrRqbDzhRp6syCMxMKZUM97NhStjsxw3cQmQkE919QmLThRW0DWvWhnqez6 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2511; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 31:IGhP8UJYQRYV158keR5iu0RX4rNn4ZdvLQYRXe3iobS7f1+ChZFKB682JQ5J1FfEPLE+aNYa2Rtbo/1BkI6/EQVcaQyTFSYCBamEO0/uXtao1R2KANu9+cmaL/BG/xYt/jbjN/tPwiqytTDQxpAXgdrMREN+KeV4BAIsaJtkdVxW9ZqTXMRCeLzGulskWAxoa4Zn4RQjb62dxDNsk0Or9iuXoTPHHSjKfOOEyGbjMW44ieA9Vxp4KB1D4JtWk/mu; 20:DP4nyThjnKCz054fGm5ZLR+yf5I7qKdvDlszUb8TEKNKLgW+p4j5nPYNgmqF4Hmr7wcV7lMTadEhp4jPGYv3X3M57AWGYyXknd4T350hVvFtpJ9MOgLg+O/tBchg7BG6m7lSruGX6Huup9WtowCUXHUkHPaka/cj5AE2MBIUGRSg/2R36z88p82ak0NAaRm6cEgPSurA93ABI2Sh89qTEERbWubllFN5IGp2PrnnrE8h8Vf9eW7QQzkj1TWA6cw/S6jcavPamAvl1g7D74yWP6YxSzl2yt/p4poq2ROdY+xZQKlsyoq6TdriehUs3NI+Bb9kX2caMfcKusOQ/k7w4r2AAuoqWNSyhiC/z0Z6aUJp3GjOG2sY4DumE9MvOqnTbo2fQwRSVQFVahVXhm7OiqUHT3/+cIE2FLGfGl65+bgowsfVApwf3fPAG5k0kNMXvJ4o1uKNAFJTtc/sH1jlJhNBS4x/wIW+sZubKUh3QBynONzk6uRoTy0IoGALmxmds6jkgAikLfIshniGvr1TlHcjLKLPaQngypMY6vObvixIbb/63tGIFedWH6cFBNdhO145Mn+02IJkgCiHHyuza1Y95lBMIWgZmD8bwnOdb2M= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:SN2PR05MB2511; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2511; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 4:BHbGBfBrhVQn5A5wpOuLHVfWqLS/fJrOytDaVmI3xz2m04zqVedLKYOrOPbGsw9hMcfU3zigB6Gr48GXqaagWIN+93tH6gnkOfbrwi5auw4lg4vBiow9+3vTf6vdx7zjoafzj7vBLpTiuEPvOINv9cL4N+lOk7WOL4EdqugfOQBSW5TURidV3RYa6ixuIOdkwb5FYPBF3DhaHyboG5qDnkjXg7wqHEC/w0LBaKI0qM36VELnYnlRFDq/oUipA+eZQJQn7qLS8xj/1DUjKsceAedDzPzI/TRNmKmIxyq8DyLKHESS23N5NbTPCn90FaIwl2SwhzXU1HKnhLv8O74P3bPrF8S8zUp7pn/2cVbueDf5GlD0SVTBEGOGSne5JOpH+8K+h8V4CCmrWEJJTgICgkcG86e/794W6y0NoipNYxo= X-Forefront-PRVS: 0108A997B2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(24454002)(377454003)(189002)(199003)(106356001)(8746002)(81156014)(81166006)(110136003)(8676002)(50226002)(558084003)(33656002)(6916009)(7736002)(2950100002)(8666005)(5660300001)(305945005)(15975445007)(53416004)(36756003)(92566002)(68736007)(82746002)(7846002)(42186005)(77096005)(105586002)(23726003)(3846002)(50466002)(586003)(6116002)(66066001)(97736004)(4326007)(47776003)(50986999)(6666003)(69596002)(93886004)(83716003)(76176999)(101416001)(97756001)(2906002)(230783001)(86362001)(19580405001)(19580395003)(46406003)(57306001)(189998001)(7059030)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2511; H:kconry-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2511; 23:WLUnd0IHC6PdhkOCes95Bbl3CutBUC+zxW2sF4vmR?= =?us-ascii?Q?FNHM9UHJMBHAs22ADG56u8CnVnAagJzAKAitpeyPDjiuM77dP25jju0LCzON?= =?us-ascii?Q?0VNcPh+nMLq4cLvLxrhF0AFUQe2m9xLFZPRYPjEatzTPLUnZfzjDXS7vKAQJ?= =?us-ascii?Q?QjSjm4N3rNnwGPlxN9Avo1awxQTvfrrd+3nmw57LfvUJ8Gn6Ol2l3AHyoPWM?= =?us-ascii?Q?bloBdBPYQNiL+eU9xEkX95q7Chh5ZLqluXKRhHevaGZ2Akmd3R/NIOVDRSqD?= =?us-ascii?Q?s4Z1Da30w9XrBqBU6dNRJullY2q/i9QVzsSPBcruN/VRbxf5Jcv8wBJxFnmg?= =?us-ascii?Q?0mGzWQ0OeyRE8Ovqxt5LTatDarSKqTHw1SE/JouYcCuoSLbgJIojhVrlnElX?= =?us-ascii?Q?QMpG1mH2BGXMUCaQF2Me/fogy0P+71dV3/tU0vX2fZYA6x0cJF9sozXDSWMq?= =?us-ascii?Q?NWxRv6kARjAIiAWrXGrRMIsW301KxWnRX98Y/dUVKZ2GSdniCvqBvQAiE65w?= =?us-ascii?Q?3ALH2Pn46nWRJryvKHGDHSvRQzvyI0rVcaqRx1GpQc2YY+l37xiRZBBRWD32?= =?us-ascii?Q?VdRsebXlZYfJdeIiYKLRY0x3FCHu/jTzGlNu4zz89rp+FHK9VYK3gmyxpfa0?= =?us-ascii?Q?LycQDTa8Hs/7hkASNrUpHkycFCyJJKg9XnX/uliQrtUhQQHfOSPewRGSry04?= =?us-ascii?Q?tpVYqQBWUnBCDHqlZ7IDll+cnByYWPcVXSt5+DEUSzBI4P8G4ji+jfpjfUXO?= =?us-ascii?Q?eMtM1GfthrjoN78pQjo0jWeAyHE51E0Zc+uL6qjV4y8lzRUtIUb2liNmJjs7?= =?us-ascii?Q?0PO5yr6iKCK9Tzg5x08GcYHG4Kcs+GP4HO5bepRupdFeL6q27hzVVebcVLFm?= =?us-ascii?Q?7VpRqCPxocY5DOyovu2QVWyGPg2R80HMKG4Za31a7sHxRP8qjEOJRdRdMlp7?= =?us-ascii?Q?BPLfdusgxHCOBNH4uAI26luUYHNvzGW4ivPZk+M+9saZeGT2M6TcOVQXysrG?= =?us-ascii?Q?lnBC1/k4gQktRho8UmsRRKOPJvj/u5ukF4O4gjN7XlG6z06NY77fXzfxHr2w?= =?us-ascii?Q?tO0pSfvCtIpT8Gm4RKrOowb+6vBg1O84GBERjLuFyxz/NnO0Drq6yeyt7WUH?= =?us-ascii?Q?KMk2J+b2Ww1cbcGfhbOva5HSVH8IAdgcD0FPJNYIASIo+zUFnjHR+xEEztuq?= =?us-ascii?Q?ilrFfxC9T3NGmS/N35cQ9fkMv1HSshoMfXO+3lg0ZvgOua4OF3bqdzoK1BDU?= =?us-ascii?Q?XRannRcjO1DrQ462R38Dri4oXN7JxoSeAbpX0lQQ3YA/YWME0aEvw/KCD3Bt?= =?us-ascii?Q?KC57pxCWNbkP3bc2Ubam81Ttby1x6CE8khBKNbp7InGHoViqR9/Mq2EdwXtQ?= =?us-ascii?Q?/KC5tgHRj3ceTPP6KjhhGrCEEzYYrQcMJfYkdRX+azOMNiphe1rasJwNj9b9?= =?us-ascii?Q?k+IHI8+dA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 6:rzTYLZfjOywUK02OU1T8YncWzLx7iE1zSPwUmI8/MsMheABJyucgRXb06tSNvjl0igK/ey4eraFCHMnhhPyI6r3GPYOo1SAo7+ztTYMsQ8P6iwEGApOhW4IRyHt7iCi87GO98V7ZT0Dvu9AgosNWWIf9SRmE5DJ0Nbb8LGEuXMJhUbrPvaei/V744fWE693JhVyJBt3Crxa4XPzDSzJD5ORAfR+STGcJFuk+sHLWCp/HZS1BXStVLjVgmSaU6UQJys5xopA10KwiT+QHpSAAnO9AXTSKnQq1pLrTRHOGoy9Y+No8NHhhcWwbS97KCsIj2s7YweNG4HYlSEm/PntZfHAAB9kem6+dODqOC6wDsag=; 5:UpY9Xr7Sdje9l6uFVCLRrNefytlu3JNeyZWCwmu1I+fgm73H/lU2ytKtjJ6EpNI5ETcKH4qvYmOvKit9DJjedaSBbK6viDeKc7ZZBBMFuk9br+Re5FOtvTVOk+uKWklkfnskAiBF6qv+FGwMZdVkBw==; 24:zdp18G2R8LB20PS7FBWg2RaXYCEvgvKe01KQbsWZ0eCc43OGx7sYCTVsIJAmSKqnqRGm0S2rrMtZZ1l1vYnPXW2lRAOsBrfItgsWCX1Rd7A= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 7:9uO7IIsKE5tShXkC/yqSHzonStr/WSOra03UVleoycv6lC1kF2ccrruEc1nDEeuOQFFlibM9vhDVvjVWCTdUC8tI0EdS/tQqJbJIA4NQ2VnaNkP8ahPBTm95eDZvGB2Vn875nJXarIrE9ib3rfZHNmLQJHBWFfgY1Ae+TbHdIXpQGuPqOXj1rvXx44o7S/PbmlGATCmm2e7sG619RPaWWfF58sVFRhwgxtdIQO6NnXODUIuUESRxLDjp5ofmMWMwrK6Xq3mj0R7ckoS4A2/oq6ncrHfD7ktR02X2xNdQFH4ixRH0HEO7jogLliCF9oPa0VLCHwQ5Kint0nreD2n6bnVX9emGzj5mHex3uW8O1XI= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2016 15:31:07.0272 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2511 Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 15:31:13 -0000 On Oct 27, 2016, at 7:44 AM, Job Snijders wrote: > it will be > something between the RFC Editor and the Authors of this draft. Actually between the IESG and the authors, see RFC 7322 and related IESG = statement = (https://trac.tools.ietf.org/group/iesg/trac/wiki/FrontPageAuthors). --John= From nobody Thu Oct 27 11:39:47 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC9912965B for ; Thu, 27 Oct 2016 11:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6wO5bP007Vwt for ; Thu, 27 Oct 2016 11:39:42 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id A40CA1295E9 for ; Thu, 27 Oct 2016 11:39:42 -0700 (PDT) Received: from www.lamehost.it (unknown [80.76.80.23]) (Authenticated sender: marco@lamehost.it) by seele.lamehost.it (Postfix) with ESMTPSA id 19397746D2; Thu, 27 Oct 2016 20:39:23 +0200 (CEST) Mime-Version: 1.0 Date: Thu, 27 Oct 2016 18:39:22 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <89511cb97f8896fd334c109ae498285e@www.lamehost.it> X-Mailer: RainLoop/1.10.3.151 From: marco@lamehost.it To: "Job Snijders" In-Reply-To: <20161027104158.GD34682@Vurt.local> References: <20161027104158.GD34682@Vurt.local> <20161027095404.GP37101@Vurt.local> <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <413402e00e4c25dea495842b8e94fa1c@www.lamehost.it> X-Originating-IP: 31.159.112.160 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Thu, 27 Oct 2016 20:39:23 +0200 (CEST) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Thu, 27 Oct 2016 20:39:23 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.99.2 at seele X-Virus-Status: Clean Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 18:39:45 -0000 October 27, 2016 12:42 PM, "Job Snijders" wrote:=0A> = On Thu, Oct 27, 2016 at 10:22:26AM +0000, marco@lamehost.it wrote:=0A> = =0A>> I was suggesting the same thing out-of-list today.=0A>> We should r= eally assign ~5 values to experimental/development puroposes=0A>> =0A>> T= he problem here is that people are not abiding the rules, and offering=0A= >> more codepoints will only work if people abide those rules. I have no= =0A>> confidence that more dev codepoints resolve the issue.=0A>> =0A>> I= am just trying to cope with the status quo. Vendors are squatting=0A>> c= odepoints for their own purposes, it is obviously is bad and they=0A>> sh= ouldn't, but they do.=0A>> =0A>> I can understand how a single value may = not be enough for large=0A>> environments with multiple development proce= sses. So i think that we=0A>> should try address the "unpleasant" habit o= f squatting what they=0A>> should ask for by giving them enough room to w= ork with.=0A> =0A> If you can't isolate your features in development bran= ches, something is=0A> strange in your development process. This is of co= urse a subjective=0A> statement, I'd like to hear from more fulltime impl= ementors what their=0A> take on this is.=0A> =0A>> My *wish* is in that w= ay vendors will use experimental space in=0A>> development phase and get = back to the community to get an assignment=0A>> when ready.=0A> =0A> If y= ou look at the numbers that have been used so far: 30, 31, 129 -=0A> thos= e are all square in the middle. If you have concurrent projects and=0A> n= eed multiple bgp path attributes, I'd expect someone to squat on the=0A> = high numbers: 254, 253, 252, etc - because IANA, obviously is counting=0A= > upwards. The presence of low (not yet used) squatted codepoints, shows= =0A> me that the social contract is not followed, so making more rules wo= n't=0A> address that.=0A> =0A> Kind regards,=0A> =0A> Job=0A=0AJob,=0A=0A= I would say that your reasoning is based on speculations, but also is min= e as none of us works for a vendor.=0AI take your point and wait for othe= rs to comment.=0A=0ARegards From nobody Thu Oct 27 12:05:07 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4393C1296D7 for ; Thu, 27 Oct 2016 12:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GJnzJSdUff5L for ; Thu, 27 Oct 2016 12:05:04 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C551129781 for ; Thu, 27 Oct 2016 12:04:14 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id b80so52752368wme.1 for ; Thu, 27 Oct 2016 12:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tw56l3CQTRGF3gQrs8vWuEeHMQkvIKR3s4TWFRAl6To=; b=Z/KEYTWCCUxhDFsh/fN8Ky68vpWUiUxXgBfuos5jsGGzfheS1+jcpj9eJMKx4KnSup xvTmZ/OUtjMMjH8xoMFW+Fj9tk/FZQBTdF4htepnHE9mCoZNUTL7c2hDvuSIaMg8jiOY TNrTNrZXqQzahu5AucF75gUGsNfZjIA3cN0DU2D4zT0e3VHL+0P04CW6KeeiKKl86Qcq lnEiPobbByyAWrZP6k8ICJHvaWzHgopQr6PGxnJU6XLYntAZnGNbg626YXvWDVwATMWE XmWinNSuUZ8VkqZ46H0aeG8BRW4mzzyxCymIhtRraWV863AWt5wumAnWk+iXIw+dxxJE xXAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tw56l3CQTRGF3gQrs8vWuEeHMQkvIKR3s4TWFRAl6To=; b=L/uyWUHuIh5g6EPzFkq2YMiYbrsILyXXZsSrab51e70vj9vGTYeGK9thoO8eGCa7Y6 gDP7AEyhyvmW7PvpkcxssqK4B8hCtKTy49Mi87/gHplUG+fTMWrgLZgtoLyA0++bXJdI eBMMMFd3+hBkmGhnvgtKkIkJI3FbEMQUqoLRIHeLCIuFz0+UxeVvjoCyRY06/+Kp+UB9 SaTcM3G+dzDCNayZLT+VQMTnV2ZrUw0xlGs/3bc6tar4kQdiFHwQRE89fyQBKgHIKPSa 9e6eBABekNW7Cp2aeZElgW19U1MwIx+vckU7i9jYTwvYKyzp/lU/9lSI7WsWLlG85Bkc 17vg== X-Gm-Message-State: ABUngvcQMq1SMThFJxWw9qk8QRJIQz3YP1tmwkmiK6EBu16kwvKoekhcrqhgXeb5hoFeei8tArJGgvRJkIEQng== X-Received: by 10.28.222.70 with SMTP id v67mr200545wmg.84.1477595052953; Thu, 27 Oct 2016 12:04:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.207 with HTTP; Thu, 27 Oct 2016 12:04:12 -0700 (PDT) In-Reply-To: <20161027095404.GP37101@Vurt.local> References: <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> From: Brian Dickson Date: Thu, 27 Oct 2016 12:04:12 -0700 Message-ID: To: Job Snijders Content-Type: multipart/alternative; boundary=001a114b103c40dc66053fdd68d4 Archived-At: Cc: heasley , IETF IDR , Susan Hares Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 19:05:06 -0000 --001a114b103c40dc66053fdd68d4 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 27, 2016 at 2:54 AM, Job Snijders wrote: > On Thu, Oct 27, 2016 at 11:20:38AM +0200, Sander Steffann wrote: > > Op 26 okt. 2016, om 19:32 heeft marco@lamehost.it het volgende > geschreven: > > > October 26, 2016 6:57 PM, "heasley" wrote: > > >> Wed, Oct 26, 2016 at 12:43:23AM -0700, Brian Dickson: > > >> > > >>> Rather than deprecate the two sequential values, why not reserve a > > >>> small range which includes those values, for non-permanent > > >>> reservations for vendor development use? Say 30-35 inclusive? > > >> > > >> isnt this bgp path attribute 255? > > > > > > I was suggesting the same thing out-of-list today. > > > We should really assign ~5 values to experimental/development puroposes > > > > I think this would be useful both to allow for larger-scale testing of > > new attributes, and for vendors to be more easily be able to test > > multiple new attributes in-house. > > The problem here is that people are not abiding the rules, and offering > more codepoints will only work if people abide those rules. I have no > confidence that more dev codepoints resolve the issue. > The counter argument is very simple: If we don't offer more code points, they *definitely* won't use them (and thus abide by the rules). The consequence of offering already-squatted code points for this purpose, is that it makes it possible to abide by the rules (if they need multiple code points simultaneously). If the number of squatted code points was truly significant, compared to the pool of code points, I'd say concern would be warranted, but we aren't at that point, IMHO. (Significant, by my estimate, would be ~10% total, or ~10% of remaining, or at a run-rate of > 5% of remaining per year. Those are roughly 25, 20, and 10/yr respectively. We've seen 3/yr this year, but it is anomalous when we consider the last 20 years.) Providing a non-trivial, but small, fixed pool, would not be harmful, and would provide both a good way of enabling those who want to play by the rules, and greater visibility to who the parties are. If squatting continues after that pool is established, then we should think about what to do. Doing so now, is probably premature. Brian --001a114b103c40dc66053fdd68d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 27, 2016 at 2:54 AM, Job Snijders <job@ntt.net> wr= ote:
On Thu, Oct 27, 2016 at 11:20:38AM += 0200, Sander Steffann wrote:
> Op 26 okt. 2016, om 19:32 heeft m= arco@lamehost.it het volgende geschreven:
> > October 26, 2016 6:57 PM, "heasley" <heas@shrubbery.net> wrote:
> >> Wed, Oct 26, 2016 at 12:43:23AM -0700, Brian Dickson:
> >>
> >>> Rather than deprecate the two sequential values, why not = reserve a
> >>> small range which includes those values, for non-permanen= t
> >>> reservations for vendor development use? Say 30-35 inclus= ive?
> >>
> >> isnt this bgp path attribute 255?
> >
> > I was suggesting the same thing out-of-list today.
> > We should really assign ~5 values to experimental/development pur= oposes
>
> I think this would be useful both to allow for larger-scale testing of=
> new attributes, and for vendors to be more easily be able to test
> multiple new attributes in-house.

The problem here is that people are not abiding the rules, and offering
more codepoints will only work if people abide those rules. I have no
confidence that more dev codepoints resolve the issue.

The counter argument is very simple: If we don't offer = more code points,
they *definitely* won't use them (and thus = abide by the rules).

The consequence of offering a= lready-squatted code points for this purpose,
is that it makes it= possible to abide by the rules (if they need multiple code points
simultaneously).

If the number of squatted code = points was truly significant, compared to the pool
of code points= , I'd say concern would be warranted, but we aren't at that point,<= /div>
IMHO.

=C2=A0(Significant, by my estimate= , would be ~10% total, or ~10% of remaining,
or at a run-rate of = > 5% of remaining per year. Those are roughly 25, 20, and
10/y= r respectively. We've seen 3/yr this year, but it is anomalous when we<= /div>
consider the last 20 years.)

Providing a= non-trivial, but small, fixed pool, would not be harmful, and would
<= div>provide both a good way of enabling those who want to play by the rules= , and
greater visibility to who the parties are. If squatting con= tinues after that pool
is established, then we should think about= what to do. Doing so now, is probably
premature.

<= /div>
Brian
--001a114b103c40dc66053fdd68d4-- From nobody Fri Oct 28 04:08:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D80C129A96 for ; Fri, 28 Oct 2016 04:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 comv_Y6jJh9L for ; Fri, 28 Oct 2016 04:08:55 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 8CD96129A94 for ; Fri, 28 Oct 2016 04:08:55 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c051q-00069t-JK (job@us.ntt.net); Fri, 28 Oct 2016 11:08:55 +0000 Date: Fri, 28 Oct 2016 13:08:51 +0200 From: Job Snijders To: Thomas Mangin Message-ID: <20161028110851.GA966@Vurt.local> References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: heasley , IETF IDR , Susan Hares Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 11:08:56 -0000 On Fri, Oct 28, 2016 at 11:29:51AM +0100, Thomas Mangin wrote: > Finally, should a document be also published to officially kill > attributes 30 and 31 asking implementations to treat as withdraw (or > discard) any routes using them ? I've asked the chairs for guidance whether that should be part of the IANA considerations in the large communities draft or whether it should be a separate document. Kind regards, Job From nobody Fri Oct 28 04:24:31 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EAD129AAD for ; Fri, 28 Oct 2016 04:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.332 X-Spam-Level: X-Spam-Status: No, score=-7.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UZ0Q-FjNbp0I for ; Fri, 28 Oct 2016 04:24:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9BA129AA6 for ; Fri, 28 Oct 2016 04:24:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1c05Gn-0008Qk-Ai; Fri, 28 Oct 2016 11:24:21 +0000 Date: Fri, 28 Oct 2016 20:24:19 +0900 Message-ID: From: Randy Bush To: Job Snijders In-Reply-To: <20161028110851.GA966@Vurt.local> References: <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: heasley , IETF IDR , Susan Hares , Thomas Mangin Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 11:24:30 -0000 >> Finally, should a document be also published to officially kill >> attributes 30 and 31 asking implementations to treat as withdraw (or >> discard) any routes using them ? > > I've asked the chairs for guidance whether that should be part of the > IANA considerations in the large communities draft or whether it > should be a separate document. no brainer. this now has nothing to do with large communities. randy From nobody Fri Oct 28 05:24:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65929129AC2 for ; Fri, 28 Oct 2016 05:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 66XUKrOtuyX8 for ; Fri, 28 Oct 2016 05:24:10 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 40928129AC1 for ; Fri, 28 Oct 2016 05:24:10 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c06Cb-000E0l-0b (job@us.ntt.net); Fri, 28 Oct 2016 12:24:07 +0000 Date: Fri, 28 Oct 2016 14:24:02 +0200 From: Job Snijders To: Randy Bush Message-ID: <20161028122402.GB966@Vurt.local> References: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: heasley , IETF IDR , Susan Hares , Thomas Mangin Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 12:24:11 -0000 On Fri, Oct 28, 2016 at 08:24:19PM +0900, Randy Bush wrote: > >> Finally, should a document be also published to officially kill > >> attributes 30 and 31 asking implementations to treat as withdraw (or > >> discard) any routes using them ? > > > > I've asked the chairs for guidance whether that should be part of the > > IANA considerations in the large communities draft or whether it > > should be a separate document. > > no brainer. this now has nothing to do with large communities. https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-00 From nobody Fri Oct 28 05:59:46 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC4E129571 for ; Fri, 28 Oct 2016 05:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 pexpsX7LPSJS for ; Fri, 28 Oct 2016 05:59:42 -0700 (PDT) Received: from out-5.mail.exa.net.uk (out-5.mail.exa.net.uk [82.219.4.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D44F1293DC for ; Fri, 28 Oct 2016 05:59:41 -0700 (PDT) Received: from smtp-2.mail.exa.net.uk (smtp-2.mail.exa.net.uk [82.219.5.2]) by out-5.mail.exa.net.uk (ExaSMTPD) with ESMTP id 283461C00DC; Fri, 28 Oct 2016 13:59:40 +0100 (BST) Received: from smtp-2.mail.exa.net.uk (localhost [127.0.0.1]) by smtp-2.mail.exa.net.uk (ExaSMTPD) with ESMTP id 15E144047E; Fri, 28 Oct 2016 13:59:40 +0100 (BST) Received: from bluemind.exa.net.uk (bluemind.exa.net.uk [82.219.13.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-2.mail.exa.net.uk (ExaSMTPD) with ESMTPS; Fri, 28 Oct 2016 13:59:40 +0100 (BST) Received: from [82.219.13.108] (bluemind.exa.net.uk [82.219.13.108]) by bluemind.exa.net.uk (Postfix) with ESMTP id 9054D1120EC9; Fri, 28 Oct 2016 13:59:39 +0100 (BST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Thomas Mangin Mime-Version: 1.0 (1.0) Message-Id: <0F5E21B8-81A4-49E4-9B33-8320DB92ECFD@exa-networks.co.uk> Date: Fri, 28 Oct 2016 13:59:38 +0100 References: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> <20161028122402.GB966@Vurt.local> To: job@ntt.net In-Reply-To: <20161028122402.GB966@Vurt.local> X-Virus-Scanned: clamav-milter 0.99.2 at outbound1.mail.exa.net.uk X-Virus-Status: Clean Archived-At: Cc: heasley , IETF IDR , Susan Hares , Thomas Mangin Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 12:59:44 -0000 So... Should it recommend treat as withdraw if seen in the wild wild DFZ ? Thomas --- from my iPhone > On 28 Oct 2016, at 13:24, Job Snijders wrote: > > On Fri, Oct 28, 2016 at 08:24:19PM +0900, Randy Bush wrote: >>>> Finally, should a document be also published to officially kill >>>> attributes 30 and 31 asking implementations to treat as withdraw (or >>>> discard) any routes using them ? >>> >>> I've asked the chairs for guidance whether that should be part of the >>> IANA considerations in the large communities draft or whether it >>> should be a separate document. >> >> no brainer. this now has nothing to do with large communities. > > https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-00 From nobody Fri Oct 28 06:05:15 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398A1129499 for ; Fri, 28 Oct 2016 06:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 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_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 O44JQ2yEbUOy for ; Fri, 28 Oct 2016 06:05:12 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 7167A1293DC for ; Fri, 28 Oct 2016 06:05:12 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3C6D4A4; Fri, 28 Oct 2016 15:05:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1477659910; bh=QoMjydRAwvftx6uMEsC33O10LnsLdIwAdHAhMoK3aQ4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=S/3H0SrY/1C7cfkGw3jTFIs1w5VFM3H8zqJe8Wbnd6vVrzcYnJqBQqSGVclCrR6Kd SwAWXjvlKgSYpf966sxGTxjl0/Qws9T2Df4lK2RpKHFYl/MH5HGghmWN+T7xNjRbJy TvJg1bGY6SBSC3mCz8uDPxXq3oEbpujPEn/9yWds= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 374EAA3; Fri, 28 Oct 2016 15:05:10 +0200 (CEST) Date: Fri, 28 Oct 2016 15:05:10 +0200 (CEST) From: Mikael Abrahamsson To: Thomas Mangin In-Reply-To: <0F5E21B8-81A4-49E4-9B33-8320DB92ECFD@exa-networks.co.uk> Message-ID: References: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> <20161028122402.GB966@Vurt.local> <0F5E21B8-81A4-49E4-9B33-8320DB92ECFD@exa-networks.co.uk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: heasley , IETF IDR , Thomas Mangin , Susan Hares Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 13:05:14 -0000 On Fri, 28 Oct 2016, Thomas Mangin wrote: > So... Should it recommend treat as withdraw if seen in the wild wild DFZ > ? What's the benefit of that? Why make these codepoints unusable forever? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Oct 28 06:08:29 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FC21294F1 for ; Fri, 28 Oct 2016 06:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 6xOPmImDYQoe for ; Fri, 28 Oct 2016 06:08:26 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 871161294DF for ; Fri, 28 Oct 2016 06:08:26 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id y2so120792889oie.0 for ; Fri, 28 Oct 2016 06:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=twPpCeFJBbStF70aHE/TlWapIOCGcvcAYgRq4rOTJAw=; b=oJN/dfO/ZJW5Mo6mKkC91dDEpCV374GUB8pwcBPaaqjQ/9wJcVKJ7ye7iR4KYQmip2 PKSJPZkSk2f1qwzlE++xv/S/r1iRvJwMdRDe5DY1u4s5o6VYDmFbi0BHB62tV/R/TMN/ p/5PrdldIq2ASOQdlEeWAYw3YIlHk0qvtX4p+GK6KwTcCWr1l5ViWL7am8mZzPj08S7A k2cl1kU47S57TzIfp78KLUZvo0dxuCcNf7B7+r2qxsTj8me4CInQHYLlDBmhgq6xRlhm /yTVm5yzlMQ85SOn8qbLCER5F65ETDwQU5JWK4ImqoV/Ob3vH+YMgyVn421wdGb/MqJL Uc+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=twPpCeFJBbStF70aHE/TlWapIOCGcvcAYgRq4rOTJAw=; b=c7KyjBCgxhDZTWI8VFAyfCZAmCHWx12GkMha835BpCy5pLH4T22I4O2AkforvtVD44 L8F8vWZefmnu8SE0wOHtDX3hC2sjXEBBHIPudWX8y7hsOAFCJ4Agu+PbipaipREFutzN kD5hums8Ong1sh/yiTTJ40WFjn5huQdP7jDweKjdrhLs3GawaeC0jv1PmyUH6I6OmUOq r8zzxeKw6XOs8ZiW56lVpsVXedNhSB8Mm7UI5bTPR6ZN/1vqU69FOrkebWKdOpUi4Lxx h/sXuhoL8vh//+NDVY/4BvCrHa+AJRq71v8aaz6MyFC1RKlh6dVrsOkgLvomtAWZ95xB Nx7w== X-Gm-Message-State: ABUngvc8sDLe4czWWC1YZVIg8ZGS1NQmct/RqMuw7mLiWjvuEwUmV9MvRRt/n61RPfKb24WFXQBEMMpNjpktKg== X-Received: by 10.202.236.130 with SMTP id k124mr5562783oih.83.1477660105871; Fri, 28 Oct 2016 06:08:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.86.34 with HTTP; Fri, 28 Oct 2016 06:08:24 -0700 (PDT) X-Originating-IP: [89.200.14.188] In-Reply-To: References: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> <20161028122402.GB966@Vurt.local> <0F5E21B8-81A4-49E4-9B33-8320DB92ECFD@exa-networks.co.uk> From: Job Snijders Date: Fri, 28 Oct 2016 15:08:24 +0200 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001a1137c88eb5c8d5053fec8d2b Archived-At: Cc: heasley , IETF IDR , Susan Hares , Thomas Mangin Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 13:08:28 -0000 --001a1137c88eb5c8d5053fec8d2b Content-Type: text/plain; charset=UTF-8 And it would be more work for everyone. Job On Friday, 28 October 2016, Mikael Abrahamsson wrote: > On Fri, 28 Oct 2016, Thomas Mangin wrote: > > So... Should it recommend treat as withdraw if seen in the wild wild DFZ ? >> > > What's the benefit of that? Why make these codepoints unusable forever? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a1137c88eb5c8d5053fec8d2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And it would be more work for everyone.=C2=A0

Job

On Friday, 28 October 2016, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Fri, 28 Oct 2016, Thomas Mangin wrote:

So... Should it recommend treat as withdraw if seen in the wild wild DFZ ?<= br>

What's the benefit of that? Why make these codepoints unusable forever?=

--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr
--001a1137c88eb5c8d5053fec8d2b-- From nobody Fri Oct 28 07:25:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F9F129B04 for ; Fri, 28 Oct 2016 07:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 L70crGS4E3BA for ; Fri, 28 Oct 2016 07:25:23 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6AA0129B02 for ; Fri, 28 Oct 2016 07:25:22 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id p190so14295769wmp.1 for ; Fri, 28 Oct 2016 07:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=5IXf6+7ZDkHdYMdkFBZUp1G690ap64D9EqFhu2gt7mY=; b=R43UezdfzJOLniaApcy+1VffXUX+y/MF0GdVVuZoXFDwvkFwv5DJnLHAfULKXViIr2 lfRKrE5VMScRPvruD0HjpAaz/Bclc+KE+kxvi+LMK9fPs/1ANOslcjk/lnqhCUNRTp80 c9HJlwNffSXxZ3JxDQQtiO3zNfFjXTyMwu6jX6dspoWikCZL+oO2aqxKixXs9U8yXzBz 0IPzzkVJnhBhpYEqyLwig0zDhy4Q/c22EJy8g/PQRvS05Q8fuhhuKnYIAl11aZSXhNer kd5qxTiSXnpB80Qho2r/futlpwBajcjSyrFXdnZdZqlEd9IdX4NW3HLO3Qd0aImyBt3j ic0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=5IXf6+7ZDkHdYMdkFBZUp1G690ap64D9EqFhu2gt7mY=; b=bxn1k0Wgvif5yRkuywZogxH2AsldKXCS+1RjrErwjc8jOfosm8YrMV/3N4y8Lo08bq 4816Dag72rUpzfo/tR9caO+POGPcmSAXOBhNw1FA7SoiLbpa0TSwaeKiJS6u+zs+whea ZSZ9izQvXZVaRV9k1KFLOik68WyU9hWkSChIAWVYLv8oI5Im4SR2RzRFe8LiuM+ehVwX D2aoS9pqj49gRY5kG6wlOO7QY3GEVenhU/e2ULxLM5tJdLLljTtKv6MEWzzn51pUzFrD 0Sl860xtMqsHLip29o+jsuh8LaZJjHiDABzoaFnVGo6a9RXo5byC57xVe+/ry9ec/W8K HzCQ== X-Gm-Message-State: ABUngvfB3pS24sxuW0o8sUm50/ZuZeNhz16Afa4JUQmxZ68QSc9pTpbTwaiOo74VAkM6GQ== X-Received: by 10.194.235.165 with SMTP id un5mr11944041wjc.200.1477664721268; Fri, 28 Oct 2016 07:25:21 -0700 (PDT) Received: from localhost ([195.76.232.154]) by smtp.gmail.com with ESMTPSA id h2sm3761540wjy.40.2016.10.28.07.25.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Oct 2016 07:25:20 -0700 (PDT) Date: Fri, 28 Oct 2016 16:25:07 +0200 From: Job Snijders To: Brian Dickson Message-ID: <20161028142507.GB956@Vurt.local> References: <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: heasley , IETF IDR , Susan Hares Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 14:25:24 -0000 On Thu, Oct 27, 2016 at 12:04:12PM -0700, Brian Dickson wrote: > > > > I was suggesting the same thing out-of-list today. We should > > > > really assign ~5 values to experimental/development puroposes > > > > > > I think this would be useful both to allow for larger-scale > > > testing of new attributes, and for vendors to be more easily be > > > able to test multiple new attributes in-house. > > > > The problem here is that people are not abiding the rules, and > > offering more codepoints will only work if people abide those rules. > > I have no confidence that more dev codepoints resolve the issue. > > The counter argument is very simple: If we don't offer more code > points, they *definitely* won't use them (and thus abide by the > rules). On the other hand, they weren't using today's 255 codepoint either. Kind regards, Job From nobody Fri Oct 28 07:26:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AA3129B02 for ; Fri, 28 Oct 2016 07:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uLk5tQkNmaVi for ; Fri, 28 Oct 2016 07:26: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 91225129AFF for ; Fri, 28 Oct 2016 07:26:34 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u9SEQVxQ048531 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2016 15:26:32 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local Message-ID: <58136016.1070203@foobar.org> Date: Fri, 28 Oct 2016 16:26:30 +0200 From: Nick Hilliard User-Agent: Postbox 5.0.5 (Macintosh/20161020) MIME-Version: 1.0 To: Job Snijders References: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> <20161028122402.GB966@Vurt.local> In-Reply-To: <20161028122402.GB966@Vurt.local> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 14:26:36 -0000 Job Snijders wrote: > https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-00 pls specify timeout in deprecation: https://www.ietf.org/mail-archive/web/idr/current/msg16576.html Nick From nobody Fri Oct 28 07:40:47 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC832124281 for ; Fri, 28 Oct 2016 07:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 eKRTbn_Q1pyT for ; Fri, 28 Oct 2016 07:40:40 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0139.outbound.protection.outlook.com [104.47.33.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BAAA1294EA for ; Fri, 28 Oct 2016 07:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pYXky9z0rq+1EIwF+WGZw+PglBpnoVfn34fFqPvtI58=; b=CXkIcRFTHZ6u5Ul5iK404d4N1dt8hbFsiSj56nyIUvSjWZa6t/m85u5nlXatdEWISbwUyJsYB/InM0vuQNQyiTTV9orcJ9HH/5t0u4WSt2p6kEZ0c8x3thvlBmCXszUus5gLDeK050paIaa2hQRqj8HikJVxqIDqqSjl3uZpCR4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from sfrost-sslvpn-nc.jnpr.net (66.129.241.14) by CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Fri, 28 Oct 2016 14:40:34 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <58136016.1070203@foobar.org> Date: Fri, 28 Oct 2016 10:40:21 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <5783C8A8-AB9B-4FED-AA44-EDEE052671A7@juniper.net> References: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> <20161028122402.GB966@Vurt.local> <58136016.1070203@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BLUPR14CA0056.namprd14.prod.outlook.com (10.163.209.152) To CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) X-MS-Office365-Filtering-Correlation-Id: 5a6cdb9c-5d20-4a1a-d6f0-08d3ff4061fb X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 2:JE+6b+E857vhz7ElMJ/U1/NGz7P9PkUKKiJ2QRiKOyyCv/w2vmspOzc7sDD6V7PdHmwnLrg8x0NFnQKe6i0EM/atlgefaMa6Smulb7jRFXVDUPIY6GP2T8rW3qAXbJ8kFBpjwuhkIyE3QE6jXJpt93lxg1vd3xONI65sBH/2YPgomAA3wmZWXex4wPZsmGsit7PiA1F8Folek3nmbAEbug==; 3:26HEF1gJCgtSev4L0LYGriyRT0Vw2xse53AlUSlHI8GahvboXC6uMGqfez7NMjA2iuyihk5UcLR/811XswzGwmR67bs4tG4pG5ZiBvax4EuYdQALHN8emMx3PttomYeK9x4x6mZzRWF0mrogta86ug==; 25:w8s9eHCSPfUa5ubWyVBT/DXPcnn2qJ9HqdujdiRX+RH3a4r4WK8xFF1er+XlKJLTrBkGFSM1jUGiSRkDBLHvUdgS6Di8SqfSJHRNUuAmSWgD6UbYjciCcDIKyXy75uzMJEXvU0fAkHRJwDhZ43KoeERMUOvpIc2YuiorhcPy5KA+XLyiXNKOa+k6wDuoq9V9xHfgB9LQDg11e5xZnLMyymRnxIU+QpIOubDc2rr1/ptXJkpVXn+HHhPiii3pGCkZHTUBmGyMjS6hX9jRRHPcw1tEY7Ud/zFfZK9/SZRJPWekkd6Dy55Fmy7sA/+K3tM3vPp5H654ymr/5IwKOaqdWJwNSNzIIQqbnBI1Lo0koKKxPFDiTCBW24kuhcTiWR6V8JOJD97jUj2V5Ir44GFfZywIhsEZzwyqV+IJkkqNn9m4jJ++NdlVjfy9wldrhkzc X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2503; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 31:s9IwbsUSofETcO6ahJpS1QVi3Gpq8neBgpqpDoac2bi1bcpGN1ywv0s29oLBMtxmf7ccvBsziF8gGlg3Rh84tKSCKpEYQNCr/ibYg3keRv9tLxQCo4SaNIpR7DwNWXokLnWJzZDRXan6O+tELlCItBOu1Azv90cpcSKaADg9TwAeMOmdFXh/zTD77z9S99f+luu/MigI6SmJIJGDg4ybN3PuiK2pN+FgAV6NrmZ7+paIZpP5hma7aIKCoWHP7I3W; 20:YBc49eEwXCyUSShRk77yyhpqCgPXV1a0Z8zbtfbYjXfQpZ6UA3ln0UdTq20kXvfttfJiNVxqHcLFgdM39P4SQiwqsTU/+Peh1AbaZ/CYRMVS8k06T3t8Wpsy3hEFiuD6AXRdV2JY76Q0rsVyhyHBNYRl6uTf3P2JzVWZ8w8AQ+fj1ETQfOpYWPShv75fUhmCC9pAtggqkUnI8aAVTDv9IAy1TYrQr/ufBFcnO4itED/CvmvZn9Rllcv2+L+EUGae/n3QU7eR5eBrQdXLdkZa9f0PrcJkNajBaon61ythJSh31po8jqiF7kNQ9cenuzZIsRDTuXCRyIGfBQApxBPbnJypTc59lDVd2i1ZgL4ZSKb3hK4S1iWFTdtku6I247BqcEuGd6PETXDRG+8/dUnmkiHgFqdcfE1BKRSZpos4Nc1P/hRLlFP2m0a4vToGQFWt79z+4+69FIjgpsJZ9c+217n3wF1bWHh5rDnFpbOsO46wn05ijCtQU5d12hzYamVF/P/MESwa5kOcuVcC9Qd8/58MZAgNH5RIz398uFi8MFsI1M2QX1i3rbAXuqe60SWqy6HS/qDKVe6SPrZd32cUqzGQGfkyMC0W5154QfArlT4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CO2PR05MB2503; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2503; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 4:Jgj355V9Rz5+5vWNJkZxeNrUFE1PT+18Ao1s/xJXc8gVYuFFVJWjHKz/aDAJzN9auV+TEJGEpRjPwv+SP4bDd23Arv3vNEH4v09u0FJXZd/7Sgc308qvv5M/vdVKl3NKukkqjGk9i8Gi4U7p707POb008xYpFvngg3NBPQr4Ca9pZJOBZa+30gayG+kuZpR1omYEQBdaX20bi/UlvoevslzCmXXTcdiy4PCAqfv0esRxi1DLutC9ixPfzE1zlZR5KpXHB0RT0IsYi+uqlu/hu8+0fpr1pLG8+mCpTbpZuNzTkP/Bsmrdjmp4GUZrduoqpEbvo641Ti2G2nnx/Wgcq//QTk58XgWtU4g/xhc1jN2sj9ipOAvnMz2wJ4+c9s7RRFxvSp0qEDw5sxiyeTWWYXuJeVe22BvyIhJ76ehxz3Y= X-Forefront-PRVS: 0109D382B0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(189002)(24454002)(377454003)(8676002)(92566002)(8746002)(50226002)(2950100002)(47776003)(6916009)(6666003)(93886004)(53416004)(42186005)(5660300001)(68736007)(2906002)(81156014)(7736002)(305945005)(23726003)(82746002)(83716003)(586003)(3846002)(189998001)(57306001)(6116002)(7846002)(4326007)(81166006)(36756003)(97756001)(101416001)(33656002)(77096005)(50986999)(76176999)(97736004)(66066001)(69596002)(46406003)(19580395003)(86362001)(15975445007)(105586002)(50466002)(110136003)(19580405001)(106356001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2503; H:sfrost-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2503; 23:wsIiW1GZNIy5Ir4aWvKBV/kiz6fKy22maNO+56g61?= =?us-ascii?Q?wu6N/oJgS59LzYN0fNI3uIh0jwuZSN5LATkqCDoQ8xkFasCzSUVMiXKS+jXK?= =?us-ascii?Q?v5Kxq1I5O7MubHyFJ5AuxMd2WU7L7le8sJ2DQvqXKppzEz+uF2Mr1tB4lLYY?= =?us-ascii?Q?UeIDl72ms33roKuS0pDn6g2yMVNyAgH1gz/ikEwp1dGbw7zSNXrSLxH/UkdS?= =?us-ascii?Q?5e6SROzEGGs8g0aYZOpNmH1s6+e7OgRimshXczelyQp9mPI9nu3kITjALMpD?= =?us-ascii?Q?0kAPR4JSgw2Sn4fD8B1T7Q7IHX4jKf/B9+Sk5e8Vt+zu6maa6nqzpvaxbHhj?= =?us-ascii?Q?X5pVN9FcfKXqdDSt1rgX+MxVn+69flvIW7ZSPBijRcgzyabaD0fuRwpNsBZ+?= =?us-ascii?Q?SC1gB/ZF95ug6+cCFH7K1Bh0LBy1JdQHQZ0yRtGYExCYlYlQkFdpknkM+neK?= =?us-ascii?Q?SmZTW+sYcDhdZfxaFyIRnp7LuXMLQtLKBUgtgKxcoUlxZ6cqRsdorfDuuHOF?= =?us-ascii?Q?xcAVlgBka7kq9pTFKCfD+oXKoqz2UG+6UTCp1Vojh+jeLwrl6NPXTeROAXXa?= =?us-ascii?Q?jHDzgXUiVrcIFENHT1kBci1dqXoj4YYyUsjgjJ6HTQpkD+d7vTG2nvVnKJsX?= =?us-ascii?Q?kzzZu6uJc+MbRm4qELy6FPgzSEHuo6ftLmsXuGwgUUJv9kgvCnmSo5GQ8k5s?= =?us-ascii?Q?9OnvOLRIcM6O8yNdXoRgEMFIAZAhGOKDnS+lnlpfoc1fIszbIH1VhNiGMY4D?= =?us-ascii?Q?OQdbAW+Sb3oxkuN1EN+lwVDNKAuRX7FXT+a7f6gAEpPv4DDUcXGE/a0WjDNt?= =?us-ascii?Q?F0YO9QoUtIjPAMCk6Rh7m1A89agp232scS87I8Nysg3wLhkJ7Ukg5UQh/LXk?= =?us-ascii?Q?vC09Z67G7RwTJia2xJkFYbONeqSkBkd9YYulAcotl5GEbVV7j0l1s6bIcOFL?= =?us-ascii?Q?6qii5I3zuVZKMxvWSW+SrZLvUGFIZ+xWvSz+/pn6atX6aMQJymF5YltGDpFi?= =?us-ascii?Q?A5TIvMlVCm4MkkVbFzWYoeHyWwNrcDn3nS2uUNqXB0QNebp+n8F6D4hUSWwo?= =?us-ascii?Q?LUlDkHRb0Wh+FE30W++Xc5v/B7dXdf8cRaOGt5BYIuT+5ZKRiiJX3Iy1+uRs?= =?us-ascii?Q?dqjMu8EVDs/TUha4qygvwr7ZIeVsa8jiQbLfeVCYQ40EpIv0oLgrsGfwA8RA?= =?us-ascii?Q?5MpyS87ByNBBX6qnPORmv7hOgJk00aWoEtFeJn6ycuNa9p/BeEuLMhH8e0AR?= =?us-ascii?Q?d5pjrfZD8fU61BTu/FSU13xlfWwdNhKkCdOAWqygnFF6KA/DzZgfsOHqDS77?= =?us-ascii?Q?A3lERBzoKEFgJPHYLVas7hEhbn/x5RVdnzuysUQg4Q7?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 6:ZQQbt5e/i82iwrYG35haBx7MI2VkGZDkEkXx3WA/MmRvQMd00VPRhQ35ajVG+U3H+ivUHPs+S6tr+WH403ZX2vea3WdPepUNWrH0d04/fUdrA+NB8JRsaaTw4ZqYF4/zPuSClrWzE+5TV1hQzv1IK+m+hABGu4j+XBtCG/M4BEbfVzK5u5seF87SMN4v7lRLJaA2M79i7HIjr1R9y7LULtBx1iGyjK4RZ09EUnS6GzewEBc2uu4SaSzh9CY8Z7uidLrYsAb6KN5XgA/a0JY+mK97xviUHbEmiMpoFATIR+U6jgCQYbJlPnL+fI8GHRBpRJKa3PJgtXXqzZeJLxfigN3yC4fk143zvyPRLIIkdJA=; 5:Zl4LxMOCz/1G8dVX0pSVD28dSNwZ1RxPPtD/fZxyapG6GuLW5648Pk9tMZ8z/2Xv36ACWrMNqxn4hvd0Dm0EOIFuQrnTPnfHqkZ7QMjx6+eBoD89j65TpeJnJEg9U1ebO9syLIe+EKks+RHoXt+ipw==; 24:C7ZXZ0/RN+PLsexa1bkA8ZP2qC6E25lJfawLAJ/5N6SHZ5iLDiuCcaYt2VPjmYPde/1dga99uTI4jsMVbFAuAbZfU2KPpSgdAriNSLqZkPs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2503; 7:jGU/pr9vf5xhgUKYGHrUNU6AaCJrAPVWSqVb7WIjkBhj1SVeJY++ctF3rrnP3cUMcU0xExPofSx1qvCayzTVfrpk1Xy7pwAVofihMSEpRSlNYqxoXvSlK6af2Plocg2UW/eQRDxzuqtKtNzplzErOmNTg9q7ZL2AlE7H4lFHDVXh+b18R/dCfyf2GYLkx5VkOdd57Fm6Tn1QoY4DajaYvuqZVxgk8rDASiw+IZXksKem01A6Y5UBwhRhxseKsjzhj0SWwo4i7U7Kolx+VD7hzcaP7OpyxkM1AGesGBSz4XiEIy38YLjZZFpo34GQZjoEE5uwh8JjO71kcKSNO1ddWatcu31AZ6z9oiH8pa/JcM8= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2016 14:40:34.9523 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2503 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 14:40:47 -0000 On Oct 28, 2016, at 10:26 AM, Nick Hilliard wrote: >=20 > Job Snijders wrote: >> https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-00 >=20 > pls specify timeout in deprecation: >=20 > https://www.ietf.org/mail-archive/web/idr/current/msg16576.html (Individual contributor hat) Ha, and I was just about to send a message saying I couldn't imagine = needing to polish this document. Obviously, my imagination needs an = upgrade. I'm not aware of a precedent for specifying a timeout in a deprecation, = in fact I'm not sure what it means. I'm not sure what benefit it would = bring either. I do see Sue's message you referenced, but the point of = that, and also my own message around the same time, is that deprecation = is one step in the state machine, necessary before code point reuse. I = don't think we need to either specify either a minimum, nor a maximum, = time the code point may spend in that state. I note that in parallel the working group has been discussing the idea = of reusing these code points to expand the Experimental range (currently = called "reserved for development"), so we may end up reusing them rather = soon. In any case, deprecation is the first step toward doing that, so I = think we may as well just get on with it with a minimum of fuss. --John= From nobody Fri Oct 28 07:45:24 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE09129B0A for ; Fri, 28 Oct 2016 07:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 EUfLd2hZXW-E for ; Fri, 28 Oct 2016 07:45:20 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE2F129B14 for ; Fri, 28 Oct 2016 07:45:19 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id y2so125520858oie.0 for ; Fri, 28 Oct 2016 07:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KbYU81bt9GzmnH3zPPYrs1vaa1Og7HNf3ksJ/V6jtE8=; b=Cf+8wPHZp2TEPgkMvuXxf+Hyy8h0QLLBle4h/f+jWmb//Ny/oQm7xId/iRQaZVHbSy Ux6Nfinr5eJ0mAS+vwaP+qPMThUNSDrBV09VM8366sCWdYEj24dobIdDdS1sg1tv7ijv nKO73I65mvf3OAA1NuSUa64Au54YHG+OQLelKSQyETr+3ts/z1q4hhsaPdXo5/zsdCpA hgcEUkvQIlcWErXpETKwoVEXFChC1t+dvo7JDw0dltLHgZUlSeOsk/PgZSzqL6owXBTS R5b0gK3N7MePlQr8LIgdqgczkOjrUzTQaz+chIqOIbrVElEIw8XNJlOfBSAor2YtZugh 4hjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KbYU81bt9GzmnH3zPPYrs1vaa1Og7HNf3ksJ/V6jtE8=; b=i56+RoK93me9AKvaKflfcItEXmVlAv8e/MxT8akfiy1go1hkyX4dbrmWpBwBE0qnqS eE1ozssfwi8qalYAgubnXysTHzU5D/x0DWyT2Y9N51lkPc9Z4BV0CVE3xI1fiOcJDEBY jg4s2pbHLv1dz2ZCd1tp05cXUMYK+6QL/o4iL989TUPszBV5/UkDtupiGeFmkV+qewIJ 2Sw1P+WgVhKWrjGCQQ6lvcWLGiskZ6OXp6c7dJpW7W+SgLAzcv1pvxWl4Yf4rUyfj5Pw V9BwfKXeTGbwbR3VSz8JAnZBaB4gRg8riXdDp7KtcGISrPXHHx+BwdpNBbZ5SZYA87SV MOhQ== X-Gm-Message-State: ABUngvcjZOules+DrJi8dTz4ixXW2k6W/3D4SutXUmJLtf769lzyTiJ0IymYcExrqgVfGSjSSid2Sdpxhiizwg== X-Received: by 10.202.81.5 with SMTP id f5mr4785985oib.24.1477665918261; Fri, 28 Oct 2016 07:45:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.86.34 with HTTP; Fri, 28 Oct 2016 07:45:17 -0700 (PDT) X-Originating-IP: [89.200.14.188] In-Reply-To: <5783C8A8-AB9B-4FED-AA44-EDEE052671A7@juniper.net> References: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> <20161028122402.GB966@Vurt.local> <58136016.1070203@foobar.org> <5783C8A8-AB9B-4FED-AA44-EDEE052671A7@juniper.net> From: Job Snijders Date: Fri, 28 Oct 2016 16:45:17 +0200 Message-ID: To: "John G. Scudder" Content-Type: multipart/alternative; boundary=001a113d7e8827cfc0053fede8ad Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 14:45:23 -0000 --001a113d7e8827cfc0053fede8ad Content-Type: text/plain; charset=UTF-8 If values are picked for development, I'd pick them closer to 255 rather then apply a degenerate distribution. It is my understanding too that deprecation is temporary in that the working group can undeprecate them in the future. Kind regards, Job On Friday, 28 October 2016, John G. Scudder wrote: > On Oct 28, 2016, at 10:26 AM, Nick Hilliard > wrote: > > > > Job Snijders wrote: > >> https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-00 > > > > pls specify timeout in deprecation: > > > > https://www.ietf.org/mail-archive/web/idr/current/msg16576.html > > (Individual contributor hat) > > Ha, and I was just about to send a message saying I couldn't imagine > needing to polish this document. Obviously, my imagination needs an upgrade. > > I'm not aware of a precedent for specifying a timeout in a deprecation, in > fact I'm not sure what it means. I'm not sure what benefit it would bring > either. I do see Sue's message you referenced, but the point of that, and > also my own message around the same time, is that deprecation is one step > in the state machine, necessary before code point reuse. I don't think we > need to either specify either a minimum, nor a maximum, time the code point > may spend in that state. > > I note that in parallel the working group has been discussing the idea of > reusing these code points to expand the Experimental range (currently > called "reserved for development"), so we may end up reusing them rather > soon. In any case, deprecation is the first step toward doing that, so I > think we may as well just get on with it with a minimum of fuss. > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a113d7e8827cfc0053fede8ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If values are picked for development,=C2=A0I'd pick them closer to 255 = rather then apply a degenerate distribution.=C2=A0

It is= my understanding too that deprecation is temporary in that the working gro= up can undeprecate them in the future.

Kind regards,

Job

On Friday, 28 Octo= ber 2016, John G. Scudder <jgs@junipe= r.net> wrote:
On Oct 28, 2016, at = 10:26 AM, Nick Hilliard <nick@foobar.org> wrote: >
> Job Snijders wrote:
>> https://tools.ietf.org/html/draft-sn= ijders-idr-deprecate-30-31-129-00
>
> pls specify timeout in deprecation:
>
> https://www.ietf.org/mail-archive/web/idr/curr= ent/msg16576.html

(Individual contributor hat)

Ha, and I was just about to send a message saying I couldn't imagine ne= eding to polish this document. Obviously, my imagination needs an upgrade.<= br>
I'm not aware of a precedent for specifying a timeout in a deprecation,= in fact I'm not sure what it means. I'm not sure what benefit it w= ould bring either. I do see Sue's message you referenced, but the point= of that, and also my own message around the same time, is that deprecation= is one step in the state machine, necessary before code point reuse. I don= 't think we need to either specify either a minimum, nor a maximum, tim= e the code point may spend in that state.

I note that in parallel the working group has been discussing the idea of r= eusing these code points to expand the Experimental range (currently called= "reserved for development"), so we may end up reusing them rathe= r soon. In any case, deprecation is the first step toward doing that, so I = think we may as well just get on with it with a minimum of fuss.

--John
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr
--001a113d7e8827cfc0053fede8ad-- From nobody Fri Oct 28 07:51:51 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323E91293F5 for ; Fri, 28 Oct 2016 07:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 MDDD284dI0Ov for ; Fri, 28 Oct 2016 07:51:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 29DEC124281 for ; Fri, 28 Oct 2016 07:51:49 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B22941E369; Fri, 28 Oct 2016 10:54:13 -0400 (EDT) Date: Fri, 28 Oct 2016 10:54:13 -0400 From: Jeffrey Haas To: "John G. Scudder" Message-ID: <20161028145413.GA23730@pfrc.org> References: <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> <20161028122402.GB966@Vurt.local> <58136016.1070203@foobar.org> <5783C8A8-AB9B-4FED-AA44-EDEE052671A7@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5783C8A8-AB9B-4FED-AA44-EDEE052671A7@juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 14:51:50 -0000 On Fri, Oct 28, 2016 at 10:40:21AM -0400, John G. Scudder wrote: > I'm not aware of a precedent for specifying a timeout in a deprecation, in > fact I'm not sure what it means. I'm not sure what benefit it would bring > either. I do see Sue's message you referenced, but the point of that, and > also my own message around the same time, is that deprecation is one step > in the state machine, necessary before code point reuse. I don't think we > need to either specify either a minimum, nor a maximum, time the code > point may spend in that state. A somewhat relevant analogy is that toxic spills tend to last in the environment a rather long time, even with active cleanup work. This has been the thought behind most of my prior comments about avoiding the need to burn attributes. And while... > I note that in parallel the working group has been discussing the idea of > reusing these code points to expand the Experimental range (currently > called "reserved for development"), so we may end up reusing them rather > soon. In any case, deprecation is the first step toward doing that, so I > think we may as well just get on with it with a minimum of fuss. I think we'll find that using the existing attribute range in such a way simply will leave further toxic waste. We're simply causing people different sorts of pain as we move around the contamination. For example, vendor A uses 30 for testing a feature and it escapes into the wild. It runs into the existing issue. The issue is really more to do with development and testing practices than code points in particular. Code point hygeine simply helps mitigate issues in those practices. -- Jeff From nobody Fri Oct 28 07:54:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60AE129653 for ; Fri, 28 Oct 2016 07:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 w40a1k6s3Bw7 for ; Fri, 28 Oct 2016 07:54:45 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0107.outbound.protection.outlook.com [104.47.37.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0574A1293F5 for ; Fri, 28 Oct 2016 07:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hZHNAEnhcD1mzPqhZHsBYm9DVhVcCvwkgsrEHV4Ezgo=; b=dM5Yy0Bk/5vqNbAm4YHTO3AfIscaoy3ee/Kctc+nowi6bXB9qwUL/G572W7LWOaBkWV9AM24Ibt4eKY62FUgKKqbRGuoxxGQNQZliHOAr1DXgsfXsBhnEXChqWjWxoPSDe526a7O1pVgVv2RiVCYJq5toIEAsRerJodRydQgu8c= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from sfrost-sslvpn-nc.jnpr.net (66.129.241.14) by BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.4; Fri, 28 Oct 2016 14:54:39 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_B7828D47-6026-44D8-8C11-4C74AF206A1F" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Fri, 28 Oct 2016 10:54:22 -0400 Message-ID: <125150FA-F466-4EC0-A2EB-1AA1E81F2E9B@juniper.net> References: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> <20161028122402.GB966@Vurt.local> <58136016.1070203@foobar.org> <5783C8A8-AB9B-4FED-AA44-EDEE052671A7@juniper.net> To: Job Snijders X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BLUPR0201CA0003.namprd02.prod.outlook.com (10.163.116.13) To BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) X-MS-Office365-Filtering-Correlation-Id: 989c7500-01d1-45cf-8dfc-08d3ff425935 X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 2:ieNfnxAMn/jqzuOe9w8ODhkRfKPXqR1Hy7XrZaa/vO37AnbV0n/pYA5qy7haTEwDWA0QBT24FQ6It6v3QlO36Cji6GrDx5N9l0aVf+szGV4zug7/aumGwOXDN3y+K7a5/Qc1JMz3oem0fulnqFgGpkajHQHNu5qzaytHC9ah4WNw6gZFixz/3+uQlPjxjHMZfns8WUX3z9Fl9HB7fs25IQ==; 3:R0mJPs72iS2QrJMpIf6/SqDiVsR/nRxmEhTpZaa11pB/TCMUSxQpCLwTbSNJKP/FAxheMmwByq1xrQ8UPxk3Nev81x9YoB8rcIzSMN5UmGRBh3MPn775lrpyP/t2hO8QwY1/fc/96qtu4JMI0QJmYA==; 25:h7t19mTtJmjvtdpANcceEdh3gOUHy5vpSp6LbGq5SzHWEx5wGZwsprwGUwgzeWRHqxUMTDODweMxRIY0jbKCvVRaDnxObjafyZmaZCxga8qTX4KXtxjeBk9eBoHmmy8LNum3E6up5hpCba7AO1fW791bFtfOZIL/pZEyNk8VfYuksNIW1HDSybXcRomhZdiRCs60F+iYTKAvyPzJpLhCuyHXAHNLZ2g74C84F6x7FxXrEzYZM31wgLcZ7knLPE2B9x3nOz1fPXGGFebiASsuqEADWOWXFCEVBDHPzyglHLDVn6OgbUgA/1qLyU2fV7PfhwC8q1gCStTPqjvX3JpS9LoTMEhUDYyZ71njeuevdQV/O1aUnzatC8JXqfgmux7SGzQvSikg93RDNPu5uhupU7xYqU0RRPKjswVH8PROvNOddEdK3uWqSTyYutN/m1ko X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 31:/06EBK6h252H9Tqj4aKaFOHtnBYq/0lJoqNUQxSmdCDbQ32uPpD6N2a88CnuGBrNWJBbWqx80fxOXOmbX7pe6zcM77CPnQCcs7RYbvT/ga5IeKrYJ3mKZikqqlIqioB+V9UU1SFfeZrFv3qfhMSSEwPKmfe6y9bxblAwF8irX+mMPjDAk1GbC2eUgI0TpaU41nUBcghUxaj0g6jpw0lKQQ1N0/MRVJez/izvdGT7g5WntKMPMkiiKsKuSwPc8RiT; 20:1D06B0M6bjzB9m3Xk7oDSwq6xRfIu9PQpcQkZ4XI4wbcbxp9viC5YZs0H8smTa7oeG7faV3147bmLWRGr99zxOJJJD0PeHiJKkZg/Zj9P65KZE2eKvWL0VTpBiS04CqKIPQ8XC3i0AVvBBXezQ3BN76FflqalYem+jKvpxNScv25Jv74Z5OBeP2Pi80WXOx+aVGFvvXnNdeI7B2WZhVl54e74TKg+SqbV70w1Fetb4fDbnU1SUzTBA5PIdd5FOP0CGqjdI/Nqs4/qB977wax7+EQEHbk8rcLaUE+smV/WYhfzwhEFCbKrU4lgO7Ud7+qpvPrIsDgWu+nXYe/0cywRKrS0/uoe5wYh2b//Et3be2UIcHxPw6fdd4mQ2AmomdCo0PLKogS6KIfC0t8U/X1lVPVKryN+uXb8E+vGm4CaXcskkAk1R2kmhq1I/W+zIbOA4O3+mb3UcumgjILqchWrwt6wnvVVzjncnlkwV0wzemT2A2uAVRdIWjrmqt+OVu0uOu186YG8i3cFa5hdLSgnihPoNRZza/fAX0cHGCKt3suP3G4cRhdtTWV66sAja34/BoklsKVWwYjLqfhuTx2orqIefrv6pR36CdpUP7y/2Y= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN3PR05MB2498; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2498; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 4:QfOTFtzXaO0+PNOOpJ104+b6WzU7iGF4+VAVpprPGI9qFtizUUopsuf+pXHcice8E23FIid/+TOQP21B1xw6vks8VgMA4xr7EzAkG0EvfrEyzTjRnqLwwlHHWXZcOTc6l8aNi0RB67h023llukLj5B2+23pUdAAMlEfmU2J8im7SaUYeMlCExk6ffWmSCMi0dGN4MjSMSgaN3PMIA77nVdOMICG/zaGtOQCEHoXkAF/dXT1oxXVRIp4XjPdeJ521vGan7fmRhxCzFLBeUinnqwm2rzCoCsvozXs6nW4R1LbDhLs9rUCJYHizT9M2GR3YymAlclgFoZEZnSwwvxrhWKZ4jUcp8qvZjbgEIAvgeDqXnOqDlaobZ9XknpXa6R2gXnOykbirbeu87qYEUtzTUYQXkLRu3saQslZagrvlzWw= X-Forefront-PRVS: 0109D382B0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7916002)(377454003)(189002)(24454002)(199003)(97736004)(82746002)(83716003)(110136003)(260700001)(66066001)(36756003)(81166006)(57306001)(8676002)(81156014)(5660300001)(69556001)(92566002)(50986999)(76176999)(101416001)(68736007)(50226002)(69596002)(84326002)(586003)(3846002)(6116002)(93886004)(4326007)(105586002)(189998001)(86362001)(2906002)(106356001)(19580395003)(19580405001)(77096005)(7736002)(512954002)(33656002)(42186005)(7846002)(6666003)(53416004)(6916009)(2950100002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2498; H:sfrost-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 23:rLFEbueSG0q964D/Hs2DTc7JsWKMijG2gcbhlclzk?= =?us-ascii?Q?rLUmEXzbO52iPFqd2lWVpV0gbCuWSC7SDQa1eDhUKMwzPwCSQ5Dl2f7XTdYA?= =?us-ascii?Q?GROF9dJrXguH+MjFP1TsWiJ5QoD45hQM2Wp1Q60AZETtWVRrdLpgjzmfTEjH?= =?us-ascii?Q?j1yhvmHp/5dav4Ey0V4+JieIPZGICzFALimPpURpIelzXk+a90IlZNgp4IrL?= =?us-ascii?Q?Qwdsco4ai62hmW3mGf/kXBy1uFjGW/7iv/uhGYyoyYbZhkuh8F0xSBS5VccX?= =?us-ascii?Q?iQiLUDLmPGJvNzkz4Xc0fIH2Di44D/yqNaqF4SV+oVY1Q/3xwyLdg+Iwmx+p?= =?us-ascii?Q?KrbfJOnY7wUlOXD4Jm43E6PhhHdJaCfmid7xy//QzLXKCm6LK7pZ8/L5BXRr?= =?us-ascii?Q?4IetkBbYzLDoOvfO5qMjkQ1kMckvWxB/SCQsAxGb4sLUG5hiI7kX6Po2Yz9h?= =?us-ascii?Q?3BDhdQXDEqnlwXxC3t/XJ1Fu7esbkaz9xIXzLhLheTAO/9CSbWW4/WjyR++L?= =?us-ascii?Q?M9PYCIUpMPI88TYOIvxhnIt3HXQWURRKode9EJ3RAvt9jd1JlQNFvB89XyMx?= =?us-ascii?Q?3EcB5RDw9Kkzl6z7WpWoA36Ct/houthilqXHlk1gxPDrSasOWS/ox3sNjC5B?= =?us-ascii?Q?V1NYS2enNAsZCDxYoAwub9D7UsPHlj2lmO4OHUQ4ypROEAOnM0rIqfxedr4p?= =?us-ascii?Q?cbIk3ib6Hli58WwMxmsVcqq/SyRhsk/XiFHI3u4D+l5RJ2cAvmvdFE7torSP?= =?us-ascii?Q?1mbEDhaAOV3wwFhAMMtRdO/sEFmi7rvfxhkqLDIMx56GkMojoV+KQoBFsCP0?= =?us-ascii?Q?4qaf8jxasYrptyHh5DjA0BXtB5Lg6EBB10otOsj3sh/drf6wPKeOq1SNKJwV?= =?us-ascii?Q?4QrWVnHXfW9f5VNiiYYT1q7fTkiYYdoziNL6lVHPI9olhuWbSBTVnjmgK8Ur?= =?us-ascii?Q?x5AhTmkCh1e1l9YBoKBodpH1JOLoaXf1NWh93LAA8qFgKmf7/bBoWaiLJ/Yn?= =?us-ascii?Q?VVmIUpOD+Gh6Az1Ro39tXjIqvh07BV8mkz+sejqZ5ep1wejEIJEFOOadduEn?= =?us-ascii?Q?2rSXIG6ZaP+QodNcifz3SACXjJ+GyzrP8nMELl4lO4/T7TUrUqLUkQF4XvO6?= =?us-ascii?Q?2G6620zAe/y4Wv8rpGkLZ7a20LV8r4kmW+KH/NHALeOvt7eIeYQZrwmqp0Il?= =?us-ascii?Q?ia7maIiSJgmqKzSls1p98alGJoJFOvoTjtIIbutOOb3K6/PVxtBI80QbQ=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 6:RlVei/WYxtAluXo/tYGqi56uADj8Qwx4zjxA6YwPqj3bmvaNp9jda1FXN9bvDygB55K4SR4EMIJ8K/1e9M77rJnQKfDGfa4N5qF0q6yBqSvCTCdLFIRpVaVQJ3wh9TQaf+QN2h2RONR/0LKv7jEhMZwkPzmFCO+knsi1bP2G7vS2tfAHeXi9x6lSG0rSNU0/nEmJxjR9m4F1f0SgVNltmbopj/Vr2Lw6gzCRdSDDq72Mba51m3ov1dCplQHKjlWHkJ9y/SughzyyoFxXyznabYjK27r0MR//VnEcQ+DA1OX0q0MBmPxSjnEfPibKbC6js8QnUhNgPYkJyHcumL4HaN5zhslgL93jlYjt+YN6kfE=; 5:+axVrypDwsdjARSpd6Z1XaRbDYps/NA3255m/9vGq8arMerKqddH7u2vxwn8BBY7bn8RI09r7OkMLIvEUhKPu81kqPwHko7hqLt1V29AcT/j4R5SgLgpur04jibYm2JF5uKAxmCULKte9ziT/dIAtA==; 24:oF/FUpvv6JD9Y3KbbqZLclR8d8g/WjScK7MtjMECOSi3zlgLYFieqWpzYSWLYYCkHHoq0LkS9q0NAgMU/sAQGizM26eToLunxU3OAre+gI4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 7:SjXG6/1JbRGtcm6cwEUSgeUWh211Lyyt4PpVbQ1Srov++YNkR0pzgycnVNH4BGi8Hnwmy7G2cq0janxLpFmZzIMZkWrKrucStFEyei/iUSnx93RMsPNOhx/7VjepbHRcqE+SVWMsFHAOe1dxFTHJxRRYvbzEUs82ZWYAf0oDPoHol9nZ9thnsxKDps9kO6n5t4z3XFNlh4j7XI1AHTw1a9GibruNNqNEH7ztSxhmO/Od9QiDrpQCgvrtC/7sdmJV7QhDZ+f+3SNoLj4HR807DcnNV0mDalSpnOONuniXk1ls444FlqXL4lwUDNOjN18y3x21WNi/1pBwrhEF3ZpSEGtIgIGFsqWIK9FgK+lQWm0= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2016 14:54:39.4167 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2498 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 14:54:47 -0000 --Apple-Mail=_B7828D47-6026-44D8-8C11-4C74AF206A1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Oct 28, 2016, at 10:45 AM, Job Snijders wrote: > If values are picked for development, I'd pick them closer to 255 = rather then apply a degenerate distribution.=20 And the fact that there is a diversity of opinions about which values to = pick for development, if any, is exactly why I think your deprecation = draft shouldn't be cluttered by this consideration. Everyone agrees (at = least, I hope so) that the values need to be deprecated, so let's make = progress on that. --John= --Apple-Mail=_B7828D47-6026-44D8-8C11-4C74AF206A1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" On Oct 28, 2016, at 10:45 AM, Job Snijders <job@instituut.net> = wrote:
If values are picked for development, I'd = pick them closer to 255 rather then apply a degenerate = distribution. 

And the fact that there is a diversity of opinions = about which values to pick for development, if any, is exactly why I = think your deprecation draft shouldn't be cluttered by this = consideration. Everyone agrees (at least, I hope so) that the values = need to be deprecated, so let's make progress on that.

--John
= --Apple-Mail=_B7828D47-6026-44D8-8C11-4C74AF206A1F-- From thomas.mangin@exa.net.uk Fri Oct 28 08:35:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE88612948F for ; Fri, 28 Oct 2016 08:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JaNLdy6Da9Al for ; Fri, 28 Oct 2016 08:35:53 -0700 (PDT) Received: from out-5.mail.exa.net.uk (out-5.mail.exa.net.uk [82.219.4.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE6012944E for ; Fri, 28 Oct 2016 08:35:53 -0700 (PDT) Received: from smtp-1.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) by out-5.mail.exa.net.uk (ExaSMTPD) with ESMTP id 750E21C00AC; Fri, 28 Oct 2016 16:35:51 +0100 (BST) Received: from smtp-1.mail.exa.net.uk (localhost [127.0.0.1]) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTP id 63E8C22158C; Fri, 28 Oct 2016 16:35:51 +0100 (BST) Received: from [10.12.32.12] (ptr-5.212.219.82.rev.exa.net.uk [82.219.212.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTPSA; Fri, 28 Oct 2016 16:35:51 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Thomas Mangin In-Reply-To: Date: Fri, 28 Oct 2016 16:36:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> <20161028122402.GB966@Vurt.local> <0F5E21B8-81A4-49E4-9B33-8320DB92ECFD@exa-networks.co.uk> To: swmike@swm.pp.se X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.99.2 at outbound1.mail.exa.net.uk X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Fri, 28 Oct 2016 08:42:11 -0700 Cc: heasley , IETF IDR , Susan Hares Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 15:36:44 -0000 > On 28 Oct 2016, at 14:05, Mikael Abrahamsson wrote: >=20 > On Fri, 28 Oct 2016, Thomas Mangin wrote: >=20 >> So... Should it recommend treat as withdraw if seen in the wild wild = DFZ ? >=20 > What's the benefit of that? Why make these codepoints unusable = forever? Yes, make sure that they are not uselessly carried on the DFZ. I can see the argument for =E2=80=98doing nothing=E2=80=99 tho. Thomas= From nobody Fri Oct 28 09:41:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16E71294B9 for ; Fri, 28 Oct 2016 09:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 dd8t4lHPyrgi for ; Fri, 28 Oct 2016 09:41:48 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3066D129436 for ; Fri, 28 Oct 2016 09:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1704; q=dns/txt; s=iport; t=1477672908; x=1478882508; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ktoa1Fss+yE4iWNnAF6F0Pjie2WA9e+twYcEKsVIcYQ=; b=Xs+63QLSsHoBl2M4sCQtBUVnMwbP8FFb4D9EbZkHv8N9GNI7ZcrmSJ/p cyVXkNrPLrusjTequ7CInrAXr3WrIBgA3zZvBQRncx12k2dN7bT7WO9Gy LngOkukOExxV8SGMcoppn9KMjWEbVb/T5eNq+dR7/mVJeGHrXuSg3rM4A U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAQCRfhNY/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoBAQEBAR9YfQcBjS6WfpQ/ggcdC4V7AhqBZD8UAQIBAQEBAQE?= =?us-ascii?q?BYiiEYgEBAQQBAQEgETMHCwwEAgEIEQQBAQECAiMDAgICJQsUAQgIAgQBDQUIi?= =?us-ascii?q?EwOsG6MYwEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQeFNoRVh0uCWwWaGAGQH4F?= =?us-ascii?q?1jhaHHoVxhAABHjZfg0+BO3KGagGBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,410,1473120000"; d="scan'208";a="341554337" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Oct 2016 16:41:47 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u9SGfl0m002806 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Oct 2016 16:41:47 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Oct 2016 11:41:46 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 28 Oct 2016 11:41:46 -0500 From: "Jakob Heitz (jheitz)" To: Thomas Mangin , "swmike@swm.pp.se" Thread-Topic: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) Thread-Index: AQHSMDgf3BhwaTAscEG6MWya7SQCLqC8/S8AgAC5xh6AAFgSgIAAEK8AgAAJ8gCAAAGMAIAAKjwA//+8C0A= Date: Fri, 28 Oct 2016 16:41:46 +0000 Message-ID: References: <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> <20161028122402.GB966@Vurt.local> <0F5E21B8-81A4-49E4-9B33-8320DB92ECFD@exa-networks.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: heasley , IETF IDR , Susan Hares Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 16:41:49 -0000 SWYgdGhleSBhcmUgb3B0aW9uYWwgdHJhbnNpdGl2ZSwgdGhlbiB0aGV5IHNob3VsZCBiZSB0cmVh dGVkIGxpa2UgYW55IG90aGVyIG9wdGlvbmFsIHRyYW5zaXRpdmUgYXR0cmlidXRlcy4NCg0KTWFu eSBCR1AgaW1wbGVtZW50YXRpb25zIGhhdmUgYSB3YXkgdG8gY29uZmlndXJlIGF0dHJpYnV0ZSBm aWx0ZXJpbmcuDQpJbiBJT1MtWFIsIHlvdSBjb25maWd1cmUgYW4gImF0dHJpYnV0ZS1maWx0ZXIg Z3JvdXAiIGFuZCB0aGVuIGFwcGx5IGl0IGluICJ1cGRhdGUgaW4gZmlsdGVyaW5nIi4NCg0KVGhh bmtzLA0KSmFrb2IuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJ ZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRob21hcyBNYW5n aW4NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDI4LCAyMDE2IDg6MzYgQU0NCj4gVG86IHN3bWlr ZUBzd20ucHAuc2UNCj4gQ2M6IGhlYXNsZXkgPGhlYXNAc2hydWJiZXJ5Lm5ldD47IElFVEYgSURS IDxpZHJAaWV0Zi5vcmc+OyBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPg0KPiBTdWJqZWN0 OiBSZTogW0lkcl0gU3F1YXR0ZXJzIChXYXM6IEJHUCBBdHRyaWJ1dGUgZm9yIExhcmdlIGNvbW11 bml0aWVzIChBdHRyaWJ1dGUgMzApIHdhcyBzcXVhdHRlZCBvbi4uKQ0KPiANCj4gDQo+ID4gT24g MjggT2N0IDIwMTYsIGF0IDE0OjA1LCBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAu c2U+IHdyb3RlOg0KPiA+DQo+ID4gT24gRnJpLCAyOCBPY3QgMjAxNiwgVGhvbWFzIE1hbmdpbiB3 cm90ZToNCj4gPg0KPiA+PiBTby4uLiBTaG91bGQgaXQgcmVjb21tZW5kIHRyZWF0IGFzIHdpdGhk cmF3IGlmIHNlZW4gaW4gdGhlIHdpbGQgd2lsZCBERlogPw0KPiA+DQo+ID4gV2hhdCdzIHRoZSBi ZW5lZml0IG9mIHRoYXQ/IFdoeSBtYWtlIHRoZXNlIGNvZGVwb2ludHMgdW51c2FibGUgZm9yZXZl cj8NCj4gDQo+IFllcywgbWFrZSBzdXJlIHRoYXQgdGhleSBhcmUgbm90IHVzZWxlc3NseSBjYXJy aWVkIG9uIHRoZSBERlouDQo+IEkgY2FuIHNlZSB0aGUgYXJndW1lbnQgZm9yIOKAmGRvaW5nIG5v dGhpbmfigJkgdGhvLg0KPiANCj4gVGhvbWFzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IElkciBtYWlsaW5nIGxpc3QNCj4gSWRyQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo= From nobody Fri Oct 28 09:54:28 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6506C129675 for ; Fri, 28 Oct 2016 09:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0p4MgIOmbm-h for ; Fri, 28 Oct 2016 09:54:25 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6859C12963C for ; Fri, 28 Oct 2016 09:54:25 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 0F48B580DB; Fri, 28 Oct 2016 16:54:25 +0000 (UTC) Date: Fri, 28 Oct 2016 16:54:25 +0000 From: heasley To: Thomas Mangin , "swmike@swm.pp.se" , heasley , IETF IDR , Susan Hares Message-ID: <20161028165424.GH21985@shrubbery.net> References: <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> <20161028122402.GB966@Vurt.local> <0F5E21B8-81A4-49E4-9B33-8320DB92ECFD@exa-networks.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 16:54:26 -0000 > > > What's the benefit of that? Why make these codepoints unusable forever? > > > > Yes, make sure that they are not uselessly carried on the DFZ. > > I can see the argument for ‘doing nothing’ tho. how would you, or how long would it take to, un-deprecate these attributes if vendors were to hard-code filtering of them? From nobody Fri Oct 28 10:23:47 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21937129565 for ; Fri, 28 Oct 2016 10:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0f1BeKTg3EGL for ; Fri, 28 Oct 2016 10:23:44 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0790129532 for ; Fri, 28 Oct 2016 10:23:44 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id s8so40422391pfj.2 for ; Fri, 28 Oct 2016 10:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zmLSpYFRYPTlEc27NW3878uo26pE24ywl6KjiRTQ1Fw=; b=pb+1GVreYINBDQOTxUXCgNAjLATRItiIbhM9ePP13yE5C97E/NE34K5YyHrcpTFkXK S8klW2LWKZmQDoBYzSIWw/7nCNJlDp2Q+CNamdzjy8d8EMVYMjwpgVVHJRAzNc0PYRy3 s+/c5bRGkHU6xh0DaXKuFJuSSgRm9Y+xuMth7E+K3kG/ia9Lf4csy8C9x5QP06DbO8uN Fak4TCd0ri6tKS2CSAViBE7bC3WRyhs/zIOxx3w/6F1pI9Kb73I0d9gmVxRFZpwQJXWF UBd6W9riHzmutzlpO3PsyCmHz4wQKo//THwZvNPeXOIuSMf4DpcOE4MtL3T+cnW1G3vE EZxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zmLSpYFRYPTlEc27NW3878uo26pE24ywl6KjiRTQ1Fw=; b=iA9yHBI/9YySbJ2xcan5iERefW3WntuhrpkRojqO/9vENGW38LUFfTqGOhb/87yYLK ANG5V8ddAu8tjhcmxlMS+dvDi1Y81+jrLrJoXgmrMXI8+ceskA5sx2b1jd6T9zEJP5Mm k1rCpuGWiqYl0qmZ/bMVC4wm8YFsFISqPxkfloq/jnhwksumeQb7yb8stXOB+O672/na 3VioWyzaLGObKbq/FXdPj5tzS3lZ5nDS3tQP/gIis33UlBEFxNRK3hlb3UST2tkh2Rqn ZoMVvWmjT/u01fiG9gVFJpwpOratnJaVzmXjWVoVymdGu9OlOYg/K9zI2aHKjucZ356V BPaQ== X-Gm-Message-State: ABUngvfx2C7R10iJ2xbTQptX+kJl8vZGm7aWf3GvIwnCVEyTdbuEWyZ9zf8ycIE6MVG+GA== X-Received: by 10.98.16.203 with SMTP id 72mr26770931pfq.57.1477675424376; Fri, 28 Oct 2016 10:23:44 -0700 (PDT) Received: from [192.168.5.105] (c-73-92-109-167.hsd1.ca.comcast.net. [73.92.109.167]) by smtp.gmail.com with ESMTPSA id r77sm18941671pfa.85.2016.10.28.10.23.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 28 Oct 2016 10:23:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (14A456) In-Reply-To: <20161028165424.GH21985@shrubbery.net> Date: Fri, 28 Oct 2016 10:23:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <088926D6-D384-4824-90BA-BFA09A91D4BF@gmail.com> References: <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> <20161028122402.GB966@Vurt.local> <0F5E21B8-81A4-49E4-9B33-8320DB92ECFD@exa-networks.co.uk> <20161028165424.GH21985@shrubbery.net> To: heasley Archived-At: Cc: IETF IDR , Susan Hares , Thomas Mangin Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 17:23:46 -0000 Sent from my iPhone On Oct 28, 2016, at 9:54 AM, heasley wrote: >>>> What's the benefit of that? Why make these codepoints unusable forever?= >>>=20 >>> Yes, make sure that they are not uselessly carried on the DFZ. >>> I can see the argument for =E2=80=98doing nothing=E2=80=99 tho. >=20 > how would you, or how long would it take to, un-deprecate these attributes= > if vendors were to hard-code filtering of them? In the case of "deprecated->testing", the hard-coded filtering would still b= e desirable. I.e. there are other kinds of un-deprecation than "available for new allocat= ion". Brian= From nobody Fri Oct 28 11:46:47 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937511204D9 for ; Fri, 28 Oct 2016 11:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 wdsxnJQqIYHd for ; Fri, 28 Oct 2016 11:46:44 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D9F127078 for ; Fri, 28 Oct 2016 11:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1396; q=dns/txt; s=iport; t=1477680404; x=1478890004; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TN3Ced0TqmHgauHbErbGfwrcaINwN9BqsvghYUUcy6U=; b=MH6onlEhB140qt7ep2kMXl0GaF2ca0z8v5A7I2ZlbQHmevuk5MXu6Rjb mCgO56ytPyNeWd4LLhCQjvV+rWN+gLyhRzSESTowKBbOluRU/2quG9GKf zoJk4BCjJm9qMXMYGUPvKjSR2UlIQp2jMnFQdDIeqEIE0iphQNpsKfceJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQAjnBNY/51dJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9YfY02ln+HXoxhggcdC4V7AhqBaT8UAQIBAQEBAQEBYii?= =?us-ascii?q?EYgEBAQMBAQEBJA0zBwsFCwIBCBgEKAICHwYLJQIEDgWIOgMPCA6TcZ0wCIhvD?= =?us-ascii?q?YNoAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBA4U6gX0IglCCR4FSEQGDHDCCLwE?= =?us-ascii?q?EmWM1AYx+gyiQBIhzhByEAAEeNl+DT4E7cgGFSYIpAQEB?= X-IronPort-AV: E=Sophos;i="5.31,411,1473120000"; d="scan'208";a="340887041" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Oct 2016 18:46:43 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u9SIkhvL011963 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Oct 2016 18:46:43 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Oct 2016 13:46:43 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 28 Oct 2016 13:46:42 -0500 From: "Jakob Heitz (jheitz)" To: Brian Dickson Thread-Topic: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) Thread-Index: AQHSMDgf3BhwaTAscEG6MWya7SQCLqC8/S8AgAC5xh6AAFgSgIAAEK8AgAAJ8gCAAAGMAIAAKjwA//+8C0CAAFnGgIAACC6A///DYG8= Date: Fri, 28 Oct 2016 18:46:42 +0000 Message-ID: <5B08657C-B010-4094-9781-FD0E4F9A4EEE@cisco.com> References: <20161027095404.GP37101@Vurt.local> <20161028110851.GA966@Vurt.local> <20161028122402.GB966@Vurt.local> <0F5E21B8-81A4-49E4-9B33-8320DB92ECFD@exa-networks.co.uk> <20161028165424.GH21985@shrubbery.net>, <088926D6-D384-4824-90BA-BFA09A91D4BF@gmail.com> In-Reply-To: <088926D6-D384-4824-90BA-BFA09A91D4BF@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: heasley , IETF IDR , Susan Hares , Thomas Mangin Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 18:46:45 -0000 VGhlcmUgaXMgTk8gV0FZIHdlIGFyZSBnb2luZyB0byBoYXJkIGNvZGUgZmlsdGVyIGFueXRoaW5n LiBGb3JnZXRhYm91dGl0LiBTZWUgbXkgZWFybGllciBlbWFpbCBhYm91dCBjb25maWd1cmluZyBm aWx0ZXJzLg0KDQpUaGFua3MsDQpKYWtvYi4NCg0KDQo+IE9uIE9jdCAyOCwgMjAxNiwgYXQgMTA6 MjMgQU0sIEJyaWFuIERpY2tzb24gPGJyaWFuLnBldGVyLmRpY2tzb25AZ21haWwuY29tPiB3cm90 ZToNCj4gDQo+IA0KPiANCj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPiANCj4gT24gT2N0IDI4LCAy MDE2LCBhdCA5OjU0IEFNLCBoZWFzbGV5IDxoZWFzQHNocnViYmVyeS5uZXQ+IHdyb3RlOg0KPiAN Cj4+Pj4+IFdoYXQncyB0aGUgYmVuZWZpdCBvZiB0aGF0PyBXaHkgbWFrZSB0aGVzZSBjb2RlcG9p bnRzIHVudXNhYmxlIGZvcmV2ZXI/DQo+Pj4+IA0KPj4+PiBZZXMsIG1ha2Ugc3VyZSB0aGF0IHRo ZXkgYXJlIG5vdCB1c2VsZXNzbHkgY2FycmllZCBvbiB0aGUgREZaLg0KPj4+PiBJIGNhbiBzZWUg dGhlIGFyZ3VtZW50IGZvciChrmRvaW5nIG5vdGhpbmehryB0aG8uDQo+PiANCj4+IGhvdyB3b3Vs ZCB5b3UsIG9yIGhvdyBsb25nIHdvdWxkIGl0IHRha2UgdG8sIHVuLWRlcHJlY2F0ZSB0aGVzZSBh dHRyaWJ1dGVzDQo+PiBpZiB2ZW5kb3JzIHdlcmUgdG8gaGFyZC1jb2RlIGZpbHRlcmluZyBvZiB0 aGVtPw0KPiANCj4gSW4gdGhlIGNhc2Ugb2YgImRlcHJlY2F0ZWQtPnRlc3RpbmciLCB0aGUgaGFy ZC1jb2RlZCBmaWx0ZXJpbmcgd291bGQgc3RpbGwgYmUgZGVzaXJhYmxlLg0KPiANCj4gSS5lLiB0 aGVyZSBhcmUgb3RoZXIga2luZHMgb2YgdW4tZGVwcmVjYXRpb24gdGhhbiAiYXZhaWxhYmxlIGZv ciBuZXcgYWxsb2NhdGlvbiIuDQo+IA0KPiBCcmlhbg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K From nobody Sat Oct 29 04:52:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29181294C3 for ; Sat, 29 Oct 2016 04:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 sfAJg0bA3cNP for ; Sat, 29 Oct 2016 04:52:18 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id C4E4C12947D for ; Sat, 29 Oct 2016 04:52:17 -0700 (PDT) Received: from www.lamehost.it (unknown [80.76.80.23]) (Authenticated sender: marco@lamehost.it) by seele.lamehost.it (Postfix) with ESMTPSA id 0471D746D1; Sat, 29 Oct 2016 13:52:14 +0200 (CEST) Mime-Version: 1.0 Date: Sat, 29 Oct 2016 11:52:13 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <95023aa5eac831d49b612a3abf92cc91@www.lamehost.it> X-Mailer: RainLoop/1.10.3.151 From: marco@lamehost.it To: "Job Snijders" , "Brian Dickson" In-Reply-To: <20161028142507.GB956@Vurt.local> References: <20161028142507.GB956@Vurt.local> <20161026165710.GC58742@shrubbery.net> <1d8301d22df0$cee63500$6cb29f00$@ndzh.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> X-Originating-IP: 79.24.77.5 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Sat, 29 Oct 2016 13:52:14 +0200 (CEST) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (seele.lamehost.it [0.0.0.0]); Sat, 29 Oct 2016 13:52:14 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.99.2 at seele X-Virus-Status: Clean Archived-At: Cc: heasley , IETF IDR , Susan Hares Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 11:52:20 -0000 October 28, 2016 4:25 PM, "Job Snijders" wrote:=0A> O= n Thu, Oct 27, 2016 at 12:04:12PM -0700, Brian Dickson wrote:=0A> =0A>>>>= I was suggesting the same thing out-of-list today. We should=0A>>>> real= ly assign ~5 values to experimental/development puroposes=0A>>> =0A>>> I = think this would be useful both to allow for larger-scale=0A>>> testing o= f new attributes, and for vendors to be more easily be=0A>>> able to test= multiple new attributes in-house.=0A>> =0A>> The problem here is that pe= ople are not abiding the rules, and=0A>> offering more codepoints will on= ly work if people abide those rules.=0A>> I have no confidence that more = dev codepoints resolve the issue.=0A>> =0A>> The counter argument is very= simple: If we don't offer more code=0A>> points, they *definitely* won't= use them (and thus abide by the=0A>> rules).=0A> =0A> On the other hand,= they weren't using today's 255 codepoint either.=0A> =0A=0AAgain: you ca= n't be sure! From nobody Sat Oct 29 07:47:34 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AC61295BC for ; Sat, 29 Oct 2016 07:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kpEGq46ovWMm for ; Sat, 29 Oct 2016 07:47:30 -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 8AAB71295F3 for ; Sat, 29 Oct 2016 07:47:30 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u9TElQg4093290 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Oct 2016 15:47:26 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be cupcake.local Message-ID: <5814B67D.1070307@foobar.org> Date: Sat, 29 Oct 2016 15:47:25 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.5 (Macintosh/20161020) MIME-Version: 1.0 To: Brian Dickson References: <20161020215938.GE1074@Vurt.local> <20161021154958.GR27221@gir.theapt.org> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <20161021164241.GC32387@Vurt.local> <20161022123423.GD79185@Space.Net> <20161023233431.GA76131@gweep.net> <580F3D94.6050900@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF IDR WG Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 14:47:33 -0000 Brian Dickson wrote: > What I am proposing, is to make the document internally consistent. > > The last paragraph of section 1 (Introduction) reads as follows: > > To address these shortcomings, this document defines a Large BGP > Communities attribute encoded as one or more twelve-octet values, > each consisting of a four-octet ASN and two four-octet operator- > defined values, each of which can be used to denote properties or > actions significant to that ASN > > Making the field descriptions and wording in section 2 agree with this, > is the intent. Brian, hmm yes, I agree this is a problem that needs to be fixed. > Since there has been no disagreement on the introduction, and in > fact that the introduction was offered as proof that there was no > need to change the wording (to which I disagree), I was suggesting > the changes that move toward the general understanding conveyed in > the introduction. The spec for the first 4 octets in the document is "Global Administrator" and this is located in section 2. The introduction is an introduction, not a definition. The text for this has been cleaned up to make it consistent with section 2 and Job plans to post -07 later today (see https://git.io/vXLO7 for diffs). I've also gone through the rest of the document to ensure that there are no other inconsistencies in this area. The other issues you raised in your email were all raised prior to John's email of oct 24, and I don't really want to get bogged down in another round of arguments about them. Nick From nobody Sun Oct 30 02:58:05 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D988B129479; Sun, 30 Oct 2016 02:58:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147782148388.20693.13430784008987385723.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2016 02:58:03 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-large-community-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 09:58:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Large BGP Communities Authors : Jakob Heitz Job Snijders Keyur Patel Ignas Bagdonas Adam Simpson Nick Hilliard Filename : draft-ietf-idr-large-community-06.txt Pages : 9 Date : 2016-10-30 Abstract: This document describes the Large BGP Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with four-octet ASNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-large-community-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 30 03:01:18 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0009126B6D; Sun, 30 Oct 2016 03:01:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147782167391.20677.10152832207329520311.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2016 03:01:13 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-li-idr-mpls-path-programming-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 10:01:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : BGP Extensions for Service-Oriented MPLS Path Programming (MPP) Authors : Zhenbin Li Shunwan Zhuang Sujian Lu Filename : draft-li-idr-mpls-path-programming-04.txt Pages : 14 Date : 2016-10-30 Abstract: Service-oriented MPLS programming (SoMPP) is to provide customized service process based on flexible label combinations. BGP will play an important role for MPLS path programming to download programmed MPLS path and map the service path to the transport path. This document defines BGP extensions to support service-oriented MPLS path programming. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-li-idr-mpls-path-programming/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-li-idr-mpls-path-programming-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-li-idr-mpls-path-programming-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 30 03:03:11 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABA0129479 for ; Sun, 30 Oct 2016 03:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.972] autolearn=ham autolearn_force=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 lq2UUG6xEEtj for ; Sun, 30 Oct 2016 03:03:08 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 83539126B6D for ; Sun, 30 Oct 2016 03:03:08 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c0mxH-0008AZ-1d (job@us.ntt.net); Sun, 30 Oct 2016 10:03:08 +0000 Date: Sun, 30 Oct 2016 11:03:01 +0100 From: Job Snijders To: idr@ietf.org Message-ID: <20161030100301.GV966@Vurt.local> References: <147782148388.20693.13430784008987385723.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147782148388.20693.13430784008987385723.idtracker@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 10:03:09 -0000 Dear Working Group, ChangeLog -05 -> -06: o Improve internal consistency about interpretation of GA (Nick, Brian) o Various wordsmithing (Richard Hartmann) o Recognise John Heasley as a significant contributor o List seventh implementation: Quagga Thank you for your contributions! Kind regards, Job On Sun, Oct 30, 2016 at 02:58:03AM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing of the IETF. > > Title : Large BGP Communities > Authors : Jakob Heitz > Job Snijders > Keyur Patel > Ignas Bagdonas > Adam Simpson > Nick Hilliard > Filename : draft-ietf-idr-large-community-06.txt > Pages : 9 > Date : 2016-10-30 > > Abstract: > This document describes the Large BGP Communities attribute, an > extension to BGP-4. This attribute provides a mechanism to signal > opaque information within separate namespaces to aid in routing > management. The attribute is suitable for use with four-octet ASNs. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-large-community-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sun Oct 30 06:52:31 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B03C12956B for ; Sun, 30 Oct 2016 06:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 oar_TXE_dOVl for ; Sun, 30 Oct 2016 06:52:28 -0700 (PDT) Received: from mailhosting.spakka.net (mailhosting.spakka.net [IPv6:2a02:af8:cafe:f00d::25]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B0412955E for ; Sun, 30 Oct 2016 06:52:27 -0700 (PDT) Received: from [2a02:a210:380:92f0:aefd:ceff:fe33:1cc9] by mailhosting.spakka.net with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c0qXC-0005QS-4a for idr@ietf.org; Sun, 30 Oct 2016 13:52:26 +0000 To: idr@ietf.org References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> From: Colin Petrie Message-ID: Date: Sun, 30 Oct 2016 14:52:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SMTP-Authenticated-User: colin@spakka.net Archived-At: Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 13:52:30 -0000 On 21/10/16 23:32, Paul Jakma wrote: > On Tue, 18 Oct 2016, Susan Hares wrote: >> Do we know which routers are sending path attributes with 20 or 21? > > I don't know about #20, but Quagga had support for AS_PATHLIMIT for a > while. I added it in '07 and removed it from the upstream code in '11. >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Peter Hessler >> I just did a check of the DFZ, both IPv4 and IPv6, and these are the >> unknown/deprecated attributes on paths that I can see. >> >> 20 Connector Attribute (deprecated) [RFC6037] >> 21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit] At RIPE NCC, we searched our RIS raw data for the last 12 months to see what unknown attributes we could find. We found the following ones that Peter mentions: 20: Connector Attribute (deprecated) 21: AS_PATHLIMIT (deprecated) We also found: 28: BGP Entropy Label Capability Attribute (deprecated) 128: ATTR_SET (not deprecated but probably shouldn't be leaking into the DFZ) In the last month we also saw: 30: LARGE_COMMUNITY (old) 32: LARGE_COMMUNITY (new) We also found an interesting unknown attribute, code 243. This appeared at all our collectors but only during June 2016. We're not sure what it is. We saw it for 4500 different prefixes, but all of them had the following sequence of AS_PATH: "7018 4466 5673" Looking at the AS graphs on bgp.he.net, at a guess, it was probably either AS5673 or AS4466 who originated this. A bit of googling also reveals a mention of it here: https://bugs.launchpad.net/juniperopenstack/+bug/1599588 " Unknown Attribute (243), length: 8, Flags [OT]: no Attribute 243 decoder 0x0000: 8071 369b 0000 0007 " Perhaps this is some internal SDN thing that leaked publicly? Anyway, hope this information is useful - if anyone needs any more details please let me know. Kind Regards, Colin From nobody Sun Oct 30 11:05:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E1112948F for ; Sun, 30 Oct 2016 11:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1dSaM-YNuoj6 for ; Sun, 30 Oct 2016 11:05:52 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A75129473 for ; Sun, 30 Oct 2016 11:05:52 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id t79so14405639wmt.0 for ; Sun, 30 Oct 2016 11:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DGCbMkgTRB7KEMrmluAKAXIut1NmIspotNcQAZlD+Ag=; b=dOQwuq933TZ0cf7s6JMvHWZ91HTNJk6QSZn2EPJwpkQn+FhRgkdbW06f5/6DR9I6qq +9JVkU6nXi6OwRk+Ix3nwRzj37MDz4ZKIdSpRw9KGC/pFnf2byxW9QRnAYXXPtk16Ufh lKwNUm8zkxbl3dN9HCYK7RgBtPg9UBmOpAUdI+L1eG0PyBYGfAAE2urUbZVbzyd8aLFR FMCLBy9JTFMbgPxom4RfkA/FHgrcZ5Kh7QDgpO5jCoFy7jyfSGKPBHRYC9Wa950j3D65 icIg2It7keaja314oSJJ9Xv1QfGIzV07JAUPo+uLNAR6iMh8GBu3AV21g36mFvY1xCj2 9aXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DGCbMkgTRB7KEMrmluAKAXIut1NmIspotNcQAZlD+Ag=; b=LnboYn2RDhPxB/osYn/7P/p921NRbMFAZELv2W78dvUnTXMxipDbDxwVsRM8LOUa0g SUgW58EvE0ED6U/T8AZglM3HTzlzM0SsvCyuVTxpHVir4Xlbj6pCk70OCyovoW3P4bna fLj7s7UlArEVakpe3lppOb2WKZlE8+ektHxmVIyc8Tecv+F27Goa7vKToRwJcJpdcck/ gbgNCJiikMFAcmcn+CUgsv3oQmUCude9+nl/COyd5c89HliWlFqLFEieft7whJHuabqQ 1qxXwFBjdUq0pTkicRi4ASxpzRH27CvNVOCS0CCKHaiP5k0Jj92sCJJm/W2coZsoRWCM lARw== X-Gm-Message-State: ABUngve7QuBDL5w4ZqMHjh65mr2M4c4xcciWN+A4alZBYuoxy1ItSDblF4ykYYYRDAtgWaK31cKgqIefGuglhg== X-Received: by 10.194.56.69 with SMTP id y5mr19277339wjp.4.1477850750521; Sun, 30 Oct 2016 11:05:50 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.137.69 with HTTP; Sun, 30 Oct 2016 11:05:49 -0700 (PDT) In-Reply-To: References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> From: Robert Raszuk Date: Sun, 30 Oct 2016 19:05:49 +0100 X-Google-Sender-Auth: 2R6eUYrhBVVZhxhvY66WtlD7Sos Message-ID: To: Colin Petrie Content-Type: multipart/alternative; boundary=047d7b86ef840418db054018f1aa Archived-At: Cc: idr wg Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 18:05:54 -0000 --047d7b86ef840418db054018f1aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Colin, > =E2=80=8B Perhaps this is some internal SDN thing that leaked publicly ? You are right ... attribute 243 is Contrail's OriginVnPath attribute useful for more complex service chaining scenarios. https://github.com/Juniper/contrail-controller/blob/82cdb6afee49b39e54364f1= 8be8eeca725dd76f4/src/bgp/bgp_attr_base.h With that let's also not forget about attributes 241 and 242 used for multicast edge replication. The work on draft describing those last two temporarily allocated attribute codes is currently being resubmitted. The good news is that they should not be leaked as they are to be send in their dedicated SAFIs so unless peer exchanges right capabilities they should be quite contained. https://github.com/Juniper/contrail-controller/blob/82cdb6afee49b39e54364f1= 8be8eeca725dd76f4/src/net/bgp_af.h Thx, R. We also found an interesting unknown attribute, code 243. This appeared > at all our collectors but only during June 2016. We're not sure what it > is. We saw it for 4500 different prefixes, but all of them had the > following sequence of AS_PATH: > "7018 4466 5673" > > Looking at the AS graphs on bgp.he.net, at a guess, it was probably > either AS5673 or AS4466 who originated this. > > A bit of googling also reveals a mention of it here: > https://bugs.launchpad.net/juniperopenstack/+bug/1599588 > " > Unknown Attribute (243), length: 8, Flags [OT]: > no Attribute 243 decoder > 0x0000: 8071 369b 0000 0007 > " > > =E2=80=8B=E2=80=8B > Perhaps this is some internal SDN thing that leaked publicly? > --047d7b86ef840418db054018f1aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colin,

= > =E2=80=8B
Perhaps th= is is some internal SDN thing that leaked publicly ?

You are right ... attribute 243 i= s Contrail's OriginVnPath attribute useful for more complex service cha= ining scenarios.=C2=A0

https://github.com/Juniper/contrail-contr= oller/blob/82cdb6afee49b39e54364f18be8eeca725dd76f4/src/bgp/bgp_attr_base.h=

With that let's also not forget about= attributes 241 and 242 used for multicast edge replication.=C2=A0The work on draft desc= ribing those last two temporarily allocated attribute codes is currently be= ing resubmitted. The good news is that they should not be leaked as they ar= e to be send in their dedicated SAFIs so unless peer exchanges right capabi= lities they should be quite contained.


Thx,
= R.


We a= lso found an interesting unknown attribute, code 243. This appeared
at all our collectors but only during June 2016. We're not sure what it=
is. We saw it for 4500 different prefixes, but all of them had the
following sequence of AS_PATH:
"7018 4466 5673"

Looking at the AS graphs on bgp.he.net, at a guess, it was probably
either AS5673 or AS4466 who originated this.

A bit of googling also reveals a mention of it here:
https://bugs.launchpad.net/juniperopens= tack/+bug/1599588
"
=C2=A0 =C2=A0Unknown Attribute (243), length: 8, Flags [OT]:
=C2=A0 =C2=A0 =C2=A0no Attribute 243 decoder
=C2=A0 =C2=A0 =C2=A00x0000: 8071 369b 0000 0007
"

=E2=80=8B=E2=80=8B
Perhaps this is s= ome internal SDN thing that leaked publicly?
--047d7b86ef840418db054018f1aa-- From nobody Sun Oct 30 11:22:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F2D129486 for ; Sun, 30 Oct 2016 11:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 6cG4TmsV6s-4 for ; Sun, 30 Oct 2016 11:22:40 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 7AA01129421 for ; Sun, 30 Oct 2016 11:22:40 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c0ukg-000CYl-Ix (job@us.ntt.net); Sun, 30 Oct 2016 18:22:39 +0000 Date: Sun, 30 Oct 2016 19:22:34 +0100 From: Job Snijders To: Robert Raszuk Message-ID: <20161030182234.GA966@Vurt.local> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: idr wg Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 18:22:42 -0000 On Sun, Oct 30, 2016 at 07:05:49PM +0100, Robert Raszuk wrote: > > Perhaps this is some internal SDN thing that leaked publicly ? > > You are right ... attribute 243 is Contrail's OriginVnPath attribute > useful for more complex service chaining scenarios. > > https://github.com/Juniper/contrail-controller/blob/82cdb6afee49b39e54364f18be8eeca725dd76f4/src/bgp/bgp_attr_base.h So this is a case of path attribute squatting, with code deployed in the wild? > With that let's also not forget about attributes 241 and 242 used for > multicast edge replication. The work on draft describing those last two > temporarily allocated attribute codes is currently being resubmitted. The > good news is that they should not be leaked as they are to be send in their > dedicated SAFIs so unless peer exchanges right capabilities they should be > quite contained. > > https://github.com/Juniper/contrail-controller/blob/82cdb6afee49b39e54364f18be8eeca725dd76f4/src/net/bgp_af.h Would this be a (partial?) implementation of https://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01 or is there another draft? Kind regards, Job From nobody Sun Oct 30 11:26:01 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289FC1294B5 for ; Sun, 30 Oct 2016 11:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kzkUtKakk_pi for ; Sun, 30 Oct 2016 11:25:58 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6877812948A for ; Sun, 30 Oct 2016 11:25:58 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id p190so109511777wmp.1 for ; Sun, 30 Oct 2016 11:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dxmJ/XK2s7oLFOt2z4snAv4Vj1MYI+F2WEtPAhoW+q0=; b=CvUa2Pbx6qGIJoh6AE4rMAY8pvHOllGkQzQQLHQYvetZraYIISB1Xb9vBbdxI4hFpd YjKmAfKjqgFo72itGZCZcPxqKk4Clg5RSeOzOi7ta58EGrT2dtN2HwxXh88ovezmrvnS J3+zf0JiaCZGoPQ7KmSyOov1qsRfpoRRWXp+FrvPwfTS3dvllpmSb08KSJMweBXidA+5 HX1mz0A8uEHsTBupjDa44E9KFlgNtpN2rwZtRdeDyRAhU2FCBWX0Zy67O5y2PNfr/IIq u8xJEKW13zaaWyIx7wD49Rf98eO9Kx+qViV6Pa/cvfuWaqRMYiGp5TW2J2w1J3wiEYKF KsTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dxmJ/XK2s7oLFOt2z4snAv4Vj1MYI+F2WEtPAhoW+q0=; b=a7Bzmmh2NAUJYeTK9S45l9Bgqe96IWmFdew2b1RZWaUVaobkhC02gmhWAzNR0WgLo+ jc+sYovdCEWgsDUboLD5+SnPioYjNud2+yvEpaXTxm9ucwsJQxvFEJTqu2x1IrHetpG2 pTSqaeZaXRxw4DObzzB/+6rF1ceQLsqlo3p46ERek/w/4aQMQUc2X5IgUNr1iJObHOAE 6OV6pXmjSmoaTj5zOJ81obF4Jzdxo2O6CzPLYIpl/4CzgyqkbPxo2S3281B8bKFv94u/ 8CVJAMcG6SBc7zO2Riop/Iosxnd5IExbyhIrNfX+REpB5SS1f9K0vKMEh0IAtor51YXG wxCQ== X-Gm-Message-State: ABUngvcJjODzIf0d5EltuzO88Ab7Zk8FWcXq+Mwq9ell5Wz1wP8egPrHjRIBSxZ1jcfgOuqat6hc8T8Pu0N3dw== X-Received: by 10.194.56.69 with SMTP id y5mr19321100wjp.4.1477851956926; Sun, 30 Oct 2016 11:25:56 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.137.69 with HTTP; Sun, 30 Oct 2016 11:25:56 -0700 (PDT) In-Reply-To: <20161030182234.GA966@Vurt.local> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> <20161030182234.GA966@Vurt.local> From: Robert Raszuk Date: Sun, 30 Oct 2016 19:25:56 +0100 X-Google-Sender-Auth: KZtV7HAEoAAjfIr3RBsc8HZVT6g Message-ID: To: Job Snijders Content-Type: multipart/alternative; boundary=047d7b86ef84ec60d105401938fe Archived-At: Cc: idr wg Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 18:26:00 -0000 --047d7b86ef84ec60d105401938fe Content-Type: text/plain; charset=UTF-8 Hi Job, Yes the last two are exactly as defined by this draft. There is an effort in place to update it and resubmit in IETF. Perhaps to BESS. Thx, r. On Sun, Oct 30, 2016 at 7:22 PM, Job Snijders wrote: > On Sun, Oct 30, 2016 at 07:05:49PM +0100, Robert Raszuk wrote: > > > Perhaps this is some internal SDN thing that leaked publicly ? > > > > You are right ... attribute 243 is Contrail's OriginVnPath attribute > > useful for more complex service chaining scenarios. > > > > https://github.com/Juniper/contrail-controller/blob/ > 82cdb6afee49b39e54364f18be8eeca725dd76f4/src/bgp/bgp_attr_base.h > > So this is a case of path attribute squatting, with code deployed in the > wild? > > > With that let's also not forget about attributes 241 and 242 used for > > multicast edge replication. The work on draft describing those last two > > temporarily allocated attribute codes is currently being resubmitted. The > > good news is that they should not be leaked as they are to be send in > their > > dedicated SAFIs so unless peer exchanges right capabilities they should > be > > quite contained. > > > > https://github.com/Juniper/contrail-controller/blob/ > 82cdb6afee49b39e54364f18be8eeca725dd76f4/src/net/bgp_af.h > > Would this be a (partial?) implementation of > https://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01 or is > there another draft? > > Kind regards, > > Job > --047d7b86ef84ec60d105401938fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Job,

Yes the last two are exactly as defined by this draft= . There is an effort in place to update it and resubmit in IETF. Perhaps to= BESS.

Thx,
r.

On Sun, Oct 30, 2016 at 7:22 PM, Job Snijders = <job@ntt.net> wrote:
On Sun, Oct = 30, 2016 at 07:05:49PM +0100, Robert Raszuk wrote:
> > Perhaps this is some internal SDN thing that leaked publicly ? >
> You are right ... attribute 243 is Contrail's OriginVnPath attribu= te
> useful for more complex service chaining scenarios.
>
> https://github.com/Juniper/contrail-controller/bl= ob/82cdb6afee49b39e54364f18be8eeca725dd76f4/src/bgp/bgp_attr_base.h

So this is a case of path attribute squatting, with code deployed in= the wild?

> With that let's also not forget about attributes 241 and 242 used = for
> multicast edge replication. The work on draft describing those last tw= o
> temporarily allocated attribute codes is currently being resubmitted. = The
> good news is that they should not be leaked as they are to be send in = their
> dedicated SAFIs so unless peer exchanges right capabilities they shoul= d be
> quite contained.
>
> https://github.com/Juniper/contrail-controller/blob/82cdb6afee49b39e54364f18be8eeca725dd76f4/src/net/bgp_af.h

Would this be a (partial?) implementation of
https://tools.ietf.org/html/draft-= marques-l3vpn-mcast-edge-01 or is
there another draft?

Kind regards,

Job

--047d7b86ef84ec60d105401938fe-- From nobody Sun Oct 30 11:28:42 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079FE1294C8 for ; Sun, 30 Oct 2016 11:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 jVuWi5qezSbY for ; Sun, 30 Oct 2016 11:28:39 -0700 (PDT) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 B619E1294B8 for ; Sun, 30 Oct 2016 11:28:39 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c0uqT-000D5w-75 (job@us.ntt.net); Sun, 30 Oct 2016 18:28:39 +0000 Date: Sun, 30 Oct 2016 19:28:34 +0100 From: Job Snijders To: idr@ietf.org Message-ID: <20161030182834.GB966@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Subject: [Idr] draft-snijders-idr-deprecate-30-31-129 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 18:28:41 -0000 Hi group, Following the news in https://mailarchive.ietf.org/arch/msg/idr/4D-TH7wlRUjQyw0FFo025cKZcUs - should 241, 242, 243 be added to this draft? Kind regards, Job ----- Forwarded message from internet-drafts@ietf.org ----- Date: Fri, 28 Oct 2016 12:23:45 -0700 From: internet-drafts@ietf.org To: Job Snijders Subject: New Version Notification for draft-snijders-idr-deprecate-30-31-129-01.txt A new version of I-D, draft-snijders-idr-deprecate-30-31-129-01.txt has been successfully submitted by Job Snijders and posted to the IETF repository. Name: draft-snijders-idr-deprecate-30-31-129 Revision: 01 Title: Deprecation of BGP Path Attribute values 30, 31 and 129 Document date: 2016-10-28 Group: Individual Submission Pages: 3 URL: https://www.ietf.org/internet-drafts/draft-snijders-idr-deprecate-30-31-129-01.txt Status: https://datatracker.ietf.org/doc/draft-snijders-idr-deprecate-30-31-129/ Htmlized: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-snijders-idr-deprecate-30-31-129-01 Abstract: This document requests IANA to deprecate the following BGP path attributes values: 30, 31 and 129. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ----- End forwarded message ----- From nobody Sun Oct 30 11:52:22 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B791294AA; Sun, 30 Oct 2016 11:52:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147785354059.20605.9919461569237599656.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2016 11:52:20 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-gredler-idr-bgp-ls-segment-routing-ext-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 18:52:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : BGP Link-State extensions for Segment Routing Authors : Stefano Previdi Peter Psenak Clarence Filsfils Hannes Gredler Mach(Guoyi) Chen Jeff Tantsura Filename : draft-gredler-idr-bgp-ls-segment-routing-ext-04.txt Pages : 35 Date : 2016-10-30 Abstract: Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS, OSPF and OSPFv3). This draft defines extensions to the BGP Link-state address-family in order to carry segment information via BGP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-gredler-idr-bgp-ls-segment-routing-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-gredler-idr-bgp-ls-segment-routing-ext-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-gredler-idr-bgp-ls-segment-routing-ext-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 30 11:56:00 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9396F1294F3 for ; Sun, 30 Oct 2016 11:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 PZdcKhKDkhzd for ; Sun, 30 Oct 2016 11:55:58 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29FBD1294B8 for ; Sun, 30 Oct 2016 11:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2130; q=dns/txt; s=iport; t=1477853758; x=1479063358; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+IohbYiU4SY91evxkLOqPQ7Rjb0ROmPBJeQPDlYfZbg=; b=TOvBC36ddAFlZ/4DRFirtjgwhvvevYJHcZ0fXWe0lWEfU2la058OjHlz BHIsw/FTX4h7bxVjRMyT3sJsBVr2O8ncEAwrxAd9lhVEKbv/FsMOaVzmy 94eeFF50lFFEP7xsT6nZXEtjHOKMNfIB8pLIzwogQ52h27aWQbhwv/bnA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQDgQRZY/5FdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9YfQeNL5Z+lD6CBx0NhXkCggE/FAECAQEBAQEBAWIohGI?= =?us-ascii?q?BAQEDAQEBATc0EAsCAQgYHhAnCyUCBBOITAgOvyQBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEchj2BfQiCUIRHgzGCLwWaGAGGL4MIhniBbk6EH4kpjRGEAQEeNmCFEnK?= =?us-ascii?q?GQ4EJAQEB?= X-IronPort-AV: E=Sophos;i="5.31,423,1473120000"; d="scan'208";a="163264875" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2016 18:55:57 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u9UItvaV027904 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 30 Oct 2016 18:55:57 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 30 Oct 2016 14:55:56 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Sun, 30 Oct 2016 14:55:56 -0400 From: "Stefano Previdi (sprevidi)" To: idr wg Thread-Topic: [Idr] I-D Action: draft-gredler-idr-bgp-ls-segment-routing-ext-04.txt Thread-Index: AQHSMt8/8r36H7k6YUeY/uPUY/KygA== Date: Sun, 30 Oct 2016 18:55:56 +0000 Message-ID: <2EAD52F9-ABCE-4204-B406-9EEDA212CF6B@cisco.com> References: <147785354059.20605.9919461569237599656.idtracker@ietfa.amsl.com> In-Reply-To: <147785354059.20605.9919461569237599656.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.73.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <2C06502835063542B0796D9A4D446DF7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-gredler-idr-bgp-ls-segment-routing-ext-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 18:55:59 -0000 All, this version introduces the new TLVs in order to keep the alignment with IS= IS and OSPF SR extensions. Thanks. s. > On Oct 30, 2016, at 7:52 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Inter-Domain Routing of the IETF. >=20 > Title : BGP Link-State extensions for Segment Routing > Authors : Stefano Previdi > Peter Psenak > Clarence Filsfils > Hannes Gredler > Mach(Guoyi) Chen > Jeff Tantsura > Filename : draft-gredler-idr-bgp-ls-segment-routing-ext-04.txt > Pages : 35 > Date : 2016-10-30 >=20 > Abstract: > Segment Routing (SR) allows for a flexible definition of end-to-end > paths within IGP topologies by encoding paths as sequences of > topological sub-paths, called "segments". These segments are > advertised by the link-state routing protocols (IS-IS, OSPF and > OSPFv3). >=20 > This draft defines extensions to the BGP Link-state address-family in > order to carry segment information via BGP. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-gredler-idr-bgp-ls-segment-routing= -ext/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-gredler-idr-bgp-ls-segment-routing-ext-= 04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-gredler-idr-bgp-ls-segment-rout= ing-ext-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sun Oct 30 12:16:18 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EF912711D for ; Sun, 30 Oct 2016 12:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ROSIfbhfoJEd for ; Sun, 30 Oct 2016 12:16:15 -0700 (PDT) Received: from mailhosting.spakka.net (mailhosting.spakka.net [IPv6:2a02:af8:cafe:f00d::25]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AFB129417 for ; Sun, 30 Oct 2016 12:16:14 -0700 (PDT) Received: from [2a02:a210:380:92f0:aefd:ceff:fe33:1cc9] by mailhosting.spakka.net with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c0vaW-0006QQ-NU; Sun, 30 Oct 2016 19:16:12 +0000 To: Robert Raszuk References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> From: Colin Petrie Message-ID: Date: Sun, 30 Oct 2016 20:16:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SMTP-Authenticated-User: colin@spakka.net Archived-At: Cc: idr wg Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 19:16:16 -0000 On 30/10/16 19:05, Robert Raszuk wrote: > The good news is that they should not be leaked as they are to be send > in their dedicated SAFIs so unless peer exchanges right capabilities > they should be quite contained. In this case, we see them appear on BGP sessions that only negotiate IPv4/Unicast or IPv6/Unicast. Cheers, Colin From nobody Sun Oct 30 12:40:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E8F1294A9 for ; Sun, 30 Oct 2016 12:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 hwfAqFgEVhga for ; Sun, 30 Oct 2016 12:40:20 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821331293EE for ; Sun, 30 Oct 2016 12:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=981; q=dns/txt; s=iport; t=1477856420; x=1479066020; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RZxr7wY0rRP8mJK/EQyZlavKaqwRP0dh/rCeAx3QFK8=; b=E9PIsqu7fC4vynE0nB1YF+8eOdiHpQna7TibA2C6aitfQ8QnUX3CNJ4v cp8wyPi4Q2LPg7ZCgX+eX/LbJMFJ9QQ4s9RgbO9jjrzM6Uyvg6dd5c6Ng yz42N+yTaO0g0U38xytIUlUjxFlP6mYuwQJdJmodXTCUJ51Ke9a7vAzGZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQAFTBZY/5NdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9YfY02ln6UPoIHHQuFewKCAT8UAQIBAQEBAQEBYiiEYgE?= =?us-ascii?q?BAQMBAQEBNzQLBQsCAQgYHhAnCyUCBA4FGogyCA6/JQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARcFhj2BfQiCUIRHgzGCLwWaGAGQL4FujhaHIIVxhAEBHjZghRJyhRQ?= =?us-ascii?q?HgjEBAQE?= X-IronPort-AV: E=Sophos;i="5.31,423,1473120000"; d="scan'208";a="169087385" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2016 19:40:19 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u9UJeJd5016464 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 30 Oct 2016 19:40:19 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 30 Oct 2016 14:40:19 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Sun, 30 Oct 2016 14:40:18 -0500 From: "Jakob Heitz (jheitz)" To: Colin Petrie Thread-Topic: [Idr] Unknown Attributes seen in the wild Thread-Index: AQHSKWSs7BkiNd6f2ECx5wzihKhK2KCu0JwAgAT1t4CADaRlgIAARs2AgAATqgD//7LrNA== Date: Sun, 30 Oct 2016 19:40:18 +0000 Message-ID: <769587CF-3E9E-40C6-9018-93B651BE9E98@cisco.com> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 19:40:21 -0000 There is no concept of a BGP attribute being "restricted" to a safi. If tha= t were the case, then you could use a single attribute code for completely = different attributes in different safis. An attribute that is understood in= one safi, but nonsense in a second safi will cause a malformed update rath= er than an unknown attribute when received in the second safi.=20 Thanks, Jakob. > On Oct 30, 2016, at 12:16 PM, Colin Petrie wrote: >=20 >> On 30/10/16 19:05, Robert Raszuk wrote: >> The good news is that they should not be leaked as they are to be send >> in their dedicated SAFIs so unless peer exchanges right capabilities >> they should be quite contained. >=20 > In this case, we see them appear on BGP sessions that only negotiate > IPv4/Unicast or IPv6/Unicast. >=20 > Cheers, > Colin >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sun Oct 30 13:05:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD16129436 for ; Sun, 30 Oct 2016 13:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Eqdi5NBgKb-L for ; Sun, 30 Oct 2016 13:05:08 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E791279EB for ; Sun, 30 Oct 2016 13:05:05 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id t79so17302018wmt.0 for ; Sun, 30 Oct 2016 13:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=NG7NjGOAzGLxOkhTJ8b5k9XHr/Qm0fP0KtJy/x805NE=; b=KIRfayRRCy41Ng5Bwsh7gwj5omlwFrj43jKDv/5V6J3r5gtbf3f+lOHbmH5Af89CgM RAEhp0idnPOUvHjGHP9boTt4fwtZCvjzPmz6Fi7vmwAt3yeS/hHuAC1z3/iJRqDOJbe5 GbVwPR8ks2Y9rteP5Er7JSFZB9Zz23zEslc1T+poVw/6v0H6hE1pKxzdrOuzCMe16gz5 m4c0bzp+k1Rf2628ROirWseWsWMi1NQQBfjOlY35pHrrzsRXbEY+RA0Dim92YbpZLhmX NLmX2T9NZOoeVeqryJTuY2i2rRs9yK4VJGsok9YGplGxmGlDVErzQCwkSJfzSgLnJ7TE WlIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=NG7NjGOAzGLxOkhTJ8b5k9XHr/Qm0fP0KtJy/x805NE=; b=Rev5qaXaUJ+1qXdO3NmAoC2cAwb/YEjObtG3HcGIAyTsQgcPskHTP/TEJt5ysHEa2A dKZKxUBeCD4KZ/96tbT+GlCs1twDJ4WIZgDCbqfDIG8O1rchqlOqtCXWodn3HfuMprGh /RRSf3o92fw4bZrqUxQbC+VLjLGJ5y5UOQS6Mc4nodtzhme2anjlP9zCSSEpInDUPN9j AXwu7fO8eFBOgFptCJ8G5/m6e3w5aSKfZeipq4RXlWxluMXpq8Oaq09kRrc6vAumNS/Q 43u1sm9e5m2Uo2OKgndSW2XLl1A8/QzvByEJRyYwml3+bqzJuOohLdlIHN1SN8iahmsn sYpg== X-Gm-Message-State: ABUngvdCVkSmc3m9K1VuYpZudDk/gUkjNXIPGrmKHZ4mIv1TGi8WAZo1bpBeDKpg4EL5GTz7/ZptjtonsinrpA== X-Received: by 10.28.185.203 with SMTP id j194mr3899611wmf.73.1477857904320; Sun, 30 Oct 2016 13:05:04 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.137.69 with HTTP; Sun, 30 Oct 2016 13:05:03 -0700 (PDT) In-Reply-To: <769587CF-3E9E-40C6-9018-93B651BE9E98@cisco.com> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> <769587CF-3E9E-40C6-9018-93B651BE9E98@cisco.com> From: Robert Raszuk Date: Sun, 30 Oct 2016 21:05:03 +0100 X-Google-Sender-Auth: xxVsh7f0f3M9APzb5e96_59goZE Message-ID: To: "Jakob Heitz (jheitz)" Content-Type: multipart/alternative; boundary=001a1148ebca6a658105401a9b11 Archived-At: Cc: idr wg Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 20:05:10 -0000 --001a1148ebca6a658105401a9b11 Content-Type: text/plain; charset=UTF-8 Jakob, contained != restricted Moreover there is number of overlay solutions in the wild which run under the cover BGP with various self defined attributes and safis. Just think about SD-WAN or DC overlay solutions. Some of them tried to take IETF path some never bothered seeing how hard is to get early IANA allocations or being aware of multiple implementation requirement. Some are limited to contained deployments some are encrypted. It is close to impossible to now list all of those. It was pretty clear this is coming ... one strategic solution was an attempt 6 years back to separate BGP into BGP used for transport for all of the application and services (new BGP port) and BGP used for Internet routing (179). That would allow complete separation of the two. https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 Thx, r. On Sun, Oct 30, 2016 at 8:40 PM, Jakob Heitz (jheitz) wrote: > There is no concept of a BGP attribute being "restricted" to a safi. If > that were the case, then you could use a single attribute code for > completely different attributes in different safis. An attribute that is > understood in one safi, but nonsense in a second safi will cause a > malformed update rather than an unknown attribute when received in the > second safi. > > Thanks, > Jakob. > > > On Oct 30, 2016, at 12:16 PM, Colin Petrie wrote: > > > >> On 30/10/16 19:05, Robert Raszuk wrote: > >> The good news is that they should not be leaked as they are to be send > >> in their dedicated SAFIs so unless peer exchanges right capabilities > >> they should be quite contained. > > > > In this case, we see them appear on BGP sessions that only negotiate > > IPv4/Unicast or IPv6/Unicast. > > > > Cheers, > > Colin > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > --001a1148ebca6a658105401a9b11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jakob,

contained !=3D restricted

=
Moreover there is number of overlay solutions in t= he wild which run under the cover BGP with various self defined attributes = and safis. Just think about SD-WAN or DC overlay solutions.=C2=A0

Some of them tried to take IETF= path some never bothered seeing how hard is to get early IANA allocations = or being aware of multiple implementation requirement.=C2=A0

Some are limited to contained deploy= ments some are encrypted. It is close to impossible to now list all of thos= e.=C2=A0

It was pretty= clear this is coming ... one strategic solution was an attempt 6 years bac= k to separate BGP into BGP used for transport for all of the application an= d services (new BGP port) and BGP used for Internet routing (179). That wou= ld allow complete separation of the two.

=
https://tools.= ietf.org/html/draft-raszuk-ti-bgp-01

Thx,<= /font>
r.

On Sun, Oct 30, 2016 at 8:40 PM, Jakob Heitz (jheitz) <jheitz= @cisco.com> wrote:
There is= no concept of a BGP attribute being "restricted" to a safi. If t= hat were the case, then you could use a single attribute code for completel= y different attributes in different safis. An attribute that is understood = in one safi, but nonsense in a second safi will cause a malformed update ra= ther than an unknown attribute when received in the second safi.

Thanks,
Jakob.

> On Oct 30, 2016, at 12:16 PM, Colin Petrie <colin@spakka.net> wrote:
>
>> On 30/10/16 19:05, Robert Raszuk wrote:
>> The good news is that they should not be leaked as they are to be = send
>> in their dedicated SAFIs so unless peer exchanges right capabiliti= es
>> they should be quite contained.
>
> In this case, we see them appear on BGP sessions that only negotiate > IPv4/Unicast or IPv6/Unicast.
>
> Cheers,
> Colin
>
> __________________= _____________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

--001a1148ebca6a658105401a9b11-- From nobody Sun Oct 30 13:26:18 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D865B1293EE for ; Sun, 30 Oct 2016 13:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 HKUJYS5UksXO for ; Sun, 30 Oct 2016 13:26:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1B512711D for ; Sun, 30 Oct 2016 13:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7760; q=dns/txt; s=iport; t=1477859175; x=1479068775; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YVsdhSQJD1uaI8/oZYSpqWIGt2pwFvwmW9H2H33pgRw=; b=VFthATCVHoZ3WpmsmW+ec0SKa3uI0BuxHZO9gei5DLJzWm1y+SrGX4wb XUsxwJkGWPCoND7Odoe7umUiq8/suVeQbbl2obsrwf2om8WG7stGaLB1m a8qKmzdtOc/VV8UE9f2nSkXkxeALvavnSV/Q75+ppJC07cHUMo+8WUwYC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AgC1VhZY/5pdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9YfY02ln6PKIUWggcdAQqFewKCAT8UAQIBAQEBAQEBYii?= =?us-ascii?q?EYgEBAQMBAQEBawsFCwIBCBgnBycLFBECBA4FGgGIMQgOvzkBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEXBYY9gX0IglCEI4NVgi8FmhgBhi+KAIFujhaHIIVxhAEBHjZ?= =?us-ascii?q?ggmiCKnKFFAeCMQEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,423,1473120000"; d="scan'208,217";a="165462322" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2016 20:26:14 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u9UKQEqx031634 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 30 Oct 2016 20:26:14 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 30 Oct 2016 15:26:14 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Sun, 30 Oct 2016 15:26:13 -0500 From: "Jakob Heitz (jheitz)" To: Robert Raszuk Thread-Topic: [Idr] Unknown Attributes seen in the wild Thread-Index: AQHSKWSs7BkiNd6f2ECx5wzihKhK2KCu0JwAgAT1t4CADaRlgIAARs2AgAATqgD//7LrNIAAWruA//+yGXE= Date: Sun, 30 Oct 2016 20:26:13 +0000 Message-ID: <70003119-429D-49AE-8126-3B462E179E71@cisco.com> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> <769587CF-3E9E-40C6-9018-93B651BE9E98@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_70003119429D49AE81263B462E179E71ciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 20:26:17 -0000 --_000_70003119429D49AE81263B462E179E71ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Send them one of those attributes in a different safi. What do you think wi= ll happen? Will they pass it on harmlessly, like any unknown optional transitive attri= bute? Thanks, Jakob. On Oct 30, 2016, at 1:05 PM, Robert Raszuk > wrote: Jakob, contained !=3D restricted Moreover there is number of overlay solutions in the wild which run under t= he cover BGP with various self defined attributes and safis. Just think abo= ut SD-WAN or DC overlay solutions. Some of them tried to take IETF path some never bothered seeing how hard is= to get early IANA allocations or being aware of multiple implementation re= quirement. Some are limited to contained deployments some are encrypted. It is close t= o impossible to now list all of those. It was pretty clear this is coming ... one strategic solution was an attemp= t 6 years back to separate BGP into BGP used for transport for all of the a= pplication and services (new BGP port) and BGP used for Internet routing (1= 79). That would allow complete separation of the two. https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 Thx, r. On Sun, Oct 30, 2016 at 8:40 PM, Jakob Heitz (jheitz) > wrote: There is no concept of a BGP attribute being "restricted" to a safi. If tha= t were the case, then you could use a single attribute code for completely = different attributes in different safis. An attribute that is understood in= one safi, but nonsense in a second safi will cause a malformed update rath= er than an unknown attribute when received in the second safi. Thanks, Jakob. > On Oct 30, 2016, at 12:16 PM, Colin Petrie > wrote: > >> On 30/10/16 19:05, Robert Raszuk wrote: >> The good news is that they should not be leaked as they are to be send >> in their dedicated SAFIs so unless peer exchanges right capabilities >> they should be quite contained. > > In this case, we see them appear on BGP sessions that only negotiate > IPv4/Unicast or IPv6/Unicast. > > Cheers, > Colin > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --_000_70003119429D49AE81263B462E179E71ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Send them one of those attributes in a different safi. What do you thi= nk will happen?
Will they pass it on harmlessly, like any un= known optional transitive attribute?

Thanks,
Jakob.

On Oct 30, 2016, at 1:05 PM, Robert Raszuk <robert@raszuk.net> wrote:

Jakob,

contained !=3D restricted

Moreover there is number of overlay solutions in the wild which run under t= he cover BGP with various self defined attributes and safis. Just think abo= ut SD-WAN or DC overlay solutions. 

Some of them tried to take IETF path some never bothered seeing how hard is= to get early IANA allocations or being aware of multiple implementation re= quirement. 

Some are limited to contained deployments some are encrypted. It is close t= o impossible to now list all of those. 

It was pretty clear this is coming ... one strategic solution was an attemp= t 6 years back to separate BGP into BGP used for transport for all of the a= pplication and services (new BGP port) and BGP used for Internet routing (1= 79). That would allow complete separation of the two.

https://tools.= ietf.org/html/draft-raszuk-ti-bgp-01
Th= x,
r.=

On Sun, Oct 30, 2016 at 8:40 PM, Jakob Heitz (jh= eitz) <jheitz@cisco.com<= /a>> wrote:
There is no concept of a BGP attribute being "restricted" to a sa= fi. If that were the case, then you could use a single attribute code for c= ompletely different attributes in different safis. An attribute that is und= erstood in one safi, but nonsense in a second safi will cause a malformed update rather than an unknown attribute when r= eceived in the second safi.

Thanks,
Jakob.

> On Oct 30, 2016, at 12:16 PM, Colin Petrie <colin@spakka.net> wrote:
>
>> On 30/10/16 19:05, Robert Raszuk wrote:
>> The good news is that they should not be leaked as they are to be = send
>> in their dedicated SAFIs so unless peer exchanges right capabiliti= es
>> they should be quite contained.
>
> In this case, we see them appear on BGP sessions that only negotiate > IPv4/Unicast or IPv6/Unicast.
>
> Cheers,
> Colin
>
> _______________________________________________=
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

--_000_70003119429D49AE81263B462E179E71ciscocom_-- From nobody Sun Oct 30 13:37:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D7512948E for ; Sun, 30 Oct 2016 13:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jqBASwcwkbcz for ; Sun, 30 Oct 2016 13:37:33 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4F3129440 for ; Sun, 30 Oct 2016 13:37:33 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id t79so18069559wmt.0 for ; Sun, 30 Oct 2016 13:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yFxr00O7lze5dyRJUm49aG8oSuKGo49UPV6QW30eKUM=; b=OTYQYIVnoN9f/h8SGr4rzPBhkK+hQViB22bITQ6oBDDgAn9pvd7q+LTr53/rqmSllV wcw9H9agObZdx/cqv39Hs+hk6zz+085YHKKs7/FYrrQD4Zf8P4xddx+lwDQ9bLIRn8ez 6ZeA1L95I7O5RS8YdulCutkhXdBgaI6esWsJ9upT38qD7wbfZiyoS7Deb5P7vbrYI3h/ lc9/JFo4ygp0fEgX9wzifBr9mfaSzVo/1fNoK6jXszN5Sh3YqiVnBXJbdjYge3+orHvX tHynMJ6jzxgz9uo7UMcP8MhfkA0bHWgH9jL17EV9pRwvKu8cUwD7NubmxxQ1IjE7mPwV 93GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yFxr00O7lze5dyRJUm49aG8oSuKGo49UPV6QW30eKUM=; b=J78uzoxQOHlXZUmisvb57/URY6FoGmIoABttabwHitAu2jVRqPqy2OwR50jpOuBcLf 63/xamDTK367KuyO+wlZEY9QafhblRyEGvZVAjnHyNMfgIksgYo78r1u3sCCWPrn26a5 XcWGeasqU/IiPVYrqTS6t8mo/eSc14AH35V8RGI7KHyRQ5zvPqiJqNdLlWmWo/J5r0Bn pxA9+JMxnfWOf3+63gejWE0TWViiwCBxHJbZC4thQnCprBcygL5XCqiNyVJ+2vKznkyt 96wfYjSRf4ypoPrt9n3T3INTnCBYybphxc6mweE01XxgVhgllEwOTfELlNY5qLWDyX/U ei8A== X-Gm-Message-State: ABUngvdT0EmZ4R0MysNGKwzZ386KtPwhwDvqpiGpeL3l+DGQs3NmxxrnSJ72aHhso4AqAnJgAA1NdwqE64Ib5Q== X-Received: by 10.194.56.69 with SMTP id y5mr19569924wjp.4.1477859851636; Sun, 30 Oct 2016 13:37:31 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.80.137.69 with HTTP; Sun, 30 Oct 2016 13:37:30 -0700 (PDT) In-Reply-To: <70003119-429D-49AE-8126-3B462E179E71@cisco.com> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> <769587CF-3E9E-40C6-9018-93B651BE9E98@cisco.com> <70003119-429D-49AE-8126-3B462E179E71@cisco.com> From: Robert Raszuk Date: Sun, 30 Oct 2016 21:37:30 +0100 X-Google-Sender-Auth: NzHqiGFLfawu-uyTYXaJvvP4ihs Message-ID: To: "Jakob Heitz (jheitz)" Content-Type: multipart/alternative; boundary=047d7b86ef847c165205401b0f9a Archived-At: Cc: idr wg Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 20:37:36 -0000 --047d7b86ef847c165205401b0f9a Content-Type: text/plain; charset=UTF-8 Those self invented attributes will not be passed/leaked as such safi they are to be part of will not be capability negotiated in the first place with any Internet router. Thx, R. On Sun, Oct 30, 2016 at 9:26 PM, Jakob Heitz (jheitz) wrote: > Send them one of those attributes in a different safi. What do you think > will happen? > Will they pass it on harmlessly, like any unknown optional transitive > attribute? > > Thanks, > Jakob. > > On Oct 30, 2016, at 1:05 PM, Robert Raszuk wrote: > > Jakob, > > contained != restricted > > Moreover there is number of overlay solutions in the wild which run under > the cover BGP with various self defined attributes and safis. Just think > about SD-WAN or DC overlay solutions. > > Some of them tried to take IETF path some never bothered seeing how hard > is to get early IANA allocations or being aware of multiple implementation > requirement. > > Some are limited to contained deployments some are encrypted. It is close > to impossible to now list all of those. > > It was pretty clear this is coming ... one strategic solution was an > attempt 6 years back to separate BGP into BGP used for transport for all of > the application and services (new BGP port) and BGP used for Internet > routing (179). That would allow complete separation of the two. > > https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 > > Thx, > r. > > On Sun, Oct 30, 2016 at 8:40 PM, Jakob Heitz (jheitz) > wrote: > >> There is no concept of a BGP attribute being "restricted" to a safi. If >> that were the case, then you could use a single attribute code for >> completely different attributes in different safis. An attribute that is >> understood in one safi, but nonsense in a second safi will cause a >> malformed update rather than an unknown attribute when received in the >> second safi. >> >> Thanks, >> Jakob. >> >> > On Oct 30, 2016, at 12:16 PM, Colin Petrie wrote: >> > >> >> On 30/10/16 19:05, Robert Raszuk wrote: >> >> The good news is that they should not be leaked as they are to be send >> >> in their dedicated SAFIs so unless peer exchanges right capabilities >> >> they should be quite contained. >> > >> > In this case, we see them appear on BGP sessions that only negotiate >> > IPv4/Unicast or IPv6/Unicast. >> > >> > Cheers, >> > Colin >> > >> > _______________________________________________ >> > Idr mailing list >> > Idr@ietf.org >> > https://www.ietf.org/mailman/listinfo/idr >> > > --047d7b86ef847c165205401b0f9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Those self= invented attributes will not be passed/leaked as such safi they are to be = part of will not be capability negotiated in the first place with any Inter= net router.

Thx,
R.=

On Su= n, Oct 30, 2016 at 9:26 PM, Jakob Heitz (jheitz) <jheitz@cisco.com><= /span> wrote:
Send them one of those attributes in a different safi. What do you thi= nk will happen?
Will they pass it on h= armlessly, like any unknown optional transitive attribute?

Thanks,
Jakob.

On Oct 30, 2016, at 1:05 PM, Robert Raszuk <robert@raszuk.net> wrote:

Jakob,

contained !=3D restricted

Moreover there is number of overlay solutions in the wild which run under t= he cover BGP with various self defined attributes and safis. Just think abo= ut SD-WAN or DC overlay solutions.=C2=A0

Some of them tried to take IETF path some never bothered seeing how hard is= to get early IANA allocations or being aware of multiple implementation re= quirement.=C2=A0

Some are limited to contained deployments some are encrypted. It is close t= o impossible to now list all of those.=C2=A0

It was pretty clear this is coming ... one strategic solution was an attemp= t 6 years back to separate BGP into BGP used for transport for all of the a= pplication and services (new BGP port) and BGP used for Internet routing (1= 79). That would allow complete separation of the two.

https://tools.ietf.org/html/draft-raszuk-ti-bgp-01
Th= x,
r.=

On Sun, Oct 30, 2016 at 8:40 PM, Jakob Heitz (jh= eitz) <jheitz@cisco.com<= /a>> wrote:
There is no concept of a BGP attribute being "restricted" to a sa= fi. If that were the case, then you could use a single attribute code for c= ompletely different attributes in different safis. An attribute that is und= erstood in one safi, but nonsense in a second safi will cause a malformed update rather than an unknown attribute when r= eceived in the second safi.

Thanks,
Jakob.

> On Oct 30, 2016, at 12:16 PM, Colin Petrie <colin@spakka.net> wrote:
>
>> On 30/10/16 19:05, Robert Raszuk wrote:
>> The good news is that they should not be leaked as they are to be = send
>> in their dedicated SAFIs so unless peer exchanges right capabiliti= es
>> they should be quite contained.
>
> In this case, we see them appear on BGP sessions that only negotiate > IPv4/Unicast or IPv6/Unicast.
>
> Cheers,
> Colin
>
> ______________________________= _________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


--047d7b86ef847c165205401b0f9a-- From nobody Sun Oct 30 14:08:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE82129487 for ; Sun, 30 Oct 2016 14:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 YNf5O-JlJIO5 for ; Sun, 30 Oct 2016 14:08:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BBA9129480 for ; Sun, 30 Oct 2016 14:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9928; q=dns/txt; s=iport; t=1477861685; x=1479071285; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wLnyve+NyUKcp1jAy0G+gZWzCgKrik/AkpWDY96Owic=; b=EyJqdbaJW4DGuPgDHaeZDfS3S6nL3Y5CWZH4ShRViEDbwmJNz90RbCjY VXRlnX0hLtTXLTaxnS0lbIcqgXtWGJ9uoC8wwdsaglPrydACCxWQDuFYs nocycAsvAM3ORETs5wj4pVKW4ryBQqn0pc1sBxciMdc0jpsIQbdaW0zWU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AgAAYRZY/5pdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9YfY02ln6PKIUWggcdAQqFewKCAT8UAQIBAQEBAQEBYii?= =?us-ascii?q?EYgEBAQMBAQEBawsFCwIBCBgnBycLFBECBA4FGgGIMQgOv0EBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEXBYY9gX0IglCEI4NVgi8FmhgBhi+KAIFujhaHIIVxhAEBHjZ?= =?us-ascii?q?ggmiCKnKFFAeCMQEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,423,1473120000"; d="scan'208,217";a="163631393" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2016 21:07:38 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u9UL7ca6027199 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 30 Oct 2016 21:07:38 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 30 Oct 2016 16:07:37 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Sun, 30 Oct 2016 16:07:37 -0500 From: "Jakob Heitz (jheitz)" To: Robert Raszuk Thread-Topic: [Idr] Unknown Attributes seen in the wild Thread-Index: AQHSKWSs7BkiNd6f2ECx5wzihKhK2KCu0JwAgAT1t4CADaRlgIAARs2AgAATqgD//7LrNIAAWruA//+yGXGAAFb4AP//tJl+ Date: Sun, 30 Oct 2016 21:07:37 +0000 Message-ID: References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> <769587CF-3E9E-40C6-9018-93B651BE9E98@cisco.com> <70003119-429D-49AE-8126-3B462E179E71@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_C096883299034C7E93BA2E09AE9C0302ciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 21:08:10 -0000 --_000_C096883299034C7E93BA2E09AE9C0302ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert, That does not answer my question. Thanks, Jakob. On Oct 30, 2016, at 1:37 PM, Robert Raszuk > wrote: Those self invented attributes will not be passed/leaked as such safi they = are to be part of will not be capability negotiated in the first place with= any Internet router. Thx, R. On Sun, Oct 30, 2016 at 9:26 PM, Jakob Heitz (jheitz) > wrote: Send them one of those attributes in a different safi. What do you think wi= ll happen? Will they pass it on harmlessly, like any unknown optional transitive attri= bute? Thanks, Jakob. On Oct 30, 2016, at 1:05 PM, Robert Raszuk > wrote: Jakob, contained !=3D restricted Moreover there is number of overlay solutions in the wild which run under t= he cover BGP with various self defined attributes and safis. Just think abo= ut SD-WAN or DC overlay solutions. Some of them tried to take IETF path some never bothered seeing how hard is= to get early IANA allocations or being aware of multiple implementation re= quirement. Some are limited to contained deployments some are encrypted. It is close t= o impossible to now list all of those. It was pretty clear this is coming ... one strategic solution was an attemp= t 6 years back to separate BGP into BGP used for transport for all of the a= pplication and services (new BGP port) and BGP used for Internet routing (1= 79). That would allow complete separation of the two. https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 Thx, r. On Sun, Oct 30, 2016 at 8:40 PM, Jakob Heitz (jheitz) > wrote: There is no concept of a BGP attribute being "restricted" to a safi. If tha= t were the case, then you could use a single attribute code for completely = different attributes in different safis. An attribute that is understood in= one safi, but nonsense in a second safi will cause a malformed update rath= er than an unknown attribute when received in the second safi. Thanks, Jakob. > On Oct 30, 2016, at 12:16 PM, Colin Petrie > wrote: > >> On 30/10/16 19:05, Robert Raszuk wrote: >> The good news is that they should not be leaked as they are to be send >> in their dedicated SAFIs so unless peer exchanges right capabilities >> they should be quite contained. > > In this case, we see them appear on BGP sessions that only negotiate > IPv4/Unicast or IPv6/Unicast. > > Cheers, > Colin > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --_000_C096883299034C7E93BA2E09AE9C0302ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Robert,

That does not answer my question. 

Thanks,
Jakob.

On Oct 30, 2016, at 1:37 PM, Robert Raszuk <robert@raszuk.net> wrote:


Those self invented attributes will not be passed/leaked as such safi they = are to be part of will not be capability negotiated in the first place with= any Internet router.

Thx,
R.

On Sun, Oct 30, 2016 at 9:26 PM, Jakob Heitz (jh= eitz) <jheitz@cisco.com<= /a>> wrote:
Send them one of those attributes in a different safi. What do you thi= nk will happen?
Will they pass it on h= armlessly, like any unknown optional transitive attribute?

Thanks,
Jakob.
Jakob,

contained !=3D restricted

Moreover there is number of overlay solutions in the wild which run under t= he cover BGP with various self defined attributes and safis. Just think abo= ut SD-WAN or DC overlay solutions. 

Some of them tried to take IETF path some never bothered seeing how hard is= to get early IANA allocations or being aware of multiple implementation re= quirement. 

Some are limited to contained deployments some are encrypted. It is close t= o impossible to now list all of those. 

It was pretty clear this is coming ... one strategic solution was an attemp= t 6 years back to separate BGP into BGP used for transport for all of the a= pplication and services (new BGP port) and BGP used for Internet routing (1= 79). That would allow complete separation of the two.

https://tools.ietf.org/html/draft-raszuk-ti-bgp-01
Th= x,
r.=

On Sun, Oct 30, 2016 at 8:40 PM, Jakob Heitz (jh= eitz) <jheitz@cisco.com<= /a>> wrote:
There is no concept of a BGP attribute being "restricted" to a sa= fi. If that were the case, then you could use a single attribute code for c= ompletely different attributes in different safis. An attribute that is und= erstood in one safi, but nonsense in a second safi will cause a malformed update rather than an unknown attribute when r= eceived in the second safi.

Thanks,
Jakob.

> On Oct 30, 2016, at 12:16 PM, Colin Petrie <colin@spakka.net> wrote:
>
>> On 30/10/16 19:05, Robert Raszuk wrote:
>> The good news is that they should not be leaked as they are to be = send
>> in their dedicated SAFIs so unless peer exchanges right capabiliti= es
>> they should be quite contained.
>
> In this case, we see them appear on BGP sessions that only negotiate > IPv4/Unicast or IPv6/Unicast.
>
> Cheers,
> Colin
>
> ______________________________= _________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


--_000_C096883299034C7E93BA2E09AE9C0302ciscocom_-- From nobody Sun Oct 30 17:34:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A693512940A for ; Sun, 30 Oct 2016 17:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 mKozxc2YM7pz for ; Sun, 30 Oct 2016 17:34:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0146127ABE for ; Sun, 30 Oct 2016 17:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10998; q=dns/txt; s=iport; t=1477874084; x=1479083684; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=47XOkzdWR5OK9zPFfDRmW27EmcHxc9JC6dGVO16B4ao=; b=Qu23/5aKikYvbGB8l78TppwJDaZuFsuNSOQGppJO2lxzWOoKcKraKs8m pkauzt/yLy6jfxyO3TVJ1HcQr5i2l8wopP+DGLywNOiF2RjUGkkq3IWnI aFhbXnSJxt98fJQrfg5Ohm2KZ6vVm7ulSti5QN5QjXmBBJ1HCsE5Ci4b0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AgBNkRZY/51dJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9YfY02ln6PKIUWggcdAQqFewKCAT8UAQIBAQEBAQEBYii?= =?us-ascii?q?EYgEBAQMBAQEBawsFCwIBCBgnBycLFBECBA4FGgGIMQgOvzQBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEXBYY9gX2CWIQjg1WCLwWaGAGGL4oAgW6OFocghXGEAQEeNmC?= =?us-ascii?q?CaIIqcoUUB4IxAQEB?= X-IronPort-AV: E=Sophos;i="5.31,572,1473120000"; d="scan'208,217";a="167736635" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2016 00:34:26 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u9V0YQUs003368 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Oct 2016 00:34:26 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 30 Oct 2016 19:34:25 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Sun, 30 Oct 2016 19:34:25 -0500 From: "Jakob Heitz (jheitz)" To: Robert Raszuk Thread-Topic: [Idr] Unknown Attributes seen in the wild Thread-Index: AQHSKWSs7BkiNd6f2ECx5wzihKhK2KCu0JwAgAT1t4CADaRlgIAARs2AgAATqgD//7LrNIAAWruA//+yGXGAAFb4AP//tJl+AAc5Dzc= Date: Mon, 31 Oct 2016 00:34:25 +0000 Message-ID: <59AE7695-66F9-433E-9B54-C2DBA152D6A6@cisco.com> References: <01f401d22950$7f988470$7ec98d50$@ndzh.com> <5806484F.5080006@foobar.org> <6E6CFB88-04E7-45B6-A325-F57A165E901A@pfrc.org> <20161018172538.GD27221@gir.theapt.org> <01e301d22967$cb3e8c50$61bba4f0$@ndzh.com> <769587CF-3E9E-40C6-9018-93B651BE9E98@cisco.com> <70003119-429D-49AE-8126-3B462E179E71@cisco.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_59AE769566F9433E9B54C2DBA152D6A6ciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg Subject: Re: [Idr] Unknown Attributes seen in the wild X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 00:34:47 -0000 --_000_59AE769566F9433E9B54C2DBA152D6A6ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to clarify, it's not just about sending an attribute, its also about r= eceiving it. Thanks, Jakob. On Oct 30, 2016, at 2:08 PM, Jakob Heitz (jheitz) > wrote: Robert, That does not answer my question. Thanks, Jakob. On Oct 30, 2016, at 1:37 PM, Robert Raszuk > wrote: Those self invented attributes will not be passed/leaked as such safi they = are to be part of will not be capability negotiated in the first place with= any Internet router. Thx, R. On Sun, Oct 30, 2016 at 9:26 PM, Jakob Heitz (jheitz) > wrote: Send them one of those attributes in a different safi. What do you think wi= ll happen? Will they pass it on harmlessly, like any unknown optional transitive attri= bute? Thanks, Jakob. On Oct 30, 2016, at 1:05 PM, Robert Raszuk > wrote: Jakob, contained !=3D restricted Moreover there is number of overlay solutions in the wild which run under t= he cover BGP with various self defined attributes and safis. Just think abo= ut SD-WAN or DC overlay solutions. Some of them tried to take IETF path some never bothered seeing how hard is= to get early IANA allocations or being aware of multiple implementation re= quirement. Some are limited to contained deployments some are encrypted. It is close t= o impossible to now list all of those. It was pretty clear this is coming ... one strategic solution was an attemp= t 6 years back to separate BGP into BGP used for transport for all of the a= pplication and services (new BGP port) and BGP used for Internet routing (1= 79). That would allow complete separation of the two. https://tools.ietf.org/html/draft-raszuk-ti-bgp-01 Thx, r. On Sun, Oct 30, 2016 at 8:40 PM, Jakob Heitz (jheitz) > wrote: There is no concept of a BGP attribute being "restricted" to a safi. If tha= t were the case, then you could use a single attribute code for completely = different attributes in different safis. An attribute that is understood in= one safi, but nonsense in a second safi will cause a malformed update rath= er than an unknown attribute when received in the second safi. Thanks, Jakob. > On Oct 30, 2016, at 12:16 PM, Colin Petrie > wrote: > >> On 30/10/16 19:05, Robert Raszuk wrote: >> The good news is that they should not be leaked as they are to be send >> in their dedicated SAFIs so unless peer exchanges right capabilities >> they should be quite contained. > > In this case, we see them appear on BGP sessions that only negotiate > IPv4/Unicast or IPv6/Unicast. > > Cheers, > Colin > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_59AE769566F9433E9B54C2DBA152D6A6ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Just to clarify, it's not just about sending an attribute, its also ab= out receiving it. 

Thanks,
Jakob.

On Oct 30, 2016, at 2:08 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:

Robert,

That does not answer my question. 

Thanks,
Jakob.

On Oct 30, 2016, at 1:37 PM, Robert Raszuk <robert@raszuk.net> wrote:


Those self invented attributes will not be passed/leaked as such safi they = are to be part of will not be capability negotiated in the first place with= any Internet router.

Thx,
R.

On Sun, Oct 30, 2016 at 9:26 PM, Jakob Heitz (jh= eitz) <jheitz@cisco.com<= /a>> wrote:
Send them one of those attributes in a different safi. What do you thi= nk will happen?
Will they pass it on h= armlessly, like any unknown optional transitive attribute?

Thanks,
Jakob.
Jakob,

contained !=3D restricted

Moreover there is number of overlay solutions in the wild which run under t= he cover BGP with various self defined attributes and safis. Just think abo= ut SD-WAN or DC overlay solutions. 

Some of them tried to take IETF path some never bothered seeing how hard is= to get early IANA allocations or being aware of multiple implementation re= quirement. 

Some are limited to contained deployments some are encrypted. It is close t= o impossible to now list all of those. 

It was pretty clear this is coming ... one strategic solution was an attemp= t 6 years back to separate BGP into BGP used for transport for all of the a= pplication and services (new BGP port) and BGP used for Internet routing (1= 79). That would allow complete separation of the two.

https://tools.ietf.org/html/draft-raszuk-ti-bgp-01
Th= x,
r.=

On Sun, Oct 30, 2016 at 8:40 PM, Jakob Heitz (jh= eitz) <jheitz@cisco.com<= /a>> wrote:
There is no concept of a BGP attribute being "restricted" to a sa= fi. If that were the case, then you could use a single attribute code for c= ompletely different attributes in different safis. An attribute that is und= erstood in one safi, but nonsense in a second safi will cause a malformed update rather than an unknown attribute when r= eceived in the second safi.

Thanks,
Jakob.

> On Oct 30, 2016, at 12:16 PM, Colin Petrie <colin@spakka.net> wrote:
>
>> On 30/10/16 19:05, Robert Raszuk wrote:
>> The good news is that they should not be leaked as they are to be = send
>> in their dedicated SAFIs so unless peer exchanges right capabiliti= es
>> they should be quite contained.
>
> In this case, we see them appear on BGP sessions that only negotiate > IPv4/Unicast or IPv6/Unicast.
>
> Cheers,
> Colin
>
> ______________________________= _________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
--_000_59AE769566F9433E9B54C2DBA152D6A6ciscocom_-- From nobody Mon Oct 31 08:35:38 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BEE1296D2; Mon, 31 Oct 2016 08:35:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147792813132.32420.11131841762669755014.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 08:35:31 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-te-pm-bgp-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 15:35:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : BGP-LS Advertisement of IGP Traffic Engineering Performance Metric Extensions Authors : Stefano Previdi Qin Wu Hannes Gredler Saikat Ray Jeff Tantsura Clarence Filsfils Les Ginsberg Filename : draft-ietf-idr-te-pm-bgp-04.txt Pages : 9 Date : 2016-10-31 Abstract: This document defines new BGP-LS TLVs in order to carry the IGP Traffic Engineering Extensions defined in IS-IS and OSPF protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-te-pm-bgp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-te-pm-bgp-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-pm-bgp-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 31 13:52:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474D7129A36 for ; Mon, 31 Oct 2016 13:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 elX_YFVeKNb6 for ; Mon, 31 Oct 2016 13:52:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 00E3E12949F for ; Mon, 31 Oct 2016 13:52:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id BE9851E337; Mon, 31 Oct 2016 16:55:15 -0400 (EDT) Date: Mon, 31 Oct 2016 16:55:15 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20161031205515.GA25507@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 20:52:47 -0000 IDR, There's a larger conversation to be had about proper stewardship and use of code points of all sorts, but path attributes have our attention for the moment. A quick draft for consideration and to motivate discussion. -- Jeff P.S. I'm sure there's a number of rough edges in this. I knocked it off in less than two hours after not enough sleep. ----- Forwarded message from internet-drafts@ietf.org ----- Date: Sun, 30 Oct 2016 07:53:04 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-haas-idr-extended-experimental-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Experimental Path Attributes for BGP Author : Jeffrey Haas Filename : draft-haas-idr-extended-experimental-00.txt Pages : 7 Date : 2016-10-30 Abstract: BGP's primary feature extension mechanism, Optional-Transitive Path Attributes, has proven to be a successful mechanism to permit BGP to be extended. In order to ease various issues during the development of new BGP features, this document proposes an extended experimental path attribute to carry prototype features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-haas-idr-extended-experimental-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ----- End forwarded message ----- From nobody Mon Oct 31 14:16:35 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AD4129A33 for ; Mon, 31 Oct 2016 14:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 wxS9s-fOHtUp for ; Mon, 31 Oct 2016 14:16:31 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0109.outbound.protection.outlook.com [104.47.36.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246721299C8 for ; Mon, 31 Oct 2016 14:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uYum5lVTMyDI4dtssK3IrePqZruDa6Eoml8X+AcsBOI=; b=KXGo86lV1sCB3XOiHXCpnmhXj1cPTFsiq5IrohcdhJoZ+XGWY93+WUFjX5lHgMht0oCii8YINxS4DUBtKj5PsXxLZQw7Jhz+VEq8nZfoL9OGXGSGr34iQEVZ+dKZIHNaGkUFKg/xeIQSDKdt28+HRclYje2VmHjXRu/4b8oEf/o= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.37.68] (66.129.241.11) by BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.4; Mon, 31 Oct 2016 21:16:29 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Date: Mon, 31 Oct 2016 17:16:25 -0400 To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN3PR10CA0038.namprd10.prod.outlook.com (10.161.211.48) To BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) X-MS-Office365-Filtering-Correlation-Id: 207dbd81-a7f8-4b77-ea80-08d401d32ecf X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 2:gd9CZwhgVVg0EK6qC1QCrF8+otH08GHEGlf3j2QSRrtVpJhe8QS+rXaTwgPzHwI+5aU4O/RxIRg6n1wtPTje4QejmcbNUrB6MNvyhzzF7KouVt1nYyfwu6oCMUWAsKM+O6oGww41sSXsgBVDMGPmK3wSqtqEkQcGiWpclKryWQF4mMhw2zbUXtO5eT92HDojceD9f4/A80sasfaAcZ8Nwg==; 3:yuCcYmJqiuUw1ABzROCeOqQhI6/ddOYEB7l8uF11Zhkv3xhPZpe+qPXyHn4EkY3KajI4wlRRnRU085KA8wIDU/GGTzq/FsNkaT4JY/IxLkdw1cPCqzGhTQsj+nvumO/0qp50orSJ9MB6bLOYDJZPZA==; 25:lwnhg7lN0rUcX/PPvB7IYPsGIC+2E9gKJb67cSMMxHyLIDZThKEpbIrqrXEnjLhXjBsngSYPZ70hujH/3P7gHwNNfuwoc7gO2jSoWM2wnQ5TW+kQTYXo0yaUYAMvQimqeaMhyAMKmMvvsF+8B2Yrq4ysb7xhOud/8DeOTOGGU2lBY/VGWcDiUEGPF/93/HdB6M9QJTbl0uECsVcd1AbhXyvimELyHFa0Xy+6cQNX/TZPA7wiHJLzqVCBfB82ssQ8QHV9k8yF4eyZu4uSFNLO7veYOtccN7O4oPKbfiprWGB87qpttTfZaJ0pQOZRrVaFsjHSulsiijfRE32CFVEg5NSME/o5Yd7ySR/+NDZU+OhqDA/RVwZMwFswulWbYF164wKChBBSy1VOba6Npycss5JnEec5RCnJ1XxI7ces7IIVTlL7/+domk86cZ80NYdP X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 31:9sQvyDmh4dP3SAMCRK/QXvwyIslmGqAtMyrzAgZnzh5KZqah1w5rxAth8Majfc9uXEcZhBWmQvEhh4AJieyFitZBRcGJh2UbpigdobjCBJn9byn5EoEHTa3NZX/ezSMbyecm4bw0NtrqtJJ/OTE/KhNUI7O8KqxM6O4nj1iYCnzHufXjdmebxCTYJIb1bGiGDldM5TXqxLJ+WDxMxsB0N0uyQvUSoVQXFP5Hzq7hLrjSk3U5uXZ902YiNHQ6qtYF; 20:1yM6Bn9B6/dXortCbgJqQmQnRn0i+1B4I+B9ueo92P8VWNAq0QNpZ/pqgQEQhBQa3w/I+bt3tU9Z7VT7+dWldtDeh8kuJ/3pOCUGLYIpF8lEtuI36oPKeifRKoViqscpM1ASzBBkQMkAhJipLvyqlzViAVwd2y16uZLj/5g7d6U/lUk/jNp9YY6Vg92pfgx0lO+jXfYrinIn64pwNmxGBibv6d8oajAaSWvRFFSX/39nbq985hGPOb9o9KW+Kh0jAAN+RXYxVjIw0lmVa6xmCWCQPDw7UHpwvbuUquPUACDyS4Ba0Mv+5x50x49ZH5mawJaXjGSC3N7lcLrL6vHFulNT3JBoqtKMX5QiWGUzqBdYSdoKYxGiG1ycrWXP5VPwiDLCxWOmCMGIK48SJiOF6i2Q0+RXLv1Z6FDedPM7vTffdzv/teSRKW9VrXsE+elF6RVKwTVM1Jvxt+khlTI0ErJK+ikRM7n6anykSAHhFoZxKuxBVnN46qqbXE9Zixd+zznh8JjH2D/CZoczKfBaxNv4R/6FVNaTx9aDJ41x1S0fA2y+3npxgh7sSBnmfFg5zgHjHITRnJ9+H6cR5NDOxjvi4V3+mmBcJiUHXyQaikU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN3PR05MB2497; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 4:OghbONzs7467b81jxSQCU41WMOc+7b3FHKDqyE1SUHOoUbUbMpMpSnfj0R+6+7ec4QTedzcLZQvFrFwsPXwu4pufvA1VdY4r8Q3kVptEBTXRTY9o/JjTVYQT63BMOrQPL9j10qo3YM+U2EOu06i4hvcRBItFdlnSq49xjP/lFY42V3utqxBft6h6c0VrrAxSJkNIZpOWFAOZtdj4CfoBmGuzdvGLswHZ+M0FeLm07Wt8A6ymSFOtBv3/k67otWD14F2LevP36IWQNsNtwQSUiNNYw4hRQr4mvffdBDTcbr5tu1sL/fF7i2ffWX41uPF2rUOjeFbiamn4pyOTKFwT2NcXAaResfqJ/enl7e8hoguNG8wTFc5CZeBZU0h0v0dFGk3DnmCer0Y2s4AnvCIR1pL+jBamAQIIK35XqUb3/N0= X-Forefront-PRVS: 01128BA907 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(53754006)(199003)(189002)(92566002)(19580395003)(42186005)(15975445007)(81166006)(50466002)(105586002)(8676002)(81156014)(107886002)(82746002)(6666003)(106356001)(189998001)(110136003)(50986999)(97736004)(450100001)(2906002)(77096005)(101416001)(230783001)(2351001)(229853001)(46406003)(6916009)(50226002)(33656002)(8746002)(66066001)(47776003)(97756001)(36756003)(586003)(6116002)(23726003)(83716003)(3846002)(5660300001)(7846002)(7736002)(86362001)(57306001)(305945005)(68736007)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2497; H:[172.29.37.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2497; 23:88heskHPIXT7ZlKazIIZW/rW6mirYnuoAF41hbjen?= =?us-ascii?Q?VN1+3fc2skzxxuc0QgcmmbqvERIjgRsJCiNmn7qbGbVYoLGOIldrOVM7+Omm?= =?us-ascii?Q?OPfAoLGi/ZXD6kPgWcqr7VwIaXULeh4DFuy2GkRa2SYs1KEVqldwG1gx/l3f?= =?us-ascii?Q?UcJUxCdawKyB/n06txzr+ePZHSu3RHOPkk7L+ccA5lfej8X84cItjoRuXqc7?= =?us-ascii?Q?57xwQVTvEZe4c4/z1BYdRG0axqPPBQquJTt4uGM1NlXRbfC1y3M65BFURAqK?= =?us-ascii?Q?uRuIldJg0A92bZYSmVza4f/ziWld63Mi+aHq8cPmers28ORXL3fl5dLVnECN?= =?us-ascii?Q?N9k6lnHvTBkjd+BdPFCP5i+/y3lnsTIMKRUnTOh7qYEvGRqVweNcUTGBLXTt?= =?us-ascii?Q?OQc8jmW1vyJhT4p52cvMKKb06pbkaiyhaVYXUyuPe2wgpSuzbh7icAQcrliI?= =?us-ascii?Q?YmaW51RZvuJqYawn2Gd5SotsFmZXIiAf+Vm8+Jx+lARwGDbH+q3Ong+1pzME?= =?us-ascii?Q?w7XGfTUariYxdX6NLfJ7Nw2NzaGMDgm0sRUjlwU5TRVlevM584b0xao+q3gv?= =?us-ascii?Q?JNehtXngHG7fPYlWrPfb4BWuU82Wz+EjDVT1VpLCY861gE8ejerbHa65KaJR?= =?us-ascii?Q?zU7TYXb949puUrsayLHts4epsa7VVfB/JRHY+5SuYomOrvPKBKDQVTpyBrJ0?= =?us-ascii?Q?3HDoIOWVXgoz4dyXyQRnPW0L6itZrNnCal2EP4j83yGHbP9jG62fzHhDJPbl?= =?us-ascii?Q?jn6ZcshEDEqHov49EJtD/oS03fNTGPifuc+jBHUCXx1MXy6tzCQ9VL/AlPQK?= =?us-ascii?Q?w/L0MKolJgAq76hefHQ1cJQS/eRBdEuGh02msVrI2BDEu5+TfsSog9g5cHhb?= =?us-ascii?Q?9j7ud5GuN0PZUHucusmzWQzPUX6PUKvADUPmZeJqoF1ryNPAuVOczi56Penq?= =?us-ascii?Q?4wvssP5iGZ8e0anwIV3rxS7c5cnN/97fwHmIhQDFsJZTR6ApTxQAqPmtiPnv?= =?us-ascii?Q?wK1d35hR8srjirOx0jK5LXA8GoHuNmYxrrPxOB3lGVXdTKJdcPpd+pGyRdmf?= =?us-ascii?Q?tqZsCvYm+BB+djf5GZu6iYRAhsz8ckpF3NqVwT6F0w3bxSiwepJHGlVmL5FY?= =?us-ascii?Q?JLiU6OWIx6SVGFEYjMWOADZcXRZZ3d95pzG/Gk852CbgbzkkZVukHIezHab/?= =?us-ascii?Q?920vMQR2tCWyGDmleH4Vw9p7pngmlv0p8nB2Hp/y1Ofrgo42oP7lHOY+xxS9?= =?us-ascii?Q?GhzQRZW7QFfOF8omLhlspU1O8sZzSM9iKOgTeVh?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 6:4vyS7ylALwp9fUIKm/PgoMRi2iaayKysPHg1805qSwWi+m1uroJFR1HpGpIvdV37+eA3UlG8sB3yVITjmZVN07DAPpcB9PbzqpTcy+LwGcn2rAOKIMLY7FJaIhA6YsprPHPiHXYPJD1d8Ym9OLhlyTIxOV9i2Q3zWlGeVmunukFPAMikows9bPKePPx7RmgA+0rmlEX6mbaOSWCw7Wvq/qMITC/StVh5ptjQQf60o8ZUZZf2SNoH9ZOxebr2/C5gIGM8eu2SJNvwcki+G69KyE+Ki1EBi75Q2tXi9CiGXfRRpKjW+2lx3PBePv6O+s2BboYzko4WShYDawKUNGddcA==; 5:jhfZQunb+TZIT2+4MI/s2n54wz2wpZezH/atRY8QBs+End5ZjoHl0muSOQMob532k0jn64glp62GUM1stJv3rHGob1JpQffANqnV4UnLI0aH69KwyktUbc2LcsG5YSvGjOM3evPyMHkQSYNYODy2Rg==; 24:dQIPOLij1G+wXnNhErAYUBiLyhKZvG223Ek6YWe3WMXxbicjXYyeOeBJo0w3ClH04hvukw6aOc1S9YDPqcsnaCqVADKwASgD6aoja9xYEN8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 7:ZB7XLmT0KI1CEwy1YunAaW41uS41bKAGiQ1kW/iDSizMOS5wzOCskn54HghpBrD+TW/Rh59nZf1IHVjSOBuXztMAwC//wX/Okr/SO+HwN/Rl8JLeoMrLCAVYI2nJExwXhpBIXqm2+FBiKFJys0Uk/IFNj4RP8YxyPKdq+Cvyt2aayt9iBm3qA/Di4nfbYtzbyd0WNd3qyOcPutFAhDF2O0/Jxz3jPggqjjeKjJn7OswXaGX1VLtyNm4m1BFM1eySmyebXdMY0bE6WcNfG2Oe6kQ4w2oYYnhDCS1igYjLRkHFYJFlAI3H2RWeGsnUJGHjcNH3YCfA+0hTuu/i/vnjD4dstVLGpVSrJigpbe3drO4= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2016 21:16:29.9236 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2497 Archived-At: Subject: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:16:33 -0000 Hi Everyone, The authors have asked (some time ago actually) for the WG to adopt = draft-gredler-idr-bgp-ls-segment-routing-ext.=20 If you support or oppose adoption please reply indicating so. Reasons = for your position are helpful, as volunteering to review, comment, = and/or shepherd. The adoption call will end November 13. Thanks, --John P.S.: = https://www.ietf.org/id/draft-gredler-idr-bgp-ls-segment-routing-ext-04.tx= t Abstract Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS, OSPF and OSPFv3). This draft defines extensions to the BGP Link-state address-family in order to carry segment information via BGP.= From nobody Mon Oct 31 14:19:07 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074E1129B08 for ; Mon, 31 Oct 2016 14:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 NfhOuzZMlUvZ for ; Mon, 31 Oct 2016 14:19:04 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0095.outbound.protection.outlook.com [104.47.40.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8297F129AFB for ; Mon, 31 Oct 2016 14:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VwQrPNCv2XpPKIDL0iIVbPYtMrb2h5Ce1iiqLE5J0F0=; b=fGaYoSjS41slu8DpKCrNuhcCJYmV8IdnL3Oh2WsuoZttq1fvOJ5rbOKerm5f294GArMBo/RkBkbKr9BVJkMqXYjJEhUdA62JSv6AxHFqCpMECVYSpOuOjh3Q/Hw0ir48ZW+z2KWFHQiL7v3DOtfnnx8k0gsMH3sa+JJWcVZpzc8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.37.68] (66.129.241.11) by SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Mon, 31 Oct 2016 21:19:02 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> Date: Mon, 31 Oct 2016 17:18:57 -0400 To: IETF IDR Working Group MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN3PR10CA0041.namprd10.prod.outlook.com (10.161.211.51) To SN2PR05MB2510.namprd05.prod.outlook.com (10.166.213.19) X-MS-Office365-Filtering-Correlation-Id: aff0ec4c-7012-41bb-df7f-08d401d389d3 X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 2:kpdu4zGTXJ0iWeJD+PREFs1Xf0Vg7O8VLS1U2L6MndYPFtV2fFIAvCnFBZMpdYnRUxn298F/q8AK4RdYnKmO1GAYw8gMEX5e7FNtoIGN6FAkVdkGq7DsTxbjfL7EN/ZA061qKo4t35diIrTe0Kt0R2iYfiy+9zqaTNW5WfBX3Kp84d4HI+PRq/2U+srkDQ4CDJq8Ds2+AVEedZlC+4LnMw==; 3:9FnFs7z/5l7MdCdC2M0xzuxWkkyWMnZJolaNuZOht6eA9MLwnXY+gp3XTGlx9UsxBB6oVpcvBbbKz1G3XpAv4fQS5IyGrGqNuVmmMrmMYV/XFMGc9a1q2/v1m7xCFHgcyRwU+u3xHvcHwnDTRfMRyQ==; 25:6V3ziYoS5ucTsUG2CbI3fucY09z7N6+kFRMIgHddmig4yRvd3V/RxQZ04vC3cWA7P9l1IGlo1hW5/DiSrvFv5x0A2dBcb+kaThi+2GWcPqa2w9vL/JA3n/eB1mKxw3YdvLm1tJutzyXNJYXuDKCja5SGlxNPz6u1bZvRxYHgm4Qsjes/PBl6fOge6s1C1ScrFP3LoMkJ1joc8AzS3I7a9W7MTuvxvfLw7bqzbHyn88v0Tu3TOyn/1t4K2UOUAncu56Xy9I88CkxiKgJRv9HVqesza5LJJ4Nmnd5eAs/RgKyEe+jBGCgsZ9IgDCEu+a1xWCg3++ldOayuH2O9Rd6zHOCHK5rOPse+GQuNahLRFZQFonULZAffaMe3ghZnROyNE8sIGlz82HXzxoz0fCpfbYZ7sG7OTmhiNNBefQjPhZC2VzbQI7+eGNwpXkIPAJbp X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 31:g00Ip1QBqwz2PbYusHv9q1Nd6iihpPcFpkmW9O+W3uklm7Fc5ut5/bXI0mSx4K08tUzUUgmhopyoc1JcAKr4xLHWaBxfOzjTb/qRaxqRlqKnx51YGMdCQjFun10MdKa6s1C/n+toERoH3CUyuPC0v19d/YsLgD47XXNbORhyRJDQp4tdpjEA3/tuC/SgNbftY5fwB0ctZUKswRBbunz/4lvZUFxDy7UAPgRx4+BTnn4cQ9gqBsax/xfeInF2/26Glt+8S4kCIuDQ8dwXvyBrWw==; 20:2mGfige80m5I9A/y3B1pI1HCKKYpYSZ3SPjjtDjjd3s8UqbWCOp8khsqskUVgQXiQEXaI7EsQ/uxFU3jDR6N3Wzi0Zttm2uUODV3zpZYItUuIrRV4/MzS5unwKyA9dfaPSBb6UdvDFwvcHrgzXkeRRrTubSEk39k2xuSuM80gj0m11AtFoMq1DghtorvSHMMhelTj6wkFRgLFnPd5QZl1+6BhITx2EiC/bDoNv0QnxrDMLZOtOpTzEOGMpc4Ln9LqPa+xlZB2NONnUZGjOZh6aoKfVIb/fMJvC8Cyv6c1x5X0Axo0Lt/UJyZ3bBHOEEgo4/LeG8tSemNm6vcoSTiTB/2rgxG8gv+ItZYReLMmoXNxqevVlWkIen3SgIEUi0d/hqSzMPOVLkVl8c1Ur5iZ/g2yhrLOZ90cGkX58VA7gdnUkuUFGcddY6hTIUzUZ7uRqP/1b03qRcwpEcdKuW8RxKyfhYarv67aiVaUTy7WLdajPwe+G93yzoOELTCj03WjJ36hGz4Ryhx7NjcqHlkCBELbZ5zjGiZ0h+4TruY5nIjiUjFqWB+RmbMpMnRs5TOYfoUajhZYh08ioQEo4z8UZyh+CX/Rf3KPGDrDnl9sVc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:SN2PR05MB2510; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 4:9dyV16Gs+Ojl+mr+KT7TbTIk9q99TgSsLm1vcho8OF0VXVGPo1aU9s58lwg/66qozb6TNxY+fZiFGvX7Gi5IPYNWqftkE4RhDtvyBTIN9nTfk4ahenQu9NzMvlIYTcvq785H+7EtlqSg+eQSyQ2jzKHN3piLLcfhJZ3tCw7oDV79oec8BUEL87s8Qw9mNV2yWyJ+3MSSv1nO3RybE7A79dxFOoigrhtdKNHfPGVBrpwEcyhWF7CRkT1VCK5McbS06IWI9bv6dxH+NUbwdwdU3Udk+tt+96mMim6hl3kJhgWqGCMM1aLM3KF7HiDyBPG8fQ/hidJzOwB6QlDlEDMZnTOlwzheEBgVxf5PRCG/fiPdLP2cofSAuqegOCCwbu/wAdmIWZXoDr6/BpkASwYZs6hK8+xkZPjXlNSsazxoMw4= X-Forefront-PRVS: 01128BA907 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(5423002)(53754006)(199003)(76104003)(189002)(33656002)(305945005)(15975445007)(8676002)(6666003)(50226002)(5660300001)(19580395003)(7736002)(7846002)(50466002)(450100001)(82746002)(586003)(46406003)(23726003)(230783001)(83716003)(189998001)(77096005)(68736007)(110136003)(6116002)(3846002)(6916009)(66066001)(86362001)(2906002)(229853001)(42186005)(50986999)(106356001)(97736004)(105586002)(97756001)(47776003)(92566002)(8746002)(81166006)(81156014)(36756003)(101416001)(107886002)(57306001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2510; H:[172.29.37.68]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2510; 23:n4zVTEnmg3lqjAo77VWXujYE+c09ST35X/kY8c7wm?= =?us-ascii?Q?NeYO6e70U+MNpGq6FjABNxh0SoZl4B1dNrYbB6iA7QD81zkkTHFe9gTWmfkx?= =?us-ascii?Q?scnvLagrEVzr9PD2qE80vao8jG9lloD0THE4Cml2CuNNsopFLuzn95TY7pgE?= =?us-ascii?Q?eIqyOzrIAp/NZ0VzYzb7oyOtwgurZz/VkL6Y9irkpR6CL5vaZpey7YYw4X/U?= =?us-ascii?Q?mhLLc5ZP/t+Oxv6uW67+2X4xtmHU5Hp77Oc1Ad/uQ3n6YKHYvbMSkSdyJ77I?= =?us-ascii?Q?lTAU2yIoShHDpU6Y/+D2hknRgXygO12zWQNRxHHbA/HR6QMU7YmDR3uU52ul?= =?us-ascii?Q?Up8BPrSplYf/4DNArSkCsirzOvUPKC1sAQYH7JwXQ5ASeDxBqivrcrNqgE/6?= =?us-ascii?Q?fP6uImgbyyqAUS4WMO8i7XGxZggHW9smNmqqb2WorbtDcW6brgWWcSUkZrsv?= =?us-ascii?Q?+Dh8WaSjNihS952M3cczC4FC/P1k95iSt6HKzoX2mXYaFK1i3iKjyGj5EMmX?= =?us-ascii?Q?oQeTn8NhMhQqEXheCmUyEpFjjbDAaRj3qw8J1VUamAGOPzZnV+RmFocVlnqB?= =?us-ascii?Q?b0fvnqombEhXp99PXx9Qrn3sy9rR9tnqkpzPWCBdn0g1EzzKLoY5H9eyji3i?= =?us-ascii?Q?GW28ezIbdCj9hpAhcH0O2NtnfcbN3tZA/Tr+v6lW5pAVlY0lXb0R/wsQkUh3?= =?us-ascii?Q?a5JF0CPOEWeY5GAnHuNzg3W5hKAJIoJUfOQDoZbAF+G52HF9+Clu7sQXyK35?= =?us-ascii?Q?ZwgPFOl+TQcGkqjj9JWtTI8plrzi+A+DoZHpChpxmntRydiIwW+n0Z8TTjSd?= =?us-ascii?Q?xkFOoScRL/QN57jy+RWAA/dLoPJrFBH9SnjKX1N1q0wcwHDsrNPfH39EnI8e?= =?us-ascii?Q?tijvZbQ/8V/Rho2K9o+foxHv6TiF4HxK4/911Edb4fOIJ+7ucxhgwxB1/ux6?= =?us-ascii?Q?imAwhEUVdcvKoLoE/X3EMgwygv+e94QjLcSsMWVoJ8AMG5DPPU77MT1SiPyj?= =?us-ascii?Q?FBInkCfq4wKUpG5Es2sNp3HCEKu8t5GsnTQEMwWMtXnPdom41Hy9LCLpSYH7?= =?us-ascii?Q?BKLw6YFtZZodO2LSACBenCYxwxEGpIIzTe8VI/f8K9sSTcsp8AvJmWYqlMYC?= =?us-ascii?Q?YkpEdqiiZiZsYrTvhJ9RVUgBELSBQOOq7YtrBM0n6UkJswm7lpT79FvFcpbp?= =?us-ascii?Q?JGQNBhAjgHS0i+I9KxBTLKsJOzMH9gVd0kMhE0It7HZqsg5OKN+AhvcPJnvG?= =?us-ascii?Q?wfboy3wx1zDXGiWMnFZGUykdvDmVh5tE56e/9+gQOiKJY9KAq262A1ypFDhl?= =?us-ascii?B?dz09?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 6:DA1Jv8dKaFX1vBid0E8O+k16nOEZ4Lxi6eoLAqrkEkXOYbeuYmOszObNnKuE67hFQ9m+wEQYBQAYtUM7jWzUenK5nyCHCgDC0p5DnlTD8cvXePtITpAZDH22oA8njj0QLwoSs4khrCiPlCcUEOM0AmeOa88sWzLG+NBBxGDUdu7E6IiuCuIQABvHOaTt1iaaxYJT2ktTFl39J1nr63yb/UOZHvrYLQEBxAmU17RoEkS2R4abUghSV9s0fd4giBqD9VX+lVnOeGiwQRVJzpZARjO0HTcC9sdKfbXq4NBDNyRcbIZlXY1loVNT/+jyWNaS9TobSGaCnKrRWsHE9/D530/8p0fTfWuA6uvxXM9U1Ko=; 5:At3U/MwzdWuiECE5bHbvvEqgoi4Ib3NOyGr6DIhZT8SLq6Pnp2eEOmC9J7uEQBaqQX2Zk/QrhHXURgzBz5Kkm6r5kUaxkERlhZk5+2pHsKHwsZ7lYInIH9m9jiTAyp6W814F3hBi3me4Cb12U+1+Ew==; 24:Q2a5d12EwLpWFdAgIMZzd0/VZBUQBv4BAXPuJL/+PGJNYM3mnswAtR8p3+igMTZwg4GTqZuSRAzWVvPqWjh1WBVaPCzxAWzcoPw/bIggebU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 7:LJbaieDHwJTBhEnxvEJtkgPkZYo1K7P9UyRwXLnc9xnvjYlZIEV5eIgHtm4YfYnsS+VWN6NkqmuV2AJlilibWIhGpPwvTWYMqMU5CyZyzQ8OjM/3vcVWUn6uk6K7YIOF5J++szJ3911VDvuuTk+0HETLdG5scXMxbkkV5lNixagUFjO0ArGnh/3wI/RENz/2+37LxUUdgM0Ch4NcaxRZpiTQu3ZrZdDofqgMvXKYQRKzN8WBSGyzXQimL4JqowC8go/yyen6Z6EvaIe5ZCZiuz3LYXqsS5rnbc0NE5lggy3y+GIVSvGoZxcIjtqeHP8Prvjv303VWZNeO/TDmA59yONIoELosoppxmIC1BvAlj8= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2016 21:19:02.5421 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2510 Archived-At: Subject: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:19:06 -0000 Hi Everyone, The author has asked for the WG to adopt = draft-snijders-idr-deprecate-30-31-129.=20 If you support or oppose adoption please reply indicating so. Reasons = for your position are helpful, as volunteering to review, comment, = and/or shepherd. As an aside, I will note that I don't think the WG has = the option of doing nothing, so if you oppose adoption please address = what you think should be done instead. The adoption call will end November 13. Thanks, --John P.S.: = https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 Abstract This document requests IANA to deprecate the following BGP path attributes values: 30, 31 and 129. From nobody Mon Oct 31 14:25:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7668129B2E for ; Mon, 31 Oct 2016 14:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 GipiokFpG49L for ; Mon, 31 Oct 2016 14:25:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E91C129B30 for ; Mon, 31 Oct 2016 14:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1778; q=dns/txt; s=iport; t=1477949132; x=1479158732; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VlMwYFSNB5zOrRb6ztuG8VDozYpMLkZNELvgyI2YjbU=; b=G2Z6BsrzL37Po50E+im68hTvb7SIV7Lm3ke8G61GX3lzVKlEoGfcyWrr hKV9v8taSApGyyBJoDUtHbP/L3Czt6eE+ZRAy8Tvj3A36dR0TWvjzAkag UMiEhJ+doS1Ivdh/KrPEP/btEN5xFBU8T47gTnWnMpO3qk6r0fZv6q6ov A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAQCKtRdY/40NJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9YfQeNL6s9ggcdDYV5AhqBeD8UAQIBAQEBAQEBYiiEYwE?= =?us-ascii?q?BBAEBARoGETobAgEIGgImAgICJQsVEAIEARKIVA6nDox0AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYEHiguHS4JcBZoYAYk3hniBboRtiSmREgEeNmCDV4E7cgGGf4E?= =?us-ascii?q?JAQEB?= X-IronPort-AV: E=Sophos;i="5.31,428,1473120000"; d="scan'208";a="168116401" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Oct 2016 21:25:31 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u9VLPV8j019473 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Oct 2016 21:25:31 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 31 Oct 2016 17:25:31 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 31 Oct 2016 17:25:30 -0400 From: "Acee Lindem (acee)" To: "John G. Scudder" , "idr@ietf.org" Thread-Topic: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext Thread-Index: AQHSM7wV1TqPR23630ygLO2mNzOdyaDDExwA Date: Mon, 31 Oct 2016 21:25:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:25:33 -0000 QXMgYSBjb250cmlidXRvciwgSSBzdXBwb3J0IFdHIGFkb3B0aW9uLiBJIGhhdmUgcmV2aWV3ZWQg c2V2ZXJhbCB2ZXJzaW9ucw0Kb2YgdGhlIGRvY3VtZW50IGFuZCB3aWxsIGJlIHJldmlld2luZyBz dWJzZXF1ZW50IHZlcnNpb25zLg0KVGhhbmtzLA0KQWNlZSANCg0KT24gMTAvMzEvMTYsIDU6MTYg UE0sICJJZHIgb24gYmVoYWxmIG9mIEpvaG4gRy4gU2N1ZGRlciINCjxpZHItYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2YgamdzQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPkhpIEV2ZXJ5b25l LA0KPg0KPlRoZSBhdXRob3JzIGhhdmUgYXNrZWQgKHNvbWUgdGltZSBhZ28gYWN0dWFsbHkpIGZv ciB0aGUgV0cgdG8gYWRvcHQNCj5kcmFmdC1ncmVkbGVyLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0 aW5nLWV4dC4NCj4NCj5JZiB5b3Ugc3VwcG9ydCBvciBvcHBvc2UgYWRvcHRpb24gcGxlYXNlIHJl cGx5IGluZGljYXRpbmcgc28uIFJlYXNvbnMgZm9yDQo+eW91ciBwb3NpdGlvbiBhcmUgaGVscGZ1 bCwgYXMgdm9sdW50ZWVyaW5nIHRvIHJldmlldywgY29tbWVudCwgYW5kL29yDQo+c2hlcGhlcmQu DQo+DQo+VGhlIGFkb3B0aW9uIGNhbGwgd2lsbCBlbmQgTm92ZW1iZXIgMTMuDQo+DQo+VGhhbmtz LA0KPg0KPi0tSm9obg0KPg0KPlAuUy46IA0KPmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0 LWdyZWRsZXItaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctZXh0LTA0LnR4DQo+dA0KPg0KPkFi c3RyYWN0DQo+DQo+ICAgU2VnbWVudCBSb3V0aW5nIChTUikgYWxsb3dzIGZvciBhIGZsZXhpYmxl IGRlZmluaXRpb24gb2YgZW5kLXRvLWVuZA0KPiAgIHBhdGhzIHdpdGhpbiBJR1AgdG9wb2xvZ2ll cyBieSBlbmNvZGluZyBwYXRocyBhcyBzZXF1ZW5jZXMgb2YNCj4gICB0b3BvbG9naWNhbCBzdWIt cGF0aHMsIGNhbGxlZCAic2VnbWVudHMiLiAgVGhlc2Ugc2VnbWVudHMgYXJlDQo+ICAgYWR2ZXJ0 aXNlZCBieSB0aGUgbGluay1zdGF0ZSByb3V0aW5nIHByb3RvY29scyAoSVMtSVMsIE9TUEYgYW5k DQo+ICAgT1NQRnYzKS4NCj4NCj4gICBUaGlzIGRyYWZ0IGRlZmluZXMgZXh0ZW5zaW9ucyB0byB0 aGUgQkdQIExpbmstc3RhdGUgYWRkcmVzcy1mYW1pbHkgaW4NCj4gICBvcmRlciB0byBjYXJyeSBz ZWdtZW50IGluZm9ybWF0aW9uIHZpYSBCR1AuDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj5JZHIgbWFpbGluZyBsaXN0DQo+SWRyQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0K From nobody Mon Oct 31 14:28:57 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38799129B31 for ; Mon, 31 Oct 2016 14:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 aQVmCZEB8YTy for ; Mon, 31 Oct 2016 14:28:54 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3380D129B38 for ; Mon, 31 Oct 2016 14:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1281; q=dns/txt; s=iport; t=1477949320; x=1479158920; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=plNekOZX22uOY80+TdsGch1RayFojRFeY39VOSog6eE=; b=aj/RXdtZcFKxI+5h0WMZ+KNMn86iPKiTIgkrbxlv1QQ+3dcVYDsHE6JM Gzm9FGjq7Qft2DyDZM31jRWvqRfLkmWO2MtvvRfrq0YjFiaSV7+l/Z4sG TGHVdJSuoEOBwC+b8oK0yqCCw9HBnwNhDkExX6i5elc5gbSuaXibSdeBg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAQCIthdY/4wNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9YfQeNL5Z/lD6CBx0NhXkCghI/FAECAQEBAQEBAWIohGI?= =?us-ascii?q?BAQEEAQEBGh00FwQCAQgRBAEBHwkHJwsUCQgCBAESCIhMDrQIAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFwWGPYRViicFlDqFXgGJN4ZxgXWEbYkpjRGEAQEeNmCDV4E?= =?us-ascii?q?7cgGGf4EJAQEB?= X-IronPort-AV: E=Sophos;i="5.31,428,1473120000"; d="scan'208";a="342483640" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Oct 2016 21:28:39 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u9VLSdlt031938 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Oct 2016 21:28:39 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 31 Oct 2016 16:28:38 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Mon, 31 Oct 2016 16:28:38 -0500 From: "Ketan Jivan Talaulikar (ketant)" To: "John G. Scudder" , "idr@ietf.org" Thread-Topic: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext Thread-Index: AQHSM7wV7zfWBjNlUUef7XuYJEjaN6DDE+Tg Date: Mon, 31 Oct 2016 21:28:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.160.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:28:56 -0000 Support adoption. Thanks, Ketan -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: 31 October 2016 14:16 To: idr@ietf.org Subject: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-seg= ment-routing-ext Hi Everyone, The authors have asked (some time ago actually) for the WG to adopt draft-g= redler-idr-bgp-ls-segment-routing-ext.=20 If you support or oppose adoption please reply indicating so. Reasons for y= our position are helpful, as volunteering to review, comment, and/or shephe= rd. The adoption call will end November 13. Thanks, --John P.S.: https://www.ietf.org/id/draft-gredler-idr-bgp-ls-segment-routing-ext-= 04.txt Abstract Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS, OSPF and OSPFv3). This draft defines extensions to the BGP Link-state address-family in order to carry segment information via BGP. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon Oct 31 14:29:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10505129B14 for ; Mon, 31 Oct 2016 14:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Xg3qCXKyMoBj for ; Mon, 31 Oct 2016 14:29:29 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44A1129B49 for ; Mon, 31 Oct 2016 14:29:10 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id p190so172218701wmp.1 for ; Mon, 31 Oct 2016 14:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+JWsk1nadfy7OaKXjfspcdWSHTgMeN1xJclLrQOCLAg=; b=Rj0Jty2zVWZ1xrjhZW0yX1DjCTPpcuLKmxr5YdU/0nx2kGG9AnOg46Nie0nMpEb6zH Gfv2i8Rj0ORgZLRsVr2Lr0Q/TyBGKl0hW/bESIwQG37U6U/bz+3FbsokACW9yDZUPj6F gmYmuuO6uyWj/yNUsp6BKJRLPHQwnqfYnXg6th2Iop6zKWd+UW8ZgNVuBugUK06I6Dmt L31KDAvkVUBXL++4grZiXvVgq3GdAI7fHvRZR56Nljeo6K4afZ4220pp2svsCsuVqrPP LfE4bD8yCjEFRJV4GCTL8U51XQHy0kbaS1j1HGP5AckHc4BB5QQOcW+yXS94HgcbbFfW LAEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+JWsk1nadfy7OaKXjfspcdWSHTgMeN1xJclLrQOCLAg=; b=EgZ+dzRjB/aQLDQ3+/kXFjNpXvc9r2HOfINL/xjwkYQqaT1FAmjluM4k7yM2HMC1nG Ir+VL1hIVc7cwM1U8mc9Q3m4NhhJvPPF001HlgADYLEWAd++k8swpL80crD5W6L0QbOf StAgnfbxM7bDcoIV5o9DOnBJFGlqaLzrERBgijG9PjxpwIV7Kcj9UVxyx7HhRKE2q0+W Oky7XCSlvNWAyjSgJ50CZ+7d2HivQSkAFh4040GYfUjSc2Y7gEcYM/4WoI92r8nlD5Zx bOT4Rq8s73ua/3IgJn0DJSuFIIenv8NnxPUHRsOvgRpBtOC+sxIPM7jZBsKqTof5OMZA KexQ== X-Gm-Message-State: ABUngvcOArYV1gtyjt5wnC6r3GOeODBQn4c+RDWEf7OBEArFxfwKyJiYc71Op+iNLlgb7Vgb/xqqKM/QiRyiWQ== X-Received: by 10.194.78.195 with SMTP id d3mr23251969wjx.96.1477949349203; Mon, 31 Oct 2016 14:29:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.197.132 with HTTP; Mon, 31 Oct 2016 14:29:08 -0700 (PDT) In-Reply-To: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> From: Brian Dickson Date: Mon, 31 Oct 2016 14:29:08 -0700 Message-ID: To: "John G.Scudder" Content-Type: multipart/alternative; boundary=047d7bfd0010f4939e05402fe50b Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:29:32 -0000 --047d7bfd0010f4939e05402fe50b Content-Type: text/plain; charset=UTF-8 I support adoption. IMHO, the primary reasons are for the ability of operators and vendors to identify occurrences "in the wild", and to be able identify their status as "deprecated" as well as to possibly provide mechanisms for stripping them when seen and/or notifying sending operators. I am willing to review and comment once adopted. Brian On Mon, Oct 31, 2016 at 2:18 PM, John G.Scudder wrote: > Hi Everyone, > > The author has asked for the WG to adopt draft-snijders-idr-deprecate- > 30-31-129. > > If you support or oppose adoption please reply indicating so. Reasons for > your position are helpful, as volunteering to review, comment, and/or > shepherd. As an aside, I will note that I don't think the WG has the option > of doing nothing, so if you oppose adoption please address what you think > should be done instead. > > The adoption call will end November 13. > > Thanks, > > --John > > P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate- > 30-31-129-01 > > Abstract > > This document requests IANA to deprecate the following BGP path > attributes values: 30, 31 and 129. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7bfd0010f4939e05402fe50b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support adoption.

IMHO, the primary r= easons are for the ability of operators and vendors to identify occurrences= "in the wild", and to be able identify their status as "dep= recated" as well as to possibly provide mechanisms for stripping them = when seen and/or notifying sending operators.

I am= willing to review and comment once adopted.

Brian=

On Mo= n, Oct 31, 2016 at 2:18 PM, John G.Scudder <jgs@juniper.net> w= rote:
Hi Everyone,

The author has asked for the WG to adopt=C2=A0 draft-snijders-idr-deprecate= -30-31-129.

If you support or oppose adoption please reply indicating so. Reasons for y= our position are helpful, as volunteering to review, comment, and/or shephe= rd. As an aside, I will note that I don't think the WG has the option o= f doing nothing, so if you oppose adoption please address what you think sh= ould be done instead.

The adoption call will end November 13.

Thanks,

--John

P.S.: https://tools.ietf.org/ht= ml/draft-snijders-idr-deprecate-30-31-129-01

Abstract

=C2=A0 =C2=A0This document requests IANA to deprecate the following BGP pat= h
=C2=A0 =C2=A0attributes values: 30, 31 and 129.


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--047d7bfd0010f4939e05402fe50b-- From nobody Mon Oct 31 14:32:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BC8129B42 for ; Mon, 31 Oct 2016 14:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 p_N8toYNwvUr for ; Mon, 31 Oct 2016 14:32:23 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA79129B36 for ; Mon, 31 Oct 2016 14:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1380; q=dns/txt; s=iport; t=1477949543; x=1479159143; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CsxPUh1imBGs8uYuucKMDqAoOj5/cy/yWB+Qt/sYsG8=; b=dXAHpWbdU/DNGZbGlSjBfdbs6gFE3K2sygr7m9hHgk0xlnpwDUFGsbTA x80IM5z9vHvWzK7vqIy0SGI1yCNen6tqqXh+Kb5epE7mim229AR8zSUId mYqsuFUveciyqiy/RrGeUp5VE+Q2fz5X0MyAk0I+18biXfPLYc0XO8JPU s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAQCrtxdY/5BdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9YfQeNL6s9ggcdC4V7AhqBeD8UAQIBAQEBAQEBYiiEYwE?= =?us-ascii?q?BBAEBARoGETobAgEIGgImAgICJQsVEAIEARKIVA6nF4x0AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBFwWBB4oLh0uCXAWaGAGGL4oAgW6EbYkpkRIBHjZgg1eBO3KHAIE?= =?us-ascii?q?JAQEB?= X-IronPort-AV: E=Sophos;i="5.31,428,1473120000"; d="scan'208";a="341865157" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2016 21:32:22 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u9VLWLGX025391 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Oct 2016 21:32:22 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 31 Oct 2016 17:32:21 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 31 Oct 2016 17:32:21 -0400 From: "Acee Lindem (acee)" To: "John G.Scudder" , IETF IDR Working Group Thread-Topic: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 Thread-Index: AQHSM75Dl+Sd42REzE2f29v6P8cJhg== Date: Mon, 31 Oct 2016 21:32:21 +0000 Message-ID: References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> In-Reply-To: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <2554077DCFA5EB4E9A91B3DE1084047B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:32:36 -0000 SSBzdXBwb3J0IGFkb3B0aW9uLg0KVGhhbmtzLA0KQWNlZSANCg0KT24gMTAvMzEvMTYsIDU6MTgg UE0sICJJZHIgb24gYmVoYWxmIG9mIEpvaG4gRy5TY3VkZGVyIg0KPGlkci1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiBqZ3NAanVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+SGkgRXZlcnlvbmUs DQo+DQo+VGhlIGF1dGhvciBoYXMgYXNrZWQgZm9yIHRoZSBXRyB0byBhZG9wdA0KPmRyYWZ0LXNu aWpkZXJzLWlkci1kZXByZWNhdGUtMzAtMzEtMTI5Lg0KPg0KPklmIHlvdSBzdXBwb3J0IG9yIG9w cG9zZSBhZG9wdGlvbiBwbGVhc2UgcmVwbHkgaW5kaWNhdGluZyBzby4gUmVhc29ucyBmb3INCj55 b3VyIHBvc2l0aW9uIGFyZSBoZWxwZnVsLCBhcyB2b2x1bnRlZXJpbmcgdG8gcmV2aWV3LCBjb21t ZW50LCBhbmQvb3INCj5zaGVwaGVyZC4gQXMgYW4gYXNpZGUsIEkgd2lsbCBub3RlIHRoYXQgSSBk b24ndCB0aGluayB0aGUgV0cgaGFzIHRoZQ0KPm9wdGlvbiBvZiBkb2luZyBub3RoaW5nLCBzbyBp ZiB5b3Ugb3Bwb3NlIGFkb3B0aW9uIHBsZWFzZSBhZGRyZXNzIHdoYXQNCj55b3UgdGhpbmsgc2hv dWxkIGJlIGRvbmUgaW5zdGVhZC4NCj4NCj5UaGUgYWRvcHRpb24gY2FsbCB3aWxsIGVuZCBOb3Zl bWJlciAxMy4NCj4NCj5UaGFua3MsDQo+DQo+LS1Kb2huDQo+DQo+UC5TLjogDQo+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNuaWpkZXJzLWlkci1kZXByZWNhdGUtMzAtMzEtMTI5 LTAxDQo+DQo+QWJzdHJhY3QNCj4NCj4gICBUaGlzIGRvY3VtZW50IHJlcXVlc3RzIElBTkEgdG8g ZGVwcmVjYXRlIHRoZSBmb2xsb3dpbmcgQkdQIHBhdGgNCj4gICBhdHRyaWJ1dGVzIHZhbHVlczog MzAsIDMxIGFuZCAxMjkuDQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5JZHIgbWFpbGluZyBsaXN0DQo+SWRyQGlldGYub3JnDQo+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0K From nobody Mon Oct 31 15:07:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127E2129B17 for ; Mon, 31 Oct 2016 15:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kZEJGFgXAw9l for ; Mon, 31 Oct 2016 15:07:45 -0700 (PDT) Received: from relay.dacor.de (relay.dacor.de [217.24.56.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB2D1294BE for ; Mon, 31 Oct 2016 15:07:45 -0700 (PDT) Received: from exchange.dacor.de (astaro1.dacor.de [217.24.48.66]) by relay.dacor.de (Postfix) with ESMTPS id E57D7E3019; Mon, 31 Oct 2016 23:07:43 +0100 (CET) Received: from ex02.suecdacor.local (192.168.1.16) by ex02.suecdacor.local (192.168.1.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 31 Oct 2016 23:07:43 +0100 Received: from ex02.suecdacor.local ([::1]) by ex02.suecdacor.local ([::1]) with mapi id 15.00.1210.000; Mon, 31 Oct 2016 23:07:43 +0100 From: Julian Seifert To: John G.Scudder , IETF IDR Working Group Thread-Topic: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 Thread-Index: AQHSM7xx96Q9hv8JWkC3HI5f0ChU1qDDHtQ1 Date: Mon, 31 Oct 2016 22:07:43 +0000 Message-ID: <1477951662005.12181@dacor.de> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> In-Reply-To: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [86.238.138.73] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:07:47 -0000 Hi,=0A= =0A= I support adoption of this draft.=0A= =0A= kind regards,=0A= =0A= Julian=0A= ________________________________________=0A= Von: Idr im Auftrag von John G.Scudder =0A= Gesendet: Montag, 31. Oktober 2016 22:18=0A= An: IETF IDR Working Group=0A= Betreff: [Idr] Working group adoption call for draft-snijders-idr-deprecat= e-30-31-129=0A= =0A= Hi Everyone,=0A= =0A= The author has asked for the WG to adopt draft-snijders-idr-deprecate-30-3= 1-129.=0A= =0A= If you support or oppose adoption please reply indicating so. Reasons for y= our position are helpful, as volunteering to review, comment, and/or shephe= rd. As an aside, I will note that I don't think the WG has the option of do= ing nothing, so if you oppose adoption please address what you think should= be done instead.=0A= =0A= The adoption call will end November 13.=0A= =0A= Thanks,=0A= =0A= --John=0A= =0A= P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01= =0A= =0A= Abstract=0A= =0A= This document requests IANA to deprecate the following BGP path=0A= attributes values: 30, 31 and 129.=0A= =0A= =0A= _______________________________________________=0A= Idr mailing list=0A= Idr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/idr=0A= From nobody Mon Oct 31 15:09:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4030C129B63 for ; Mon, 31 Oct 2016 15:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DrSpqpX_Duvw for ; Mon, 31 Oct 2016 15:09:37 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F08129B61 for ; Mon, 31 Oct 2016 15:09:32 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id d2so8223802pfd.0 for ; Mon, 31 Oct 2016 15:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=OEZimO77JfOcqRjvMGTBjrsREVwwzpLrUzRcqFD6CRM=; b=Ohdmfbpv4zQ64hSY4wNIKKBa9thoWAOqT5MtwEdVgZGCaGrsyHKHqXReuzX7wUYsZe hwziAtlf+BPUp6Y9s6gTmdYNbypODp9oEPCG3BDBJN6SfBh7+rmyZhFTElOgLKT1JO6r Luwgr8X3bDiAje/nx+qYlX3KGWWYjPntxfir0dCVl/UXNSnZLRPAvlHqGWjrtfLIEMQc 9S5RiMbLAusBIqdxD1Qq74ndytp4gPbk0+bJlXZ7xHGgMri8Qtz/s1UypEGI00gc6j5P IsIgiTLCSIHYfDJFG5EjcAliTsLpKd2LTnPP76jq509nxn6IgY2PfXQiQ4CW1xQKGhpT oD9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=OEZimO77JfOcqRjvMGTBjrsREVwwzpLrUzRcqFD6CRM=; b=PsKD28onWk+WvUwtmpsUccVPHa9CKjOB+y17fBMLPLm0hdErRd76xMB2Q1n98VI6wz 7kFrg3M9hTjvpD3oxnrZ8JutDS0HjWYqjMy7a5n8KL88BFSd5YOHQMHYKx3xq003TLMc JgOGw4XJbIIRnUt2uv09fW2x4rBY+xuqSn/yvBMDXWYJIAtUesrdtsQJ/p0p8batinMC iRPeJ0pJvQpbabIGR9PEJ/Peprfhps1zEJnsvumfYKT8AQyOw7Ew478W2ugeo+kRek4O yvZWPkwPptCKKpZOvkZOiuUpF7y2KDquHmHQvtW1tpTtTOzbADaVcNOMrCQ13rhoZfrX Cujw== X-Gm-Message-State: ABUngveTLG/hlaFcyjxrwcihLahLBMXiGDUdO1pRbAiY4/kI/qlnV4I3XhlPwXl7v9p7IQ== X-Received: by 10.98.106.196 with SMTP id f187mr53089994pfc.91.1477951772010; Mon, 31 Oct 2016 15:09:32 -0700 (PDT) Received: from [192.168.255.25] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id a7sm3167607pfl.87.2016.10.31.15.09.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 15:09:31 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Mon, 31 Oct 2016 15:09:29 -0700 From: Jeff Tantsura To: IETF IDR Working Group Message-ID: <83A6EE2D-F1A1-4BA9-A419-1E04383FE411@gmail.com> Thread-Topic: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:09:39 -0000 Yes/support Cheers, Jeff On 10/31/16, 5:18 PM, "Idr on behalf of John G.Scudder" wrote: >Hi Everyone, > >The author has asked for the WG to adopt >draft-snijders-idr-deprecate-30-31-129. > >If you support or oppose adoption please reply indicating so. Reasons for >your position are helpful, as volunteering to review, comment, and/or >shepherd. As an aside, I will note that I don't think the WG has the >option of doing nothing, so if you oppose adoption please address what >you think should be done instead. > >The adoption call will end November 13. > >Thanks, > >--John > >P.S.: >https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 > >Abstract > > This document requests IANA to deprecate the following BGP path > attributes values: 30, 31 and 129. > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Mon Oct 31 15:19:44 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7681D129B6D for ; Mon, 31 Oct 2016 15:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 g2Z70daN28SI for ; Mon, 31 Oct 2016 15:19:40 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A18129B8C for ; Mon, 31 Oct 2016 15:19:40 -0700 (PDT) Received: from [64.134.98.75] (helo=doom.twoguys.org) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1c1KvS-0008GF-EW; Mon, 31 Oct 2016 18:19:30 -0400 Received: from doom.twoguys.org (localhost.twoguys.org [127.0.0.1]) by doom.twoguys.org (8.14.4/8.12.11) with ESMTP id u9VMJP3o004343; Mon, 31 Oct 2016 18:19:25 -0400 Received: (from ghankins@localhost) by doom.twoguys.org (8.14.4/8.14.4/Submit) id u9VMJPlG004339; Mon, 31 Oct 2016 18:19:25 -0400 X-Authentication-Warning: doom.twoguys.org: ghankins set sender to greg.hankins@nokia.com using -f Date: Mon, 31 Oct 2016 18:19:25 -0400 From: "Hankins, Greg (Nokia - US)" To: "John G.Scudder" Message-ID: <20161031221925.GA4275@nokia.com> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> User-Agent: Mutt/1.5.19 (2009-01-05) X-ELNK-Trace: 176464c9115cf5b39c7f779228e2f6aeda0071232e20db4dba561acf4bc3ad2692581730cd8f994f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.134.98.75 Archived-At: Cc: IETF IDR Working Group Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:19:42 -0000 I support adoption to deprecate the squatted path attribute codes. Greg -- Greg Hankins -----Original Message----- Date: Mon, 31 Oct 2016 17:18:57 -0400 From: "John G.Scudder" To: IETF IDR Working Group Subject: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 Hi Everyone, The author has asked for the WG to adopt draft-snijders-idr-deprecate-30-31-129. If you support or oppose adoption please reply indicating so. Reasons for your position are helpful, as volunteering to review, comment, and/or shepherd. As an aside, I will note that I don't think the WG has the option of doing nothing, so if you oppose adoption please address what you think should be done instead. The adoption call will end November 13. Thanks, --John P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 Abstract This document requests IANA to deprecate the following BGP path attributes values: 30, 31 and 129. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon Oct 31 15:50:02 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C060B127078 for ; Mon, 31 Oct 2016 15:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9TVZ-9SSjQ6v for ; Mon, 31 Oct 2016 15:49:50 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4297129BA0 for ; Mon, 31 Oct 2016 15:49:49 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id s8so83365928pfj.2 for ; Mon, 31 Oct 2016 15:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=VAOkJ+KmBHhNjrXHfWzop4WXFH9p3Awpwp2lJWCO6e4=; b=Kl/7xUn/IjNhKwoq87hkSowzwsUvuEaaE2PJSlJVXZw2iqXEqzBg9b3bv1o1usBf90 d3U2KxXpclvEdR/7k0eU14t05wctncrHsjkgvsMHrQGg1zCvUuUsWBJfTcGfplkH3Ec9 wjqWT4lfWtObi+H5ASmgWwVgfXpYInZDB2Y90RGMiyuIxDltySv7OKHVBzvvCrSjbjZf avVO5XkJW8LIpdf+G1JSpS7lumA75OcUrdbzk3FvKrLIhzHSbpbEJdN7isHFixcc6PyC uHPGji5O3s4lZd7IL9i6jhJyxpdSHACoy2BUsSgB+e9lROdlAd7N0Jh9CCJ102BjzCe1 KWFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=VAOkJ+KmBHhNjrXHfWzop4WXFH9p3Awpwp2lJWCO6e4=; b=Ij/8/SPObTQRQsfsKBVF2hErgsNyemJeGITfAI+nUswTv1DhhmmNqOpY1c3U9ZTdT0 IZ5OjnnAknCCyzCcZG0E3UcJW6iYJxSvj0Vm09fxPMzOg9zrvhI36tJP51Sx84Bj5wkS sKJ5nYh1w2FTeQfRRcgsqbuPAMfL1hM+Plo/LUa0aXZ2gEzZ8CUtPpleeTPLgMzRNNhn k0ri3AA9eNLc1vjtZR8Y4B1Fyx73uFxqhEXM+/MYvtzvXp+yn8C+7EKOhxjjGUVDHNSR nv1wry63LsUufRgkDAzqmwTi2DMk/7lW/Ftyy4eoKdf/qTGQsnzCLruQRJ0+YBGNpwiH r5Fg== X-Gm-Message-State: ABUngvebrH9M3Z3tdRxoOoN/T2IHLkhReY89nQDikQnx1l3gXSt+YorjkTGjlDIldmALyg== X-Received: by 10.99.44.84 with SMTP id s81mr14993856pgs.153.1477954189464; Mon, 31 Oct 2016 15:49:49 -0700 (PDT) Received: from [192.168.255.25] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id z6sm37854198pay.31.2016.10.31.15.49.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 15:49:48 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Mon, 31 Oct 2016 15:49:47 -0700 From: Jeff Tantsura To: "John G. Scudder" , Message-ID: <1CD0792A-745C-43C1-9904-26F675C6DA28@gmail.com> Thread-Topic: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:50:01 -0000 Hi John, Support as co-author. Cheers, Jeff On 10/31/16, 14:16, "Idr on behalf of John G. Scudder" wrote: Hi Everyone, The authors have asked (some time ago actually) for the WG to adopt draft-gredler-idr-bgp-ls-segment-routing-ext. If you support or oppose adoption please reply indicating so. Reasons for your position are helpful, as volunteering to review, comment, and/or shepherd. The adoption call will end November 13. Thanks, --John P.S.: https://www.ietf.org/id/draft-gredler-idr-bgp-ls-segment-routing-ext-04.txt Abstract Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS, OSPF and OSPFv3). This draft defines extensions to the BGP Link-state address-family in order to carry segment information via BGP. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon Oct 31 20:10:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F6212958B for ; Mon, 31 Oct 2016 20:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9pj4kEUKEU7k for ; Mon, 31 Oct 2016 20:10:10 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC421293EE for ; Mon, 31 Oct 2016 20:10:10 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id t125so22215534ywc.1 for ; Mon, 31 Oct 2016 20:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FWvFpGP7jufOJq2P4F7iFzfu39u5iycCr6XA5z2gNps=; b=mYOGa54reR7TmdzoDaTID210+8ImpXMEy+k3igmwOkb7h8pY9aXJ4DEIuQsAN3QEVu BQrkwgoNw51yE8HSx9XFbnR+LPzMGqXContAWZqGzzxY4HWMb+sHGM3zVvoWdcjQR1Ob BHIusSJ9Y9mpOP1jrcIwpoLfbYkhejuR+Ltu/f2LaYNL+nSlK2ymuHah4hiXqSIMmBp7 nN3axbTDc0tCOko4N86RppWZVcMmPgNn3N0Kqj4UR2qYVREBqW+HUoWMH5DJhF25V44g +J7RQQrfbrui6XwH6rVzkIazxxgakwJmrFKFobeyP5sahi7LTjS7SpXexM3/1nvakcJM N+Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FWvFpGP7jufOJq2P4F7iFzfu39u5iycCr6XA5z2gNps=; b=fKJcBipsSbSUGL3q6kd04nxTuF4gCveOjfF/ON5u2XEgMyfAlVhncZF/CQ+beXAuFt vQfqyCDAUCDvJK/lk03RS1ubxwmdUXEXcnKrhaDkjg5v5mAkSg/fjL71h4rrggBPrWt8 hAlsz4WJHVxoPw6cB9ypH4zHZJgVi0ZhtoEVhKl3hY9athl4GrXyUh8MATHBeJ/4cw/h o3LiKvU75mj1NezdbvU30R6qq98TxsfGQIUvlBrK0TEYWsYKuZxdK9oaYEQ7dm+aRkFY pbyn/a28jf1EtSMfmItA7wTZ4ARjZ6XSdrB3+fNw8cBSpyg1/53Lp6rWaUsti/8+Kvr6 7gCA== X-Gm-Message-State: ABUngvd0QFIgZbuUhpdYOlw/rSd/YXxHf1MeEZ8Fp1mC7+Np92OQ32N7d3mSF0j3qXfQIeXxBNRiLAxatkFkHQ== X-Received: by 10.129.93.86 with SMTP id r83mr29651529ywb.15.1477969809393; Mon, 31 Oct 2016 20:10:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.172.30 with HTTP; Mon, 31 Oct 2016 20:10:08 -0700 (PDT) In-Reply-To: References: From: Pushpasis Sarkar Date: Tue, 1 Nov 2016 08:40:08 +0530 Message-ID: To: "John G. Scudder" Content-Type: multipart/alternative; boundary=001a114d805c7a4a8d054034a977 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 03:10:13 -0000 --001a114d805c7a4a8d054034a977 Content-Type: text/plain; charset=UTF-8 Hi John, Support as a WG member. Thanks Pushpasis On Tuesday, 1 November 2016, John G. Scudder wrote: > Hi Everyone, > > The authors have asked (some time ago actually) for the WG to adopt > draft-gredler-idr-bgp-ls-segment-routing-ext. > > If you support or oppose adoption please reply indicating so. Reasons for > your position are helpful, as volunteering to review, comment, and/or > shepherd. > > The adoption call will end November 13. > > Thanks, > > --John > > P.S.: https://www.ietf.org/id/draft-gredler-idr-bgp-ls-segment- > routing-ext-04.txt > > Abstract > > Segment Routing (SR) allows for a flexible definition of end-to-end > paths within IGP topologies by encoding paths as sequences of > topological sub-paths, called "segments". These segments are > advertised by the link-state routing protocols (IS-IS, OSPF and > OSPFv3). > > This draft defines extensions to the BGP Link-state address-family in > order to carry segment information via BGP. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a114d805c7a4a8d054034a977 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi John,

Support as a WG member.

Thanks
Pushpasis=C2=A0

On Tuesday, 1= November 2016, John G. Scudder <jgs@= juniper.net> wrote:
Hi Everyone,
The authors have asked (some time ago actually) for the WG to adopt draft-g= redler-idr-bgp-ls-segment-routing-ext.

If you support or oppose adoption please reply indicating so. Reasons for y= our position are helpful, as volunteering to review, comment, and/or shephe= rd.

The adoption call will end November 13.

Thanks,

--John

P.S.: https://www.ietf.org/id/draft-gre= dler-idr-bgp-ls-segment-routing-ext-04.txt

Abstract

=C2=A0 =C2=A0Segment Routing (SR) allows for a flexible definition of end-t= o-end
=C2=A0 =C2=A0paths within IGP topologies by encoding paths as sequences of<= br> =C2=A0 =C2=A0topological sub-paths, called "segments".=C2=A0 Thes= e segments are
=C2=A0 =C2=A0advertised by the link-state routing protocols (IS-IS, OSPF an= d
=C2=A0 =C2=A0OSPFv3).

=C2=A0 =C2=A0This draft defines extensions to the BGP Link-state address-fa= mily in
=C2=A0 =C2=A0order to carry segment information via BGP.
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr
--001a114d805c7a4a8d054034a977-- From nobody Mon Oct 31 20:36:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E0512967D for ; Mon, 31 Oct 2016 20:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 PPbSxuQR3hLP for ; Mon, 31 Oct 2016 20:36:30 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF60C129849 for ; Mon, 31 Oct 2016 20:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4320; q=dns/txt; s=iport; t=1477971390; x=1479180990; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PAen3XFVBusHEIx+esn879dPaSM9FpfeHOo8aD3JpnM=; b=lOLdf/nLr5+uCJrR3WrO7JBFR5IBZkVCjxLdZA+zs0veF0LMp2uPsCjd FpF9sUjC7w7qFMMxwRFnmn6KS4TrfD9WmXwlwXNHuHh71gjlVJXjzManj pYub1RXKtwwM3cWdNgyuJ2lIQpHx33qPJ3pguQq78fNY/qAWqj+g+TO9D o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiAQBSDBhY/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnM3AQEBAQEfWH0HhCSJC6YphReCBx0BDIV4AoIVPxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRjAQEEAQEBGlELEAIBCAQ7BycLFBECBAENBYhUDrRKAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFwEECwGGMYRViicFmhoBhjCDCYZ7gW6EbokqjROEAgEeNmC?= =?us-ascii?q?CaW+BO3IBhxKBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,430,1473120000"; d="scan'208,217";a="341139741" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2016 03:36:29 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uA13aTLG018938 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Nov 2016 03:36:29 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 31 Oct 2016 22:36:29 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Mon, 31 Oct 2016 22:36:29 -0500 From: "Bertrand Duvivier (bduvivie)" To: Pushpasis Sarkar , "John G. Scudder" Thread-Topic: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext Thread-Index: AQHSM7wVahW/27Di2E2hlIydCAHajqDDxz8AgAAHWgA= Date: Tue, 1 Nov 2016 03:36:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.107.227] Content-Type: multipart/alternative; boundary="_000_D43DCB8A6479Bbduvivieciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 03:36:32 -0000 --_000_D43DCB8A6479Bbduvivieciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as Product Manager for Cisco, implementation completed and shipping= on 2 Cisco operating systems: IOS-XR (SP routing) and IOS classic (Enterpr= ise routing). Best Regards Bertrand Duvivier https://wiki.cisco.com/display/SLA/Segment%20Routing On Tuesday, 1 November 2016, John G. Scudder > wrote: Hi Everyone, The authors have asked (some time ago actually) for the WG to adopt draft-g= redler-idr-bgp-ls-segment-routing-ext. If you support or oppose adoption please reply indicating so. Reasons for y= our position are helpful, as volunteering to review, comment, and/or shephe= rd. The adoption call will end November 13. Thanks, --John P.S.: https://www.ietf.org/id/draft-gredler-idr-bgp-ls-segment-routing-ext-= 04.txt Abstract Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS, OSPF and OSPFv3). This draft defines extensions to the BGP Link-state address-family in order to carry segment information via BGP. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_D43DCB8A6479Bbduvivieciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <90FFD8D66CF9394CBD58276DDBE0AAB3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support as Product Manager for Cisco, implementation completed and shi= pping on 2 Cisco operating systems: IOS-XR (SP routing) and IOS classic (En= terprise routing).
Best Regards Bertrand Duvivier
On Tuesday, 1 November 2016, John G. Scudder <jgs@juniper.net> wrote:
Hi Everyone,

The authors have asked (some time ago actually) for the WG to adopt draft-g= redler-idr-bgp-ls-segment-routing-ext.

If you support or oppose adoption please reply indicating so. Reasons for y= our position are helpful, as volunteering to review, comment, and/or shephe= rd.

The adoption call will end November 13.

Thanks,

--John

P.S.: https://www.ietf.org/id/draft-gredler-idr-bgp-ls-segment-routing-= ext-04.txt

Abstract

   Segment Routing (SR) allows for a flexible definition of end-t= o-end
   paths within IGP topologies by encoding paths as sequences of<= br>    topological sub-paths, called "segments".  Thes= e segments are
   advertised by the link-state routing protocols (IS-IS, OSPF an= d
   OSPFv3).

   This draft defines extensions to the BGP Link-state address-fa= mily in
   order to carry segment information via BGP.
_______________________________________________
Idr mailing list
Idr@= ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr
 --_000_D43DCB8A6479Bbduvivieciscocom_-- From nobody Mon Oct 31 21:47:39 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C34F124281 for ; Mon, 31 Oct 2016 21:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NG8kbNxLKklH for ; Mon, 31 Oct 2016 21:47:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12AB3129A93 for ; Mon, 31 Oct 2016 21:47:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZL41954; Tue, 01 Nov 2016 04:47:21 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Nov 2016 04:47:20 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 1 Nov 2016 12:47:14 +0800 From: Zhuangshunwan To: "John G. Scudder" , "idr@ietf.org" Thread-Topic: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext Thread-Index: AQHSM7we6fxJnuOgz0qNBxcvspuno6DDjdTA Date: Tue, 1 Nov 2016 04:47:13 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858C87A9258@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.254] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58181E59.008E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7a17522774cc57c1ea78e4eb68b3e372 Archived-At: Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 04:47:37 -0000 U3VwcG9ydC4NCg0KVGhhbmtzLA0KU2h1bndhbg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7I yzogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSm9obiBHLiBTY3VkZGVy DQq3osvNyrG85DogMjAxNsTqMTHUwjHI1SA1OjE2DQrK1bz+yMs6IGlkckBpZXRmLm9yZw0K1vfM 4jogW0lkcl0gV29ya2luZyBncm91cCBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1ncmVkbGVyLWlk ci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLWV4dA0KDQpIaSBFdmVyeW9uZSwNCg0KVGhlIGF1dGhv cnMgaGF2ZSBhc2tlZCAoc29tZSB0aW1lIGFnbyBhY3R1YWxseSkgZm9yIHRoZSBXRyB0byBhZG9w dCBkcmFmdC1ncmVkbGVyLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLWV4dC4gDQoNCklmIHlv dSBzdXBwb3J0IG9yIG9wcG9zZSBhZG9wdGlvbiBwbGVhc2UgcmVwbHkgaW5kaWNhdGluZyBzby4g UmVhc29ucyBmb3IgeW91ciBwb3NpdGlvbiBhcmUgaGVscGZ1bCwgYXMgdm9sdW50ZWVyaW5nIHRv IHJldmlldywgY29tbWVudCwgYW5kL29yIHNoZXBoZXJkLg0KDQpUaGUgYWRvcHRpb24gY2FsbCB3 aWxsIGVuZCBOb3ZlbWJlciAxMy4NCg0KVGhhbmtzLA0KDQotLUpvaG4NCg0KUC5TLjogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtZ3JlZGxlci1pZHItYmdwLWxzLXNlZ21lbnQtcm91dGlu Zy1leHQtMDQudHh0DQoNCkFic3RyYWN0DQoNCiAgIFNlZ21lbnQgUm91dGluZyAoU1IpIGFsbG93 cyBmb3IgYSBmbGV4aWJsZSBkZWZpbml0aW9uIG9mIGVuZC10by1lbmQNCiAgIHBhdGhzIHdpdGhp biBJR1AgdG9wb2xvZ2llcyBieSBlbmNvZGluZyBwYXRocyBhcyBzZXF1ZW5jZXMgb2YNCiAgIHRv cG9sb2dpY2FsIHN1Yi1wYXRocywgY2FsbGVkICJzZWdtZW50cyIuICBUaGVzZSBzZWdtZW50cyBh cmUNCiAgIGFkdmVydGlzZWQgYnkgdGhlIGxpbmstc3RhdGUgcm91dGluZyBwcm90b2NvbHMgKElT LUlTLCBPU1BGIGFuZA0KICAgT1NQRnYzKS4NCg0KICAgVGhpcyBkcmFmdCBkZWZpbmVzIGV4dGVu c2lvbnMgdG8gdGhlIEJHUCBMaW5rLXN0YXRlIGFkZHJlc3MtZmFtaWx5IGluDQogICBvcmRlciB0 byBjYXJyeSBzZWdtZW50IGluZm9ybWF0aW9uIHZpYSBCR1AuDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K From nobody Mon Oct 31 21:51:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAAA129500 for ; Mon, 31 Oct 2016 21:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 DlMK-JzVI7Tv for ; Mon, 31 Oct 2016 21:51:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BAFF1294E8 for ; Mon, 31 Oct 2016 21:51:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUH31312; Tue, 01 Nov 2016 04:51:01 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Nov 2016 04:51:00 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 1 Nov 2016 12:50:56 +0800 From: Zhuangshunwan To: "John G.Scudder" , IETF IDR Working Group Thread-Topic: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 Thread-Index: AQHSM7x0LDqClv5FX0SkYHi6m5Kh16DDj2EQ Date: Tue, 1 Nov 2016 04:50:56 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858C87A9272@NKGEML515-MBX.china.huawei.com> References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> In-Reply-To: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.254] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58181F35.00C9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e95230685f3f151d9c3e1f6a2e380c80 Archived-At: Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 04:51:05 -0000 U3VwcG9ydCBhZG9wdGlvbi4NCg0KVGhhbmtzLA0KU2h1bndhbg0KDQotLS0tLdPKvP7Urbz+LS0t LS0NCreivP7IyzogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSm9obiBH LlNjdWRkZXINCreiy83KsbzkOiAyMDE2xOoxMdTCMcjVIDU6MTkNCsrVvP7IyzogSUVURiBJRFIg V29ya2luZyBHcm91cA0K1vfM4jogW0lkcl0gV29ya2luZyBncm91cCBhZG9wdGlvbiBjYWxsIGZv ciBkcmFmdC1zbmlqZGVycy1pZHItZGVwcmVjYXRlLTMwLTMxLTEyOQ0KDQpIaSBFdmVyeW9uZSwN Cg0KVGhlIGF1dGhvciBoYXMgYXNrZWQgZm9yIHRoZSBXRyB0byBhZG9wdCAgZHJhZnQtc25pamRl cnMtaWRyLWRlcHJlY2F0ZS0zMC0zMS0xMjkuIA0KDQpJZiB5b3Ugc3VwcG9ydCBvciBvcHBvc2Ug YWRvcHRpb24gcGxlYXNlIHJlcGx5IGluZGljYXRpbmcgc28uIFJlYXNvbnMgZm9yIHlvdXIgcG9z aXRpb24gYXJlIGhlbHBmdWwsIGFzIHZvbHVudGVlcmluZyB0byByZXZpZXcsIGNvbW1lbnQsIGFu ZC9vciBzaGVwaGVyZC4gQXMgYW4gYXNpZGUsIEkgd2lsbCBub3RlIHRoYXQgSSBkb24ndCB0aGlu ayB0aGUgV0cgaGFzIHRoZSBvcHRpb24gb2YgZG9pbmcgbm90aGluZywgc28gaWYgeW91IG9wcG9z ZSBhZG9wdGlvbiBwbGVhc2UgYWRkcmVzcyB3aGF0IHlvdSB0aGluayBzaG91bGQgYmUgZG9uZSBp bnN0ZWFkLg0KDQpUaGUgYWRvcHRpb24gY2FsbCB3aWxsIGVuZCBOb3ZlbWJlciAxMy4NCg0KVGhh bmtzLA0KDQotLUpvaG4NCg0KUC5TLjogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXNuaWpkZXJzLWlkci1kZXByZWNhdGUtMzAtMzEtMTI5LTAxDQoNCkFic3RyYWN0DQoNCiAgIFRo aXMgZG9jdW1lbnQgcmVxdWVzdHMgSUFOQSB0byBkZXByZWNhdGUgdGhlIGZvbGxvd2luZyBCR1Ag cGF0aA0KICAgYXR0cmlidXRlcyB2YWx1ZXM6IDMwLCAzMSBhbmQgMTI5Lg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0 DQpJZHJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRy DQo= From nobody Mon Oct 31 23:35:59 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2436A126CD8 for ; Mon, 31 Oct 2016 23:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kzUF69Pe9koO for ; Mon, 31 Oct 2016 23:35:55 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A2E12952D for ; Mon, 31 Oct 2016 23:35:54 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id n67so268497909wme.1 for ; Mon, 31 Oct 2016 23:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Okk9sY1lB5V+6fLsqM/9Z8AOrqveY77lPZoGdZP5gwA=; b=g7eQzZsV0glBMijE+sFD0nVIl28KkWqyToZA3bJSkxbSHyJctm11DM75npArukxT73 4T3UpCO433kcytU3W26UZ9SNiQluAQ57FFZy0LaG6UEMppIPASKopenLY6QpodB1IiRK 6z6k3KTXvD1rZvA7beI4DIyPEk+phDsn2CxAu5UpI7peFgGBQmwFt2fbxtdD8xp40X1E pV0hZH02iTlBv5/WmOGiLe1WDH7xzF2Z2L/sA3pYXxHI6xhDs3oC9JLo20r5X2qp4HYm I1PJAb1397SogXFz1T+ORE4UwlphvOsUHHAGe72wSfsTz3rDHWBPVsQo15BVPtnfCCJ7 I8Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Okk9sY1lB5V+6fLsqM/9Z8AOrqveY77lPZoGdZP5gwA=; b=ACwLQ+K0x9A7QaK0Uh1txheMA1M5mZoE9zfyc29xEPq1UYmeh5m2EANboSs7M/2t8+ u5KyVcafYiEN0sgcM6UV4Sw5IAD7ldO7fg+HgwxZYW646cBMMDAwJkPtYZqwYQBchEK5 UV+ViC5xgfZdQ2nMogkRVPO48u1OXoc/7ceAVIKoHI8IIUuBsRc3UdbgsGIEtfDGLsUH 8+VvMsvrhFOS8ZU+V40myxBpI6hNFyKBHFFrcVZF0zw7w65cQygU/XdMXdxAtnYncexs nulnIsY0Fix/IwODSyStsudPD8dryWf9DJHZ+gSYUfRZW7+AWoAsbyfhFWTLEOXIpAbA bNNw== X-Gm-Message-State: ABUngvfu7n4R7YRBgehYQqesT5uCilLqMh89/t4SsbfCkzMR4gPYmqNdPAoZ7anjXuVOOjrCdvPrdVKVfM+O6g== X-Received: by 10.194.167.40 with SMTP id zl8mr878599wjb.226.1477982152928; Mon, 31 Oct 2016 23:35:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.22.8 with HTTP; Mon, 31 Oct 2016 23:35:52 -0700 (PDT) In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858C87A9258@NKGEML515-MBX.china.huawei.com> References: <19AB2A007F56DB4E8257F949A2FB9858C87A9258@NKGEML515-MBX.china.huawei.com> From: Mamud Hasan Date: Tue, 1 Nov 2016 12:05:52 +0530 Message-ID: To: Zhuangshunwan Content-Type: multipart/alternative; boundary=089e0112d15635b4340540378959 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] Working group adoption call for draft-gredler-idr-bgp-ls-segment-routing-ext X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 06:35:57 -0000 --089e0112d15635b4340540378959 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Support. I am willing to review and comment Thanks, Mamud On Tue, Nov 1, 2016 at 10:17 AM, Zhuangshunwan wrote: > Support. > > Thanks, > Shunwan > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Idr [mailto:idr-bounces@ietf.org] =E4=BB=A3= =E8=A1=A8 John G. Scudder > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B411=E6=9C=881=E6=97=A5 = 5:16 > =E6=94=B6=E4=BB=B6=E4=BA=BA: idr@ietf.org > =E4=B8=BB=E9=A2=98: [Idr] Working group adoption call for draft-gredler-i= dr-bgp-ls- > segment-routing-ext > > Hi Everyone, > > The authors have asked (some time ago actually) for the WG to adopt > draft-gredler-idr-bgp-ls-segment-routing-ext. > > If you support or oppose adoption please reply indicating so. Reasons for > your position are helpful, as volunteering to review, comment, and/or > shepherd. > > The adoption call will end November 13. > > Thanks, > > --John > > P.S.: https://www.ietf.org/id/draft-gredler-idr-bgp-ls-segment- > routing-ext-04.txt > > Abstract > > Segment Routing (SR) allows for a flexible definition of end-to-end > paths within IGP topologies by encoding paths as sequences of > topological sub-paths, called "segments". These segments are > advertised by the link-state routing protocols (IS-IS, OSPF and > OSPFv3). > > This draft defines extensions to the BGP Link-state address-family in > order to carry segment information via BGP. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --089e0112d15635b4340540378959 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support. I am willing to review and comment

Thanks,
Mamud

=
On Tue, Nov 1, 2016 at 10:17 AM, Zhuangshunwan <= span dir=3D"ltr"><zhuangshunwan@huawei.com> wrote:
Support.

Thanks,
Shunwan

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: Idr [mailto:idr-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 John G. Scudder
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B411=E6=9C=881=E6=97=A5 5:= 16
=E6=94=B6=E4=BB=B6=E4=BA=BA: idr@ietf.org
=E4=B8=BB=E9=A2=98: [Idr] Working group adoption call for draft-gredler-idr= -bgp-ls-segment-routing-ext

Hi Everyone,

The authors have asked (some time ago actually) for the WG to adopt draft-g= redler-idr-bgp-ls-segment-routing-ext.

If you support or oppose adoption please reply indicating so. Reasons for y= our position are helpful, as volunteering to review, comment, and/or shephe= rd.

The adoption call will end November 13.

Thanks,

--John

P.S.: https://www.ietf.or= g/id/draft-gredler-idr-bgp-ls-segment-routing-ext-04.txt

Abstract

=C2=A0 =C2=A0Segment Routing (SR) allows for a flexible definition of end-t= o-end
=C2=A0 =C2=A0paths within IGP topologies by encoding paths as sequences of<= br> =C2=A0 =C2=A0topological sub-paths, called "segments".=C2=A0 Thes= e segments are
=C2=A0 =C2=A0advertised by the link-state routing protocols (IS-IS, OSPF an= d
=C2=A0 =C2=A0OSPFv3).

=C2=A0 =C2=A0This draft defines extensions to the BGP Link-state address-fa= mily in
=C2=A0 =C2=A0order to carry segment information via BGP.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--089e0112d15635b4340540378959--