From nobody Mon May 1 06:26:47 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F22E1277BB for ; Mon, 1 May 2017 06:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 qn39YqTLRgZB for ; Mon, 1 May 2017 06:26:44 -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 A0AAA128B38 for ; Mon, 1 May 2017 06:23:49 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id r190so97454764wme.1 for ; Mon, 01 May 2017 06:23:49 -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=IQaweHABiw4USH0oYo4JBEC4sLx+Xe5sy5HFejzmrDc=; b=JuM0Wege9qmAkwyj+FDPIGScTwLqPaHFj8Rf6B/vXCwMhEN4CttN30j485nmha2kla Vt9xMC3qO4a3dSb/K97pOgzefan8OUXBP1okH6H1SplGwC63WiZbBb/vN52kVCgJ9Uva Rywl0lEAz41bTKUjyGUP7wFTYNy/tjVCjWAiXYBM42nVXtRIocbLiYfiVQTosz4v80qn nwiEPLK7kr7ubcfhXq4TA23oBgjozHDFtSxJgiipPP1BWDKE15PaXi6LkdHPuGzzEnF4 5Sboaz/R81Mm2HUZ80Q5dLDbHA3jBpgS+uJwppXKcPDWJbJwwhfAPU9RmgSqssTnsw76 etvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=IQaweHABiw4USH0oYo4JBEC4sLx+Xe5sy5HFejzmrDc=; b=gNI3EAGDzOI+kgdZL7bCgm37AIp/2+iNC8wZxs6utNRtE/2wOkQX90QDQFaqm9dsNR gprQjpLDVe06PUIxz3k65qbc2k10VLWH2V4mZa2fUzhqWa8OJG5wDQ6zxl61Z1kEgU4H Zmhviqjt3NsWqhyPH6d8BRKzl3eIsVlQoWdkJrwLOibl/GezYlsjX8gjXKmQvHQwtgK4 c466iOCLWSTGoiJsJ446JxXCghFqooS0vdi7Rn3mBPQkcyYh/n4K0Jdl9XL0aE4gKY3h A2+Og/wJ3K05qBQ5DITLFgtLPU/kFs7j0BFeo72KezUq33/4kvWdY4ZZ62kSKMAWxloc i+jA== X-Gm-Message-State: AN3rC/4NalhChf57fzeNodmJa2pWHagQ1dRYAh+HlWHzkEg/Y9GYEgCx Yw2dG6YamC/LXQ== X-Received: by 10.80.186.85 with SMTP id 21mr20023823eds.104.1493645027894; Mon, 01 May 2017 06:23:47 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:14c0:327d:7e70:a488]) by smtp.gmail.com with ESMTPSA id a56sm7132272edd.48.2017.05.01.06.23.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2017 06:23:45 -0700 (PDT) Date: Mon, 1 May 2017 15:23:44 +0200 From: Job Snijders To: Randy Bush Cc: idr@ietf.org Message-ID: <20170501132344.mhzniqgbtev3iqqi@hanna.meerval.net> References: 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: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 13:26:46 -0000 On Sat, Apr 29, 2017 at 01:30:26PM +0900, Randy Bush wrote: > but ignoring broken analogies and to the point, in the case of this > draft, the operator is in definite danger of a major oops (that's a > technical term) when field upgrading the software in a router. > > despite this exposure, i am mostly of the opinion that the benefits > outweigh the risks with this draft. but vendors should do their best to > ameliorate the risks with loud warnings. In addition to warnings, perhaps some inspiration can be drawn from the deprecation of SSHv1 in OpenSSH. This too required a process that spanned several years (and isn't finished yet, since distributions haven't yet incorporated the latest upstream version of OpenSSH, but alas). If OpenSSH can do it, so can others! :-) First: http://undeadly.org/cgi?action=article&sid=20150324200217 Then: http://undeadly.org/cgi?action=article&sid=20170501005206 Considerations of others regarding SSHv1: PuTTY: http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/no-ssh1-fallback.html Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807107 Kind regards, Job From nobody Mon May 1 11:40:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE69612EAF2 for ; Mon, 1 May 2017 11:40:36 -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 JlYQbBcF2xww for ; Mon, 1 May 2017 11:40:35 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 9B7DA129C6A for ; Mon, 1 May 2017 11:37:30 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id u65so93360901wmu.1 for ; Mon, 01 May 2017 11:37:30 -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=gwB0lydl2QRaK9Lx4sqoFK4LpQYKRCoPgb/yWGxZexs=; b=hMGa2zqjOLqTRA5xe2kFJ/sKY/Zyp8kXahF0IUcqu9/0+e+xgEBUJzAtUe2WVYZ7w6 QMohcuguk4YaJCD8dEyZ+yn95OFGimtHsBTxwFTcdKnJEhge9WQzo8ATowYn2LTy7J26 m4iKJT7BmW0MoKonF3Q4y4RjZii/Vwyfsm3QvJHEOvuDbYuR9R8Ep1ExkHNL4GKeKY/U 1YTU0fokEb5ydBO6dpwwslGQ+GCvbiKCsofmgJ0h4jK+fTn+7GG8ZvCAc/VpP4uYU4ko iba1VnlbzSIKKNtmA2+en/BmJJMdfSSjzvEJxumfVRacz2mt2VrB4aFuEmEv9ePBGVYj 2P7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=gwB0lydl2QRaK9Lx4sqoFK4LpQYKRCoPgb/yWGxZexs=; b=A8QgW9eblC9sjzIBKsN7f/CuCA5Ad1jsahrHYsUr0WbpEkhd16Vl+5jkr5+M9RbFkG ArMM6kYr2eycQTHEh17Zj25huKkrSpwxBeMhhEWmMLIq2v8t+bMsmDHy72OK4i5JaQ4f MmTIuyFWHUmFCr6gIHJqTl3wT+98ZMw6mEIA6oSVDzwjoEQdcTfifihuDUI6rr+YE+l8 uWtIz+6xVC41BhY0mQot5QVioIbZf8qrDCo5Cm92htGtRkEQNnDdzwYACPTH2vEfcE4C shgWeXwgMdCwlk0oydCJJysrfHYxYAcR2iPfddAJn9m3P30ErVkn6Sz+3cO8TiHAfPLW pVgA== X-Gm-Message-State: AN3rC/517NUsa9FqYl9SUWpiZCbN3as/T7SyoVRBRptGI+Ns7mOfjEWe gDrCU83twYxokg== X-Received: by 10.80.148.123 with SMTP id q56mr20894305eda.58.1493663848919; Mon, 01 May 2017 11:37:28 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:9d8e:1399:5d1e:e878]) by smtp.gmail.com with ESMTPSA id z34sm4999306edz.57.2017.05.01.11.37.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2017 11:37:28 -0700 (PDT) Date: Mon, 1 May 2017 20:37:27 +0200 From: Job Snijders To: Robert Raszuk Cc: Randy Bush , idr wg Message-ID: <20170501183727.axqmnxdomwc5ti3e@hanna.meerval.net> References: 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: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 18:40:37 -0000 On Sat, Apr 29, 2017 at 05:20:25AM -0400, Robert Raszuk wrote: > > but vendors should do their best to ameliorate the risks with loud > > warnings. > > Indeed ... > > There is also proposed option to significantly reduce the risk by > changing this default only to protect from becomig an accidental > transit I suggested in this thread already. > > It is simple to implement by vendors, does not require any protocol > change and does not affect in any way stub guys which today advertise > their PI prefix out and get default in. draft-ietf-grow-bgp-reject is just as simple (or as hard) to implement. More to this point of allowing ^$ and nothing else, it does not help against origin-washing (EBGP->IGP->EBGP), and it does not provide for a consistent experience like the current proposals do. I would also like to note that while some people may have just their supernets in BGP, others might have hundreds of thousands of /32s for VMs. There is no justification as to why it is more desirable to make it easy for someone to spill their internal guts rather then project them. The very same arguments apply for both the 'dont accidentally become transit' as 'dont accidentally announce things you didnt explicitly want to announce'. There is no new argument here. You can keep mangling the bgp-reject idea, but in the end we do not know what all use-cases are, so we cannot accomodate one and not the other, therefore the only logical outcome is that you ensure that in all cases there is consistent and safe behavior. > Which btw they must already explicitely enumerate either in "network" > statement or "route/prefix-map" during redistribution. Why to enforce > same thing to be configured multiple times in your config ? That is > always error prone. Yes, the platform you are referring to has more then one pitfall. Please talk to your vendor's account manager to help build a case for this enhancement request. Kind regards, Job From nobody Tue May 2 10:34:17 2017 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 6F4F3129BC5; Tue, 2 May 2017 10:34:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149374644940.21544.9116260419599244091@ietfa.amsl.com> Date: Tue, 02 May 2017 10:34:09 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:34:09 -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 : Notification Message support for BGP Graceful Restart Authors : Keyur Patel Rex Fernando John Scudder Jeff Haas Filename : draft-ietf-idr-bgp-gr-notification-11.txt Pages : 7 Date : 2017-05-02 Abstract: The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message or the Hold Time expires. This document also defines a new BGP NOTIFICATION Cease Error subcode whose effect is to request a full session restart instead of a Graceful Restart. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-11 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-gr-notification-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-gr-notification-11 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 May 2 10:38:58 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0278D1294CE for ; Tue, 2 May 2017 10:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cJS76KLW9hr for ; Tue, 2 May 2017 10:38:55 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0098.outbound.protection.outlook.com [104.47.36.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 AD5DD12EB87 for ; Tue, 2 May 2017 10:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rcBGQOfctvotoxX1Z60EwUJH4IS/YaLGuL0YuxMY41c=; b=XSb4WhsL59izDiK3jOPy6/6e8ie3GXBVkdeD4HHRomaMgPl5zHFgVrGi/7rEiYny1doDIU1lkPrpcajLu+8+wiBDpIK0SViPK38Uw6gC53LFz0aW9kpKxEoZ/9eP0O2Vg0eaKfnjT9NAWGJfmFTcVbalgBQtnHWZNP9jIHs1dBs= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.38.145] (66.129.241.14) by SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Tue, 2 May 2017 17:35:17 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Date: Tue, 2 May 2017 13:35:13 -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.14] X-ClientProxiedBy: BN6PR12CA0018.namprd12.prod.outlook.com (10.168.222.28) To SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 94f77448-7fac-4b91-1acd-08d491819987 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:SN2PR05MB2509; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 3:825GB8n6dktypYgmasqm2GEPXPKSSz1/+JnHTCIjdcBig7mCrqPDRo3h1umUgA4Kuzez9q4fZr6k1po150YHBBOU70v0KeFdj0Jmo3r7gd4G3IrMksdzL8seFQzsoDL6NuzzqxVBdmVX3vHcTw58+93drzX3rplIrPyJtzb/HNLMY5DDi//W5aGC58tqfiqJA25iAC1ZUYS1J2CnE8QKn6u83D63xv7R9eE6y124rgOZv3umiVo4jeYytGu1Tqh/2OVJrrULIDbT8mZVSJ9YUy727gv2Q38mmcmzO/i6Rq7LwobmO4JSFFO7VMmqc9vKy7B3/AIIXWWuawQtFp8dwuwFTlyHzb+LPUzk2JeIRTs=; 25:ilaMhTy+47IJv7JRJANSx9sIRgB9EGB475FGCQxsAc4bWKQhxSvjvA4qgptpSKpVnp9tMIAH8/cvi/6/nMw3HCNYAMQOUzX6Wy8WjCj3japTIHGSgd7298jQytQ+lZEd5++OW3XgysGXBCANQrBURwbvnxZ1RMdn2FsC6vsdl6TyZ6ELJOvMlAozmuhb5jLZc2ixMjHMCpM/nOWQTOg/3zzJXUUaG6ydvDNwRy9RFboryhDO1KQXd5VruIVktR/+oJ6V1VIsQY4X7B9n87bH1PPH5RsGeL1j4/UThCLdFx/XBjfWNEbS/yXLMlw6cR8b0oPu5LNBZ8MrNg0gQqYXzy9W8TwkI9FEAdQpGipn9wQBb3hX3hsRSYlkKKnKXoX45ftPzd1S5SUPr8NWOXF4DIBUNLKZBGP+eITn602Z3zA/RXD7lBPZ/3KHGvV3UW0WzJPXe5SH28qNV42zfNQoP1lcouz+NyJHQJPHojZjdEA= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 31:xqZsAbLGnEMgOzqY2q9rY8+/nbwPeCvhaR6PRYUeblPQ/gyaCDMaqZkm2p8fzQftWrhjnH8UfP6Hb2iKXMcmwVdA0WV4ol4yumYrTjuMHUZQ3rHEcn4qmDpZ/qGkjCJs80b6lbTjjIGV5NSah+LaaYuvUSrIpDG4FAhDatHMvH3jCvyZLD/gJpDBVaTvZ7rsZL748nZXqs6fchAsY2Y5lGJDuu9GreeN3LO9WgmgSMayRB3ch2mzmpt6oMrZ8cFKhQCQ7tqWdDMCZrqhanTAZg==; 20:cf5X76UzYxLLg3JUY/CxwwS4gUBkmJTWd4enkTr/p2+59r/8gHHwalOgK6rvn9CuxgE6aevna5miWrLsCMZ74TQXhap0Rl/LLEk8X71Oq4r2+C4xkErYIqPyTE4VrpkZIptmCHswFDUnfX5/q4I6ECZSplmJn4Fo++GUDt7HgMvPkRSirJ63T2QL5hZ3jtP8HGZ1BRe89YO8VP40F04lCYcZNCepJ23nNHJJx5vNUfcj9SfOV+/JAr9AFyPGg/uXeu474Apc7v9ZT6ULTTpQ76QmUHxpZPuBfCh3Xu0t890GjSRhPUWAJ5bKcL9enDjTVu6UlokiS+31CY94ZVbCOObXjSB+MEqFztX49X7lzIbPqqxY/Hh3sIsx1n8yf8irKfNK3mW4H+zvFwqPbPorOsM6RizyYrwNOSLxj9hlTRMnHoi59WYbNPBa1XjfcQJPCWdy1mWvaY0x3W995yBb6Al5kKns3RC+FrZOxkJtnnVGwFmx4lbQl+vKVDGykHlTZ4qcBz7q3Kz07LEkbrxI6pDiUL7zt4UZYgdKm+sQwjwF2Xh7rHkzkl+anQ7zBsj2FMT2nqqDRec9DbiE4uI1nDCxussWFj6GujOLOYfockQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(1591387915157); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:SN2PR05MB2509; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2509; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 4:Y9oi2xbLE6vZZ/f50WtoH1jXskHQOWktUhURt8ewUHzEc7HNlPC6mGjv1sXAVeisnMBhor4Gd0V6Ogq/Ow9em5yJP9VSwU6JRfiPOWktSBJDmv7DZixxVmUqH+96j6x3sxMwJbcAfUoJlAB17pRtS9/djhTF3QiLgn6o5L+rGWiqXQlKS8Xpn9kPWGpD6E2aKdaNgcwqDIQNIqRfh7EqImqbpqke3vNa83OtDbbxtoyEagCdIrtuwjLgSGwoHrA6/vtJgxPKz/79HdzRcOvJHkr+Dzxk6UZCoZ5rGrYD5PCg90nP5ygQD3N6lWomkiWXKcBYr8NUeC75lrk3d4UZh0NCBmDI63s45pTSt7lO5jkEkzKW89vfNTixqWw2BezyXESBbf4NPzgfO91WtIZ0zRmKkc2GovuZTOVSV/SqE1FtDGkgdPlCdrRR6F24QPKx8TcQ5F6Z79rOmFw5wZ0lYb1OZAGgbHvfVrXLEJhbzC6lWrBt9C0Rl/z2Dj9g/KtcEhTmHANqUQ5ifVI7S9gbQggxl/U4kj3wJceyuyd+7QMtRjo3WCtywbiSnDUFE+0NiQWY42FsQB1Z5f+rOLAV7X9GEVpk3BoUXS74IXThIYcGnPVK7CQqP5MKPhng0rdKn1+1vYLJg5eKTRboozC6044/9RxjhudwnKkTmp4/9hNJZXKbbj/OemXs4s4aplr/4Q7t8L8m7VlSABVgTBmKfThfk2OPooobkp+J3Rkrj7QBnAZPBOZ8Y2sgcS2FyljxuwsIq4It+c7OhNeUtY7xbRtpX2CXQ2GVBc31nxqYbKAAGH7BdO/2xSmJgzvS4iDoVs51AFeb2OjUUtFRCXffVyKJ0kGNcnXO+r6qHbuvzgI= X-Forefront-PRVS: 02951C14DC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39850400002)(39400400002)(39860400002)(39410400002)(39840400002)(39450400003)(53754006)(23726003)(110136004)(38730400002)(36756003)(6306002)(25786009)(7736002)(42186005)(3846002)(6116002)(53936002)(77096006)(6486002)(90366009)(86362001)(15650500001)(478600001)(81166006)(2906002)(558084003)(97756001)(50986999)(8676002)(189998001)(230783001)(6916009)(50466002)(5660300001)(8746002)(46406003)(57306001)(305945005)(6666003)(47776003)(50226002)(2351001)(66066001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2509; H:[172.29.38.145]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 23:tcenSU6Q+GXdfcv3Oo6o+QFk4VWnU7ljIE4u2Yvy8?= =?us-ascii?Q?Z7DLn0ZcqdFvuqtyXT93FJKZSoqs3JPRcxObRixFARq3NQQBTnpp8qUP8BTe?= =?us-ascii?Q?/a9k7HlmltXQTtc9SKUyhyFLm/zdacZeMzBS/TS3n/QPyMfA+TghgeIEG6So?= =?us-ascii?Q?yrBtJpEC4Gb7ypnUHRUQYEHnIV29Ud7xzo9sGrT2uqoHr53q+D7Ee15JIwcr?= =?us-ascii?Q?fPaMhuvnPdSRJi4q9Flq576Z2LfcAlyg6qOa5MVPEVETUANKb42JtRT8BacX?= =?us-ascii?Q?0WcaFETGT/bTIYA+kfiG6/EbQf/4l25wsaHcl2+hVlwn2CAJVWiNxGevr0Bo?= =?us-ascii?Q?HxqXKbblIvs9FHNaXq+9jENISV/WO5ltcCj+kbdQHmQIlnVmIxemp27HQz6A?= =?us-ascii?Q?cek4KDhRmsTlMhKZYBG1SyFNB/sn2ZQzYh1RFTNuDWpb4CDL+mlmEtc26zp3?= =?us-ascii?Q?s7w8q9LzKjQDZpfOhXkmGRVZRDQTjr/tB5lAnoNxdSz3kTZ41GaMWAO38n8e?= =?us-ascii?Q?UyAWjsj2DfoCrZXTujNDRAnpq1g+iFulQuOATPrGZhTtytIemov8vI6y+O1A?= =?us-ascii?Q?auB1U8LNq5ndPUQPNBl5EQ9d5vrpuqY720i8jPQqxmcfdiGMfHPz85HzVAJr?= =?us-ascii?Q?aymkUFkSTW3TuqezInZfJ0UnUjFx9Q2oK4EPNr9RtosP6g5fkHOhbIDME9xZ?= =?us-ascii?Q?B2reEnRoKfd53T+JpSuKzQhHYrXfCPgxQktbZhNafgIIj1EVhRtoIP5i43iu?= =?us-ascii?Q?IfxNMbZwkafYP+Eg4xyVGqSOO9DUmPSit2kOfCsbykrKpIvHnA/8apGifJSz?= =?us-ascii?Q?7icuv7htwlBth9Zx5qzlUb9FcFJk5keHgBHB19vTt0fuAoPG+9W+SpmI30dF?= =?us-ascii?Q?W8Dxgoq6TCjtX2qthvX5ud9T4iu23vfUAdezBLKb2pWywtO11j9j6OyJ0YGC?= =?us-ascii?Q?UajJs890RHrQaIIN4tB3JGnwn4A5QwXR5P2mBfN1yghy8Orqttk9hRda7Fbx?= =?us-ascii?Q?iCKVVAyCqBbY3anLMOOx+wuFfTCvq//7FVLHM7Rj4gIv+OoAutagEl86FZkk?= =?us-ascii?Q?TdbFCQCWyEGuj50Nh9MvanXzhakw1j89yUgPElGeEEUNg5vrCkvROqas19pI?= =?us-ascii?Q?C5e6F3NLWmCtiiS8sJH0BfxKrz5QDFQAcccQObw+dITesXYGiLnjYNDY2CSl?= =?us-ascii?Q?v6A9HlpOYRKJ6k+dnSMPzwZd0cQbw4urNVm?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 6:ZCv8oqR/BzyOZC7lTVuBiH2QfnOHSkDPDp8/69+Wmp7EAuYU0f3m2DT21EZ+IzOOTpWsZwtRhJ/gXKe/kdu+w8CZACmNizFgXetv8sjENOnGj8WyCVJcxYeZh+HQBdmjRFnFCRuwzLiaE+zv/P0lpYVVuo3KUUZZ1OdhxmvrOYGGhEjlcMxfVGkHds5+k9m1MpXoR+3kwYFTg5u4TJ+2Ef//jU/Hh6+5JVQtVEeL2ou5oxbXm51L2/EkVjZTFEE91txx19KpiPNloJJJeVV9y0ee2LUibQpvYKxQ2F1bIl6xzbCo4vUgI0EoM9ujYTvt4hbu4mYL/OnE/GbAurmRqF6o8lQGe5QSSTG9eGk3ZCfhW5i1zB//kISUIN+VamrLm48/+fR1R22nJPfTCXIgPtwXokK1NzDQAfJljMJkKpjCJ6779V3T2Qkp1WEE0oEtxNrFgI1subkYRP1WFKiGGDvly2TgwOoVxB9piKKPeDAn/mmU5+tThlPeAxMyHvy9OU6jeA65+TJuKSKBIUQExm1aooptXvrHpxLJkfu03wA=; 5:cNC/8Gx4iSXgBGLLKt+Ns7DQTEb7mbpZpqyO3m2wXAp6fdOXfYCj1UL96KHIx1PWOQ1JW96t3II5W5eHHj/Mfy/NAOndMP0x26kBkHr9FPdnIP84vV3qbk6o8E74TQTj2Y9XF4I/heUuTyNMhSZxKQ==; 24:5AuGdKnjD3PP/lF9DkHtFowlYzBh9HA47q/FoaObGi/TT5SkB0595oJBcnwxvGJG+LF3Uhotg/Ny86BOCiMbwT7NLg2e+CHLph9R0xYgU7g= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 7:1vg2UosHg6pdqcCC2tLuzLE0WuolMF8GQbeRiQaPRzeuyG+5ag0J9ptqZXSOtQ7ZMZ19A3m30z2JiNLlDSGtnufEWSM2yNAcgWjE7tOBZanDK6VPorGQOkdJRksi1AioFStF0yeHzVBdPuyFISATMq1S04daeZMcDjkTjmn/WFOCXPCY/XkqLZit5kblX+UFOXHAXcTZ6ndmwr8D/45xk4nc20NuJ3ABanMzjwWif6iZdT7uFaMDgIcGlZxcWbtofRJWJBPZdgPQjerbieV1j6aICPmR3I7rWJrNu1831ae5PvzaboLdDNJ98gEV3qTAFVAvutsykb1skBs5X5CVGQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2017 17:35:17.6017 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2509 Archived-At: Subject: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification -- completed X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:38:57 -0000 Hi All, IANA has done the early allocation for the Hard Reset subcode. See = https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-p= arameters-8 I've posted an update to the draft, revising the IANA section to reflect = the temporary allocation. Thanks, --John= From nobody Wed May 3 11:32:59 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B223D129AD0; Wed, 3 May 2017 11:32:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 htzQqNpIleYf; Wed, 3 May 2017 11:32:42 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 903F6128A32; Wed, 3 May 2017 11:30:44 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id l9so114879092wre.1; Wed, 03 May 2017 11:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=9at8Wy1mrGRMGzfIyPfoE2Jv0IsVO+1nG196ji+ZiIU=; b=BYdr4CCCNOZ9vpcQJ40SOkElakivHWbhwEwwTzjGwiiCj0Srwl2wOQC7plz85M1pVX xifIUna+lO2sdPtM1pkk4B0F5a7AfOGX3oW4q+Q8qGGnIVIrZjY6T6GbOUMUHz/c2lWe suk4CSQ4ncXt45KIA/5fvdztgOaVkUwOM7j2PFnFx4uMADQrZbpypOt96CoIk3NmX1MS G7PF7cYQTZLfGS7ilwD7u6opuNTCHWP2qOfC7rpf9fiUZfOUyyU6hilO+v33umTqUOQp FxGnLvckAP+ilwUemBfnOhcA3Ce1v8b5Gj431oKohQ2LxMKD+2C92l/V0PqWj9QJw5m8 g6dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=9at8Wy1mrGRMGzfIyPfoE2Jv0IsVO+1nG196ji+ZiIU=; b=k9oQeq9iK38JtMuhK+JPefRH75c9hDCihJMYqbSmjHOJqaBaBzlCOT/PO8EQZAWbYR BEI9Gj9tgFNJqtQbT9o/kKqcEYZtaCYxNePEUKapiLQuGjypTTcDCsnM69zx3F/baiJ+ dPzrMcOqR2G4F4gH4HCKiun+u0eL8I8wKeE0kUXoGDEqLvilaNRuOjlUB1GMSkMVEBXr tfckobVEiB3go3tw2Fk2ZduoaSe4PLt8402swT8t7qDVXUy41Q2mNzJqyxxSpXCkMUOQ 59gn9OPog+ltjkkO+6uC3VeyEUq8FwvBA3arNQPwbaJ9oKW8bhI91AaB+zTd9+3iVuZl CW7w== X-Gm-Message-State: AN3rC/73P92zYKahrWp5QQMMQqXbgBdZkCA1+yT1gme2SmG2tXMNJy0R l9h0aIhEP7dtq+TXtqabg5PEPcQSYo/g X-Received: by 10.223.150.74 with SMTP id c10mr24975963wra.85.1493836242944; Wed, 03 May 2017 11:30:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.86 with HTTP; Wed, 3 May 2017 11:30:42 -0700 (PDT) In-Reply-To: <149383397646.4894.14546129703556603533.idtracker@ietfa.amsl.com> References: <149383397646.4894.14546129703556603533.idtracker@ietfa.amsl.com> From: Alia Atlas Date: Wed, 3 May 2017 14:30:42 -0400 Message-ID: To: OSPF List , "rtgwg@ietf.org" , "idr@ietf. org" Content-Type: multipart/alternative; boundary=001a113c0e869d0909054ea2da46 Archived-At: Subject: [Idr] Fwd: Last Call: (Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:32:45 -0000 --001a113c0e869d0909054ea2da46 Content-Type: text/plain; charset=UTF-8 Dear RTGWG, OSPF WG & IDR WG, I'd like to bring this IETF Last Call to your attention. The method for advertising L2 bundle information via IS-IS described in this draft may be of interest for other protocols (OSPF, BGP-LS) that may use it as precedent for how to advertise such information if there is need in the future and consistency is desired at that point. Regards, Alia ---------- Forwarded message ---------- From: The IESG Date: Wed, May 3, 2017 at 1:52 PM Subject: Last Call: (Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard To: IETF-Announce Cc: hannes@gredler.at, isis-chairs@ietf.org, isis-wg@ietf.org, draft-ietf-isis-l2bundles@ietf.org, akatlas@gmail.com The IESG has received a request from the IS-IS for IP Internets WG (isis) to consider the following document: - 'Advertising L2 Bundle Member Link Attributes in IS-IS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-05-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links which comprise the Layer 2 interface bundle link attribute information about the bundle members is required. This document introduces the ability for IS-IS to advertise the link attributes of layer 2 (L2) bundle members. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-isis-l2bundles/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-isis-l2bundles/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2793/ --001a113c0e869d0909054ea2da46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear RTGWG, OSPF WG & IDR WG,

I'd like to bring this IETF Last Call to your attention.=C2=A0 Th= e method for advertising
L2 bundle information via IS-IS describe= d in this draft may be of interest for other
protocols (OSPF, =C2= =A0BGP-LS) that may use it as precedent for how to advertise
such= information if there is need in the future and consistency is desired at t= hat point.

Regards,
Alia

<= /div>
---------- Forwarded message ----------=
From: The IESG <= iesg-secretary@ietf.org><= /span>
Date: Wed, May 3, 2017 at 1:52 PM
Subject: Last Call: <draf= t-ietf-isis-l2bundles-04.txt> (Advertising L2 Bundle Member Link Attribu= tes in IS-IS) to Proposed Standard
To: IETF-Announce <ietf-announce@ietf.org>
Cc: hannes@gredler.at, isis-chairs@ietf.org, isis-wg@ietf.org, draft-ietf-isis-l2bundles@ietf.org, akatlas@gmail.com



The IESG has received a request from the IS-IS for IP Internets WG (isis) to consider the following document:
- 'Advertising L2 Bundle Member Link Attributes in IS-IS'
=C2=A0 <draft-ietf-isis-l2bundles-04.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-05= -17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In eith= er case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0There are deployments where the Layer 3 interface on which IS-= IS
=C2=A0 =C2=A0operates is a Layer 2 interface bundle.=C2=A0 Existing IS-IS =C2=A0 =C2=A0advertisements only support advertising link attributes of the= Layer
=C2=A0 =C2=A03 interface.=C2=A0 If entities external to IS-IS wish to contr= ol traffic
=C2=A0 =C2=A0flows on the individual physical links which comprise the Laye= r 2
=C2=A0 =C2=A0interface bundle link attribute information about the bundle m= embers
=C2=A0 =C2=A0is required.

=C2=A0 =C2=A0This document introduces the ability for IS-IS to advertise th= e link
=C2=A0 =C2=A0attributes of layer 2 (L2) bundle members.





The file can be obtained via
https://datatracker.ietf.org/doc/dra= ft-ietf-isis-l2bundles/

IESG discussion can be tracked via
https://datatracker.ietf.org/= doc/draft-ietf-isis-l2bundles/ballot/

The following IPR Declarations may be related to this I-D:

=C2=A0 =C2=A0https://datatracker.ietf.org/ipr/2793/





--001a113c0e869d0909054ea2da46-- From nobody Thu May 4 15:41:21 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572A5129478 for ; Thu, 4 May 2017 15:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-vPqBKZK53j for ; Thu, 4 May 2017 15:41:17 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0133.outbound.protection.outlook.com [104.47.38.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A1D128B38 for ; Thu, 4 May 2017 15:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CWmhzWwlqSB5xngSghckFarzfghYkXz8MSKiCuHNmzw=; b=g9ATEXX7F0Y1lcVgCQFZxluH+sdTQEGDdY2JU6xIY3NReU3YxVU0ss1Q3ze5GVABpn3j03mm/IAP2L4+dWsz23WjllT+WQg9BDGfrzHLkyRc4rHwiFHszBp74xvGEuG25fiT5weEzQsKtW50IDtJXsbjl5/812OIZ75fwmdE57g= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.38.145] (66.129.241.14) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Thu, 4 May 2017 22:41:13 +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: Date: Thu, 4 May 2017 18:41:07 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <81424CC3-C4B0-487E-BF56-0113CA637239@juniper.net> References: To: X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BN6PR11CA0035.namprd11.prod.outlook.com (10.173.25.21) To CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9f2331b7-fb39-40e9-ca18-08d4933eab3a X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR05MB2506; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 3:yL7Vn+PiR3mHmLc5aK2MHZSK+WD0abn1wVeYyK2ecuApObGz34EwSLfUlJBrvU0MKW35eQmk9P4DnaiMQdUS1O3s5gW4DcnzwCfBxjk2WOqemUY/ng8fLIPV+UBacawDk4VdzV+T0UjMIuHz/Q9fMrbmqAtP367Nu5VI4cpL7q94fwyTLNXeGyA8W26dgs2fSmosBODmYfebbNIY8GCm6bLUhg/n+KfOs45RIctEzI5Jks7eK7j3sSQprYu4ewgD6gpEMjnVv4Jezim413IyEWOmtud+M2hejwYdc0GoRVgBa2miCoZ1AxfU+jcb+Ym2DJyh4pHVGrwaPjlvskmEHz7t6jfU8SiHKOadt/LlvCc=; 25:qW4xSlSQzvux9+jhsnI/pEVMUc/pyaBU1n57Bq34X52bbHMgoA/lUl9HMNKk/rzww3yeS1mQm1KkpN1LwKv4dXgcWQR4kYayv4vtNiKgupvSA6nM0vzFPNSeq/eumEuGfmFiK6wdcGzrUIyMKIIXRPGOb4mVl/wkqVYJW0uGbq5S51SfD2bQWMMduAFLrwMbjI/4Fij9LSRBy23D4sVdXqdk7y5qChhkjg1T/OB0IPryf9OaMmxXjqr/GWcdvOM96AJZvr63TQcp7a4j6oJs+Wyv03M3IRyNZcj6+XdhEsYJwcGxH5zpv5oKCcLI8SoTy14X/PHMHyV0RSZ7tjs9GLFlbM11FQ+YIrBX7X7Ekmnk0GJHU4vsGA9EUYGHGfk5u/mert80HicE3vZyARg0oGtKrIEE2hbcGy63eJBXl4IImXH46Obpk+pPSgT4ApDL2T4nIadJ3rnTZUGC7bhHDPFGSKtexIdV6P9leLwcvgI= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 31:jyx3ogqCcmVxm3aKvqbfarTrbDGcet/pxJsFeDqPB0FomGDF0o2nAUalwhyhTdfldmjFQYznSHYsst+fluYm75FQ+iGdKGiS0q7oz2982XN1o1cztbIvOn+qREc+t0LHAynN2BbeQJ8BxNU+DR2IFrkr7AMle9ao+YlU6zipoFzYHwbR7RhbFm1Py2KWrWxVArbkG6T8OvWjy3BQGOxJHMgBX2dw3hOCG7OlVhmsgxTZNHAvqo5eb7Acp094kN5TqYoqg3dlhlfuGsZMMBMPGWxG3N7N3dw6yhv8dYzdfyg=; 20:qL1MhsOq+hd/7kHQyillTv41w1T8rIG1CJaGRDsrR0+wkFvnGxOadDziOlw83/h9CFtpetqfwiDw5zUPy7W2y5DLRhQRaGNpva7PBB/dZsjo8hxpQu8e00Mq4VX+pYZV9X7F3WVjUDKTx3RLnuzl1k7p9SPiW5Y5tcYnXQtLyupq8AcjWMAfcYjYxtKfzRsIkeLD/wGhgWLgVQJSNeFxTUfIB76OgDIoSmTyH8ttYNF5rGNxI5R7GIG/XRz6Jy3wJRGYhLyjkJaX6lH3/3j5K5W79BV2W5KFroFj0NEhEZR2ovAjUp+xuBXfc38q1mkcvMmsnPlj8vxZ+IjlaMW0++YzFffKuHp04r/OdbRcgKJeuuspQSB2ClzxOyLI4MY0dXBILbq8FmbUgW3hreGzB0UjcHA+TonHbiOCK5lYA/n1I2h5xjkui+emOHMRdQt0rgKp3hTZuwKKyhMXusi3J4HmaWHiztZPoxiacX7gOzov1r7AymWribB8MJALKg2qOXbBqX+lW911oMfEGUCUAaOgq3iDeOaCIwkH4ss4phol2fhmsz42HkO+dEcnBBB4g+Km984rDYKzKD7hdtd1wereTE4TfWlJL2VtbVsgTR4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(192374486261705)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(6072148); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2506; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 4:gOjUC4lFtzYykzVdZr0wyv3ZgOdhld1/R6+LYfVqAJLYzKgGQHXTsYIKeFZQuPosZmHgl1+vaCSNXWbyg9K14OlTdjq7/h+3OT0JIGzm1uXCANF5UlpzWbwzZjvdYEP4CoOHAh6Ju9q33cDpkXDDoG5vRuFy6wSOW9gw5T8faGIonpGHCdZon4u231m4WJx4fxxtYstcLluZNTL2QXKAOCGD1pipOfhFABWRz42MEEGAxP+SRFPkKlwgiDlRVCsdRrNoofgjOZ+43tL31ZgnTL/0DhW33TJZxMX03v/0QzoT+bKv3n9ZERndKDHwlMqL8aJAqp5XXV+Bac432IzQ1nCO04lRu/jaKaVt9OCUevmKiPle9Vw5BfyQxoF3lG8xKCb4H0DN+NfV10AaUg5yPsOqQzyxcnRyklXhgki81hAqTTH2Ya3SlDzlp8YJp8Fo19Q8Rbq7Y14l5f+K7j64BRaEMlC6PhrMjvTP+FEFoZM342E6tNVwdTVsG7AoT8IePO/cqRcds5gZRE/cvZPvCvhSfBACkFIhjVcztbNQp+92/E2ofGGV4Zx+GwC1+rbnT2XJSQeQb6bcqnM0pazDP0Fo2M3n4e54zVWhvfCZ+SjYbqWZ7FQZul6i0V6rCKVaap6fUt5dCMFa3j1blw3AlQsN5/PQJb03PzWF8X/v+GWgs2EilnKJiHpyyOH+SEgxAraG+9h8pZvs4rOHHyT3kTOKycZRVb52xWI279BKv3PYIOm1e2PlDHZ0atmmH+VOgiXZxgEmi0d4IUNSp0RSEelwF+nrBjqDHHQ/0dWxj8kouo8fhPs6Qo0vZvn8R4BTQK07Ejw+c5zZFj8+vKsrcHLoqpgMft5wquKRay4mmURn4qVpSYgA3Ez9PxkIxAmPCw1v3Pdo8M+nZPN1Itmu4pYzSoKVrsDg23iwUXiJCk4= X-Forefront-PRVS: 02973C87BC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(39450400003)(39850400002)(39860400002)(39400400002)(39410400002)(39840400002)(69234005)(53754006)(86362001)(6246003)(5660300001)(42186005)(66066001)(33656002)(6916009)(46406003)(2906002)(6666003)(2950100002)(8676002)(50466002)(8746002)(97756001)(81166006)(2351001)(38730400002)(50986999)(478600001)(76176999)(50226002)(189998001)(3846002)(6116002)(110136004)(77096006)(36756003)(305945005)(6486002)(83716003)(229853002)(47776003)(82746002)(53936002)(230783001)(7736002)(561944003)(25786009)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:[172.29.38.145]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2506; 23:QUQMfiCC5XDuIXYsunbmT/PLLNdJLBUk/2l7661F9?= =?us-ascii?Q?ET8/AxydzrdOZkSlG3yEhs0nOK+nbuclAeKNB8+rkh2e7cdW5CQq6pA5RIZ+?= =?us-ascii?Q?ovFACbTEnsTg+W9VNWqJNw8NvWfbH2gh/1lKohohzHOzsBMGQrdw8s9uqDxK?= =?us-ascii?Q?xzusQFpes2aK7FhveVzmGqAMC44ycyXcWf9p3+0rgDtmqHdkXFWdSpgxqVFk?= =?us-ascii?Q?FHUQXntPd69xNncx14XuoBJBbckjKrTbk5/0LWHRobU8IXElQa2Z9BRzJzvo?= =?us-ascii?Q?R7we4bDhyLzjJ37xOVuGypcvWfV5U7C17w4KM2H43BQFHZLrq8en7Yo1N150?= =?us-ascii?Q?1mVWZojLVRKrcdbs2tRlrS239CoCCdQjE+BFMmEAFMOBgbIHyJNfSDNLVaK9?= =?us-ascii?Q?tgWy08O+2wTvS2vDC1BE3ZHwKnl3d40krZ+uKlCkb5s3UvQPgn2cMm2c+z8V?= =?us-ascii?Q?fExrlQDY4b+djKtwbamFVOKiizDygT0Ag2TtqjLwXdPknFIhag/fBnfP52Ro?= =?us-ascii?Q?Cpk+UEe3PfJEBWEeZJjdFeqcpwmtFmtcfwU7jO4PaHB3jUgLyUSbcNMrQGpX?= =?us-ascii?Q?O2T6z5QfpmqMOH6ar80czdxXLcLbVi3vTv1+5+Jjf6l5S8h9nZc2+C6REAlb?= =?us-ascii?Q?JYIionLEtW6rTwFR8NOKyKnXP7Vn96jnUq8dKzPF47i9cwxOKRHCvcNVE6qs?= =?us-ascii?Q?vHP/vjo9J6D+UAp0XlOHgmNIbf+ul7ReCS0HUq7VMS1MzJmh84eygitmigTr?= =?us-ascii?Q?HnW4jBdDl0TgqYxkBVSRu7onHbS4cPsykNsjQTxaRs7OR3qmMs8IsP5hYnPT?= =?us-ascii?Q?M9QNL0yAWeol7oCwOSY5zU0thFWjFrfMlYvuEdiVNVZjBlVFd8i8ij63HOJu?= =?us-ascii?Q?MPhnn6u7jzQkqfKOCYS2fmM6/5piIepvr3BtcrgE4bNG0jZTIpp03Ndva6cS?= =?us-ascii?Q?RmntcsNRETL36x1rnVqpXJNiKi2SIg2avMcEZLPzS+KNZlJqC0/DZYCYRDB9?= =?us-ascii?Q?6xiTKD+kchGxm316vbr91F3u9XLBNuJ5cjTgD1guLs6QKIBWSNI9Aww4MVv4?= =?us-ascii?Q?yk/i7YawNP9P0S7fNnlwqEg2qQUvj2pzUSeUldeixW5YljuXgsunVv1nblna?= =?us-ascii?Q?cn+n0rD6uhm23OWgl/PwAJU1oLF840soXkuIEJWKZJccg1aekp3Z7NOcd/zl?= =?us-ascii?Q?YVcSyqMfAXG8s34FRib+9R9nobsqZDGoWGR62tKV4sT80ySeZRFQSbGNTfaf?= =?us-ascii?Q?tPbFRhWC7O09PqCWWc=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 6:OKlLimU1iuL7/1TGZ2sw3Ah7ASdvm7CNu/C20O9vj+aZ3aI9xlATM1exeQfAVsOcNKUzK/pQO6zoNvlYpOfzOzaC/XGGBsjXCTwUz+hmsppfU3/nbjI830NeVhHe2Hqn88rZBwAxQG2r39eohjnjiVSXrUuOzQhEv1W47AwQjuOuwfJ59E0vTY0GqciuUgpYWMnQVnDKD4QlhKGOAKOvI+85WBF1ulN6zWI8048AEw4ecl82dRJZBaVLiQsC/u+wm/IT+auAmS+s7uC1yhSZTV3zH4sIXtcXbbpUc969gYpQN4h2qkyyYjGR6L9gyFzFCD9J/D2Bchq7/F0LMHP/5gc7Z1NQk1xF2rMNCg+mHEcUwK3UB1mWQeyR2KFw9Lj/KwJf1LpoHzPpGi4tmrBjVVm5Sg9gG3WlPiQM7D5lZ009UZosJmej0zhWYfshSr3bmj/+lgU/xJPfD6iRuPjD4FmmvLvdp6knTVnjSL50kQUTmCKh2xveuQEL8NT27P0yMvWkMJO6OF2MLwgYTvyuogf3EBPbxHlzGn32gsenKQ4=; 5:uq7xjvsSWV7dSYEfjAa9dwoN+TA23jBfEpNFGw9+HtzoJ2diTv6+rU5vmUyLxr3fxpCGf9un/El7WW6nLrfiwlV1e8vYcDgpttNaKC8cJH1WG1mIVsJVGLTjnkHNaXPNg0+/xBYtpKi1dwh8ABfA4g==; 24:oQXfgmRz0FI7414ZoW88B/FVS8tXV57olMCaHDbo/S6RvGfxWqUvAyBOiD7k58RppGrCeDFuu6L9fDTIahTQg5vPZebRCWvFdDhL9eE6Tjk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 7:bn66bGhILLskzhY/LSZuflsBLjMCHhAtoih2AetZTVyH5NGAs4Td77JTT3RLodsF9WdxD5qMSj35Y8Kwteq43NXP4wDxjfugZpZdBGPjAaB4fGmmYnC6lGbQtSixjeZoIA2kaInkaDFctMsqSvb2BOUJmRz2SqV2s6YV7GveTqqBI6kb+Hi4T5nvwjwqB1/L5pW5/iuvlMWrpIzBrp5eKW9OPAnjUj/af/qgN9YS1G8eTc30+nq1nRl7wr+ARUOxlyaEVMG2FB+yxxgELhUJ4h2W3UL95eM0VAAELjHdGSaeHqiZI+cEEyyKjFuf3+mulMcCxWllQniSMqnCNz9rxw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2017 22:41:13.1500 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506 Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 22:41:19 -0000 Hi All, Below is my summary of this mail thread, FYI. As I understand it the next steps will be for the GROW AD (Warren) in = consultation with the GROW chairs (Pete and Chris) to decide. Thanks to all for your participation. --John The thread "[Idr] IETF LC for IDR-ish document = (Default EBGP Route Propagation = Behavior Without Policies) to Proposed Standard" started on April 19 and = by May 1 had accumulated well over a hundred messages from 27 or so = contributors. The thread defies a simple declaration of "there was consensus". = However, and somewhat to my surprise, after reading back through the = history and trying to give special attention to issues opened but = subsequently rebutted, I think we do have consensus supporting = advancement.=20 There was quite a bit of discussion about the intended status of the = document -- Standards Track vs. Informational vs. BCP, Updates 4271 or = not. In the end, I think the best we can really say is that there was no = consensus to choose something other than what the doc currently says. = I've counted those who had document status objections under "con". If it were up to me to call consensus (which it is not) I would say = there is rough consensus to advance the document on the Standards Track, = updating 4271. I might consider offering a few extra days of LC for = editorial comments *only*, with discussion of the document status and = general outline and features of the solution being placed explicitly out = of scope. This is because there were, interspersed among the many other = comments, a few editorial ones, and I just don't have the energy to = figure out if they were all taken in (although I think the authors have = been fairly diligent about this). It's also because the most recent = versions of the document have some fairly significant changes compared = to -05.=20 Several issues were raised and discussed as part of the thread, = including (but not limited to, I'm under no illusions that I've captured = or even fairly represented every single point): 1. A number of people, largely from router vendors, expressed concern = that changing defaults is difficult. These ranged from saying it was = impossible, to merely difficult and not worth it. In response to this, = others (including but not limited to other vendor folk) provided = examples for how a default could be changed without invoking a flag day. = Greg Hankins, in particular, provided a detailed explanation of his = company's process. The proponents of "it's hard to change defaults" = didn't follow up to the various rebuttals, so on the balance I would = have to say they're "in the rough". It's a bit dicey to make this call = since failure to follow up can also reflect simple fatigue, but in this = case the conversation doesn't just tail off, it ends with concrete = arguments on the "this can be done" side. 2. Related, there is the position that "yes of course anything can be = done in software but the cost/benefit ratio isn't right". This is = clearly a matter of personal taste so can't be dismissed (or supported) = solely on the basis of logic.=20 3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to = apply only to Internet routing and not other applications? Pro: the motivation section of the document calls out the Internet use = case Con: there's no clear, unambiguous way to actually specify this = (AFI/SAFI 1/1 can be used in a VPN context, e.g.). different defaults = for different AFI/SAFI is confusing for the user and the extra = complexity not required. 4. How about "default no-propagate" rather than "default no-advertise"? Pro: Keeps CE configurations more compact, less surprising behavior. Con: Behavior is actually more surprising (since harder to explain, less = consistent). Doesn't cover all plausible use cases. 5. These defaults will hurt some deployments that want to rely on the = old defaults. Examples, data centers, CEs. Pro: as stated. Con: it seems unlikely anyone is actually relying on default behavior in = their data center, since defaults vary between vendors, can any examples = be brought forward? None offered, instead a couple DC operators stated = support for the draft as written. For CEs, discussion around upgrade = strategies without breaking existing deployments, see #1. 6. This should not update 4271, not be Standards Track, it should be a = BCP, should be Informational, etc. Pro: It's not protocol, but just defaults, doesn't affect state machine, = wire encoding. Con: Plenty of Standards Track documents specify defaults when = considered important to operation of protocol, and even more ephemeral = things such as textual encodings. Pro: It should be a BCP and/or shouldn't update 4271 because it's bad to = make existing implementations nonconformant. Con: Formally, it doesn't work that way. Also, the point is to ask = implementations to change. 7. There are various other proposals to mitigate route leaks and provide = BGP security features. Pro: implied, "we've already got one" Con: some of these are still in flight, not even WG docs. None address = exactly the same issues. Some don't even overlap. 8. Why not just do perfect filtering at the service provider border? = It's an education problem! Pro: perfect filtering prevents harm from route leaks. Con: decades of experience indicate strategies that require perfection = are not successful. Taking a rough head count, here's here I understand people's positions = to have ended up: Commented, no discernible position on advancing the doc -- 2 chris morrow alvaro retana Pro -- 16 john scudder randy bush brian dickson joe provo warren kumari jared mauch job snijders gert doering mik abrahamson jeff haas -- support, though would prefer BCP greg hankins nick hilliard jay borkenhagen ian dickinson martijn schmidt keyur patel Con -- On procedural grounds (should be a BCP, or should be = Informational) -- 3 eric rosen -- would be OK as Informational, opposes other statuses tony przygienda -- it should be a BCP enke chen -- fine if it's a BCP. changing defaults is infeasible ("in = the rough") Con -- In the rough -- 2 acee lindem -- contrary to auto-discovery (rebutted, in the rough), = should have a 'backwards compatibility' section jeff tantsura -- changing defaults "can not be changed". -- in the rough Con -- Other objections, in most cases not explicitly stated as opposing = advancement but that's my reading of their mood -- 4 robert raszuk -- not explicitly, but has raised numerous "but what = about...", all or most replied to alex azimov -- 'it'll just result in empty policy' and 'route leaks are = rare anyway', both later rebutted and not replied (so, "in the rough") tom petch -- not explicitly, but generally skeptical tone to comments. = specifically requested an analysis of what harms the proposal might = cause. (not done or replied to AFAIK) bruno decraene -- would rather improve route-leak draft, numerous other = points and suggestions, mostly replied to, too much to summarize= From nobody Thu May 4 19:05:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7821292C5 for ; Thu, 4 May 2017 19:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 4lZW2xV1Cuen for ; Thu, 4 May 2017 19:05:36 -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 30EB61289B0 for ; Thu, 4 May 2017 19:05:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMH46632; Fri, 05 May 2017 02:05:34 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 5 May 2017 03:05:33 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.200]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 5 May 2017 10:05:26 +0800 From: "Dongjie (Jimmy)" To: "'idr wg'" Thread-Topic: Implementation report for draft-ietf-idr-bgp-gr-notification Thread-Index: AdLFQGSDaxCXAJwZSg6ox4SZcC1Pvg== Date: Fri, 5 May 2017 02:05:25 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9279368DD45@NKGEML515-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C9279368DD45NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.590BDDEE.0190, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.200, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 224d6d73453bcc76d3492fcc64d569b1 Archived-At: Subject: [Idr] Implementation report for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 02:05:37 -0000 --_000_76CD132C3ADEF848BD84D028D243C9279368DD45NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Two implementations of this draft have been reported, and there may be othe= rs. This is a reminder for implementers to report their implementations of = this document. All implementers are invited to fill out the implementation info AND the fe= ature support in the implementation report: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-gr-notification%20im= plementations, Best regards, Jie --_000_76CD132C3ADEF848BD84D028D243C9279368DD45NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Two implementations of this dra= ft have been reported, and there may be others. This is a reminder for impl= ementers to report their implementations of this document.

 

All implementers are invited to= fill out the implementation info AND the feature support in the implementa= tion report:

https= ://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-gr-notification%20impleme= ntations,

 

Best regards,=

Jie

--_000_76CD132C3ADEF848BD84D028D243C9279368DD45NKGEML515MBSchi_-- From nobody Fri May 5 02:34:59 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C035129490 for ; Fri, 5 May 2017 02:34:58 -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 jh-rQu_Eog17 for ; Fri, 5 May 2017 02:34:55 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 17D69127058 for ; Fri, 5 May 2017 02:34:55 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id x188so475553itb.0 for ; Fri, 05 May 2017 02:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=E72W/kKIjXRIHRe+Cu/08ul15JvNWPjPxUaozr5QIjQ=; b=L+8AgENZ7yJrPbl9R2NuTJVZZMWLgqLztIDCvyzzL07L9EIE6iEXBm6qaIOqYKxHMU QJnQ9cg0A8SFMTjOIfCNakIA2tYiLqTiXbO79Q9VX/UlAnFVcqw1SXb5QUNLgXquAnpo AlPSGsptRdjI5SftzeCylrSlyhGjI9gYgLEJiYKxauwiAEJtzyCNwLleEbuH0hlLqsbn sGdvPq61dIPE57VGYDtnPGS44Aw5qQr2SbKLNFAJoeAyFWVLIvOOc9U8tdsHucFNGt7I MyI8Rjbv3gFlpfXrMNNpzWhdJl9alJ7L6dC0eYytTz6pDFwFBt25kvlZF99pyZ6tOv11 ZVFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=E72W/kKIjXRIHRe+Cu/08ul15JvNWPjPxUaozr5QIjQ=; b=BEB2Jybu/j3DNSoY/uz4ENZlACpwPnlSk89BiTfzuccg40ETkhvo7gQHcK37BmL68v snIHt9PcFZcmY72dIJsjueIM7eoPHZPa7eQf8TsmHsreX4RgII0ay++Xfr8vxJFjm+Xq 6TnOJQRG0y/e1dNEMB4W3PWUkX0IKwXiJZ2sNt09oN7Bq97xiOKjmU99no5xxiX+uBfX 542Q4qJlPJJZlmAzh0EIqNwOk9f4y3rTKTHbSXblIqvV9n2dvSl2jrWtKAGp7vbmC0/7 YZtrgp/L7O1NdEYtj3G1wASRW4chO+Y5xC3yI0CcqJzDKrYmPj2gvy5rlflEN2SrAiZz lvjg== X-Gm-Message-State: AN3rC/50tmYddp+a89Kb+ZQnJc6ACEqKZdzGZgbxxEJYQO8I/y5CpmL3 GiOIHBzXZkeUqAwH7QqKvPKO6xslIQ== X-Received: by 10.36.245.201 with SMTP id k192mr7808771ith.104.1493976894113; Fri, 05 May 2017 02:34:54 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Fri, 5 May 2017 02:34:51 -0700 (PDT) Received: by 10.79.62.24 with HTTP; Fri, 5 May 2017 02:34:51 -0700 (PDT) In-Reply-To: References: <81424CC3-C4B0-487E-BF56-0113CA637239@juniper.net> From: Robert Raszuk Date: Fri, 5 May 2017 05:34:51 -0400 X-Google-Sender-Auth: DhPZfl2b1LtFTT25Z7G5JGQAxxY Message-ID: To: "John G. Scudder" Cc: idr wg Content-Type: multipart/alternative; boundary=94eb2c041c70138ba8054ec39a6e Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 09:34:58 -0000 --94eb2c041c70138ba8054ec39a6e Content-Type: text/plain; charset=UTF-8 Hi John, If someone make a point of the discussion and stops arguing about it ib next 100 emails does not mean that the rough consensus was reached on his or her comment. Honestly to me I do not see that rough consensus to adopt this change as standard track document has been reached on IDRWG mailing list. Moreover document does not define what policy is. Is accepting ORF a policy or not ? No clarity will lead to very inconsistent implementations. Cheers, R. PS I uderstand that forcing inbound policy is to push folks to apply BCP38. But this at best is applicable only at the ISP inbound side .... On May 5, 2017 12:41 AM, "John G. Scudder" wrote: Hi All, Below is my summary of this mail thread, FYI. As I understand it the next steps will be for the GROW AD (Warren) in consultation with the GROW chairs (Pete and Chris) to decide. Thanks to all for your participation. --John The thread "[Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard" started on April 19 and by May 1 had accumulated well over a hundred messages from 27 or so contributors. The thread defies a simple declaration of "there was consensus". However, and somewhat to my surprise, after reading back through the history and trying to give special attention to issues opened but subsequently rebutted, I think we do have consensus supporting advancement. There was quite a bit of discussion about the intended status of the document -- Standards Track vs. Informational vs. BCP, Updates 4271 or not. In the end, I think the best we can really say is that there was no consensus to choose something other than what the doc currently says. I've counted those who had document status objections under "con". If it were up to me to call consensus (which it is not) I would say there is rough consensus to advance the document on the Standards Track, updating 4271. I might consider offering a few extra days of LC for editorial comments *only*, with discussion of the document status and general outline and features of the solution being placed explicitly out of scope. This is because there were, interspersed among the many other comments, a few editorial ones, and I just don't have the energy to figure out if they were all taken in (although I think the authors have been fairly diligent about this). It's also because the most recent versions of the document have some fairly significant changes compared to -05. Several issues were raised and discussed as part of the thread, including (but not limited to, I'm under no illusions that I've captured or even fairly represented every single point): 1. A number of people, largely from router vendors, expressed concern that changing defaults is difficult. These ranged from saying it was impossible, to merely difficult and not worth it. In response to this, others (including but not limited to other vendor folk) provided examples for how a default could be changed without invoking a flag day. Greg Hankins, in particular, provided a detailed explanation of his company's process. The proponents of "it's hard to change defaults" didn't follow up to the various rebuttals, so on the balance I would have to say they're "in the rough". It's a bit dicey to make this call since failure to follow up can also reflect simple fatigue, but in this case the conversation doesn't just tail off, it ends with concrete arguments on the "this can be done" side. 2. Related, there is the position that "yes of course anything can be done in software but the cost/benefit ratio isn't right". This is clearly a matter of personal taste so can't be dismissed (or supported) solely on the basis of logic. 3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to apply only to Internet routing and not other applications? Pro: the motivation section of the document calls out the Internet use case Con: there's no clear, unambiguous way to actually specify this (AFI/SAFI 1/1 can be used in a VPN context, e.g.). different defaults for different AFI/SAFI is confusing for the user and the extra complexity not required. 4. How about "default no-propagate" rather than "default no-advertise"? Pro: Keeps CE configurations more compact, less surprising behavior. Con: Behavior is actually more surprising (since harder to explain, less consistent). Doesn't cover all plausible use cases. 5. These defaults will hurt some deployments that want to rely on the old defaults. Examples, data centers, CEs. Pro: as stated. Con: it seems unlikely anyone is actually relying on default behavior in their data center, since defaults vary between vendors, can any examples be brought forward? None offered, instead a couple DC operators stated support for the draft as written. For CEs, discussion around upgrade strategies without breaking existing deployments, see #1. 6. This should not update 4271, not be Standards Track, it should be a BCP, should be Informational, etc. Pro: It's not protocol, but just defaults, doesn't affect state machine, wire encoding. Con: Plenty of Standards Track documents specify defaults when considered important to operation of protocol, and even more ephemeral things such as textual encodings. Pro: It should be a BCP and/or shouldn't update 4271 because it's bad to make existing implementations nonconformant. Con: Formally, it doesn't work that way. Also, the point is to ask implementations to change. 7. There are various other proposals to mitigate route leaks and provide BGP security features. Pro: implied, "we've already got one" Con: some of these are still in flight, not even WG docs. None address exactly the same issues. Some don't even overlap. 8. Why not just do perfect filtering at the service provider border? It's an education problem! Pro: perfect filtering prevents harm from route leaks. Con: decades of experience indicate strategies that require perfection are not successful. Taking a rough head count, here's here I understand people's positions to have ended up: Commented, no discernible position on advancing the doc -- 2 chris morrow alvaro retana Pro -- 16 john scudder randy bush brian dickson joe provo warren kumari jared mauch job snijders gert doering mik abrahamson jeff haas -- support, though would prefer BCP greg hankins nick hilliard jay borkenhagen ian dickinson martijn schmidt keyur patel Con -- On procedural grounds (should be a BCP, or should be Informational) -- 3 eric rosen -- would be OK as Informational, opposes other statuses tony przygienda -- it should be a BCP enke chen -- fine if it's a BCP. changing defaults is infeasible ("in the rough") Con -- In the rough -- 2 acee lindem -- contrary to auto-discovery (rebutted, in the rough), should have a 'backwards compatibility' section jeff tantsura -- changing defaults "can not be changed". -- in the rough Con -- Other objections, in most cases not explicitly stated as opposing advancement but that's my reading of their mood -- 4 robert raszuk -- not explicitly, but has raised numerous "but what about...", all or most replied to alex azimov -- 'it'll just result in empty policy' and 'route leaks are rare anyway', both later rebutted and not replied (so, "in the rough") tom petch -- not explicitly, but generally skeptical tone to comments. specifically requested an analysis of what harms the proposal might cause. (not done or replied to AFAIK) bruno decraene -- would rather improve route-leak draft, numerous other points and suggestions, mostly replied to, too much to summarize _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --94eb2c041c70138ba8054ec39a6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

If = someone make a point of the discussion and stops arguing about it ib next 1= 00 emails does not mean that the rough consensus was reached on his or her = comment.

Honestly to me = I do not see that rough consensus to adopt this change as standard track do= cument has been reached on IDRWG mailing list.

<= /div>
Moreover document does not define what policy is. Is= accepting ORF a policy or not ? No clarity will lead to very inconsistent = implementations.

Cheers,=
R.

PS I uderstand that forcing inbound policy is to push folks to apply BCP= 38. But this at best is applicable only at the ISP inbound side ....
<= /div>

On May 5, 20= 17 12:41 AM, "John G. Scudder" <jgs@juniper.net> wrote:
Hi All,

Below is my summary of this mail thread, FYI.

As I understand it the next steps will be for the GROW AD (Warren) in consu= ltation with the GROW chairs (Pete and Chris) to decide.

Thanks to all for your participation.

--John

The thread "[Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp= -reject-05.txt> (Default EBGP Route Propagation Behavior Without Po= licies) to Proposed Standard" started on April 19 and by May 1 had acc= umulated well over a hundred messages from 27 or so contributors.

The thread defies a simple declaration of "there was consensus". = However, and somewhat to my surprise, after reading back through the histor= y and trying to give special attention to issues opened but subsequently re= butted, I think we do have consensus supporting advancement.

There was quite a bit of discussion about the intended status of the docume= nt -- Standards Track vs. Informational vs. BCP, Updates 4271 or not. In th= e end, I think the best we can really say is that there was no consensus to= choose something other than what the doc currently says. I've counted = those who had document status objections under "con".

If it were up to me to call consensus (which it is not) I would say there i= s rough consensus to advance the document on the Standards Track, updating = 4271. I might consider offering a few extra days of LC for editorial commen= ts *only*, with discussion of the document status and general outline and f= eatures of the solution being placed explicitly out of scope. This is becau= se there were, interspersed among the many other comments, a few editorial = ones, and I just don't have the energy to figure out if they were all t= aken in (although I think the authors have been fairly diligent about this)= . It's also because the most recent versions of the document have some = fairly significant changes compared to -05.

Several issues were raised and discussed as part of the thread, including (= but not limited to, I'm under no illusions that I've captured or ev= en fairly represented every single point):

1. A number of people, largely from router vendors, expressed concern that = changing defaults is difficult. These ranged from saying it was impossible,= to merely difficult and not worth it. In response to this, others (includi= ng but not limited to other vendor folk) provided examples for how a defaul= t could be changed without invoking a flag day. Greg Hankins, in particular= , provided a detailed explanation of his company's process. The propone= nts of "it's hard to change defaults" didn't follow up to= the various rebuttals, so on the balance I would have to say they're &= quot;in the rough". It's a bit dicey to make this call since failu= re to follow up can also reflect simple fatigue, but in this case the conve= rsation doesn't just tail off, it ends with concrete arguments on the &= quot;this can be done" side.

2. Related, there is the position that "yes of course anything can be = done in software but the cost/benefit ratio isn't right". This is = clearly a matter of personal taste so can't be dismissed (or supported)= solely on the basis of logic.

3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to apply = only to Internet routing and not other applications?
Pro: the motivation section of the document calls out the Internet use case=
Con: there's no clear, unambiguous way to actually specify this (AFI/SA= FI 1/1 can be used in a VPN context, e.g.). different defaults for differen= t AFI/SAFI is confusing for the user and the extra complexity not required.=

4. How about "default no-propagate" rather than "default no-= advertise"?
Pro: Keeps CE configurations more compact, less surprising behavior.
Con: Behavior is actually more surprising (since harder to explain, less co= nsistent). Doesn't cover all plausible use cases.

5. These defaults will hurt some deployments that want to rely on the old d= efaults. Examples, data centers, CEs.
Pro: as stated.
Con: it seems unlikely anyone is actually relying on default behavior in th= eir data center, since defaults vary between vendors, can any examples be b= rought forward? None offered, instead a couple DC operators stated support = for the draft as written. For CEs, discussion around upgrade strategies wit= hout breaking existing deployments, see #1.

6. This should not update 4271, not be Standards Track, it should be a BCP,= should be Informational, etc.
Pro: It's not protocol, but just defaults, doesn't affect state mac= hine, wire encoding.
Con: Plenty of Standards Track documents specify defaults when considered i= mportant to operation of protocol, and even more ephemeral things such as t= extual encodings.
Pro: It should be a BCP and/or shouldn't update 4271 because it's b= ad to make existing implementations nonconformant.
Con: Formally, it doesn't work that way. Also, the point is to ask impl= ementations to change.

7. There are various other proposals to mitigate route leaks and provide BG= P security features.
Pro: implied, "we've already got one"
Con: some of these are still in flight, not even WG docs. None address exac= tly the same issues. Some don't even overlap.

8. Why not just do perfect filtering at the service provider border? It'= ;s an education problem!
Pro: perfect filtering prevents harm from route leaks.
Con: decades of experience indicate strategies that require perfection are = not successful.

Taking a rough head count, here's here I understand people's positi= ons to have ended up:

Commented, no discernible position on advancing the doc -- 2

chris morrow
alvaro retana

Pro -- 16

john scudder
randy bush
brian dickson
joe provo
warren kumari
jared mauch
job snijders
gert doering
mik abrahamson
jeff haas -- support, though would prefer BCP
greg hankins
nick hilliard
jay borkenhagen
ian dickinson
martijn schmidt
keyur patel

Con -- On procedural grounds (should be a BCP, or should be Informational) = -- 3

eric rosen -- would be OK as Informational, opposes other statuses
tony przygienda -- it should be a BCP
enke chen -- fine if it's a BCP. changing defaults is infeasible ("= ;in the rough")

Con -- In the rough -- 2

acee lindem -- contrary to auto-discovery (rebutted, in the rough), should = have a 'backwards compatibility' section
jeff tantsura -- changing defaults "can not be changed". -- in th= e rough

Con -- Other objections, in most cases not explicitly stated as opposing ad= vancement but that's my reading of their mood -- 4

robert raszuk -- not explicitly, but has raised numerous "but what abo= ut...", all or most replied to
alex azimov -- 'it'll just result in empty policy' and 'rou= te leaks are rare anyway', both later rebutted and not replied (so, &qu= ot;in the rough")
tom petch -- not explicitly, but generally skeptical tone to comments. spec= ifically requested an analysis of what harms the proposal might cause. (not= done or replied to AFAIK)
bruno decraene -- would rather improve route-leak draft, numerous other poi= nts and suggestions, mostly replied to, too much to summarize
___________________________________________= ____
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--94eb2c041c70138ba8054ec39a6e-- From nobody Fri May 5 05:10:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C969B128CDB for ; Fri, 5 May 2017 05:10:44 -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 jFC1bjkpL6SJ for ; Fri, 5 May 2017 05:10:42 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 BA8361288B8 for ; Fri, 5 May 2017 05:10:42 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id m123so4358096wma.0 for ; Fri, 05 May 2017 05:10:42 -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:content-transfer-encoding:in-reply-to :user-agent; bh=ETau9HJjhXyMDTkwd+ZZxll/aF9C8HxRLIQN9T3nliY=; b=QA6DHABZSPlaaC8r1ntxJ45BTSwAWE3tQFOcigklyFfpsZhFp7pT9RHI0IGpT8dVNS zkIRbfxIUfz2Y0ofb4k7pYzQ6mq7947GDLAvbbTuLLGjOU9ehx36hoBgXSr915mKUc9D IlOh0f2aepRSmlWsUvkpRYGVW6sQuF1CDWbOkcY/BaHRi0RnDbjlo3DxKFMxdyZP+oZt eD7xBQlB1BLal7X94S6Uz2o9j37twnZYGfVwvrDtDQ+wrrdSXe+s/O+fdMiT+0VRrbGf 3oUYW82blL+YAi6myUUV+C3UvettrOuZjPHaD4DxPA3Ezoy3pQvtKCpM78qqJjs92Yoz Jn5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=ETau9HJjhXyMDTkwd+ZZxll/aF9C8HxRLIQN9T3nliY=; b=prwQJvwXmbUwVE2xvnh1WTxzPW3HMVI5XFsG9x5XDrM1VIAtPxu3H/6wfH5uW3a/nJ HQpGjqHC+2OumQCOFPThUKcHjLSRKK3mMuAapf/ZcRjEwwuQuO95Ds90hqhRjTsxj0jK bKYWZ4ugbN/8YKqFjvbbPBV7Dbmbcr1YrazlEkziTnvs7pZII+HnTxQ7YNZqlB3t/0px uoNkhH08tmsxuiDPDofdkYLYLlPpdZ7OS3Q7ZQ3vWzvBtCxNGZeAu6E39kiDlwfDGs4p BwtO5uSCWePDWfux4QmY/FW/WRCI3YtUXb+LETBGYxXnrOYXXj5w7v8I/SbFewICDJ2w T6Yg== X-Gm-Message-State: AN3rC/4/absZmdKpAkJCyogdYbpUSOkxjHmgdjPxZ1kRPPybKTIqIDvQ uAabgqBYoh17Zg== X-Received: by 10.80.143.164 with SMTP id y33mr33433495edy.89.1493986241091; Fri, 05 May 2017 05:10:41 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:597:4a36:bb29:1e61]) by smtp.gmail.com with ESMTPSA id d38sm1266106edb.26.2017.05.05.05.10.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 05:10:40 -0700 (PDT) Date: Fri, 5 May 2017 14:10:32 +0200 From: Job Snijders To: "Alvaro Retana (aretana)" Cc: "draft-ietf-idr-shutdown@ietf.org" , "idr-chairs@ietf.org" , Hares Susan , "idr@ietf.org" Message-ID: <20170505121032.2sdnez3lxemdszsb@Vurt.local> References: <010A73B6-A030-483F-8D79-3498D92C3335@cisco.com> <20170422101013.4unb4a3ulsq2kueg@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-shutdown-07 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 12:10:45 -0000 Dear Alvaro, On Mon, Apr 24, 2017 at 09:59:47PM +0000, Alvaro Retana (aretana) wrote: > On 4/22/17, 6:10 AM, "Job Snijders" wrote: > … > > > C5. Section 4. (Error Handling): “Any erroneous or malformed Shutdown > > > Communication received SHOULD be logged for the attention of the > > > operator and then MAY be discarded.†> > > > > > C5.1. What does “erroneous or malformed†mean? I guess this is beyond > > > a bad length, but maybe it refers to invalid UTF-8 sequences, or maybe > > > something different. ?? > > > > Yes, section 2 "A receiving BGP speaker MUST NOT interpret invalid UTF-8 > > sequences." So, what a BGP speaker could do is send a hexdumped version > > of the received data to syslog after something like "printf("%02x", > > *p++);", rather then present that data through usual ways (as UTF-8). > > Ok, so “erroneous or malformed†just refers to an “invalid UTF-8 > sequence� If so, then just say that and don’t leave it up to > interpretation. OLD: If an erroneous or malformed Shutdown Communication is received, a message indicating this event SHOULD be logged for the attention of the operator. Perhaps: If a Shutdown Communication with an invalid Length value, or an invalid UTF-8 sequence is received, a message indicating this event SHOULD be logged for the attention of the operator. > > > C7. Section 6. (Security Considerations) > > > > > > C7.1. REQUIRING is not an rfc2119 keyword. Please work REQUIRED > > > in there instead. > > > > OK, I got that from RFC 5424, so we might need an errata there. > > It looks like we do. Done: https://www.rfc-editor.org/errata/eid5010 > > > C7.3. In the Shepherd’s write-up [2], Sue wrote: “The Security-ADs > > > will look at the ability to send data which indicates specific > > > details regarding an operator or the operator's topology.†Given > > > that the operator can put anything in the string, it would be nice > > > if you addressed this concern up front (and not wait for the SEC > > > ADs). Even if the information is being sent to a “trusted†peer, > > > I think Sue raises an interesting point as “confidential†> > > information may be inadvertently sent out. One way to address > > > this concern may be with guidance to operators and to reaffirm the > > > fact that while the information is sent only one hop away (to your > > > peer), it can be used as the receiver’s discretion. > > > > > > [2] https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/shepherdwriteup/ > > > > Interesting point. Do you think XMPP, SMTP, NNTP, and SYSLOG, > > include similar clauses? > > I don’t know, did you look? ;-) > > All those protocols were standardized before the IAB/IESG acquired a > new taste for privacy. Take a look at rfc6973 and at this short > review [3]. > > [3] https://ietf.org/edu/tutorials/89-Privacy-Tschofenig.pdf > > > > I personally may want to wait for a security AD to actually make and > > argue the point rather then 'preempt' the angle with text which > > borders on legalese. > > No need to be too clever when writing this up; all you need is a > recognition that secondary use of the data can occur, some > recommendations about how to mitigate (by not including too much), and > maybe a pointer to rfc6973. OK, perhaps the following should be added to the security section? NEW: Users of this mechanism should consider applying data minimization practises as outlined in Section 6.1 [RFC6973] as a received Shutdown Communication may be used at the receiver's discretion. Kind regards, Job From nobody Fri May 5 07:35:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750571294B8; Fri, 5 May 2017 07:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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.001, 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 nYopmx1TcRp5; Fri, 5 May 2017 07:35:36 -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 9F8C31294E6; Fri, 5 May 2017 07:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=568; q=dns/txt; s=iport; t=1493994935; x=1495204535; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HF+85A8viZl8atRu9Io1a39uwrcokuGA8eho+4tJzyU=; b=g8J5rBx3jyMw5MgGolq/Zru82RFMeEQQXkPPQ5+5wsOzi7xSb5TQTqWD /tVnnHt0YPe8VNsnwBYN9q/eLDU+gzFV7ayKY7i1I+KhkE/GbxG+dCoOO A3seBpue4QmckuBMxanBwFBU6XEZC7sK4EyiVwXW6A5spnav3an4U4M27 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAQA8jQxZ/4UNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1WBbgeDYYoYp0aCD4YkAhqELj8YAQIBAQEBAQEBayiFFgYjEUUQAgE?= =?us-ascii?q?IGgImAgICMBUQAgQOBYogsReCJopmAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELh?= =?us-ascii?q?VSCCYJwh2kugjEBBJZhhw4BkxaBbAGPe5Q2AR84gQpvFVgBhl92h2iBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,292,1491264000"; d="scan'208";a="419336708" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2017 14:35:34 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v45EZYbt011660 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 May 2017 14:35:34 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 5 May 2017 09:35:34 -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; Fri, 5 May 2017 09:35:34 -0500 From: "Alvaro Retana (aretana)" To: Job Snijders CC: "draft-ietf-idr-shutdown@ietf.org" , "idr-chairs@ietf.org" , Hares Susan , "idr@ietf.org" Thread-Topic: [Idr] AD Review of draft-ietf-idr-shutdown-07 Thread-Index: AQHSutI62HNkeEG8rUet1MjLuMXn26HRf3CAgAOn2YCAEOgTAP//5XeA Date: Fri, 5 May 2017 14:35:34 +0000 Message-ID: <283A4CFB-0D84-4EF1-B0CD-4708DE51FE79@cisco.com> References: <010A73B6-A030-483F-8D79-3498D92C3335@cisco.com> <20170422101013.4unb4a3ulsq2kueg@Vurt.local> <20170505121032.2sdnez3lxemdszsb@Vurt.local> In-Reply-To: <20170505121032.2sdnez3lxemdszsb@Vurt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="utf-8" Content-ID: <198DF3ADA870CF40BCE01A8BBE4C8C1D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-shutdown-07 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 14:35:38 -0000 SGkhDQoNCknigJltIGZpbmUgd2l0aCB0aGF0IHRleHQuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0K DQpPbiA1LzUvMTcsIDg6MTAgQU0sICJKb2IgU25pamRlcnMiIDxqb2JAaW5zdGl0dXV0Lm5ldD4g d3JvdGU6DQoNCk9LLCBwZXJoYXBzIHRoZSBmb2xsb3dpbmcgc2hvdWxkIGJlIGFkZGVkIHRvIHRo ZSBzZWN1cml0eSBzZWN0aW9uPw0KDQpORVc6DQogICAgVXNlcnMgb2YgdGhpcyBtZWNoYW5pc20g c2hvdWxkIGNvbnNpZGVyIGFwcGx5aW5nIGRhdGEgbWluaW1pemF0aW9uDQogICAgcHJhY3Rpc2Vz IGFzIG91dGxpbmVkIGluIFNlY3Rpb24gNi4xIFtSRkM2OTczXSBhcyBhIHJlY2VpdmVkDQogICAg U2h1dGRvd24gQ29tbXVuaWNhdGlvbiBtYXkgYmUgdXNlZCBhdCB0aGUgcmVjZWl2ZXIncyBkaXNj cmV0aW9uLg0KDQoNCg0K From nobody Fri May 5 07:43:52 2017 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 40BF11275AB; Fri, 5 May 2017 07:43:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149399542921.8378.4407203960866133538@ietfa.amsl.com> Date: Fri, 05 May 2017 07:43:49 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-shutdown-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 14:43:49 -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 Administrative Shutdown Communication Authors : Job Snijders Jakob Heitz John Scudder Filename : draft-ietf-idr-shutdown-08.txt Pages : 7 Date : 2017-05-05 Abstract: This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-shutdown-08 https://datatracker.ietf.org/doc/html/draft-ietf-idr-shutdown-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-shutdown-08 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 Fri May 5 07:49:24 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DCC1294E6 for ; Fri, 5 May 2017 07:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 7D1YENwZXdXY for ; Fri, 5 May 2017 07:49:20 -0700 (PDT) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) (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 32DC7128B4E for ; Fri, 5 May 2017 07:49:20 -0700 (PDT) Received: by mail-wm0-f49.google.com with SMTP id w64so26060619wma.0 for ; Fri, 05 May 2017 07:49:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=RasfnL5YW1dAF9Vr0fT3cDkaodhmdCs21T3ChPkfhqc=; b=E9tCEqzUMfstnNyOyPacgEdgcj7F6bVVGfsRAzYFwAxAXhYc1giqNaeJ4Jvr+KYGa8 eUf1xC5zxQceSf9RCiPHMPgApq7ZjUaVj/KHeTS5q0T5Vzj667zBExJufIjwkAHEoF4Q 4e68v/xlJ/1YfIg3+FUivHnacg1FAdUckh0ftQasvRS742u7Q151wB/NVdPSTkn2qX/p O29Ckw97ro24ZjVlHUUyi5g8xQCGA8C+6MWcwQIyPAc37hiPx86wCl0OJAmpND5Be0jr fcWlIHoQKap3Y3RklHetJNAQFAomh475Z3Zbl2jua4bOxS7+iU+EvANlG/N0bQZtdKOd 1aJA== X-Gm-Message-State: AN3rC/7VAVVWd+csgVTAnCE1K7oIyfO0pvuVclnl7j+85NKZ1cPUtQ1a wEKeCjHIzCn9hA== X-Received: by 10.80.134.208 with SMTP id 16mr34218228edu.67.1493995758488; Fri, 05 May 2017 07:49:18 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:597:4a36:bb29:1e61]) by smtp.gmail.com with ESMTPSA id b25sm3489734edc.58.2017.05.05.07.49.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 07:49:17 -0700 (PDT) Date: Fri, 5 May 2017 16:49:15 +0200 From: Job Snijders To: "Alvaro Retana (aretana)" Cc: "draft-ietf-idr-shutdown@ietf.org" , "idr-chairs@ietf.org" , Hares Susan , "idr@ietf.org" Message-ID: <20170505144915.5jiaojgrg4h3k6zu@Vurt.local> References: <010A73B6-A030-483F-8D79-3498D92C3335@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010A73B6-A030-483F-8D79-3498D92C3335@cisco.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-shutdown-07 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 14:49:23 -0000 On Fri, Apr 21, 2017 at 07:05:22PM +0000, Alvaro Retana (aretana) wrote: > I would like to (at least) see the comments about the Security > Considerations addressed before starting the IETF Last Call. Alvaro, ball is in your court! :-) -------- Date: Fri, 05 May 2017 16:43:49 +0200 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-shutdown-08.txt 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 Administrative Shutdown Communication Authors : Job Snijders Jakob Heitz John Scudder Filename : draft-ietf-idr-shutdown-08.txt Pages : 7 Date : 2017-05-05 Abstract: This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-shutdown-08 https://datatracker.ietf.org/doc/html/draft-ietf-idr-shutdown-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-shutdown-08 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 Fri May 5 08:50:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA3E12956B for ; Fri, 5 May 2017 08:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 RXMTSoRVW-fJ for ; Fri, 5 May 2017 08:50:43 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5C313129557 for ; Fri, 5 May 2017 08:50:43 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id 1830C540E34; Fri, 5 May 2017 11:50:43 -0400 (EDT) Date: Fri, 5 May 2017 11:50:43 -0400 From: Jared Mauch To: Robert Raszuk Cc: "John G. Scudder" , idr wg Message-ID: <20170505155043.GA6623@puck.nether.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 15:50:45 -0000 On Fri, May 05, 2017 at 05:34:51AM -0400, Robert Raszuk wrote: > Hi John, > > If someone make a point of the discussion and stops arguing about it ib > next 100 emails does not mean that the rough consensus was reached on his > or her comment. > > Honestly to me I do not see that rough consensus to adopt this change as > standard track document has been reached on IDRWG mailing list. (Not touching the above). > Moreover document does not define what policy is. Is accepting ORF a policy > or not ? No clarity will lead to very inconsistent implementations. We already have inconsistent implemencations. Requring an operator to do something is not a high bar to clear. If vendors require additional guidance here beyond the existing yang or openconfig models I'm welcome to discuss offline with them, but this doesn't seem to be related to the summary. - 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 Fri May 5 09:41:20 2017 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 83135129AEB; Fri, 5 May 2017 09:41:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joe Clarke To: Cc: idr@ietf.org, draft-ietf-idr-sla-exchange.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149400246349.8370.5477015906856459639@ietfa.amsl.com> Date: Fri, 05 May 2017 09:41:03 -0700 Archived-At: Subject: [Idr] Opsdir early review of draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 16:41:03 -0000 Reviewer: Joe Clarke Review result: Has Issues I have been asked to do a review of this draft as a representative of OPS-DIR. This draft lays out a means to exchange SLA/QoS policies via BGP UPDATE messages. Overall, I found this draft a bit difficult to read. There are grammatical issues such as the user of "thru" instead of "through", odd commas, and missing articles. But this is not a grammatical overview. I think this draft would benefit from some examples that show what some practical QoS policies would look like that convey the required classes within the maximum BGP message size (that is, in section 7 add more specific examples of what policies may look like in the ADVERTISE messages). What do the authors feel typical uses of this would look like from the UPDATE message perspective? What kind of processing overhead can one typically expect if a router, for example, will be the QoS Attribute Speaker and SLA Consumer? Below are some specific per-section questions and issues: Section 2: You state that a BGP Speaker need not be a QoS Attribute Speaker, but even if the QoS data is opaque to the BGP Speaker, it would still need to know that the QoS Attribute Speaker exists and there is data to be added to the UPDATE. So why the two entities don't need to be co-resident in the same process, a BGP Speaker needs to be QoS aware to some extent in order for this exchange to work. Additionally, why are SLA Producer and Consumer broken out whereas QoS and BGP just have "speakers?" For consistency, maybe you just state that there exists an SLA-aware QoS Attribute Speaker. You do not define NLRI and AFI/SAFI in your terminology. === Section 3.2: Why the need to have the SLA SubType Flags be set to 0? Couldn't you just as easily set the Source AS and Destination AS Counts to 0? You state that a value of 0 for Source AS when flags are 1 is illegal, so I believe this would work. For SLA ID, you state: The SLA ID applies to aggregate traffic to prefixes for a given AFI/SAFI that share the same Source AS and SLA ID. The SLA ID applies to aggregate traffic that shares the same SLA ID? This seems circular to me. I'm not really clear on how I would allocate an SLA ID and how I align that with the intended QoS policies. Would the intent of having a 0-length SLA Content be to remove the policy for the given prefixes? I'm not clear exactly as to that use case. I'm confused a bit as to how the Destination AS List works. Initially, I thought this would only be set by the sending AS to indicate to which external ASes the content applies. However, each QoS Attribute Speaker can update the Destination AS List. In Sections 4.1.2, 5.1 and 5.2 you attempt to address this, but it is still not clear what kind of updating or trimming of the Destination AS list should be done (and in Section 5.2 you allude to rules to trim the Destination AS List, but I did not see those rules). This could be clarified with an example of what can happen at various hops in the network. === Section 3.3: Related to a point above, if the SLA Content needs to be set per direction, would I use the same SLA ID to do that? I don't think that's clear enough in the current text. You state: Any Traffic Class Element advertised in the QoS Attribute only applies to the advertised AFI/SAFI NLRI within the BGP UPDATE message the QoS Attribute is contained in. However, if I understand correctly, I could specify IPFIX attributes of sourceIPv6Prefix and/or destinationIPv6Prefix that does not line up with the NLRIs, would that not constitute an error? Or Maybe my AFI/SAFI are 1/1, and I'm trying to match IPv6. This seems more like an error, but you only state what to do if the AFI/SAFI is not supported. === Section 3.3.2.2: Why have such a huge range for length here? I can specify that the number of bytes to specify the amount of L2 overhead to use is 255. Why not advise that length should be 4, and then use an IEEE FP number like you did for the TSPEC? At the very least, I think this should be reined in a bit. === Section 3.3.2.7: I think you have a typo in precedence. I think you want to say: - MINRATE_IN_PROFILE_MARKING takes highest precedence (that is over MAXRATE_IN_PROFILE_MARKING), - MAXRATE_IN_PROFILE_MARKING takes precedence over MINRATE_OUT_PROFILE_MARKING, and - MINRATE_OUT_PROFILE_MARKING takes precedence over MAXRATE_OUT_PROFILE_MARKING === Section 5.2 What I did not see is what the actual SLA Consumer should do after it processes the SLA Content. I realize this can delve into implementation details, but perhaps it's worth mentioning that the SLA Consumer can use protocols like NETCONF or RESTCONF to configure the policies on the necessary interfaces. From nobody Fri May 5 10:01:13 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD091201F8 for ; Fri, 5 May 2017 10:01:11 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-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 X_CDFFNd2QC2 for ; Fri, 5 May 2017 10:01:08 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 90C971294C8 for ; Fri, 5 May 2017 10:01:08 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id m36so9967372qtb.0 for ; Fri, 05 May 2017 10:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1GeeaO3ONWr0P7PPgA183q3SLnWCZcm7Ljyvuicw8Ek=; b=BS49g0n3QO53fMSbOdf+65P3weES1uIndQgdq+zRfKJi+VSFqh7MuInWVtXEw/DzTg pxYme56mS4/WY9bYlS9XheF3pohP0dk2Z/iDLM5+2UdwycsdI+vY3U8nzURe3bt9Kya2 X37tc0lYBFfR2gKOguTFKmBDlV+L8+5unSOOUOhm1TVGO4x21IgLh6uwtfUjbW6zLZIH IAO2aHbqZJfis9qUbrbSt7ONbzRwJF37iwDaxkbQ5ajh96nM5/niX59pbT03tyWS9v1L eUjkGFoafFEbGSd0zpHbWLSK13/BIQgggKt1XRBH+RkIQHVzGYYRj4XhisPtJzxGiSlE 2g9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1GeeaO3ONWr0P7PPgA183q3SLnWCZcm7Ljyvuicw8Ek=; b=WRgDEEoYrCwwhEz22IPkTXLc4yJxGzfqNUe4gtCCefUAxdz/uVH6cLlyWEOIlqFL4w nK1RZMTv2iRfmxCkMuwHm45RVOH+yffPWUN0WLGBYP+YM9kqrSJhkbfm/dGK65WdOxF0 10kxYdBx3IaN3q08rM7aSiTirzu7MGgMYdTViwP+oKxkS+uWRicM7OpFYcZ5VvM41D3I gpJUdZxefBPXVrg8eYKEIDCZWhtU8l6Kr11AHg6vKblEk+4BpWVhnseXnW7eH8wa+OEI T9hvTpRg8imAEWpGZVbqK6uAIztlyJK4sNwTeBi8YLkPO1UkBV/ROFrWkY9nRa+CtyX8 8nAw== X-Gm-Message-State: AN3rC/44gd+crtHKHN9vsjsdvxJJl8rySmwXqtA5pxfSraSePztxyb+n y/ULHISy0sDD2Y/ZXr9HVTqnugmcDUgA X-Received: by 10.200.44.36 with SMTP id d33mr46146687qta.51.1494003667049; Fri, 05 May 2017 10:01:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.171.68 with HTTP; Fri, 5 May 2017 10:00:26 -0700 (PDT) In-Reply-To: References: <81424CC3-C4B0-487E-BF56-0113CA637239@juniper.net> From: Warren Kumari Date: Fri, 5 May 2017 13:00:26 -0400 Message-ID: To: Robert Raszuk Cc: "John G. Scudder" , idr wg , "Alvaro Retana (aretana)" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 17:01:11 -0000 [ + Alvaro, explicitly ] The way that (rough) consensus is judged in the IETF is not when everyone is happy, but when people have had a chance to raise their issues, have them discussed and considered. This LC generated a *significant* amount of discussion, and a large amount of back and forth The issues were, IMO discussed and considered, and some text added / changed to address the discussion. John's judgement of consensus is not his alone; I (as the GROW AD) viewed there as being **rough** consensus; I discussed this with Alvaro (as IDR AD) who concurred. John provided a really helpful summary which he shared with us - I used this to confirm my view, and I asked him to provide to the list. This is clearly not unanimous/ not everyone is happy, but (in my view) there is *rough* consensus for this to progress. The authors are still integrating final edits / word smithing and will post a new version shortly. W On Fri, May 5, 2017 at 5:34 AM, Robert Raszuk wrote: > Hi John, > > If someone make a point of the discussion and stops arguing about it ib next > 100 emails does not mean that the rough consensus was reached on his or her > comment. > > Honestly to me I do not see that rough consensus to adopt this change as > standard track document has been reached on IDRWG mailing list. > > Moreover document does not define what policy is. Is accepting ORF a policy > or not ? No clarity will lead to very inconsistent implementations. > > Cheers, > R. > > PS I uderstand that forcing inbound policy is to push folks to apply BCP38. > But this at best is applicable only at the ISP inbound side .... > > On May 5, 2017 12:41 AM, "John G. Scudder" wrote: > > Hi All, > > Below is my summary of this mail thread, FYI. > > As I understand it the next steps will be for the GROW AD (Warren) in > consultation with the GROW chairs (Pete and Chris) to decide. > > Thanks to all for your participation. > > --John > > The thread "[Idr] IETF LC for IDR-ish document > (Default EBGP Route Propagation Behavior > Without Policies) to Proposed Standard" started on April 19 and by May 1 had > accumulated well over a hundred messages from 27 or so contributors. > > The thread defies a simple declaration of "there was consensus". However, > and somewhat to my surprise, after reading back through the history and > trying to give special attention to issues opened but subsequently rebutted, > I think we do have consensus supporting advancement. > > There was quite a bit of discussion about the intended status of the > document -- Standards Track vs. Informational vs. BCP, Updates 4271 or not. > In the end, I think the best we can really say is that there was no > consensus to choose something other than what the doc currently says. I've > counted those who had document status objections under "con". > > If it were up to me to call consensus (which it is not) I would say there is > rough consensus to advance the document on the Standards Track, updating > 4271. I might consider offering a few extra days of LC for editorial > comments *only*, with discussion of the document status and general outline > and features of the solution being placed explicitly out of scope. This is > because there were, interspersed among the many other comments, a few > editorial ones, and I just don't have the energy to figure out if they were > all taken in (although I think the authors have been fairly diligent about > this). It's also because the most recent versions of the document have some > fairly significant changes compared to -05. > > Several issues were raised and discussed as part of the thread, including > (but not limited to, I'm under no illusions that I've captured or even > fairly represented every single point): > > 1. A number of people, largely from router vendors, expressed concern that > changing defaults is difficult. These ranged from saying it was impossible, > to merely difficult and not worth it. In response to this, others (including > but not limited to other vendor folk) provided examples for how a default > could be changed without invoking a flag day. Greg Hankins, in particular, > provided a detailed explanation of his company's process. The proponents of > "it's hard to change defaults" didn't follow up to the various rebuttals, so > on the balance I would have to say they're "in the rough". It's a bit dicey > to make this call since failure to follow up can also reflect simple > fatigue, but in this case the conversation doesn't just tail off, it ends > with concrete arguments on the "this can be done" side. > > 2. Related, there is the position that "yes of course anything can be done > in software but the cost/benefit ratio isn't right". This is clearly a > matter of personal taste so can't be dismissed (or supported) solely on the > basis of logic. > > 3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to apply > only to Internet routing and not other applications? > Pro: the motivation section of the document calls out the Internet use case > Con: there's no clear, unambiguous way to actually specify this (AFI/SAFI > 1/1 can be used in a VPN context, e.g.). different defaults for different > AFI/SAFI is confusing for the user and the extra complexity not required. > > 4. How about "default no-propagate" rather than "default no-advertise"? > Pro: Keeps CE configurations more compact, less surprising behavior. > Con: Behavior is actually more surprising (since harder to explain, less > consistent). Doesn't cover all plausible use cases. > > 5. These defaults will hurt some deployments that want to rely on the old > defaults. Examples, data centers, CEs. > Pro: as stated. > Con: it seems unlikely anyone is actually relying on default behavior in > their data center, since defaults vary between vendors, can any examples be > brought forward? None offered, instead a couple DC operators stated support > for the draft as written. For CEs, discussion around upgrade strategies > without breaking existing deployments, see #1. > > 6. This should not update 4271, not be Standards Track, it should be a BCP, > should be Informational, etc. > Pro: It's not protocol, but just defaults, doesn't affect state machine, > wire encoding. > Con: Plenty of Standards Track documents specify defaults when considered > important to operation of protocol, and even more ephemeral things such as > textual encodings. > Pro: It should be a BCP and/or shouldn't update 4271 because it's bad to > make existing implementations nonconformant. > Con: Formally, it doesn't work that way. Also, the point is to ask > implementations to change. > > 7. There are various other proposals to mitigate route leaks and provide BGP > security features. > Pro: implied, "we've already got one" > Con: some of these are still in flight, not even WG docs. None address > exactly the same issues. Some don't even overlap. > > 8. Why not just do perfect filtering at the service provider border? It's an > education problem! > Pro: perfect filtering prevents harm from route leaks. > Con: decades of experience indicate strategies that require perfection are > not successful. > > Taking a rough head count, here's here I understand people's positions to > have ended up: > > Commented, no discernible position on advancing the doc -- 2 > > chris morrow > alvaro retana > > Pro -- 16 > > john scudder > randy bush > brian dickson > joe provo > warren kumari > jared mauch > job snijders > gert doering > mik abrahamson > jeff haas -- support, though would prefer BCP > greg hankins > nick hilliard > jay borkenhagen > ian dickinson > martijn schmidt > keyur patel > > Con -- On procedural grounds (should be a BCP, or should be Informational) > -- 3 > > eric rosen -- would be OK as Informational, opposes other statuses > tony przygienda -- it should be a BCP > enke chen -- fine if it's a BCP. changing defaults is infeasible ("in the > rough") > > Con -- In the rough -- 2 > > acee lindem -- contrary to auto-discovery (rebutted, in the rough), should > have a 'backwards compatibility' section > jeff tantsura -- changing defaults "can not be changed". -- in the rough > > Con -- Other objections, in most cases not explicitly stated as opposing > advancement but that's my reading of their mood -- 4 > > robert raszuk -- not explicitly, but has raised numerous "but what > about...", all or most replied to > alex azimov -- 'it'll just result in empty policy' and 'route leaks are rare > anyway', both later rebutted and not replied (so, "in the rough") > tom petch -- not explicitly, but generally skeptical tone to comments. > specifically requested an analysis of what harms the proposal might cause. > (not done or replied to AFAIK) > bruno decraene -- would rather improve route-leak draft, numerous other > points and suggestions, mostly replied to, too much to summarize > _______________________________________________ > 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 > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri May 5 10:54:34 2017 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 B4A55124E15; Fri, 5 May 2017 10:54:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk CC: idr@ietf.org, skh@ndzh.com, Susan Hares , idr-chairs@ietf.org, aretana@cisco.com, draft-ietf-idr-shutdown@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149400686065.8457.16928207738917615877.idtracker@ietfa.amsl.com> Date: Fri, 05 May 2017 10:54:20 -0700 Archived-At: Subject: [Idr] Last Call: (BGP Administrative Shutdown Communication) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 17:54:21 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'BGP Administrative Shutdown Communication' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-05-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri May 5 14:39:02 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D634126C3D for ; Fri, 5 May 2017 14:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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.001, 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 v_FeBt84Ur-g for ; Fri, 5 May 2017 14:38:56 -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 114E1124BFA for ; Fri, 5 May 2017 14:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9857; q=dns/txt; s=iport; t=1494020336; x=1495229936; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=zioTh7ZN+aOVsTzzfeR9rBrLNO3PONLjGlRdfdWVd9U=; b=HYCVLKINo5gSpRN3ZKQHatmXDhJNRPJqs+6vthvUZaWhJznrbXgR+1KV ExjhXhcHt991NKnW/O9fze5eh7E9+V26/yB0Xe6zcrYKJgKM+Dwih6xDB A9eDB1cjsq4yw9AKrRvxvhl71DuoIcxwkXM3eMJzAsl4PDSTpWXld3KJR 0=; X-IronPort-AV: E=Sophos;i="5.38,294,1491264000"; d="scan'208";a="419506867" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2017 21:38:55 +0000 Received: from [10.41.60.248] ([10.41.60.248]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v45LcrRP015285; Fri, 5 May 2017 21:38:54 GMT To: Robert Raszuk References: Cc: "John G. Scudder" , idr wg , Enke Chen From: Enke Chen Message-ID: <83ea4c7c-5d17-b92d-19a4-cfa572b3f070@cisco.com> Date: Fri, 5 May 2017 14:38:53 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:38:58 -0000 Hi, Folks: I still believe that the draft is BCP material. In addition, I would like see several points (raised by Robert R and others) addressed in the draft: 1) Inbound filter on the CE: Requiring inbound filtering makes sense for the providers, and I believe that is the common practice. But it is not needed and has little to do with route leaking on the CE side. Currently for the customers that receive full routes or partial routes from their providers, there is no need for inbound filters (and no rational way to generate such a filter in many cases) and they are not used in many cases. The draft should document these facts about the inbound filter. 2) ORF: Certainly it would be just as effective as "outbound filtering" if a customer registers its prefixes with IRR and then relies on receiving the ORF (from its provider) generated from the IRR. This should be noted in the draft. 3) Policy definition Again as pointed out many times, would "permit all" considered as an acceptable policy? Such policy does nothing or very little to help route leaking reduction. This should also be noted in the draft. Regards, -- Enke On 5/5/17 2:34 AM, Robert Raszuk wrote: > Hi John, > > If someone make a point of the discussion and stops arguing about it ib next 100 emails does > not mean that the rough consensus was reached on his or her comment. > > Honestly to me I do not see that rough consensus to adopt this change as standard track > document has been reached on IDRWG mailing list. > > Moreover document does not define what policy is. Is accepting ORF a policy or not ? > No clarity will lead to very inconsistent implementations. > > Cheers, > R. > > PS I uderstand that forcing inbound policy is to push folks to apply BCP38. But this at best is applicable only at the ISP inbound side .... > > On May 5, 2017 12:41 AM, "John G. Scudder" > wrote: > > Hi All, > > Below is my summary of this mail thread, FYI. > > As I understand it the next steps will be for the GROW AD (Warren) in consultation with the GROW chairs (Pete and Chris) to decide. > > Thanks to all for your participation. > > --John > > The thread "[Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard" started on April 19 and by May 1 had accumulated well over a hundred messages from 27 or so contributors. > > The thread defies a simple declaration of "there was consensus". However, and somewhat to my surprise, after reading back through the history and trying to give special attention to issues opened but subsequently rebutted, I think we do have consensus supporting advancement. > > There was quite a bit of discussion about the intended status of the document -- Standards Track vs. Informational vs. BCP, Updates 4271 or not. In the end, I think the best we can really say is that there was no consensus to choose something other than what the doc currently says. I've counted those who had document status objections under "con". > > If it were up to me to call consensus (which it is not) I would say there is rough consensus to advance the document on the Standards Track, updating 4271. I might consider offering a few extra days of LC for editorial comments *only*, with discussion of the document status and general outline and features of the solution being placed explicitly out of scope. This is because there were, interspersed among the many other comments, a few editorial ones, and I just don't have the energy to figure out if they were all taken in (although I think the authors have been fairly diligent about this). It's also because the most recent versions of the document have some fairly significant changes compared to -05. > > Several issues were raised and discussed as part of the thread, including (but not limited to, I'm under no illusions that I've captured or even fairly represented every single point): > > 1. A number of people, largely from router vendors, expressed concern that changing defaults is difficult. These ranged from saying it was impossible, to merely difficult and not worth it. In response to this, others (including but not limited to other vendor folk) provided examples for how a default could be changed without invoking a flag day. Greg Hankins, in particular, provided a detailed explanation of his company's process. The proponents of "it's hard to change defaults" didn't follow up to the various rebuttals, so on the balance I would have to say they're "in the rough". It's a bit dicey to make this call since failure to follow up can also reflect simple fatigue, but in this case the conversation doesn't just tail off, it ends with concrete arguments on the "this can be done" side. > > 2. Related, there is the position that "yes of course anything can be done in software but the cost/benefit ratio isn't right". This is clearly a matter of personal taste so can't be dismissed (or supported) solely on the basis of logic. > > 3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to apply only to Internet routing and not other applications? > Pro: the motivation section of the document calls out the Internet use case > Con: there's no clear, unambiguous way to actually specify this (AFI/SAFI 1/1 can be used in a VPN context, e.g.). different defaults for different AFI/SAFI is confusing for the user and the extra complexity not required. > > 4. How about "default no-propagate" rather than "default no-advertise"? > Pro: Keeps CE configurations more compact, less surprising behavior. > Con: Behavior is actually more surprising (since harder to explain, less consistent). Doesn't cover all plausible use cases. > > 5. These defaults will hurt some deployments that want to rely on the old defaults. Examples, data centers, CEs. > Pro: as stated. > Con: it seems unlikely anyone is actually relying on default behavior in their data center, since defaults vary between vendors, can any examples be brought forward? None offered, instead a couple DC operators stated support for the draft as written. For CEs, discussion around upgrade strategies without breaking existing deployments, see #1. > > 6. This should not update 4271, not be Standards Track, it should be a BCP, should be Informational, etc. > Pro: It's not protocol, but just defaults, doesn't affect state machine, wire encoding. > Con: Plenty of Standards Track documents specify defaults when considered important to operation of protocol, and even more ephemeral things such as textual encodings. > Pro: It should be a BCP and/or shouldn't update 4271 because it's bad to make existing implementations nonconformant. > Con: Formally, it doesn't work that way. Also, the point is to ask implementations to change. > > 7. There are various other proposals to mitigate route leaks and provide BGP security features. > Pro: implied, "we've already got one" > Con: some of these are still in flight, not even WG docs. None address exactly the same issues. Some don't even overlap. > > 8. Why not just do perfect filtering at the service provider border? It's an education problem! > Pro: perfect filtering prevents harm from route leaks. > Con: decades of experience indicate strategies that require perfection are not successful. > > Taking a rough head count, here's here I understand people's positions to have ended up: > > Commented, no discernible position on advancing the doc -- 2 > > chris morrow > alvaro retana > > Pro -- 16 > > john scudder > randy bush > brian dickson > joe provo > warren kumari > jared mauch > job snijders > gert doering > mik abrahamson > jeff haas -- support, though would prefer BCP > greg hankins > nick hilliard > jay borkenhagen > ian dickinson > martijn schmidt > keyur patel > > Con -- On procedural grounds (should be a BCP, or should be Informational) -- 3 > > eric rosen -- would be OK as Informational, opposes other statuses > tony przygienda -- it should be a BCP > enke chen -- fine if it's a BCP. changing defaults is infeasible ("in the rough") > > Con -- In the rough -- 2 > > acee lindem -- contrary to auto-discovery (rebutted, in the rough), should have a 'backwards compatibility' section > jeff tantsura -- changing defaults "can not be changed". -- in the rough > > Con -- Other objections, in most cases not explicitly stated as opposing advancement but that's my reading of their mood -- 4 > > robert raszuk -- not explicitly, but has raised numerous "but what about...", all or most replied to > alex azimov -- 'it'll just result in empty policy' and 'route leaks are rare anyway', both later rebutted and not replied (so, "in the rough") > tom petch -- not explicitly, but generally skeptical tone to comments. specifically requested an analysis of what harms the proposal might cause. (not done or replied to AFAIK) > bruno decraene -- would rather improve route-leak draft, numerous other points and suggestions, mostly replied to, too much to summarize > _______________________________________________ > 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 May 5 15:07:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00880126DC2 for ; Fri, 5 May 2017 15: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 8hwlTBbQtZ5R for ; Fri, 5 May 2017 15:07:27 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 37C181273E2 for ; Fri, 5 May 2017 15:07:27 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id p80so23114781iop.3 for ; Fri, 05 May 2017 15:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PtsCNWFFdTqWqCdc+5tzXiFj6i1k+IiyyJausO20gLU=; b=AYFywq7103ipivNsDhi/NczDyDDS1ts2lMKv2zMynXUDMblJHkNhboP7xU9WNEoEGh TgALiPrah8Zbf2w3mC6Dq21ZuU9o13RGP0L9Acsl1XTqqwx0QPvjvcu0mDYcdWFoyC41 OcLZGonqfwi8KAMFzV9M7T7vQjtKw4iK7FMkoAJ+u0ffcI/MMKzCtI0j5nrPUjos05Ed g5s8y6AR9dwKwVQRRndP/5WOEv8kGZk08yXgHC36zVg9LzwAbsetFQ6NqPKhY4QPFhXa U98YAIhgUbXQl7uwGGJGVhoKWZl3QHocIVrQxY6eA6SJPP/EL2IGJc8su+VPIMnq8aOq 9gHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PtsCNWFFdTqWqCdc+5tzXiFj6i1k+IiyyJausO20gLU=; b=H/k0QXh+S1euA3dRprfMInQo+Hs3f8v30SghBp/7ctFnHOJsDzLZ6Fq+4Wq8U4nsta bnXk0Rf0Dxg3OstwEhK2qHlVZn3VfqGEL/Lsukbgp7z/MxMddWH1XXXv/W+Z3B8HEXbL ph7H5IA4+yfYw80l/IlWL9UrgZcVwC0E3fCX4PwGMEFSyBpftX1xV6cZL1vuXqsU6j6C kr/z8oJkgwL+iLPwrs3SXhYQRr6k0Z7RYpzAytCN7RCEjdoL6YTe3wnaAkfxb+yM3Gtr u2rsF0V62ocFcz0DGhad+KGcGCJcV8h+9GRD8bFAQZIxT+U7xURHSXrTuWu13gl765jd z8dQ== X-Gm-Message-State: AN3rC/7eTn0NGnp5z/JBzCqptj3626kn1CWSyeWWjVMdV49ZWawuq1DZ XAdN1xS3ZEeePoiVHjPkEsUl0c38eg== X-Received: by 10.107.59.12 with SMTP id i12mr49360639ioa.225.1494022046529; Fri, 05 May 2017 15:07:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.90.77 with HTTP; Fri, 5 May 2017 15:07:25 -0700 (PDT) In-Reply-To: <83ea4c7c-5d17-b92d-19a4-cfa572b3f070@cisco.com> References: <83ea4c7c-5d17-b92d-19a4-cfa572b3f070@cisco.com> From: Brian Dickson Date: Fri, 5 May 2017 15:07:25 -0700 Message-ID: To: Enke Chen Cc: Robert Raszuk , idr wg Content-Type: multipart/alternative; boundary=94eb2c0633e65ec13f054ece1dea Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 22:07:32 -0000 --94eb2c0633e65ec13f054ece1dea Content-Type: text/plain; charset=UTF-8 Top-reply, to make it easy to read the summary responses. I speak only for myself, of course. 1) CE - either existing CE stuff can handle this during upgrades (qv discussion about upgrade vs out-of-the-box), and/or suitable warnings. Use of "permit all" policy achieves the desired effect on CE, and satisfies the requirements of this standard. 2) ORF - there is no guarantee that ORF is configured or present, and cannot be checked prior to bringing up BGP. Thus, "No." Just, no, ORF is not adequate for this. 3) Yes, permit all would be sufficient. All that is needed is an *explicit* policy, regardless of what it is. This all can be expressed by the difference between two mathematical comparisons: X>=0 X>0 If X is the place-holder for "policy", and "0" means no policy is configured, all that is required is ANY value of X which is not 0. There is no minimum positive value for "X", in other words - just as long as it is not 0. There is no requirement that the same rules be used by any given implementation. There is no interoperability requirement, as these are all local (implementations and policies configured). The "X>0" must be a forcing function, so BCP is not sufficient. That is the intent and purpose of "-reject". Respectfully, Brian On Fri, May 5, 2017 at 2:38 PM, Enke Chen wrote: > Hi, Folks: > > I still believe that the draft is BCP material. In addition, I would like > see several > points (raised by Robert R and others) addressed in the draft: > > 1) Inbound filter on the CE: > > Requiring inbound filtering makes sense for the providers, and I > believe that > is the common practice. But it is not needed and has little to do with > route > leaking on the CE side. Currently for the customers that receive full > routes > or partial routes from their providers, there is no need for inbound > filters > (and no rational way to generate such a filter in many cases) and they > are not > used in many cases. > > The draft should document these facts about the inbound filter. > > 2) ORF: > > Certainly it would be just as effective as "outbound filtering" if a > customer > registers its prefixes with IRR and then relies on receiving the ORF > (from its > provider) generated from the IRR. > > This should be noted in the draft. > > 3) Policy definition > > Again as pointed out many times, would "permit all" considered as an > acceptable > policy? Such policy does nothing or very little to help route leaking > reduction. > > This should also be noted in the draft. > > Regards, -- Enke > > On 5/5/17 2:34 AM, Robert Raszuk wrote: > > Hi John, > > > > If someone make a point of the discussion and stops arguing about it ib > next 100 emails does > > not mean that the rough consensus was reached on his or her comment. > > > > Honestly to me I do not see that rough consensus to adopt this change as > standard track > > document has been reached on IDRWG mailing list. > > > > Moreover document does not define what policy is. Is accepting ORF a > policy or not ? > > No clarity will lead to very inconsistent implementations. > > > > Cheers, > > R. > > > > PS I uderstand that forcing inbound policy is to push folks to apply > BCP38. But this at best is applicable only at the ISP inbound side .... > > > > On May 5, 2017 12:41 AM, "John G. Scudder" jgs@juniper.net>> wrote: > > > > Hi All, > > > > Below is my summary of this mail thread, FYI. > > > > As I understand it the next steps will be for the GROW AD (Warren) > in consultation with the GROW chairs (Pete and Chris) to decide. > > > > Thanks to all for your participation. > > > > --John > > > > The thread "[Idr] IETF LC for IDR-ish document > (Default EBGP Route Propagation > Behavior Without Policies) to Proposed Standard" started on April 19 and by > May 1 had accumulated well over a hundred messages from 27 or so > contributors. > > > > The thread defies a simple declaration of "there was consensus". > However, and somewhat to my surprise, after reading back through the > history and trying to give special attention to issues opened but > subsequently rebutted, I think we do have consensus supporting advancement. > > > > There was quite a bit of discussion about the intended status of the > document -- Standards Track vs. Informational vs. BCP, Updates 4271 or not. > In the end, I think the best we can really say is that there was no > consensus to choose something other than what the doc currently says. I've > counted those who had document status objections under "con". > > > > If it were up to me to call consensus (which it is not) I would say > there is rough consensus to advance the document on the Standards Track, > updating 4271. I might consider offering a few extra days of LC for > editorial comments *only*, with discussion of the document status and > general outline and features of the solution being placed explicitly out of > scope. This is because there were, interspersed among the many other > comments, a few editorial ones, and I just don't have the energy to figure > out if they were all taken in (although I think the authors have been > fairly diligent about this). It's also because the most recent versions of > the document have some fairly significant changes compared to -05. > > > > Several issues were raised and discussed as part of the thread, > including (but not limited to, I'm under no illusions that I've captured or > even fairly represented every single point): > > > > 1. A number of people, largely from router vendors, expressed > concern that changing defaults is difficult. These ranged from saying it > was impossible, to merely difficult and not worth it. In response to this, > others (including but not limited to other vendor folk) provided examples > for how a default could be changed without invoking a flag day. Greg > Hankins, in particular, provided a detailed explanation of his company's > process. The proponents of "it's hard to change defaults" didn't follow up > to the various rebuttals, so on the balance I would have to say they're "in > the rough". It's a bit dicey to make this call since failure to follow up > can also reflect simple fatigue, but in this case the conversation doesn't > just tail off, it ends with concrete arguments on the "this can be done" > side. > > > > 2. Related, there is the position that "yes of course anything can > be done in software but the cost/benefit ratio isn't right". This is > clearly a matter of personal taste so can't be dismissed (or supported) > solely on the basis of logic. > > > > 3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to > apply only to Internet routing and not other applications? > > Pro: the motivation section of the document calls out the Internet > use case > > Con: there's no clear, unambiguous way to actually specify this > (AFI/SAFI 1/1 can be used in a VPN context, e.g.). different defaults for > different AFI/SAFI is confusing for the user and the extra complexity not > required. > > > > 4. How about "default no-propagate" rather than "default > no-advertise"? > > Pro: Keeps CE configurations more compact, less surprising behavior. > > Con: Behavior is actually more surprising (since harder to explain, > less consistent). Doesn't cover all plausible use cases. > > > > 5. These defaults will hurt some deployments that want to rely on > the old defaults. Examples, data centers, CEs. > > Pro: as stated. > > Con: it seems unlikely anyone is actually relying on default > behavior in their data center, since defaults vary between vendors, can any > examples be brought forward? None offered, instead a couple DC operators > stated support for the draft as written. For CEs, discussion around upgrade > strategies without breaking existing deployments, see #1. > > > > 6. This should not update 4271, not be Standards Track, it should be > a BCP, should be Informational, etc. > > Pro: It's not protocol, but just defaults, doesn't affect state > machine, wire encoding. > > Con: Plenty of Standards Track documents specify defaults when > considered important to operation of protocol, and even more ephemeral > things such as textual encodings. > > Pro: It should be a BCP and/or shouldn't update 4271 because it's > bad to make existing implementations nonconformant. > > Con: Formally, it doesn't work that way. Also, the point is to ask > implementations to change. > > > > 7. There are various other proposals to mitigate route leaks and > provide BGP security features. > > Pro: implied, "we've already got one" > > Con: some of these are still in flight, not even WG docs. None > address exactly the same issues. Some don't even overlap. > > > > 8. Why not just do perfect filtering at the service provider border? > It's an education problem! > > Pro: perfect filtering prevents harm from route leaks. > > Con: decades of experience indicate strategies that require > perfection are not successful. > > > > Taking a rough head count, here's here I understand people's > positions to have ended up: > > > > Commented, no discernible position on advancing the doc -- 2 > > > > chris morrow > > alvaro retana > > > > Pro -- 16 > > > > john scudder > > randy bush > > brian dickson > > joe provo > > warren kumari > > jared mauch > > job snijders > > gert doering > > mik abrahamson > > jeff haas -- support, though would prefer BCP > > greg hankins > > nick hilliard > > jay borkenhagen > > ian dickinson > > martijn schmidt > > keyur patel > > > > Con -- On procedural grounds (should be a BCP, or should be > Informational) -- 3 > > > > eric rosen -- would be OK as Informational, opposes other statuses > > tony przygienda -- it should be a BCP > > enke chen -- fine if it's a BCP. changing defaults is infeasible > ("in the rough") > > > > Con -- In the rough -- 2 > > > > acee lindem -- contrary to auto-discovery (rebutted, in the rough), > should have a 'backwards compatibility' section > > jeff tantsura -- changing defaults "can not be changed". -- in the > rough > > > > Con -- Other objections, in most cases not explicitly stated as > opposing advancement but that's my reading of their mood -- 4 > > > > robert raszuk -- not explicitly, but has raised numerous "but what > about...", all or most replied to > > alex azimov -- 'it'll just result in empty policy' and 'route leaks > are rare anyway', both later rebutted and not replied (so, "in the rough") > > tom petch -- not explicitly, but generally skeptical tone to > comments. specifically requested an analysis of what harms the proposal > might cause. (not done or replied to AFAIK) > > bruno decraene -- would rather improve route-leak draft, numerous > other points and suggestions, mostly replied to, too much to summarize > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr < > 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 > --94eb2c0633e65ec13f054ece1dea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Top-reply, to make it easy to read the summary responses. = I speak only for myself, of course.

1) CE - either exist= ing CE stuff can handle this during upgrades (qv discussion about upgrade v= s out-of-the-box), and/or suitable warnings.=C2=A0
Use of "p= ermit all" policy achieves the desired effect on CE, and satisfies the= requirements of this standard.

2) ORF - there is = no guarantee that ORF is configured or present, and cannot be checked prior= to bringing up BGP. Thus, "No." Just, no, ORF is not adequate fo= r this.

3) Yes, permit all would be sufficient. Al= l that is needed is an *explicit* policy, regardless of what it is.

This all can be expressed by the difference between two m= athematical comparisons:
X>=3D0
X>0
If X is the place-holder for "policy", and "0&qu= ot; means no policy is configured, all that is required is ANY value of X w= hich is not 0.

There is no minimum positive value = for "X", in other words - just as long as it is not 0.
=
There is no requirement that the same rules be used by any g= iven implementation. There is no interoperability requirement, as these are= all local (implementations and policies configured).

<= div>The "X>0" must be a forcing function, so BCP is not suffic= ient.

That is the intent and purpose of "-rej= ect".

Respectfully,

= Brian

On Fri, = May 5, 2017 at 2:38 PM, Enke Chen <enkechen@cisco.com> wrot= e:
Hi, Folks:

I still believe that the draft is BCP material. In addition, I would like s= ee several
points (raised by Robert R and others) addressed in the draft:

1) Inbound filter on the CE:

=C2=A0 =C2=A0Requiring inbound filtering makes sense for the providers, and= I believe that
=C2=A0 =C2=A0is the common practice.=C2=A0 But it is not needed and has lit= tle to do with route
=C2=A0 =C2=A0leaking on the CE side.=C2=A0 Currently for the customers that= receive full routes
=C2=A0 =C2=A0or partial routes from their providers, there is no need for i= nbound filters
=C2=A0 =C2=A0(and no rational way to generate such a filter in many cases) = and they are not
=C2=A0 =C2=A0used in many cases.

=C2=A0 =C2=A0The draft should document these facts about the inbound filter= .

2) ORF:

=C2=A0 =C2=A0Certainly it would be just as effective as "outbound filt= ering" if a customer
=C2=A0 =C2=A0registers its prefixes with IRR and then relies on receiving t= he ORF (from its
=C2=A0 =C2=A0provider) generated from the IRR.

=C2=A0 =C2=A0This should be noted in the draft.

3) Policy definition

=C2=A0 =C2=A0Again as pointed out many times, would "permit all" = considered as an acceptable
=C2=A0 =C2=A0policy?=C2=A0 Such policy does nothing or very little to help = route leaking reduction.

=C2=A0 =C2=A0This should also be noted in the draft.

Regards,=C2=A0 -- Enke

On 5/5/17 2:34 AM, Robert Raszuk wrote:
> Hi John,
>
> If someone make a point of the discussion and stops arguing about it i= b next 100 emails does
> not mean that the rough consensus was reached on his or her comment. >
> Honestly to me I do not see that rough consensus to adopt this change = as standard track
> document has been reached on IDRWG mailing list.
>
> Moreover document does not define what policy is. Is accepting ORF a p= olicy or not ?
> No clarity will lead to very inconsistent implementations.
>
> Cheers,
> R.
>
> PS I uderstand that forcing inbound policy is to push folks to apply B= CP38. But this at best is applicable only at the ISP inbound side ....
>
> On May 5, 2017 12:41 AM, "John G. S= cudder" <jgs@juniper.net <= ;mailto:jgs@juniper.net>> wrot= e:
>
>=C2=A0 =C2=A0 =C2=A0Hi All,
>
>=C2=A0 =C2=A0 =C2=A0Below is my summary of this mail thread, FYI.
>
>=C2=A0 =C2=A0 =C2=A0As I understand it the next steps will be for the G= ROW AD (Warren) in consultation with the GROW chairs (Pete and Chris) to de= cide.
>
>=C2=A0 =C2=A0 =C2=A0Thanks to all for your participation.
>
>=C2=A0 =C2=A0 =C2=A0--John
>
>=C2=A0 =C2=A0 =C2=A0The thread "[Idr] IETF LC for IDR-ish document= <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propaga= tion Behavior Without Policies) to Proposed Standard" started on April= 19 and by May 1 had accumulated well over a hundred messages from 27 or so= contributors.
>
>=C2=A0 =C2=A0 =C2=A0The thread defies a simple declaration of "the= re was consensus". However, and somewhat to my surprise, after reading= back through the history and trying to give special attention to issues op= ened but subsequently rebutted, I think we do have consensus supporting adv= ancement.
>
>=C2=A0 =C2=A0 =C2=A0There was quite a bit of discussion about the inten= ded status of the document -- Standards Track vs. Informational vs. BCP, Up= dates 4271 or not. In the end, I think the best we can really say is that t= here was no consensus to choose something other than what the doc currently= says. I've counted those who had document status objections under &quo= t;con".
>
>=C2=A0 =C2=A0 =C2=A0If it were up to me to call consensus (which it is = not) I would say there is rough consensus to advance the document on the St= andards Track, updating 4271. I might consider offering a few extra days of= LC for editorial comments *only*, with discussion of the document status a= nd general outline and features of the solution being placed explicitly out= of scope. This is because there were, interspersed among the many other co= mments, a few editorial ones, and I just don't have the energy to figur= e out if they were all taken in (although I think the authors have been fai= rly diligent about this). It's also because the most recent versions of= the document have some fairly significant changes compared to -05.
>
>=C2=A0 =C2=A0 =C2=A0Several issues were raised and discussed as part of= the thread, including (but not limited to, I'm under no illusions that= I've captured or even fairly represented every single point):
>
>=C2=A0 =C2=A0 =C2=A01. A number of people, largely from router vendors,= expressed concern that changing defaults is difficult. These ranged from s= aying it was impossible, to merely difficult and not worth it. In response = to this, others (including but not limited to other vendor folk) provided e= xamples for how a default could be changed without invoking a flag day. Gre= g Hankins, in particular, provided a detailed explanation of his company= 9;s process. The proponents of "it's hard to change defaults"= didn't follow up to the various rebuttals, so on the balance I would h= ave to say they're "in the rough". It's a bit dicey to ma= ke this call since failure to follow up can also reflect simple fatigue, bu= t in this case the conversation doesn't just tail off, it ends with con= crete arguments on the "this can be done" side.
>
>=C2=A0 =C2=A0 =C2=A02. Related, there is the position that "yes of= course anything can be done in software but the cost/benefit ratio isn'= ;t right". This is clearly a matter of personal taste so can't be = dismissed (or supported) solely on the basis of logic.
>
>=C2=A0 =C2=A0 =C2=A03. Should the behavior be per-AFI/SAFI instead of g= lobal? Perhaps to apply only to Internet routing and not other applications= ?
>=C2=A0 =C2=A0 =C2=A0Pro: the motivation section of the document calls o= ut the Internet use case
>=C2=A0 =C2=A0 =C2=A0Con: there's no clear, unambiguous way to actua= lly specify this (AFI/SAFI 1/1 can be used in a VPN context, e.g.). differe= nt defaults for different AFI/SAFI is confusing for the user and the extra = complexity not required.
>
>=C2=A0 =C2=A0 =C2=A04. How about "default no-propagate" rathe= r than "default no-advertise"?
>=C2=A0 =C2=A0 =C2=A0Pro: Keeps CE configurations more compact, less sur= prising behavior.
>=C2=A0 =C2=A0 =C2=A0Con: Behavior is actually more surprising (since ha= rder to explain, less consistent). Doesn't cover all plausible use case= s.
>
>=C2=A0 =C2=A0 =C2=A05. These defaults will hurt some deployments that w= ant to rely on the old defaults. Examples, data centers, CEs.
>=C2=A0 =C2=A0 =C2=A0Pro: as stated.
>=C2=A0 =C2=A0 =C2=A0Con: it seems unlikely anyone is actually relying o= n default behavior in their data center, since defaults vary between vendor= s, can any examples be brought forward? None offered, instead a couple DC o= perators stated support for the draft as written. For CEs, discussion aroun= d upgrade strategies without breaking existing deployments, see #1.
>
>=C2=A0 =C2=A0 =C2=A06. This should not update 4271, not be Standards Tr= ack, it should be a BCP, should be Informational, etc.
>=C2=A0 =C2=A0 =C2=A0Pro: It's not protocol, but just defaults, does= n't affect state machine, wire encoding.
>=C2=A0 =C2=A0 =C2=A0Con: Plenty of Standards Track documents specify de= faults when considered important to operation of protocol, and even more ep= hemeral things such as textual encodings.
>=C2=A0 =C2=A0 =C2=A0Pro: It should be a BCP and/or shouldn't update= 4271 because it's bad to make existing implementations nonconformant.<= br> >=C2=A0 =C2=A0 =C2=A0Con: Formally, it doesn't work that way. Also, = the point is to ask implementations to change.
>
>=C2=A0 =C2=A0 =C2=A07. There are various other proposals to mitigate ro= ute leaks and provide BGP security features.
>=C2=A0 =C2=A0 =C2=A0Pro: implied, "we've already got one"=
>=C2=A0 =C2=A0 =C2=A0Con: some of these are still in flight, not even WG= docs. None address exactly the same issues. Some don't even overlap. >
>=C2=A0 =C2=A0 =C2=A08. Why not just do perfect filtering at the service= provider border? It's an education problem!
>=C2=A0 =C2=A0 =C2=A0Pro: perfect filtering prevents harm from route lea= ks.
>=C2=A0 =C2=A0 =C2=A0Con: decades of experience indicate strategies that= require perfection are not successful.
>
>=C2=A0 =C2=A0 =C2=A0Taking a rough head count, here's here I unders= tand people's positions to have ended up:
>
>=C2=A0 =C2=A0 =C2=A0Commented, no discernible position on advancing the= doc -- 2
>
>=C2=A0 =C2=A0 =C2=A0chris morrow
>=C2=A0 =C2=A0 =C2=A0alvaro retana
>
>=C2=A0 =C2=A0 =C2=A0Pro -- 16
>
>=C2=A0 =C2=A0 =C2=A0john scudder
>=C2=A0 =C2=A0 =C2=A0randy bush
>=C2=A0 =C2=A0 =C2=A0brian dickson
>=C2=A0 =C2=A0 =C2=A0joe provo
>=C2=A0 =C2=A0 =C2=A0warren kumari
>=C2=A0 =C2=A0 =C2=A0jared mauch
>=C2=A0 =C2=A0 =C2=A0job snijders
>=C2=A0 =C2=A0 =C2=A0gert doering
>=C2=A0 =C2=A0 =C2=A0mik abrahamson
>=C2=A0 =C2=A0 =C2=A0jeff haas -- support, though would prefer BCP
>=C2=A0 =C2=A0 =C2=A0greg hankins
>=C2=A0 =C2=A0 =C2=A0nick hilliard
>=C2=A0 =C2=A0 =C2=A0jay borkenhagen
>=C2=A0 =C2=A0 =C2=A0ian dickinson
>=C2=A0 =C2=A0 =C2=A0martijn schmidt
>=C2=A0 =C2=A0 =C2=A0keyur patel
>
>=C2=A0 =C2=A0 =C2=A0Con -- On procedural grounds (should be a BCP, or s= hould be Informational) -- 3
>
>=C2=A0 =C2=A0 =C2=A0eric rosen -- would be OK as Informational, opposes= other statuses
>=C2=A0 =C2=A0 =C2=A0tony przygienda -- it should be a BCP
>=C2=A0 =C2=A0 =C2=A0enke chen -- fine if it's a BCP. changing defau= lts is infeasible ("in the rough")
>
>=C2=A0 =C2=A0 =C2=A0Con -- In the rough -- 2
>
>=C2=A0 =C2=A0 =C2=A0acee lindem -- contrary to auto-discovery (rebutted= , in the rough), should have a 'backwards compatibility' section >=C2=A0 =C2=A0 =C2=A0jeff tantsura -- changing defaults "can not be= changed". -- in the rough
>
>=C2=A0 =C2=A0 =C2=A0Con -- Other objections, in most cases not explicit= ly stated as opposing advancement but that's my reading of their mood -= - 4
>
>=C2=A0 =C2=A0 =C2=A0robert raszuk -- not explicitly, but has raised num= erous "but what about...", all or most replied to
>=C2=A0 =C2=A0 =C2=A0alex azimov -- 'it'll just result in empty = policy' and 'route leaks are rare anyway', both later rebutted = and not replied (so, "in the rough")
>=C2=A0 =C2=A0 =C2=A0tom petch -- not explicitly, but generally skeptica= l tone to comments. specifically requested an analysis of what harms the pr= oposal might cause. (not done or replied to AFAIK)
>=C2=A0 =C2=A0 =C2=A0bruno decraene -- would rather improve route-leak d= raft, numerous other points and suggestions, mostly replied to, too much to= summarize
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0Idr mailing list
>=C2=A0 =C2=A0 =C2=A0Idr@iet= f.org <mailto:Idr@ietf.org> >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/l= istinfo/idr <https://www.ietf.org/mailman/listi= nfo/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

--94eb2c0633e65ec13f054ece1dea-- From nobody Fri May 5 15:09:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81668128D40; Fri, 5 May 2017 15:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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.001, 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 F83QivRlhhgp; Fri, 5 May 2017 15:09:22 -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 58E5E126E64; Fri, 5 May 2017 15:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34181; q=dns/txt; s=iport; t=1494022162; x=1495231762; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=8K4qNcY1N1wODb4QOMt6LWi9tcQnjSakP4Ypjho8ofk=; b=Sdq1sUvqejsUxr3ENKDuSSI7waqK/9xS/QNju37ywTGQuOZQsofZBjdX OUCH+opXYsibDwURH3WsS20iBS7LXngLm0qH7hrxTm+jwMAyJ9vy8YVcj /swyrSYtGQzLXs+wcBFXuLKqek1GxdmkLWmEeQl1I5/kPdZjFve/46obh k=; X-Files: showbgp2policy.c : 17650 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAQCH9wxZ/4MNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm5nYoEMB4NhihiSSI9GhTiCDyyFeAIahC8/GAECAQEBAQEBAWsohRY?= =?us-ascii?q?GIwQGXAIBCDsHAgICMCUCBAESCAYGigwOsHGBbDqKaAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQ4Phl+BXQGCZzSEQDGCeIJAHwWQGoZHhw4BhAyCE3uDM4hAgg1VgUK?= =?us-ascii?q?HCIZFlDYBHziBCm8VRoRzHBmBSnaGGIEvAYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.38,294,1491264000"; d="c'?scan'208,217";a="420331806" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2017 22:09:21 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v45M9LB6032239 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 May 2017 22:09:21 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; Fri, 5 May 2017 17:09: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; Fri, 5 May 2017 17:09:20 -0500 From: "Jakob Heitz (jheitz)" To: idr wg , "grow@ietf.org" Thread-Topic: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard Thread-Index: AQHSuS0M5jIx7MGdxkC4vGLrHY5gKKHNfK+AgAAERQCAAALDgIAAEt4AgAACugCAB6DegIAF+msAgAAJeICAAIr0gIAAEDgAgAAGkwCAAANTAIAAQPsAgABRBYCACezjQA== Date: Fri, 5 May 2017 22:09:20 +0000 Message-ID: <0b84d588d67e420d9286f56ee45d49c2@XCH-ALN-014.cisco.com> References: <9047A5A0-ED12-43C2-B2C5-D2A71CBB4373@arrcus.com> <0A49219D-E721-4DA8-B9BF-A55C2FA36FBE@puck.nether.net> 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: [128.107.147.38] Content-Type: multipart/mixed; boundary="_004_0b84d588d67e420d9286f56ee45d49c2XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 22:09:26 -0000 --_004_0b84d588d67e420d9286f56ee45d49c2XCHALN014ciscocom_ Content-Type: multipart/alternative; boundary="_000_0b84d588d67e420d9286f56ee45d49c2XCHALN014ciscocom_" --_000_0b84d588d67e420d9286f56ee45d49c2XCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXZlbiBpZiB2aW9sYXRpbmcgcm91dGVyLW9zJ3MgYXJlIHVwZGF0ZWQsIGxlYWtzIHdpbGwgY29u dGludWUgZm9yIGEgbG9uZyB0aW1lLg0KSSBob3BlIEkgY2FuIGhlbHAgb24gdGhlIGZpbHRlcmlu ZyBzaWRlLiBObyBSRkMgb3IgdmVuZG9yIGNvZGUgY2hhbmdlIHJlcXVpcmVkLg0KDQpJIHdyb3Rl IGFuIGFwcCBpbiBDIHRoYXQgdGFrZXMgdGhlIG91dHB1dCBvZiAic2hvdyBiZ3AiIGFuZCBjcmVh dGVzDQphIHNldCBvZiByb3V0ZS1wb2xpY2llcyB0aGF0IHdpbGwgcHJldmVudCB0aGUgbGVha3Mu DQpJdCBsb29rcyBhdCB0aGUgYXMtcGF0aHMsIGZpbmRzIHlvdXIgbmVpZ2hib3JzIGFuZCB0aGVu IGFsbCB0aGVpciB1cHN0cmVhbXMuDQpUaGVuIGl0IHdyaXRlcyBhcy1wYXRoIHBvbGljaWVzIHRv IGFsbG93IG9ubHkgdGhvc2UgdXBzdHJlYW1zIGZvciB5b3VyIG5laWdoYm9ycy4NCllvdSB0aGVu IHVzZSB0aGUgcG9saWN5IGluIHlvdXIgbmVpZ2hib3IgaW5ib3VuZCBwb2xpY2llcyB0byBlaXRo ZXIgZHJvcA0Kb3Igc2V0IGEgbG93IGxvY2FscHJlZi4gVGhlcmUgaXMgYSB3YXkgdG8gc2hvdyB0 aGUgcm91dGVzIHRoYXQgYXJlIGRpc2FsbG93ZWQuDQpTb3JyeSwgaXQgb25seSB3b3JrcyB3aXRo IENpc2NvLg0KVGhlIHNvdXJjZSBpcyBmcmVlIGZvciBhbnlvbmUgdG8gZG8gd2hhdGV2ZXIgdGhl eSB3YW50Lg0KT3RoZXIgdmVuZG9ycyBjYW4gYWRhcHQgaXQgYXQgd2lsbC4NCg0KQ29tcGlsZSBp dCBhdCBhIExpbnV4IGNvbW1hbmQgbGluZTsgImNjIHNob3diZ3AycG9saWN5LmMiLg0KU29ycnkg YWJvdXQgdGhlIEMsIGJ1dCBweXRob24gaXMgbm90IG15IG1vdGhlciB0b25ndWUuDQpTdGFydCB3 aXRoIG51bV9wb2xpY2llcyBvZiAzMCBhbmQgc2VlIGhvdyBpdCBsb29rcy4NCg0KDQpUaGFua3Ms DQpKYWtvYi4NCg0K --_000_0b84d588d67e420d9286f56ee45d49c2XCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBDb25zb2xlIjsNCglwYW5vc2Ut MToyIDExIDYgOSA0IDUgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNp bVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7DQoJY29s b3I6IzcwMzBBMDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJ dGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5FdmVu IGlmIHZpb2xhdGluZyByb3V0ZXItb3MncyBhcmUgdXBkYXRlZCwgbGVha3Mgd2lsbCBjb250aW51 ZSBmb3IgYSBsb25nIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+SSBob3BlIEkgY2FuIGhlbHAgb24g dGhlIGZpbHRlcmluZyBzaWRlLiBObyBSRkMgb3IgdmVuZG9yIGNvZGUgY2hhbmdlIHJlcXVpcmVk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmO2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkkgd3JvdGUgYW4gYXBw IGluIEMgdGhhdCB0YWtlcyB0aGUgb3V0cHV0IG9mICZxdW90O3Nob3cgYmdwJnF1b3Q7IGFuZCBj cmVhdGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+YSBzZXQgb2Ygcm91dGUtcG9saWNpZXMgdGhhdCB3aWxs IHByZXZlbnQgdGhlIGxlYWtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkl0IGxvb2tzIGF0IHRoZSBhcy1w YXRocywgZmluZHMgeW91ciBuZWlnaGJvcnMgYW5kIHRoZW4gYWxsIHRoZWlyIHVwc3RyZWFtcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJp Zjtjb2xvcjojNzAzMEEwIj5UaGVuIGl0IHdyaXRlcyBhcy1wYXRoIHBvbGljaWVzIHRvIGFsbG93 IG9ubHkgdGhvc2UgdXBzdHJlYW1zIGZvciB5b3VyIG5laWdoYm9ycy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEw Ij5Zb3UgdGhlbiB1c2UgdGhlIHBvbGljeSBpbiB5b3VyIG5laWdoYm9yIGluYm91bmQgcG9saWNp ZXMgdG8gZWl0aGVyIGRyb3A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5vciBzZXQgYSBsb3cgbG9jYWxwcmVm LiBUaGVyZSBpcyBhIHdheSB0byBzaG93IHRoZSByb3V0ZXMgdGhhdCBhcmUgZGlzYWxsb3dlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJp Zjtjb2xvcjojNzAzMEEwIj5Tb3JyeSwgaXQgb25seSB3b3JrcyB3aXRoIENpc2NvLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9y OiM3MDMwQTAiPlRoZSBzb3VyY2UgaXMgZnJlZSBmb3IgYW55b25lIHRvIGRvIHdoYXRldmVyIHRo ZXkgd2FudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5PdGhlciB2ZW5kb3JzIGNhbiBhZGFwdCBpdCBhdCB3 aWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmO2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkNvbXBpbGUgaXQg YXQgYSBMaW51eCBjb21tYW5kIGxpbmU7ICZxdW90O2NjIHNob3diZ3AycG9saWN5LmMmcXVvdDsu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWY7Y29sb3I6IzcwMzBBMCI+U29ycnkgYWJvdXQgdGhlIEMsIGJ1dCBweXRob24gaXMgbm90IG15 IG1vdGhlciB0b25ndWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+U3RhcnQgd2l0aCBudW1fcG9saWNpZXMg b2YgMzAgYW5kIHNlZSBob3cgaXQgbG9va3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29s b3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNp ZGEgQ29uc29sZSZxdW90Oztjb2xvcjojNzAzMEEwIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjojNzAzMEEwIj5KYWtv Yi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7 O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_0b84d588d67e420d9286f56ee45d49c2XCHALN014ciscocom_-- --_004_0b84d588d67e420d9286f56ee45d49c2XCHALN014ciscocom_ Content-Type: text/plain; name="showbgp2policy.c" Content-Description: showbgp2policy.c Content-Disposition: attachment; filename="showbgp2policy.c"; size=17650; creation-date="Fri, 05 May 2017 21:55:41 GMT"; modification-date="Fri, 05 May 2017 21:55:41 GMT" Content-Transfer-Encoding: base64 Ly8gV3JpdGUgQVMtUEFUSCBwb2xpY2llcywgZ2l2ZW4gdGhlIG91dHB1dCBvZiAic2hvdyBiZ3Ai Ci8vIEpha29iIEhlaXR6IChqaGVpdHpAY2lzY28uY29tKQovLyBUaGlzIGNvZGUgaXMgZnJlZS4g RG8gd2hhdGV2ZXIgeW91IHdhbnQuIENvbW1lbnRzIGFuZCBidWcgcmVwb3J0cyB3ZWxjb21lLgov LyBDb21waWxlIGl0IG9uIGEgTGludXggY29tbWFuZCBsaW5lIHdpdGggImNjIHNob3diZ3AycG9s aWN5LmMiLgovLyBUaGUgcmVzdWx0IGlzIHRoZSBleGVjdXRhYmxlLCBjYWxsZWQgYS5vdXQuIFJ1 biBpdC4gSXQgd2lsbCBwcmludCBoZWxwLgoKI2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVkZSA8 c3RkaW8uaD4KI2luY2x1ZGUgPHN0ZGludC5oPgojaW5jbHVkZSA8c3RyaW5nLmg+CiNpbmNsdWRl IDxzZWFyY2guaD4KI2luY2x1ZGUgPGFzc2VydC5oPgoKI2RlZmluZSBNQVhfQVNfUEFUSCAyNQoj ZGVmaW5lIE1BWF9JT1NfUEwgNTAwICAvLyBtYXhpbXVtIG51bWJlciBvZiBwb2xpY3ktbGlzdHMK CnR5cGVkZWYgZW51bSB7CiAgICBPU19OT05FID0gMCwKICAgIE9TX1hSLAogICAgT1NfSU9TCn0g cm91dGVyX29zX3Q7CiAgICAKdHlwZWRlZiBzdHJ1Y3QgewogICAgdWludDMyX3QgY291bnQ7IC8v IG51bWJlciBvZiByb3V0ZXMgdXNpbmcgdGhpcyBhcyBwYXRoCiAgICB1aW50MzJfdCBhc25bTUFY X0FTX1BBVEhdOwp9IGFzcGF0aF90OwoKLy8gYXMgYWRqYWNlbmN5Ci8vIGFzblswXSBpcyBhbiBh c24uIGFzblsxXSBpcyBpdHMgdXBzdHJlYW0uCi8vIGlmIGFzblsxXSA9PSAwLCB0aGVuIGFzblsw XSBpcyBhIG5laWdoYm9yLgp0eXBlZGVmIHN0cnVjdCB7CiAgICB1aW50MzJfdCBhc25bMl07CiAg ICB1aW50MzJfdCBjb3VudDsgLy8gbnVtYmVyIG9mIHJvdXRlcyBmcm9tIHRoaXMgbmJyIChvbmx5 IGlmIGFzblsxXT09MCkKfSBhc2FfdDsKCgp2b2lkICphc3BhdGhfdHJlZSA9IE5VTEw7CnZvaWQg KmFzYV90cmVlID0gTlVMTDsKdm9pZCAqbmJyX3RyZWUgPSBOVUxMOyAvLyBuYnJzIGluIGNvdW50 IG9yZGVyCnJvdXRlcl9vc190IHJvdXRlcl9vcyA9IE9TX05PTkU7CgpGSUxFICpmOwpjaGFyIGJ1 ZlsxMDAwXTsKaW50IG1heF9wYXRoX2xlbiA9IDA7CnVpbnQzMl90IGN1cnJlbnRfYXNuLCBsYXN0 X2FzbjsKaW50IG51bV9wb2xpY2llcywgZmlyc3RfcGFydDsKCmludApjbXBfYXNwYXRoIChjb25z dCB2b2lkICphLCBjb25zdCB2b2lkICpiKQp7CiAgICBpbnQgaTsKICAgIGFzcGF0aF90ICpwYSA9 IChhc3BhdGhfdCopYTsKICAgIGFzcGF0aF90ICpwYiA9IChhc3BhdGhfdCopYjsKICAgIAogICAg Zm9yIChpPTA7IGk8TUFYX0FTX1BBVEg7IGkrKykgewogICAgICAgIGlmIChwYS0+YXNuW2ldIDwg cGItPmFzbltpXSkgcmV0dXJuIC0xOwogICAgICAgIGlmIChwYS0+YXNuW2ldID4gcGItPmFzbltp XSkgcmV0dXJuIDE7CiAgICAgICAgaWYgKHBhLT5hc25baV0gPT0gMCAmJiBwYi0+YXNuW2ldID09 IDApIHJldHVybiAwOwogICAgfQogICAgcmV0dXJuIDA7Cn0KCmludApjbXBfYXNhIChjb25zdCB2 b2lkICphLCBjb25zdCB2b2lkICpiKQp7CiAgICBpbnQgaTsKICAgIGFzYV90ICpwYSA9IChhc2Ff dCopYTsKICAgIGFzYV90ICpwYiA9IChhc2FfdCopYjsKICAgIAogICAgZm9yIChpPTA7IGk8Mjsg aSsrKSB7CiAgICAgICAgaWYgKHBhLT5hc25baV0gPCBwYi0+YXNuW2ldKSByZXR1cm4gLTE7CiAg ICAgICAgaWYgKHBhLT5hc25baV0gPiBwYi0+YXNuW2ldKSByZXR1cm4gMTsKICAgIH0KICAgIHJl dHVybiAwOwp9CgppbnQKY21wX25iciAoY29uc3Qgdm9pZCAqYSwgY29uc3Qgdm9pZCAqYikKewog ICAgaW50IGk7CiAgICBhc2FfdCAqcGEgPSAoYXNhX3QqKWE7CiAgICBhc2FfdCAqcGIgPSAoYXNh X3QqKWI7CiAgICAKICAgIGlmIChwYS0+Y291bnQgPiBwYi0+Y291bnQpIHJldHVybiAtMTsKICAg IGlmIChwYS0+Y291bnQgPCBwYi0+Y291bnQpIHJldHVybiAxOwogICAgaWYgKHBhLT5hc25bMF0g PCBwYi0+YXNuWzBdKSByZXR1cm4gLTE7CiAgICBpZiAocGEtPmFzblswXSA+IHBiLT5hc25bMF0p IHJldHVybiAxOwogICAgcmV0dXJuIDA7Cn0KCnZvaWQKcHJpbnRfYXNhX3RyZWUgKGNvbnN0IHZv aWQgKm5vZGVwLCBjb25zdCBWSVNJVCB3aGljaCwgY29uc3QgaW50IGRlcHRoKQp7CiAgICBhc2Ff dCAqYXNhOwogICAgCiAgICBzd2l0Y2god2hpY2gpIHsKICAgIGNhc2UgcHJlb3JkZXI6CiAgICBj YXNlIGVuZG9yZGVyOgogICAgICAgIGJyZWFrOwogICAgY2FzZSBwb3N0b3JkZXI6CiAgICBjYXNl IGxlYWY6CiAgICAgICAgYXNhID0gKihhc2FfdCoqKW5vZGVwOwogICAgICAgIGlmIChhc2EtPmFz blswXSAhPSBjdXJyZW50X2FzbikgcmV0dXJuOwogICAgICAgIGlmIChhc2EtPmFzblsxXSA9PSAw KSB7CiAgICAgICAgICAgIHByaW50ZigiXG4lNnU9ICU2dToiLCBhc2EtPmNvdW50LCBhc2EtPmFz blswXSk7CiAgICAgICAgfSBlbHNlIHsKICAgICAgICAgICAgcHJpbnRmKCIgJXUiLCBhc2EtPmFz blsxXSk7CiAgICAgICAgfQogICAgICAgIGJyZWFrOwogICAgfQp9Cgp2b2lkCnByaW50X3JvdXRl X3BvbGljeSAoY29uc3Qgdm9pZCAqbm9kZXAsIGNvbnN0IFZJU0lUIHdoaWNoLCBjb25zdCBpbnQg ZGVwdGgpCnsKICAgIGFzYV90ICphc2E7CiAgICAKICAgIHN3aXRjaCh3aGljaCkgewogICAgY2Fz ZSBwcmVvcmRlcjoKICAgIGNhc2UgZW5kb3JkZXI6CiAgICAgICAgYnJlYWs7CiAgICBjYXNlIHBv c3RvcmRlcjoKICAgIGNhc2UgbGVhZjoKICAgICAgICBhc2EgPSAqKGFzYV90Kiopbm9kZXA7CiAg ICAgICAgaWYgKGFzYS0+YXNuWzBdICE9IGN1cnJlbnRfYXNuKSByZXR1cm47CiAgICAgICAgaWYg KGFzYS0+YXNuWzFdID09IDApIHsKICAgICAgICAgICAgaWYgKG51bV9wb2xpY2llcyA8PSAwKSBy ZXR1cm47CiAgICAgICAgICAgIG51bV9wb2xpY2llcy0tOwogICAgICAgICAgICAvLyBub3csIGFz blswXSBpcyB0aGUgYXNuIHRvIHdyaXRlIHRoZSBwb2xpY3kgZm9yCiAgICAgICAgICAgIGlmIChs YXN0X2FzbiAhPSAwKSB7CiAgICAgICAgICAgICAgICAvLyBlbmQgdGhlIHByZXZpb3VzIHBvbGlj eS4gRG9uJ3QgcHJpbnQgaXQgdGhlIGZpcnN0IHRpbWUKICAgICAgICAgICAgICAgIHN3aXRjaCAo cm91dGVyX29zKSB7CiAgICAgICAgICAgICAgICBjYXNlIE9TX1hSOgogICAgICAgICAgICAgICAg ICAgIHByaW50ZigiICBvclxuIgogICAgICAgICAgICAgICAgICAgICAgICAgICAiICAgICBub3Qg YXMtcGF0aCBwYXNzZXMtdGhyb3VnaCBcJyV1XCcgIHRoZW5cbiIKICAgICAgICAgICAgICAgICAg ICAgICAgICAgIiAgICBwYXNzXG4iCiAgICAgICAgICAgICAgICAgICAgICAgICAgICIgIGVuZGlm XG4iCiAgICAgICAgICAgICAgICAgICAgICAgICAgICJlbmQtcG9saWN5XG4iCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICIhXG4iLAogICAgICAgICAgICAgICAgICAgICAgICAgICBsYXN0X2Fz bik7CiAgICAgICAgICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgICAgICAgICBjYXNlIE9TX0lP UzoKICAgICAgICAgICAgICAgICAgICBwcmludGYoImlwIGFzLXBhdGggYWNjZXNzLWxpc3QgJWQg ZGVueSBeJXVfXG4iLAogICAgICAgICAgICAgICAgICAgICAgICAgICBNQVhfSU9TX1BMLTEtbnVt X3BvbGljaWVzLCBsYXN0X2Fzbik7CiAgICAgICAgICAgICAgICAgICAgcHJpbnRmKCJpcCBhcy1w YXRoIGFjY2Vzcy1saXN0ICVkIHBlcm1pdCBfJXVfXG4iLAogICAgICAgICAgICAgICAgICAgICAg ICAgICBNQVhfSU9TX1BMLTEtbnVtX3BvbGljaWVzLCBsYXN0X2Fzbik7CiAgICAgICAgICAgICAg ICB9CiAgICAgICAgICAgIH0KICAgICAgICAgICAgc3dpdGNoIChyb3V0ZXJfb3MpIHsKICAgICAg ICAgICAgY2FzZSBPU19YUjoKICAgICAgICAgICAgICAgIHByaW50Zigicm91dGUtcG9saWN5IFBM XyV1XG4iCiAgICAgICAgICAgICAgICAgICAgICAgIiAgaWYgYXMtcGF0aCBuZWlnaGJvci1pcyBc JyV1XCciLAogICAgICAgICAgICAgICAgICAgICAgIGFzYS0+YXNuWzBdLCBhc2EtPmFzblswXSk7 CiAgICAgICAgICAgICAgICBicmVhazsKICAgICAgICAgICAgY2FzZSBPU19JT1M6CiAgICAgICAg ICAgICAgICBicmVhazsKICAgICAgICAgICAgfQogICAgICAgICAgICBsYXN0X2FzbiA9IGFzYS0+ YXNuWzBdOwogICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgIGlmIChudW1fcG9saWNpZXMgPD0g MCkgcmV0dXJuOwogICAgICAgICAgICAvLyBub3csIGFzblsxXSBpcyBhbiB1cHN0cmVhbSBvZiBh c25bMF0KICAgICAgICAgICAgc3dpdGNoIChyb3V0ZXJfb3MpIHsKICAgICAgICAgICAgY2FzZSBP U19YUjoKICAgICAgICAgICAgICAgIHByaW50ZigiICBvclxuIgogICAgICAgICAgICAgICAgICAg ICAgICIgICAgIGFzLXBhdGggcGFzc2VzLXRocm91Z2ggXCcldSAgJXVcJyIsCiAgICAgICAgICAg ICAgICAgICAgICAgYXNhLT5hc25bMV0sIGFzYS0+YXNuWzBdKTsKICAgICAgICAgICAgICAgIGJy ZWFrOwogICAgICAgICAgICBjYXNlIE9TX0lPUzoKICAgICAgICAgICAgICAgIHByaW50ZigiaXAg YXMtcGF0aCBhY2Nlc3MtbGlzdCAlZCBkZW55IF8ldV8ldV9cbiIsCiAgICAgICAgICAgICAgICAg ICAgICAgTUFYX0lPU19QTC1udW1fcG9saWNpZXMsIGFzYS0+YXNuWzFdLCBhc2EtPmFzblswXSk7 CiAgICAgICAgICAgICAgICBicmVhazsKICAgICAgICAgICAgfQogICAgICAgIH0KICAgICAgICBi cmVhazsKICAgIH0KfQoKdm9pZApwcmludF9yb3V0ZV9wb2xpY3lfZmluaXNoIChjb25zdCB2b2lk ICpub2RlcCwgY29uc3QgVklTSVQgd2hpY2gsIGNvbnN0IGludCBkZXB0aCkKewogICAgYXNhX3Qg KmFzYTsKICAgIAogICAgc3dpdGNoKHdoaWNoKSB7CiAgICBjYXNlIHByZW9yZGVyOgogICAgY2Fz ZSBlbmRvcmRlcjoKICAgICAgICBicmVhazsKICAgIGNhc2UgcG9zdG9yZGVyOgogICAgY2FzZSBs ZWFmOgogICAgICAgIGFzYSA9ICooYXNhX3QqKilub2RlcDsKICAgICAgICBpZiAoYXNhLT5hc25b MF0gIT0gY3VycmVudF9hc24pIHJldHVybjsKICAgICAgICBpZiAoYXNhLT5hc25bMV0gPT0gMCkg ewogICAgICAgICAgICBudW1fcG9saWNpZXMtLTsKICAgICAgICAgICAgaWYgKG51bV9wb2xpY2ll cyA8IDApIHJldHVybjsKICAgICAgICAgICAgLy8gbm93LCBhc25bMF0gaXMgdGhlIGFzbiB0byB3 cml0ZSB0aGUgcG9saWN5IGZvcgogICAgICAgICAgICBpZiAobGFzdF9hc24gIT0gMCkgewogICAg ICAgICAgICAgICAgLy8gZW5kIHRoZSBwcmV2aW91cyBwb2xpY3kuIERvbid0IHByaW50IGl0IHRo ZSBmaXJzdCB0aW1lCiAgICAgICAgICAgICAgICBwcmludGYoIiBhbmRcbiIKICAgICAgICAgICAg ICAgICAgICAgICAiICAgICAiKTsKICAgICAgICAgICAgfQogICAgICAgICAgICBwcmludGYoImFw cGx5IFBMXyV1IiwKICAgICAgICAgICAgICAgICAgIGFzYS0+YXNuWzBdKTsKICAgICAgICAgICAg bGFzdF9hc24gPSBhc2EtPmFzblswXTsKICAgICAgICB9CiAgICAgICAgYnJlYWs7CiAgICB9Cn0K CnZvaWQKY3JlYXRlX25iciAoY29uc3Qgdm9pZCAqbm9kZXAsIGNvbnN0IFZJU0lUIHdoaWNoLCBj b25zdCBpbnQgZGVwdGgpCnsKICAgIGFzYV90ICphc2EsICoqYXNhcDsKICAgIAogICAgc3dpdGNo KHdoaWNoKSB7CiAgICBjYXNlIHByZW9yZGVyOgogICAgY2FzZSBlbmRvcmRlcjoKICAgICAgICBi cmVhazsKICAgIGNhc2UgcG9zdG9yZGVyOgogICAgY2FzZSBsZWFmOgogICAgICAgIGFzYSA9ICoo YXNhX3QqKilub2RlcDsKICAgICAgICBpZiAoYXNhLT5hc25bMV0gPT0gMCkgewogICAgICAgICAg ICBhc2FwID0gdHNlYXJjaChhc2EsICZuYnJfdHJlZSwgY21wX25icik7CiAgICAgICAgICAgIGFz c2VydCgqYXNhcCAhPSBOVUxMKTsgLy8gb3V0IG9mIG1lbW9yeQogICAgICAgIH0KICAgICAgICBi cmVhazsKICAgIH0KfQoKdm9pZApjcmVhdGVfYXNhIChjb25zdCB2b2lkICpub2RlcCwgY29uc3Qg VklTSVQgd2hpY2gsIGNvbnN0IGludCBkZXB0aCkKewogICAgYXNwYXRoX3QgKmFzcDsKICAgIGlu dCBpOwogICAgYXNhX3QgKmFzYSwgKm5iciwgKiphc2FwLCAqKm5icnA7CiAgICAKICAgIHN3aXRj aCh3aGljaCkgewogICAgY2FzZSBwcmVvcmRlcjoKICAgIGNhc2UgZW5kb3JkZXI6CiAgICAgICAg YnJlYWs7CiAgICBjYXNlIHBvc3RvcmRlcjoKICAgIGNhc2UgbGVhZjoKICAgICAgICBhc3AgPSAq KGFzcGF0aF90Kiopbm9kZXA7CiAgICAgICAgLy8gYWRkIHRoZSBuZWlnaGJvciBlbnRyeSAod2l0 aCBhc25bMV09PTApCiAgICAgICAgbmJyID0gY2FsbG9jKHNpemVvZigqbmJyKSwgMSk7CiAgICAg ICAgYXNzZXJ0KG5iciAhPSBOVUxMKTsgIC8vIG91dCBvZiBtZW1vcnkKICAgICAgICBuYnItPmFz blswXSA9IGFzcC0+YXNuWzBdOwogICAgICAgIG5ici0+YXNuWzFdID0gMDsKICAgICAgICBuYnJw ID0gdHNlYXJjaChuYnIsICZhc2FfdHJlZSwgY21wX2FzYSk7CiAgICAgICAgaWYgKG5iciAhPSAq bmJycCkgZnJlZSAobmJyKTsKICAgICAgICBhc3NlcnQoKm5icnAgIT0gTlVMTCk7IC8vIG91dCBv ZiBtZW1vcnkKICAgICAgICAoKm5icnApLT5jb3VudCArPSBhc3AtPmNvdW50OwogICAgICAgIGZv ciAoaT0wOyBpPE1BWF9BU19QQVRILTE7IGkrKykgewogICAgICAgICAgICBpZiAoYXNwLT5hc25b aSsxXSA9PSAwKSBicmVhazsKICAgICAgICAgICAgYXNhID0gY2FsbG9jKHNpemVvZigqYXNhKSwg MSk7CiAgICAgICAgICAgIGFzc2VydChhc2EgIT0gTlVMTCk7ICAvLyBvdXQgb2YgbWVtb3J5CiAg ICAgICAgICAgIGFzYS0+YXNuWzBdID0gYXNwLT5hc25baSsxXTsKICAgICAgICAgICAgYXNhLT5h c25bMV0gPSBhc3AtPmFzbltpXTsgIC8vIHRoZSB1cHN0cmVhbSBBU04KICAgICAgICAgICAgYXNh cCA9IHRzZWFyY2goYXNhLCAmYXNhX3RyZWUsIGNtcF9hc2EpOwogICAgICAgICAgICBpZiAoYXNh ICE9ICphc2FwKSBmcmVlIChhc2EpOwogICAgICAgICAgICBhc3NlcnQoKmFzYXAgIT0gTlVMTCk7 IC8vIG91dCBvZiBtZW1vcnkKICAgICAgICB9CiAgICAgICAgYnJlYWs7CiAgICB9Cn0KCnZvaWQK bmJyX3dhbGsgKGNvbnN0IHZvaWQgKm5vZGVwLCBjb25zdCBWSVNJVCB3aGljaCwgY29uc3QgaW50 IGRlcHRoKQp7CiAgICBhc2FfdCAqYXNhLCAqKmFzYXA7CiAgICAKICAgIHN3aXRjaCh3aGljaCkg ewogICAgY2FzZSBwcmVvcmRlcjoKICAgIGNhc2UgZW5kb3JkZXI6CiAgICAgICAgYnJlYWs7CiAg ICBjYXNlIHBvc3RvcmRlcjoKICAgIGNhc2UgbGVhZjoKICAgICAgICBhc2EgPSAqKGFzYV90Kiop bm9kZXA7CiAgICAgICAgLy8gY2Fubm90IHN0YXJ0IG9yIHN0b3AgdGhlIHdhbGsgaW5zaWRlIHRo ZSB0cmVlIHdpdGggdHNlYXJjaCwKICAgICAgICAvLyBzbyB3YWxrIHRoZSB3aG9sZSB0aGluZy4K ICAgICAgICAvLyBzZWxlY3QgdGhlIGNvcnJlY3QgcmVjb3JkIHdpdGggY3VycmVudF9hc24KICAg ICAgICBjdXJyZW50X2FzbiA9IGFzYS0+YXNuWzBdOwogICAgICAgIC8vdHdhbGsoYXNhX3RyZWUs IHByaW50X2FzYV90cmVlKTsKICAgICAgICBpZiAoZmlyc3RfcGFydCkgewogICAgICAgICAgICB0 d2Fsayhhc2FfdHJlZSwgcHJpbnRfcm91dGVfcG9saWN5KTsKICAgICAgICB9IGVsc2UgewogICAg ICAgICAgICB0d2Fsayhhc2FfdHJlZSwgcHJpbnRfcm91dGVfcG9saWN5X2ZpbmlzaCk7CiAgICAg ICAgfQogICAgICAgIGJyZWFrOwogICAgfQp9Cgp2b2lkCnByaW50X2FzcGF0aF90cmVlIChjb25z dCB2b2lkICpub2RlcCwgY29uc3QgVklTSVQgd2hpY2gsIGNvbnN0IGludCBkZXB0aCkKewogICAg YXNwYXRoX3QgKmFzcDsKICAgIGludCBpLCBqOwogICAgYXNhX3QgYXNhLCAqKmFzYXA7CiAgICBp bnQgcGVlcmNudDsKICAgIAogICAgc3dpdGNoKHdoaWNoKSB7CiAgICBjYXNlIHByZW9yZGVyOgog ICAgY2FzZSBlbmRvcmRlcjoKICAgICAgICBicmVhazsKICAgIGNhc2UgcG9zdG9yZGVyOgogICAg Y2FzZSBsZWFmOgogICAgICAgIGFzcCA9ICooYXNwYXRoX3QqKilub2RlcDsKICAgICAgICBwcmlu dGYoIiV1OiIsIGFzcC0+Y291bnQpOwogICAgICAgIHBlZXJjbnQgPSAwOwogICAgICAgIGZvciAo aT0wOyBpPE1BWF9BU19QQVRIOyBpKyspIHsKICAgICAgICAgICAgaWYgKGFzcC0+YXNuW2ldID09 IDApIGJyZWFrOwogICAgICAgICAgICBwcmludGYoIiAldSIsIGFzcC0+YXNuW2ldKTsKICAgICAg ICB9CiAgICAgICAgcHJpbnRmKCIgXG4iKTsKICAgICAgICBicmVhazsKICAgIH0KfQoKdm9pZApj cmVhdGVfaW9zX3BvbGljeV9saXN0cyAoaW50IG51bV9wb2xpY2llc19zYXZlKQp7CiAgICBpbnQg aTsKICAgIAogICAgLy8gd2FsayB0aGUgbmJyX3RyZWUgdG8gY3JlYXRlIGVhY2ggYWNjZXNzLWxp c3QKICAgIAogICAgZmlyc3RfcGFydCA9IDE7CiAgICBsYXN0X2FzbiA9IDA7CiAgICBudW1fcG9s aWNpZXMgPSBudW1fcG9saWNpZXNfc2F2ZTsKICAgIHR3YWxrKG5icl90cmVlLCBuYnJfd2Fsayk7 CiAgICAvLyBwcmludCB0aGUgZW5kIG9mIHRoZSBsYXN0IHBvbGljeQogICAgcHJpbnRmKCJpcCBh cy1wYXRoIGFjY2Vzcy1saXN0ICVkIGRlbnkgXiV1X1xuIiwKICAgICAgICAgICBNQVhfSU9TX1BM LW51bV9wb2xpY2llcywgbGFzdF9hc24pOwogICAgcHJpbnRmKCJpcCBhcy1wYXRoIGFjY2Vzcy1s aXN0ICVkIHBlcm1pdCBfJXVfXG4iLAogICAgICAgICAgIE1BWF9JT1NfUEwtbnVtX3BvbGljaWVz LCBsYXN0X2Fzbik7CiAgICAKICAgIC8vIGNyZWF0ZSB0aGUgcG9saWN5LWxpc3Qgd2hpY2ggbWF0 Y2hlcyBhbGwgdGhlIG90aGVycwogICAgCiAgICBwcmludGYoImlwIHBvbGljeS1saXN0IEJMT0NL X0FTIHBlcm1pdFxuIgogICAgICAgICAgICIgbWF0Y2ggYXMtcGF0aCIpOwogICAgZm9yIChpPU1B WF9JT1NfUEwrMS1udW1fcG9saWNpZXNfc2F2ZTsgaTw9TUFYX0lPU19QTC1udW1fcG9saWNpZXM7 IGkrKykgewogICAgICAgIHByaW50ZigiICV1IiwgaSk7CiAgICB9CiAgICBwcmludGYoIlxuIik7 Cn0KCnZvaWQKY3JlYXRlX2lvc194cl9wb2xpY2llcyAoaW50IG51bV9wb2xpY2llc19zYXZlKQp7 CiAgICAvLyB3YWxrIHRoZSBuYnJfdHJlZSB0byBjcmVhdGUgZWFjaCBwb2xpY3kKICAgIAogICAg Zmlyc3RfcGFydCA9IDE7CiAgICBsYXN0X2FzbiA9IDA7CiAgICBudW1fcG9saWNpZXMgPSBudW1f cG9saWNpZXNfc2F2ZTsKICAgIHR3YWxrKG5icl90cmVlLCBuYnJfd2Fsayk7CiAgICAvLyBwcmlu dCB0aGUgZW5kIG9mIHRoZSBsYXN0IHBvbGljeQogICAgcHJpbnRmKCIgIG9yXG4iCiAgICAgICAg ICAgIiAgICAgbm90IGFzLXBhdGggcGFzc2VzLXRocm91Z2ggXCcldVwnICB0aGVuXG4iCiAgICAg ICAgICAgIiAgICBwYXNzXG4iCiAgICAgICAgICAgIiAgZW5kaWZcbiIKICAgICAgICAgICAiZW5k LXBvbGljeVxuIgogICAgICAgICAgICIhXG4iLAogICAgICAgICAgIGxhc3RfYXNuKTsKCiAgICAv LyB3YWxrIHRoZSBuYnJfdHJlZSB0byBjcmVhdGUgdGhlIGFsbG93X2FzIHBvbGljeSB3aGljaCBh cHBsaWVzIGFsbCB0aGUgb3RoZXJzCiAgICAKICAgIHByaW50Zigicm91dGUtcG9saWN5IGFsbG93 X2FzXG4iCiAgICAgICAgICAgIiAgaWYgIik7CiAgICBmaXJzdF9wYXJ0ID0gMDsKICAgIGxhc3Rf YXNuID0gMDsKICAgIG51bV9wb2xpY2llcyA9IG51bV9wb2xpY2llc19zYXZlOwogICAgdHdhbGso bmJyX3RyZWUsIG5icl93YWxrKTsKICAgIHByaW50ZigiIHRoZW5cbiIKICAgICAgICAgICAiICAg IHBhc3NcbiIKICAgICAgICAgICAiICBlbmRpZlxuIgogICAgICAgICAgICJlbmQtcG9saWN5XG4i KTsKfQoKaW50Cm1haW4gKGludCBhcmdjLCBjaGFyICphcmd2W10pCnsKICAgIGNoYXIgKmNwOwog ICAgaW50IHBvcywgcmVzLCByZXMxLCBpLCBwYXRobGVuLCB0YXJnZXRfZm91bmQsIG51bV9wb2xp Y2llc19zYXZlOwogICAgdWludDMyX3QgYXNuLCBsYXN0YXNuLCB0YXJnZXRfYXNuOwogICAgYXNw YXRoX3QgKmFzcCwgKiphc3BwOwogICAgY2hhciAqcDEsICpwMiwgKiplbmRwMSwgKiplbmRwMjsK ICAgIGludCBwYXRoX29mZnMgPSAtMTsKCiAgICBpZiAoYXJnYyA9PSA1KSB7CiAgICAgICAgLy8g ZXh0cmFjdCBwYXRocyB3aXRoIHRoaXMgQVMsIGFmdGVyIHRoaXMgQVMuCiAgICAgICAgLy8gdGhh dCBtZWFucyBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoaXMgQVMuCiAgICAgICAgLy8gZ2V0 IGFsbCBwYXRocyBpZiB0aGlzIGlzIDAuCiAgICAgICAgcmVzID0gc3NjYW5mKGFyZ3ZbMl0sICIl dSIsICZ0YXJnZXRfYXNuKTsKICAgICAgICByZXMxID0gc3NjYW5mKGFyZ3ZbM10sICIlZCIsICZu dW1fcG9saWNpZXNfc2F2ZSk7CiAgICAgICAgaWYgKCFzdHJjbXAoYXJndls0XSwgIklPUy1YUiIp KSByb3V0ZXJfb3MgPSBPU19YUjsKICAgICAgICBpZiAoIXN0cmNtcChhcmd2WzRdLCAiSU9TIikp IHJvdXRlcl9vcyA9IE9TX0lPUzsKICAgICAgICAvLyBJT1Mgc3VwcG9ydHMgbm8gbW9yZSB0aGFu IDUwMCBhcy1wYXRoIGFjY2Vzcy1saXN0CiAgICAgICAgaWYgKHJvdXRlcl9vcyA9PSBPU19JT1Mg JiYgbnVtX3BvbGljaWVzX3NhdmUgPiBNQVhfSU9TX1BMKSByb3V0ZXJfb3MgPSBPU19OT05FOwog ICAgICAgIC8vIHNob3cgYmdwIGZyb20gaHR0cDovL2FyY2hpdmUucm91dGV2aWV3cy5vcmcvb2l4 LXJvdXRlLXZpZXdzLwogICAgICAgIGYgPSBmb3Blbihhcmd2WzFdLCAiciIpOwogICAgfQoKICAg IGlmIChhcmdjICE9IDUgfHwgcmVzICE9IDEgfHwgcmVzMSAhPSAxIHx8IHJvdXRlcl9vcyA9PSBP U19OT05FIHx8IGYgPT0gTlVMTCkgewogICAgICAgIGlmIChhcmdjID09IDUgJiYgcmVzID09IDEg JiYgcmVzMSA9PSAxICYmIHJvdXRlcl9vcyAhPSBPU19OT05FKSB7CiAgICAgICAgICAgIGZwcmlu dGYoc3RkZXJyLCAiQ291bGQgbm90IG9wZW4gZmlsZSAlc1xuXG4iLCBhcmd2WzFdKTsKICAgICAg ICB9CiAgICAgICAgZnByaW50ZihzdGRlcnIsICJDcmVhdGUgYSByb3V0ZS1wb2xpY3kgdG8gcHJl dmVudCByb3V0ZSBsZWFrcyBmb3IgSU9TLVhSXG4iCiAgICAgICAgICAgICAgICAic3lub3BzaXM6 XG4iCiAgICAgICAgICAgICAgICAiICBhLm91dCBzaG93X2JncCBhc24gbnVtX3BvbGljaWVzIHJv dXRlcl9vc1xuIgogICAgICAgICAgICAgICAgIndoZXJlOlxuIgogICAgICAgICAgICAgICAgImEu b3V0ICAgICAgICBpcyB0aGUgcHJvZ3JhbSBuYW1lXG4iCiAgICAgICAgICAgICAgICAic2hvd19i Z3AgICAgIGlzIHRoZSBuYW1lIG9mIGEgZmlsZSBjb250YWluaW5nIHRoZSBvdXRwdXQgb2YgXCJz aG93IGJncFwiXG4iCiAgICAgICAgICAgICAgICAiYXNuICAgICAgICAgIGlzIHRoZSBhdXRvbm9t b3VzIHN5c3RlbSBudW1iZXIgKHNlZSBiZWxvdylcbiIKICAgICAgICAgICAgICAgICJudW1fcG9s aWNpZXMgaXMgdGhlIG51bWJlciBvZiBhc25cJ3MgeW91IHdhbnQgdG8gd3JpdGUgcG9saWNpZXMg Zm9yXG4iCiAgICAgICAgICAgICAgICAicm91dGVyX29zICAgIGlzIElPUyBvciBJT1MtWFIuIFRo ZSB0YXJnZXQgT1MgZm9yIHdoaWNoIHRvIHdyaXRlIHBvbGljaWVzXG4iCiAgICAgICAgICAgICAg ICAiXG4iCiAgICAgICAgICAgICAgICAiSWYgc2hvd19iZ3AgaXMgZnJvbSB5b3VyIG93biBBUywg dGhlbiB1c2UgMCBmb3IgYXNuLlxuIgogICAgICAgICAgICAgICAgIklmIHNob3dfYmdwIGlzIGZy b20gYW5vdGhlciBBUyB0aGF0IHJlY2VpdmVzIHJvdXRlcyBmcm9tIHlvdSxcbiIKICAgICAgICAg ICAgICAgICJzdWNoIGFzIHJvdXRldmlld3Mub3JnLCB0aGVuIHVzZSB5b3VyIG93biBBU04gZm9y IGFzbi5cbiIKICAgICAgICAgICAgICAgICJUaGlzIHByb2dyYW0gd2lsbCBzY2FuIHRoZSBhcy1w YXRocyBpbiBzaG93X2JncCwgbG9va2luZyBmb3IgeW91ciBuZWlnaGJvciBBU1wncy5cbiIKICAg ICAgICAgICAgICAgICJOZXh0LCBpdCB3aWxsIHNjYW4gYWdhaW4sIGxvb2tpbmcgZm9yIHJvdXRl cyB0aGF0IGluY2x1ZGUgZWFjaCBvZiB0aG9zZVxuIgogICAgICAgICAgICAgICAgIm5laWdoYm9y cy4gRm9yIGVhY2ggb25lIHRoYXQgaXQgZmluZHMsIGl0IHdpbGwgbm90ZSB0aGUgdXBzdHJlYW0g Zm9yIHRoYXRcbiIKICAgICAgICAgICAgICAgICJuZWlnaGJvci4gSXQgd2lsbCBub3cgaGF2ZSBh IGxpc3Qgb2YgZWFjaCBvZiB5b3VyIG5laWdoYm9yIEFTXCdzIGFuZFxuIgogICAgICAgICAgICAg ICAgImVhY2ggb2YgdGhlaXIgdXBzdHJlYW0gQVMncyBvdGhlciB0aGFuIHlvdS5cbiIKICAgICAg ICAgICAgICAgICJJdCB3aWxsIGFzc3VtZSB0aGF0IGVhY2ggdXBzdHJlYW0gaXQgZmluZHMgZm9y IGEgbmVpZ2hib3IgaXMgYW4gYWxsb3dlZFxuIgogICAgICAgICAgICAgICAgInVwc3RyZWFtIEFT IHRvIHJlYWNoIHlvdS5cbiIKICAgICAgICAgICAgICAgICJOZXh0LCB0aGUgcHJvZ3JhbSB3aWxs IHdyaXRlIGEgcm91dGUtcG9saWN5IGZvciBlYWNoIG5laWdoYm9yLlxuIgogICAgICAgICAgICAg ICAgIlRoZSBwb2xpY3kgd2lsbCBkcm9wIGFueSByb3V0ZSB0aGF0IGluY2x1ZGVzIHRoZSBuZWln aGJvciBBU04gaW4gaXRzIEFTLVBBVEhcbiIKICAgICAgICAgICAgICAgICJpZiB0aGUgbmV4dCBB U04gaXMgbm90IGFuIGFsbG93ZWQgdXBzdHJlYW0uXG4iCiAgICAgICAgICAgICAgICAiTmV4dCwg aXQgd2lsbCB3cml0ZSByb3V0ZS1wb2xpY3kgYWxsb3dfYXMsIHdoaWNoIHdpbGwgYXBwbHkgYWxs IHRoZSBwcmV2aW91c2x5XG4iCiAgICAgICAgICAgICAgICAid3JpdHRlbiByb3V0ZS1wb2xpY2ll cy5cbiIKICAgICAgICAgICAgICAgICJZb3UgbWF5IG5vdyBhcHBseSB0aGlzIHBvbGljeSBpbiB5 b3VyIG93biBuZWlnaGJvciBpbmJvdW5kIHBvbGljaWVzLlxuIgogICAgICAgICAgICAgICAgIkZv ciBleGFtcGxlIGZvciBJT1MtWFI6XG4iCiAgICAgICAgICAgICAgICAiXG4iCiAgICAgICAgICAg ICAgICAicm91dGUtcG9saWN5IHlvdXJfbmVpZ2hib3JfaW5cbiIKICAgICAgICAgICAgICAgICIg IGlmIGFwcGx5IGFsbG93X2FzIHRoZW5cbiIKICAgICAgICAgICAgICAgICIgICAgcGFzc1xuIgog ICAgICAgICAgICAgICAgIiAgZWxzZVxuIgogICAgICAgICAgICAgICAgIiAgICBzZXQgY29tbXVu aXR5ICg2NTAwMDo2NjYpXG4iCiAgICAgICAgICAgICAgICAiICAgIHNldCBsb2NhbC1wcmVmZXJl bmNlIDBcbiIKICAgICAgICAgICAgICAgICIgIGVuZGlmXG4iCiAgICAgICAgICAgICAgICAiZW5k LXBvbGljeVxuIgogICAgICAgICAgICAgICAgIlxuIgogICAgICAgICAgICAgICAgIllvdSBtYXkg bGlzdCBhbGwgdGhlIHJvdXRlcyB0aGF0IHdlcmUgZGlzYWxsb3dlZCBsaWtlIHRoaXM6XG4iCiAg ICAgICAgICAgICAgICAic2hvdyBiZ3AgY29tbXVuaXR5IDY1MDAwOjY2NlxuIgogICAgICAgICAg ICAgICAgIlxuIgogICAgICAgICAgICAgICAgIklmIHJvdXRlcl9vcyBpcyBJT1MsIHRoZW4gdGhl IHByb2dyYW0gd2lsbCB3cml0ZSBhbiBpcCBwb2xpY3ktbGlzdFxuIgogICAgICAgICAgICAgICAg ImFuZCBpcCBhcy1wYXRoIGFjY2Vzcy1saXN0cyBpbnN0ZWFkIG9mIHJvdXRlLXBvbGljaWVzLlxu IgogICAgICAgICAgICAgICAgIllvdSBjYW4gbWF0Y2ggdGhlIGlwIHBvbGljeS1saXN0IGluIHlv dXIgcm91dGUtbWFwc1xuIgogICAgICAgICAgICAgICAgIlRoZSBhY2Nlc3MtbGlzdCBpbmRleGVz IHJhbmdlIGZyb20gKDUwMCAtIG51bV9wb2xpY2llcykgdG8gNTAwXG4iCiAgICAgICAgICAgICAg ICAiVGhlcmVmb3JlLCBudW1fcG9saWNpZXMgY2Fubm90IGJlID4gNTAwLlxuIgogICAgICAgICAg ICAgICAgIlxuIgogICAgICAgICAgICAgICAgIlRoZSBwcm9ncmFtIHdpbGwgb25seSB3cml0ZSB1 cCB0byB0aGUgbnVtYmVyIG9mIHBvbGljaWVzIHlvdSBzcGVjaWZ5IGluIHRoZVxuIgogICAgICAg ICAgICAgICAgIm51bV9wb2xpY2llcyBwYXJhbWV0ZXIsIHRvIGxpbWl0IHRoZSBudW1iZXIgb2Yg cG9saWNpZXMgdGhhdCBoYXZlIHRvIGJlIGV2YWx1YXRlZFxuIgogICAgICAgICAgICAgICAgImZv ciBlYWNoIHJlY2VpdmVkIHJvdXRlLiBJdCBjaG9vc2VzIHRoZSBBU05zIHRoYXQgc2VuZCB5b3Ug dGhlIG1vc3Qgcm91dGVzLlxuIgogICAgICAgICAgICAgICAgIlJvdXRlIGxlYWtzIGZyb20gdGhv c2UgQVNOcyBoYXZlIHRoZSBsYXJnZXN0IGltcGFjdC5cbiIKICAgICAgICAgICAgICAgICJUaGUg c2hvd19iZ3AgZmlsZSBpcyBhc3N1bWVkIG5vdCB0byBpbmNsdWRlIGFueSByb3V0ZSBsZWFrcyBh bHJlYWR5LlxuIgogICAgICAgICAgICAgICAgIklmIHRoZXJlIGFyZSByb3V0ZSBsZWFrcyBhbHJl YWR5LCB0aGVuIHlvdSB3aWxsIGhhdmUgdG8gZml4IHVwIHRoZSBwb2xpY2llcy5cbiIKICAgICAg ICAgICAgICAgICJcbiIKICAgICAgICAgICAgICAgICJzaG93X2JncCBjYW4gYmUgZnJvbSBhbnkg SU9TIG9yIElPUy1YUiByb3V0ZXIsIGlwdjQgb3IgaXB2Ni5cbiIKICAgICAgICAgICAgICAgICJZ b3UgY2FuIHVzZSB0aGUgcmVzdWx0aW5nIHJvdXRlLXBvbGljaWVzIGluIGFsbCByb3V0ZXJzIGlu IHRoZSBzYW1lIHJlZ2lvbiBvZiB5b3VyIEFTLlxuIgogICAgICAgICAgICAgICAgIkEgbmVpZ2hi b3IgQVMgbWF5IGhhdmUgYW4gYWxsb3dlZCB1cHN0cmVhbSBpbiBvbmUgcmVnaW9uIHRoYXQgaXMg bm90IGFsbG93ZWRcbiIKICAgICAgICAgICAgICAgICJpbiBhbm90aGVyIHJlZ2lvbi4gSW4gdGhh dCBjYXNlLCB5b3UgbmVlZCBkaWZmZXJlbnQgcG9saWNpZXMgaW4gZGlmZmVyZW50IHJlZ2lvbnMu XG4iCiAgICAgICAgICAgICAgICApOwogICAgICAgIGV4aXQoMCk7CiAgICB9CiAgICAvLyBza2lw IHRoZSBoZWFkZXIKICAgIHdoaWxlIChmZ2V0cyhidWYsIDEwMDAsIGYpKSB7CiAgICAgICAgcDEg PSBzdHJzdHIoYnVmLCAiTmV0d29yayIpOwogICAgICAgIHAyID0gc3Ryc3RyKGJ1ZiwgIlBhdGgi KTsKICAgICAgICBpZiAocDEgIT0gTlVMTCAmJiBwMiAhPSBOVUxMICYmIHAxIDwgcDIpIHsKICAg ICAgICAgICAgcGF0aF9vZmZzID0gcDIgLSBidWY7IC8vIFRoZSB3b3JkICJQYXRoIiByZXByZXNl bnRzIHRoZSBjb2x1bW4gb2YgdGhlIGFzLXBhdGgKICAgICAgICAgICAgYnJlYWs7CiAgICAgICAg fQogICAgfQogICAgYXNzZXJ0KHBhdGhfb2ZmcyA+PSAwKTsKCiAgICAvLyByZWFkIHRoZSBhcy1w YXRocyBmcm9tIHRoZSByb3V0ZXMgaW4gdGhlIHNob3cgYmdwIGZpbGUuCiAgICAvLyBzdG9yZSB0 aGUgYXMtcGF0aCBvbmx5IGFmdGVyIHRoZSB0YXJnZXRfYXNuLgogICAgLy8gaWYgdGFyZ2V0X2Fz biBpcyBub3QgaW4gdGhlIGFzLXBhdGgsIHRoZW4gaWdub3JlIHRoZSBhcy1wYXRoLgogICAgLy8g aWYgdGFyZ2V0X2Fzbj09MCwgc3RvcmUgdGhlIGVudGlyZSBhcy1wYXRoLgogICAgLy8gYXNwYXRo X3RyZWUgc3RvcmVzIHRoZSBwYXRocy4KICAgIC8vIGNvdW50IGlzIHRoZSBudW1iZXIgb2Ygcm91 dGVzIGluIHdoaWNoIGFuIGFzLXBhdGggaXMgZm91bmQuCiAgICAKICAgIHdoaWxlIChmZ2V0cyhi dWYsIDEwMDAsIGYpKSB7CiAgICAgICAgaWYgKHN0cmxlbihidWYpIDw9IHBhdGhfb2ZmcykgYnJl YWs7IC8vIHNob3cgYmdwIGlwdjYgbWF5IHNwYW4gMiBsaW5lcyBwZXIgcm91dGUKICAgICAgICBj cCA9IGJ1ZitwYXRoX29mZnM7ICAvLyBzdGFydCBhdCBhcy1wYXRoCiAgICAgICAgbGFzdGFzbiA9 IDA7CiAgICAgICAgcGF0aGxlbiA9IDA7CiAgICAgICAgdGFyZ2V0X2ZvdW5kID0gKHRhcmdldF9h c24gPT0gMCk7CiAgICAgICAgYXNwID0gY2FsbG9jKHNpemVvZigqYXNwKSwgMSk7CiAgICAgICAg YXNzZXJ0KGFzcCAhPSBOVUxMKTsgIC8vIG91dCBvZiBtZW1vcnkKICAgICAgICB3aGlsZSAoMSkg ewogICAgICAgICAgICAvLyByZWFkIHRoZSBhc24gYW5kIHBvc2l0aW9uIG9mIHRoZSBuZXh0IG9u ZQogICAgICAgICAgICByZXMgPSBzc2NhbmYoY3AsICIgJXUlbiIsICZhc24sICZwb3MpOwogICAg ICAgICAgICBpZiAocmVzICE9IDEpIGJyZWFrOyAvLyBub24tbnVtcmVpYyBvciBlb2wKICAgICAg ICAgICAgY3AgKz0gcG9zOwogICAgICAgICAgICBpZiAoKmNwID09ICcsJykgYnJlYWs7IC8vIEFT X1NFVAogICAgICAgICAgICBpZiAodGFyZ2V0X2ZvdW5kICYmIChhc24gIT0gdGFyZ2V0X2Fzbikp IHsKICAgICAgICAgICAgICAgIGlmIChhc24gIT0gbGFzdGFzbikgeyAvLyBza2lwIGR1cGxpY2F0 ZXMgKGFzIHByZXBlbmRzKQogICAgICAgICAgICAgICAgICAgIC8vcHJpbnRmKCIgJXUiLCBhc24p OwogICAgICAgICAgICAgICAgICAgIGFzcC0+YXNuW3BhdGhsZW5dID0gYXNuOwogICAgICAgICAg ICAgICAgICAgICsrcGF0aGxlbjsKICAgICAgICAgICAgICAgICAgICBpZiAocGF0aGxlbiA+IG1h eF9wYXRoX2xlbikgbWF4X3BhdGhfbGVuID0gcGF0aGxlbjsKICAgICAgICAgICAgICAgIH0KICAg ICAgICAgICAgICAgIGxhc3Rhc24gPSBhc247CiAgICAgICAgICAgIH0KICAgICAgICAgICAgaWYg KGFzbiA9PSB0YXJnZXRfYXNuKSB0YXJnZXRfZm91bmQgPSAxOwogICAgICAgIH0KICAgICAgICBp ZiAocGF0aGxlbiA9PSAwKSB7CiAgICAgICAgICAgIGZyZWUoYXNwKTsKICAgICAgICB9IGVsc2Ug ewogICAgICAgICAgICBhc3BwID0gdHNlYXJjaChhc3AsICZhc3BhdGhfdHJlZSwgY21wX2FzcGF0 aCk7IC8vIGZpbmQgb3IgYWRkCiAgICAgICAgICAgIGFzc2VydCgqYXNwcCAhPSBOVUxMKTsgIC8v IG91dCBvZiBtZW1vcnkgdG8gYWRkCiAgICAgICAgICAgICgqYXNwcCktPmNvdW50Kys7CiAgICAg ICAgICAgIGlmIChhc3AgIT0gKmFzcHApIGZyZWUgKGFzcCk7CiAgICAgICAgICAgIC8vcHJpbnRm KCIgXG4iKTsKICAgICAgICB9CiAgICB9CgogICAgLy9wcmludGYoIm1heCBwYXRoIGxlbiA9ICVk XG4iLCBtYXhfcGF0aF9sZW4pOwogICAgaWYgKG1heF9wYXRoX2xlbiA9PSAwKSB7IC8vIG5vIGFz LXBhdGhzIHJlYWQKICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIk5vIG1hdGNoaW5nIGFzLXBhdGhz IHdlcmUgZm91bmRcbiIpOwogICAgICAgIHJldHVybjsKICAgIH0KCiAgICAvLyBjcmVhdGUgdGhl IGFzYV90cmVlLgogICAgLy8gVGhpcyBzdG9yZXMgdGhlIEFTIGFkamFjZW5jaWVzLgogICAgLy8g Zm9yIGVhY2ggcmVjb3JkLCBhc25bMF0gaXMgdGhlIHN1YmplY3QgQVNOIGFuZCBhc25bMV0gaXMg YW4gdXBzdHJlYW0gb2YgYXNuWzBdLgogICAgLy8gaWYgYXNuWzFdPT0wLCB0aGVuIGNvdW50IGlz IHRoZSBudW1iZXIgb2YgdGltZXMgdGhpcyBBU04gYXBwZWFycyBpbiBhIHJvdXRlLgoKICAgIHR3 YWxrKGFzcGF0aF90cmVlLCBjcmVhdGVfYXNhKTsKICAgIC8vdHdhbGsoYXNwYXRoX3RyZWUsIHBy aW50X2FzcGF0aF90cmVlKTsKCiAgICAvLyBjcmVhdGUgdGhlIG5icl90cmVlLgogICAgLy8gVGhp cyBzdG9yZXMgdGhlIG5laWdoYm9yIEFTTnMKICAgIAogICAgdHdhbGsoYXNhX3RyZWUsIGNyZWF0 ZV9uYnIpOwoKICAgIHN3aXRjaCAocm91dGVyX29zKSB7CiAgICBjYXNlIE9TX1hSOgogICAgICAg IGNyZWF0ZV9pb3NfeHJfcG9saWNpZXMobnVtX3BvbGljaWVzX3NhdmUpOwogICAgICAgIGJyZWFr OwogICAgY2FzZSBPU19JT1M6CiAgICAgICAgY3JlYXRlX2lvc19wb2xpY3lfbGlzdHMobnVtX3Bv bGljaWVzX3NhdmUpOwogICAgICAgIGJyZWFrOwogICAgfQp9Cg== --_004_0b84d588d67e420d9286f56ee45d49c2XCHALN014ciscocom_-- From nobody Fri May 5 15:17:24 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D72126E64 for ; Fri, 5 May 2017 15:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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.001, 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 Obd_9_jqgxj0 for ; Fri, 5 May 2017 15:17:21 -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 1D0E8126DED for ; Fri, 5 May 2017 15:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7848; q=dns/txt; s=iport; t=1494022641; x=1495232241; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tR/nMidDANX8d8LprT73r3vTC/D156eCCgsGnm/NdWY=; b=azbDnIZBaE/zSKykMCp/Hje+q8Qeji7H2mn+b/yhqxs95kiILNvhTzjl lnlvxfoh/Ljc0PFAnC5vqJepCv9Yb4CZ5BN47GmaOUHbcc6dRDeCu7eX6 Y5Gww42XAQcA2KArcBElCxgw8Rb7FwSGCRUXQ33mGCERlzbKfRFcm0VwB Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAQB5+QxZ/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4NhihiRVpA4hTiCD4YkAhqELz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQEDIwpMEAIBCBEEAQEkBAMCAgIwFAkIAgQBDQUIihixAYImimgBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdhl+BXoMbhFZDglCCQB8FlmGHDgGTDZFxlDYBHzi?= =?us-ascii?q?BCm8VhW6BSnaGGYEuAYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.38,294,1491264000"; d="scan'208,217";a="422501560" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2017 22:17:20 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v45MHK8i015207 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 May 2017 22:17:20 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 5 May 2017 17:17: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; Fri, 5 May 2017 17:17:19 -0500 From: "Jakob Heitz (jheitz)" To: Brian Dickson , "Enke Chen (enkechen)" CC: idr wg , Robert Raszuk Thread-Topic: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard Thread-Index: AQHSuS0M5jIx7MGdxkC4vGLrHY5gKKHlMIGAgABi8wWAAR3+gIAAB/mA//+uUwA= Date: Fri, 5 May 2017 22:17:19 +0000 Message-ID: References: <83ea4c7c-5d17-b92d-19a4-cfa572b3f070@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.147.38] Content-Type: multipart/alternative; boundary="_000_d861a100123b4c76bb8672e93f8ab52bXCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 22:17:22 -0000 --_000_d861a100123b4c76bb8672e93f8ab52bXCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSByb3V0ZXIgY2Fubm90IHRlbGwgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB1cGdyYWRlIGFuZCBv dXQtb2YtdGhlLWJveCBpbiBnZW5lcmFsLg0KVHVybiBvbiBhbiB1bmNvbmZpZ3VyZWQgcm91dGVy IGFuZCB0aGVuIHBhc3RlIGluIGFuIGV4aXN0aW5nIGNvbmZpZ3VyYXRpb24uDQpUaGF0IGlzIGFu IHVwZ3JhZGUgdGhhdCBsb29rcyBsaWtlIG91dC1vZi10aGUtYm94Lg0KDQpUaGFua3MsDQpKYWtv Yi4NCg0KRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBCcmlhbiBEaWNrc29uDQpTZW50OiBGcmlkYXksIE1heSAwNSwgMjAxNyAzOjA3IFBNDQpUbzog RW5rZSBDaGVuIChlbmtlY2hlbikgPGVua2VjaGVuQGNpc2NvLmNvbT4NCkNjOiBpZHIgd2cgPGlk ckBpZXRmLm9yZz47IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0Pg0KU3ViamVjdDog UmU6IFtJZHJdIElFVEYgTEMgZm9yIElEUi1pc2ggZG9jdW1lbnQgPGRyYWZ0LWlldGYtZ3Jvdy1i Z3AtcmVqZWN0LTA1LnR4dD4gKERlZmF1bHQgRUJHUCBSb3V0ZSBQcm9wYWdhdGlvbiBCZWhhdmlv ciBXaXRob3V0IFBvbGljaWVzKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQoNCjEpIENFIC0gZWl0 aGVyIGV4aXN0aW5nIENFIHN0dWZmIGNhbiBoYW5kbGUgdGhpcyBkdXJpbmcgdXBncmFkZXMgKHF2 IGRpc2N1c3Npb24gYWJvdXQgdXBncmFkZSB2cyBvdXQtb2YtdGhlLWJveCksIGFuZC9vciBzdWl0 YWJsZSB3YXJuaW5ncy4NClVzZSBvZiAicGVybWl0IGFsbCIgcG9saWN5IGFjaGlldmVzIHRoZSBk ZXNpcmVkIGVmZmVjdCBvbiBDRSwgYW5kIHNhdGlzZmllcyB0aGUgcmVxdWlyZW1lbnRzIG9mIHRo aXMgc3RhbmRhcmQuDQo= --_000_d861a100123b4c76bb8672e93f8ab52bXCHALN014ciscocom_ 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 dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2Vy aWY7DQoJY29sb3I6IzcwMzBBMDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpu b3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkEgcm91dGVyIGNhbm5vdCB0ZWxs IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdXBncmFkZSBhbmQgb3V0LW9mLXRoZS1ib3ggaW4gZ2Vu ZXJhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5UdXJuIG9uIGFuIHVuY29uZmlndXJlZCByb3V0ZXIgYW5k IHRoZW4gcGFzdGUgaW4gYW4gZXhpc3RpbmcgY29uZmlndXJhdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEw Ij5UaGF0IGlzIGFuIHVwZ3JhZGUgdGhhdCBsb29rcyBsaWtlIG91dC1vZi10aGUtYm94LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2Nv bG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVj aWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6IzcwMzBBMCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6IzcwMzBBMCI+SmFr b2IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss c2VyaWY7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+QnJpYW4gRGlja3Nvbjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1heSAw NSwgMjAxNyAzOjA3IFBNPGJyPg0KPGI+VG86PC9iPiBFbmtlIENoZW4gKGVua2VjaGVuKSAmbHQ7 ZW5rZWNoZW5AY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gaWRyIHdnICZsdDtpZHJAaWV0 Zi5vcmcmZ3Q7OyBSb2JlcnQgUmFzenVrICZsdDtyb2JlcnRAcmFzenVrLm5ldCZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZHJdIElFVEYgTEMgZm9yIElEUi1pc2ggZG9jdW1lbnQgJmx0 O2RyYWZ0LWlldGYtZ3Jvdy1iZ3AtcmVqZWN0LTA1LnR4dCZndDsgKERlZmF1bHQgRUJHUCBSb3V0 ZSBQcm9wYWdhdGlvbiBCZWhhdmlvciBXaXRob3V0IFBvbGljaWVzKSB0byBQcm9wb3NlZCBTdGFu ZGFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4xKSBDRSAtIGVpdGhlciBleGlzdGluZyBDRSBzdHVmZiBjYW4gaGFuZGxlIHRo aXMgZHVyaW5nIHVwZ3JhZGVzIChxdiBkaXNjdXNzaW9uIGFib3V0IHVwZ3JhZGUgdnMgb3V0LW9m LXRoZS1ib3gpLCBhbmQvb3Igc3VpdGFibGUgd2FybmluZ3MuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Vc2Ugb2YgJnF1b3Q7cGVybWl0 IGFsbCZxdW90OyBwb2xpY3kgYWNoaWV2ZXMgdGhlIGRlc2lyZWQgZWZmZWN0IG9uIENFLCBhbmQg c2F0aXNmaWVzIHRoZSByZXF1aXJlbWVudHMgb2YgdGhpcyBzdGFuZGFyZC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_d861a100123b4c76bb8672e93f8ab52bXCHALN014ciscocom_-- From nobody Fri May 5 15:24:15 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC19126E64 for ; Fri, 5 May 2017 15:24:13 -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 Z8HjundeWp2X for ; Fri, 5 May 2017 15:24:11 -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 9C5FD126DED for ; Fri, 5 May 2017 15:24:11 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id c15so38584970ith.0 for ; Fri, 05 May 2017 15:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rEn92PwuWBRUkM9Y1rFLPalFtJv/dylQ+XMxxEEzrsk=; b=J7i34BEN25mmzHD03a2uvDHhNWfGAbrK6BmqOZ00aI3bbfouvRi6SoNRCjZiZF2kqE Y/OCSr2WN7BPo/b/DwbHy5XCjmn6b32bhC8C0HcO7dHh0eqqPFjpZy4i2yBej6uu3o4W 6tln32AosoeFJSZ3MOvyeAJgJm5L4QXcRfO7vVG/+MpUtTx+4eSpLkUQFybz9p+bH70N GBH27cOYughmkQP+gkRIMkrlq10rT3rZMRt86vr/jOmv5ljuFv+ReN+lHCDqDeXkR3PG uJAthJ4LDeeXp4nw80FDTDbc1eiqy95o9lXERWNS8fxoFe3Rr/4OeavtUk2/3aAY7jCT 3vKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rEn92PwuWBRUkM9Y1rFLPalFtJv/dylQ+XMxxEEzrsk=; b=N6ZQUcSoPi8wFe6hQk24gD5Ua2/fvR2ozvBSVf09uaKPqHpX+MS7YL7nBUExDFxRsf xUhZJHsttXJ43fxmvUYF25oV+WvWlbEUApQOWXw6n7IBEHW/F9EAFdNp3SNRAfiBCgot hI9Fts94sUOCuXvMsQzz5b5DotRTKbqvP4LqiYIMKdpJ5tZN+c0XlYwEzMxy4pD34b2b SvPmnTUqvLb9ZcF/Eg/lFmCLLkUFOVTzlF00es9KWIKRhtJXjxQS+FhvIdBzfJiICczK KQ1xZP5ywVFK+WknDX/ISU+eGFTtg9piVDNGfEqsg1iKqHE5gmrEy3Ot61vL6faKC4lL jHaw== X-Gm-Message-State: AN3rC/6LG5ZJzjeHPKb8JN82pIu79PZilqZBt2f4DjYSnuO8iSD2FAU1 wxZaq7Ja4D+SV5JaitSjY9SgjpbZVb2E X-Received: by 10.36.94.138 with SMTP id h132mr12217630itb.104.1494023051013; Fri, 05 May 2017 15:24:11 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Fri, 5 May 2017 15:24:10 -0700 (PDT) In-Reply-To: References: <83ea4c7c-5d17-b92d-19a4-cfa572b3f070@cisco.com> From: Robert Raszuk Date: Sat, 6 May 2017 00:24:10 +0200 X-Google-Sender-Auth: PPbG1QsqrEna4fJMrNrNMY7iczg Message-ID: To: Brian Dickson Cc: idr wg Content-Type: multipart/alternative; boundary=001a114252723df82e054ece5974 Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 22:24:13 -0000 --001a114252723df82e054ece5974 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, > 1) CE - either existing CE stuff can handle this during upgrades (qv > discussion about upgrade vs out-of-the-box), and/or suitable warnings. > Use of "permit all" policy achieves the desired effect on CE, and > satisfies the requirements of this standard. > =E2=80=8BAnd accomplishes nothing useful for BGP. There is so many default we can change in all protocols which will accomplish nothing other then getting new RFC then I see a lot of opportunities for 100s of new drafts. =E2=80=8B =E2=80=8BConclusion:=E2=80=8B =E2=80=8BHowever I have reconsidered and changed my mind on this draft toda= y. I fully support =E2=80=8Bit's publication as MUST DO IMMEDIATELY and to be pr= oposed standard and to update RFC4271. What I have been missing till today is that this draft makes BGP harder to configure and harder to use by vast majority of non transit ISP users. And perhaps this is the real hidden beauty of it which is to discourage users from using BGP as common application transport. Great doc ! Kind regards, Robert. --001a114252723df82e054ece5974 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,
=C2=A0
1) CE - either existing CE stuff can handle this d= uring upgrades (qv discussion about upgrade vs out-of-the-box), and/or suit= able warnings.=C2=A0
Use of "permit all" policy ach= ieves the desired effect on CE, and satisfies the requirements of this stan= dard.

=E2=80= =8BAnd accomplishes nothing useful for BGP. =C2=A0
=
There is so many default we can change in all = protocols which will accomplish nothing other then getting new RFC then I s= ee a lot of opportunities for 100s of new drafts. =E2=80=8B

=E2=80=8BConclu= sion:=E2=80=8B

=E2=80=8BHowever I have reconsidered an= d changed my mind on this draft today. I fully support =E2=80=8Bit's pu= blication as MUST DO IMMEDIATELY and to be proposed standard and to update = RFC4271.=C2=A0

What I = have been missing till today is that this draft makes BGP harder to configu= re and harder to use by vast majority of non transit ISP users.

And perhaps this is the real hidd= en beauty of it which is to discourage users from using BGP as common appli= cation transport. Great doc !

Kind regards,
Robert.



<= /div>
--001a114252723df82e054ece5974-- From nobody Fri May 5 22:43:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602F7127B52 for ; Fri, 5 May 2017 22:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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.001, 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 sj9Gme--GnGP for ; Fri, 5 May 2017 22:43:43 -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 5BB72120725 for ; Fri, 5 May 2017 22:43:42 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D0AF8A4; Sat, 6 May 2017 07:43:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1494049419; bh=v5w6DjmIne2JuXx0khK3T+aZgSB0LgNmzBYgtos7lCU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=GBRFvwkspFKB3MTlrVW4B1gDe2SzG3akf0RYJsrGpuKcxcMG1HGv9aBg1id4Wt0EC IZUAsEG1Z2TuJTHlA9Fe6xlWS6+0Sdp52bC4NwcG1YTsn+ZXm2sdEDwpcBJluFx19m JeOC4XN85gQUFXes5kwUsJ1upFpMRXwGdsN5xIGc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CBD7FA3; Sat, 6 May 2017 07:43:39 +0200 (CEST) Date: Sat, 6 May 2017 07:43:39 +0200 (CEST) From: Mikael Abrahamsson To: "Jakob Heitz (jheitz)" cc: idr wg In-Reply-To: Message-ID: References: <83ea4c7c-5d17-b92d-19a4-cfa572b3f070@cisco.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: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 05:43:45 -0000 On Fri, 5 May 2017, Jakob Heitz (jheitz) wrote: > A router cannot tell the difference between upgrade and out-of-the-box in general. > Turn on an unconfigured router and then paste in an existing configuration. > That is an upgrade that looks like out-of-the-box. Pasting in an existing configuration is out-of-the-box. Booting an existing configuration that includes operating version that created it, means change of defaults can be managed by version migration code. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sat May 6 10:10:59 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7943E120454; Sat, 6 May 2017 10:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, SPF_PASS=-0.001] autolearn=no 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 5BAJsg_QiCxK; Sat, 6 May 2017 10:10:57 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 EF903128896; Sat, 6 May 2017 10:10:56 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id c15so46308877ith.0; Sat, 06 May 2017 10:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=D6DhI5QlWRj/OhE+dr4Ax+ZCEOAFzyGE3gT0VWFpKrM=; b=WsSaQXXIRHZaK1yUsbMf50Qde+MUZj2zTUDRD6MRhmZGBQN7VdRNhisCjWNOPF/9Jb D3q1PWLtACLiO850LFPEfeQvclXPe1iHlX2L1xVS8dj1IztcwYwsr3ccGFMF485RmIq4 GvgwTMvPSMe1O+7rWInPXN8AoFmp3AMWPZ8UrbksGyPniLNIOv/ChnROxB31FRYKra9D SNiD1LuZEjpIDtuDrxzlbr2svxu3lX994uc20S+9iPvUE1MScXNnK3ckQ3j+Nh7qYNCR bImr+lTZ0YQksTKlA1IiIgLiEFZdeXGTRc+eAKIw8dksdNTP3ZUrxCNTQeOxhKCsWZyf 5rbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=D6DhI5QlWRj/OhE+dr4Ax+ZCEOAFzyGE3gT0VWFpKrM=; b=I9zskQfy0uA/f4CXRUjl/IsT2Fc2YchDINHcP2EE/QG84Jc48Fc8v67eIhOl04AE1J c01uMEIr+b/AVWwCrIwnxNkgknUKmY9Br6PG89avzJExZZtNO2NgkKUjCXcQ1zJDovB/ FNJWL0MeJzbKNlV5rABQhRebL4BfqbFl4CYyu691zp2YElX2/cSrFnHZtbif3oo/6niM bpbnOiWhl9hu0nD7N02KgMtSteq1N7lXTgXZkoqVOIycyzlN6apHi9YoNwXJLmrqMKcY hLygHo2Lov/0NPdkmZJMDy0j4YQAlT1lLxDrzZq+AoqZjKGeb+bK8SWKUZLhQxRRSde9 TffQ== X-Gm-Message-State: AN3rC/7Uo24obIbx0vpRvRY7TcReKAJQcz9dv8PsUgVBEMvhjjteSvf4 PUEsmE0yyy5txhaaa/5bVLCuZcXCiQ== X-Received: by 10.36.139.67 with SMTP id g64mr13496063ite.18.1494090656144; Sat, 06 May 2017 10:10:56 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Sat, 6 May 2017 10:10:55 -0700 (PDT) From: Robert Raszuk Date: Sat, 6 May 2017 19:10:55 +0200 X-Google-Sender-Auth: UoVjCdAa81LG1iOxXNWZm8XEmQM Message-ID: To: idr wg , "bess@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c04b7c0d293d6054ede161c Archived-At: Subject: [Idr] Point #3 on draft-ietf-grow-bgp-reject X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 17:10:58 -0000 --94eb2c04b7c0d293d6054ede161c Content-Type: text/plain; charset=UTF-8 Dear IDR and BESS WGs members, As you have either participated or seen from other email exchanges there is ongoing communication about change in eBGP specification to mandate by default use of policy in order to make all receive routes ineligible for best path and to suppress sending them to your peers. And that in spite of different opinions of the authors itself at this point is to apply to all existing and future AFI/SAFIs. John S. summarized this point as stated below: *"3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to apply only to Internet routing and not other applications?Pro: the motivation section of the document calls out the Internet use caseCon: there's no clear, unambiguous way to actually specify this (AFI/SAFI 1/1 can be used in a VPN context, e.g.). different defaults for different AFI/SAFI is confusing for the user and the extra complexity not required."* So first let me observe that technically it is very clear to know that under vrf in a VPN context (towards CEs or inter-as ASBR in option A) address family ipv4 or ipv6 unicast is configured. There is no disambiguity of it of any sort. Likewise it is also very clear when address family vpnv4 or vpnv6 is configured over eBGP Inter-AS option B or C sessions. During IDR discussion 4 individual contributors where opposed to make this proposal applicable to any eBGP AFI/SAFI and recommended to make it only for IPv4 and IPv6 existing address families. While in the same time only voice of 1 with reference to past discussion in GROW WG had taken place expressed otherwise. Well this reference to GROW list in 2016 results in one voice against, one pro and author concluding that this is pro all AFs. I think on that point if there is rough consensus at all it is really against that. Now why I am bringing this specific point up ... * There are numerous SAFIs in use today that even authors of this proposal fail to produce any valid in or out policy other then "send all/accept all". So even with good will operator will be simply forced to add those lines to the configuration. Now fun starts when an implementation code does not allow for it in some specific AFI/SAFIs or that manual policy would overwrite RTC or ORF based for L2VPN or L3VPN. That effectively means that to be complaint to this proposal implementations must change. * This draft is to update RFC4271 that means that now any newly defined AFI/SAFI will also have to define a set of policies to be used to enable it over eBGP sessions both in the draft/rfc and in the code. That clearly makes it harder for everyone with no gain. * There are address families today which are opaque to best path and are applied when received .. examples BGP-LS or Flow-spec. At most best path is run only when sending it out (if at all). The current spec does not limit reception of the information but does limit its eligibility for best path computation. I think there is room for large number of surprising behaviors with that for those SAFIs which carry opaque information to core BGP. * As the spec (as it is written today) applies to all eBGP sessions what happens if BGP UPDATE message contains in new SAFI no MP_REACH attribute at all and does not carry "routes" ? Would it be explicitly allowed ? (Example: draft-ietf-idr-operational-message-00). * As the spec (as it is written today) applies to all "routes" received or to be sent over eBGP sessions it actually fails to define what is a "route" Within MP_REACH we have a concept of NLRI which for different address families have been redefined and departed long time back from pure definition of ip route. * If BGP UPDATE message carries only MP_UNREACH attribute .. so effectively routes to be withdrawn .. are those still subject to proposed policy or not ? Therefor I would like to ask members of both working groups to express clear opinion if this proposal and update to RFC4271 specification should apply only IPv4 and IPv6 unicast (AFI/SAFI 1/1 & 2/1) or should be extended to all AFI/SAFIs we have today and we are going to invent in the future. If the majority of WG members would choose to have this change applicable to all AFI/SAFIs I do ask authors to address in the document all of the above points before proceeding forward. Kind regards, Robert. --94eb2c04b7c0d293d6054ede161c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear IDR and BESS WGs members,

As you have either participate= d or seen from other email exchanges there is ongoing communication about c= hange in eBGP specification to mandate by default use of policy in order to= make all receive routes ineligible for best path and to suppress sending t= hem to your peers. And that in spite of different opinions of the authors i= tself at this point is to apply to all existing and future AFI/SAFIs.=C2=A0=

John S. summarized th= is point as stated below:

"= 3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to apply = only to Internet routing and not other applications?
Pro: the motivation section of the document = calls out the Internet use case
Con: there's no clear, unambiguous way to actually specify th= is (AFI/SAFI 1/1 can be used in a VPN context, e.g.). different defaults fo= r different AFI/SAFI is confusing for the user and the extra complexity not= required."

So first = let me observe that technically it is very clear to know that under vrf in = a VPN context (towards CEs or inter-as ASBR in option A) address family ipv= 4 or ipv6 unicast is configured. There is no disambiguity of it of any sort= . Likewise it is also very clear when address family vpnv4 or vpnv6 is conf= igured over eBGP Inter-AS option B or C sessions.

Dur= ing IDR discussion 4 individual contributors where opposed to make this pro= posal applicable to any eBGP AFI/SAFI and recommended to make it only for I= Pv4 and IPv6 existing address families. While in the same time only voice o= f 1 with reference to past discussion in GROW WG had taken place expressed = otherwise. Well this reference=C2=A0to GROW list in 2016 results in one voi= ce against, one pro and author concluding that this is pro all AFs.=C2=A0

I think on that point if there is r= ough consensus at all it is really against that.=C2=A0
Now why I am bringing this specific point up ...

* There are numerous SAFIs in use today that even authors = of this proposal fail to produce any valid in or out policy other then &quo= t;send all/accept all". So even with good will operator will be simply= forced to add those lines to the configuration. Now fun starts when an imp= lementation code does not allow for it in some specific AFI/SAFIs or that m= anual policy would overwrite RTC or ORF based for L2VPN or L3VPN. That effe= ctively means that to be complaint to this proposal implementations must ch= ange.=C2=A0=C2=A0

* This draft is to update RFC4271 t= hat means that now any newly defined AFI/SAFI will also have to define a se= t of policies to be used to enable it over eBGP sessions both in the draft/= rfc and in the code. That clearly makes it harder for everyone with no gain= .=C2=A0

* There are address families today which are opaque to best path= and are applied when received .. examples BGP-LS or Flow-spec. At most bes= t path is run only when sending it out (if at all). The current spec does n= ot limit reception of the information but does limit its eligibility for be= st path computation. I think there is room for large number of surprising b= ehaviors=C2=A0with that for those SAFIs which carry opaque information to c= ore BGP.

* As the spec (as it is written today) applies to all eBGP sess= ions what happens if BGP UPDATE message contains in new SAFI no MP_REACH at= tribute at all and does not carry "routes" ? Would it be explicit= ly=C2=A0allowed ? (Example:=C2=A0draft-ietf-idr-operational-message-00).

*=C2=A0=C2=A0As the spec (as it is written today) applies to all "rou= tes" received or to be sent over eBGP sessions it actually fails to de= fine what is a "route" Within MP_REACH we have a concept of NLRI = which for different address families have been redefined and departed long = time back from pure definition of ip route.=C2=A0

* If BGP UPDATE messag= e carries only MP_UNREACH attribute=C2=A0.. so effectively routes to be wit= hdrawn .. are those still subject to proposed policy or not ?
<= div class=3D"gmail_default">

Therefor I would like to ask members of= both working groups to express clear opinion if this proposal and update t= o RFC4271 specification should apply only IPv4 and IPv6 unicast (AFI/SAFI 1= /1 & 2/1) or should be extended to all AFI/SAFIs we have today and we a= re going to invent in the future.=C2=A0
<= br>
If the majority of WG members would c= hoose to have this change applicable to all AFI/SAFIs I do ask authors to a= ddress in the document all of the above points before proceeding forward.= =C2=A0

Kind regards,
Robert.=C2=A0

--94eb2c04b7c0d293d6054ede161c-- From nobody Sat May 6 10:12:44 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F98120454; Sat, 6 May 2017 10:12:42 -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 eMD4anhkFjkU; Sat, 6 May 2017 10:12:41 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 C4A9C126C26; Sat, 6 May 2017 10:12:40 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id e65so23276671ita.1; Sat, 06 May 2017 10:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VS5DFREwGEiCguH1KngNs+5MG2VnDQO9ZfxWR01m7Y8=; b=NMvicBOkAyHZUdac7/DfgFsGTJIjOsB37NmHQjmjiL9HFdNcA/CTQ0ZbMDResN6du5 KR9z3FXo+eF3ermpITEv/O5ULfAzzlDJ9SflL96yZFTUZNtuGHVjVFbYkCmQZEmFmD7Y UkFW2Blkp392Bermj1EXdL+hoCnY6VCYWz9ven4+h1G6Wskj84Zh2Bb5Hiagpojvdu3C LAyf7kX7bk5ni2b3J2gIGWJWI6XaT6aSkk6hfrxwmWYynlB10GiTPaE4Ns9dXvMPvP29 J0mksNB7HHarMUCiH5LgPFujubYE1YI9du4Z/+3R2zio/dLIpHpbfHZYoMXhOmOLrKfu +F8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=VS5DFREwGEiCguH1KngNs+5MG2VnDQO9ZfxWR01m7Y8=; b=XxkskQkWv6ge2v74K7JT21CoK+lMedUdc6PfCe6vpEwEWhiR3d90VVPGx3qkONN+4l slBfL0/6GCmWIvfZNk0BIdzs9Bi2TNRSFv/Yq8gjABX8UvbgqHrWw6ZfsKIMPLxMpyF7 0rHvF/sG8NMOOtCPRpbD67ea+NhzX1BkvgYCNvKzuKf5z2CB7qTQB5/Gtf8FULSOTeJc ulliivGubye2Mxq402oq4RciVIlY4nGQj2YF57N0/67D8WqJN6DKcw37PVNVH9LPAabh rSpDAWDjsJP1H0jGVvqTrsk890KWyr7X4yRdAm4yqBP97tfWHMnY3mDYts5urICf56qF kdqw== X-Gm-Message-State: AN3rC/4MHkD+qAhhAqJj1vUwITUbph/Apc4+5JlnctmyKr8R3u2qXZLr XmhTOwjTENOUo/dYVVmHAHlmZIdK2HxI8Yc= X-Received: by 10.36.28.74 with SMTP id c71mr13353072itc.18.1494090760026; Sat, 06 May 2017 10:12:40 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Sat, 6 May 2017 10:12:39 -0700 (PDT) In-Reply-To: References: From: Robert Raszuk Date: Sat, 6 May 2017 19:12:39 +0200 X-Google-Sender-Auth: ocv_l_lDLQip1BYI66ulnD1Lf8k Message-ID: To: idr wg , "bess@ietf.org" Content-Type: multipart/alternative; boundary=001a1140574e038d29054ede1da5 Archived-At: Subject: Re: [Idr] Point #3 on draft-ietf-grow-bgp-reject X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 17:12:43 -0000 --001a1140574e038d29054ede1da5 Content-Type: text/plain; charset=UTF-8 Sorry one typo: s/to make all receive routes ineligible for best path/to make all receive routes eligible for best path/ Apologies, r. On Sat, May 6, 2017 at 7:10 PM, Robert Raszuk wrote: > Dear IDR and BESS WGs members, > > As you have either participated or seen from other email exchanges there > is ongoing communication about change in eBGP specification to mandate by > default use of policy in order to make all receive routes ineligible for > best path and to suppress sending them to your peers. And that in spite of > different opinions of the authors itself at this point is to apply to all > existing and future AFI/SAFIs. > > John S. summarized this point as stated below: > > > > > *"3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to > apply only to Internet routing and not other applications?Pro: the > motivation section of the document calls out the Internet use caseCon: > there's no clear, unambiguous way to actually specify this (AFI/SAFI 1/1 > can be used in a VPN context, e.g.). different defaults for different > AFI/SAFI is confusing for the user and the extra complexity not required."* > > So first let me observe that technically it is very clear to know that > under vrf in a VPN context (towards CEs or inter-as ASBR in option A) > address family ipv4 or ipv6 unicast is configured. There is no disambiguity > of it of any sort. Likewise it is also very clear when address family vpnv4 > or vpnv6 is configured over eBGP Inter-AS option B or C sessions. > > During IDR discussion 4 individual contributors where opposed to make this > proposal applicable to any eBGP AFI/SAFI and recommended to make it only > for IPv4 and IPv6 existing address families. While in the same time only > voice of 1 with reference to past discussion in GROW WG had taken place > expressed otherwise. Well this reference to GROW list in 2016 results in > one voice against, one pro and author concluding that this is pro all AFs. > > I think on that point if there is rough consensus at all it is really > against that. > > Now why I am bringing this specific point up ... > > * There are numerous SAFIs in use today that even authors of this proposal > fail to produce any valid in or out policy other then "send all/accept > all". So even with good will operator will be simply forced to add those > lines to the configuration. Now fun starts when an implementation code does > not allow for it in some specific AFI/SAFIs or that manual policy would > overwrite RTC or ORF based for L2VPN or L3VPN. That effectively means that > to be complaint to this proposal implementations must change. > > * This draft is to update RFC4271 that means that now any newly defined > AFI/SAFI will also have to define a set of policies to be used to enable it > over eBGP sessions both in the draft/rfc and in the code. That clearly > makes it harder for everyone with no gain. > > * There are address families today which are opaque to best path and are > applied when received .. examples BGP-LS or Flow-spec. At most best path is > run only when sending it out (if at all). The current spec does not limit > reception of the information but does limit its eligibility for best path > computation. I think there is room for large number of surprising > behaviors with that for those SAFIs which carry opaque information to core > BGP. > > * As the spec (as it is written today) applies to all eBGP sessions what > happens if BGP UPDATE message contains in new SAFI no MP_REACH attribute at > all and does not carry "routes" ? Would it be explicitly allowed ? > (Example: draft-ietf-idr-operational-message-00). > > * As the spec (as it is written today) applies to all "routes" received > or to be sent over eBGP sessions it actually fails to define what is a > "route" Within MP_REACH we have a concept of NLRI which for different > address families have been redefined and departed long time back from pure > definition of ip route. > > * If BGP UPDATE message carries only MP_UNREACH attribute .. so > effectively routes to be withdrawn .. are those still subject to proposed > policy or not ? > > > Therefor I would like to ask members of both working groups to express > clear opinion if this proposal and update to RFC4271 specification should > apply only IPv4 and IPv6 unicast (AFI/SAFI 1/1 & 2/1) or should be extended > to all AFI/SAFIs we have today and we are going to invent in the future. > > If the majority of WG members would choose to have this change applicable > to all AFI/SAFIs I do ask authors to address in the document all of the > above points before proceeding forward. > > Kind regards, > Robert. > > --001a1140574e038d29054ede1da5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry one typo:

s/to make all receive routes ineligible for b= est path/to make all receive routes eligible for best path/

Apologies,
r.=


On Sat, May 6, 2017 at 7:10 PM, Robert Raszuk <rob= ert@raszuk.net> wrote:
Dear IDR and BESS WGs members,

As you have either participated or= seen from other email exchanges there is ongoing communication about chang= e in eBGP specification to mandate by default use of policy in order to mak= e all receive routes ineligible for best path and to suppress sending them = to your peers. And that in spite of different opinions of the authors itsel= f at this point is to apply to all existing and future AFI/SAFIs.=C2=A0

John S. summarized this p= oint as stated below:

= "3. S= hould the behavior be per-AFI/SAFI instead of global? Perhaps to apply only= to Internet routing and not other applications?
Pro: the motivation section of the document call= s out the Internet use case
Con: there's no clear, unambiguous way to actually specify this (= AFI/SAFI 1/1 can be used in a VPN context, e.g.). different defaults for di= fferent AFI/SAFI is confusing for the user and the extra complexity not req= uired."

= So first let = me observe that technically it is very clear to know that under vrf in a VP= N context (towards CEs or inter-as ASBR in option A) address family ipv4 or= ipv6 unicast is configured. There is no disambiguity of it of any sort. Li= kewise it is also very clear when address family vpnv4 or vpnv6 is configur= ed over eBGP Inter-AS option B or C sessions.

=
During = IDR discussion 4 individual contributors where opposed to make this proposa= l applicable to any eBGP AFI/SAFI and recommended to make it only for IPv4 = and IPv6 existing address families. While in the same time only voice of 1 = with reference to past discussion in GROW WG had taken place expressed othe= rwise. Well this reference=C2=A0to GROW list in 2016 results in one voice a= gainst, one pro and author concluding that this is pro all AFs.=C2=A0

I think on that point if there is rough= consensus at all it is really against that.=C2=A0

=
Now why I am bringing this specific point up ...<= /div>

* There are numerous SAFIs in use today that even authors of= this proposal fail to produce any valid in or out policy other then "= send all/accept all". So even with good will operator will be simply f= orced to add those lines to the configuration. Now fun starts when an imple= mentation code does not allow for it in some specific AFI/SAFIs or that man= ual policy would overwrite RTC or ORF based for L2VPN or L3VPN. That effect= ively means that to be complaint to this proposal implementations must chan= ge.=C2=A0=C2=A0

* This draft is to update RFC4271 tha= t means that now any newly defined AFI/SAFI will also have to define a set = of policies to be used to enable it over eBGP sessions both in the draft/rf= c and in the code. That clearly makes it harder for everyone with no gain.= =C2=A0

* There are address families today which are opaque to best path = and are applied when received .. examples BGP-LS or Flow-spec. At most best= path is run only when sending it out (if at all). The current spec does no= t limit reception of the information but does limit its eligibility for bes= t path computation. I think there is room for large number of surprising be= haviors=C2=A0with that for those SAFIs which carry opaque information to co= re BGP.

* As the spec (as it is written today) applies to all eBGP sessi= ons what happens if BGP UPDATE message contains in new SAFI no MP_REACH att= ribute at all and does not carry "routes" ? Would it be explicitl= y=C2=A0allowed ? (Example:=C2=A0draft-ietf-idr-operational-message-00)= .

*=C2=A0=C2=A0As the spec (as it is written today) applies to all "= ;routes" received or to be sent over eBGP sessions it actually fails t= o define what is a "route" Within MP_REACH we have a concept of N= LRI which for different address families have been redefined and departed l= ong time back from pure definition of ip route.=C2=A0

* If BGP UPDATE me= ssage carries only MP_UNREACH attribute=C2=A0.. so effectively routes to be= withdrawn .. are those still subject to proposed policy or not ?


Therefor I would like to ask member= s of both working groups to express clear opinion if this proposal and upda= te to RFC4271 specification should apply only IPv4 and IPv6 unicast (AFI/SA= FI 1/1 & 2/1) or should be extended to all AFI/SAFIs we have today and = we are going to invent in the future.=C2=A0

If the majority of WG members wou= ld choose to have this change applicable to all AFI/SAFIs I do ask authors = to address in the document all of the above points before proceeding forwar= d.=C2=A0

Kind regards,
Robert.=C2=A0
<= div class=3D"gmail_default">

--001a1140574e038d29054ede1da5-- From nobody Sun May 7 09:25:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2197127419; Sun, 7 May 2017 09:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, 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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 LQGNryx86ipi; Sun, 7 May 2017 09:24:56 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-oln040092002086.outbound.protection.outlook.com [40.92.2.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B810B126CE8; Sun, 7 May 2017 09:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kKo0QH+qBJVhmG2XkhXF575Tm+a3SsrsiAtaX5bBmqY=; b=Tn6fCq33yZTZl5D8z3bgYmDgg7+A2CkJIvyFb2xJzNURkfDd19lWMqy4w5xfUpq1+KEHB9GCMzUmOUb2GyDPq4F1cofSYEE1w5bFRE2hkP63HHNBPk2dSdB1ith41PEb1cjlSMfTTVDQQv5QiQkufuYa4CiY1yBUxSJrnla6oeUnPmGa4NFLOJfGPAp7cyQwDetoqmYyL0/DIP3Fy+9p8f6Kl/NVUDUNoeklTzlWMWS10D+BoIF70WelS0ktRnCE/7dho612sS7Lc7y8PwC1u+GbyTfcU43j7GK4y1I3rV++NqQhqz7ohi+uHf8xcfBrTtQDuIdfhbZnXAJlSpj2ZQ== Received: from BY2NAM01FT042.eop-nam01.prod.protection.outlook.com (10.152.68.56) by BY2NAM01HT162.eop-nam01.prod.protection.outlook.com (10.152.69.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1047.9; Sun, 7 May 2017 16:24:51 +0000 Received: from BY2PR13MB0789.namprd13.prod.outlook.com (10.152.68.57) by BY2NAM01FT042.mail.protection.outlook.com (10.152.68.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.9 via Frontend Transport; Sun, 7 May 2017 16:24:51 +0000 Received: from BY2PR13MB0789.namprd13.prod.outlook.com ([10.164.169.9]) by BY2PR13MB0789.namprd13.prod.outlook.com ([10.164.169.9]) with mapi id 15.01.1084.015; Sun, 7 May 2017 16:24:51 +0000 From: Shitanshu Shah To: Joe Clarke , "ops-dir@ietf.org" CC: "idr@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" , "ietf@ietf.org" Thread-Topic: Opsdir early review of draft-ietf-idr-sla-exchange-10 Thread-Index: AQHSxb5nxADcrfnZeka1+vZACdnIwqHpDDyz Date: Sun, 7 May 2017 16:24:51 +0000 Message-ID: References: <149400246349.8370.5477015906856459639@ietfa.amsl.com> In-Reply-To: <149400246349.8370.5477015906856459639@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:9947602216EA64DA54798EE7E0DBB43BF8CA4EA66D3787559058E746134C9E83; UpperCasedChecksum:FB6F99646E28FD6EC73285E1F2ECC6DF11186E66E207CB58E1E58037583D9B9D; SizeAsReceived:8401; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [zOxyrrItBaR2YR0G0S3aMsEUZ8oL5Dms] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2NAM01HT162; 5:z7UxWQ5bzRXQMnigOgIkya26vYqAP9hq66AKI3g4o8WUrOh/V9fB45xlcJWhswxHpp+So6XFVsG643bawWwoUNp6SM01HRR6zrVX6bhZHOePrn3oYKTtlug8TsfJd3+fNDYWgwAO4CL162f2Cge6VQ==; 24:IcGx9C1a1sedwUU9d6deGO1YqpsJGfsJQmcY1AQ1MdsDKZZfo0bzAk6V1cJLWsAtsPnvJipZVjZwKJDFnMBIDxvZ44lflJrc8tpodFwtBgw=; 7:reqrmVHYQWbPVA1UivLzqFfUwHWkvdIpP6ukYLyH/dVpPKNRc2EYueL4c340YqAaKFXCuF2x3dgT3j4XSZOhzJwYlcNf0YwIrslv+1GdlbtklcnaR05RuDvh/ncfV7xq2DDBQgfPRT7tGm/X0DC5pUwQVinTfRaO8bQggHOQIeLX2kltsUZwUbs7Z/dyss/9th7ThfNfj2neil9pFa9TqCMWrZcAySWsHuT8o2hpZ7MVTLfLY6ech7DZDoj3GflsynVcFSIugdCpLUIma5v0wXaHIXA9ZhXpPGin8XPrgN48fS2FajpygWKs8EDJ5Hl0 x-incomingheadercount: 46 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BY2NAM01HT162; H:BY2PR13MB0789.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: bc771417-6762-411d-8f90-08d49565965b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1603101448)(1601125374)(1701031045); SRVR:BY2NAM01HT162; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BY2NAM01HT162; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM01HT162; x-forefront-prvs: 03008837BD spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR13MB07892B8E9249E59ED7CE692AE5E90BY2PR13MB0789namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2017 16:24:51.1494 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM01HT162 Archived-At: Subject: Re: [Idr] Opsdir early review of draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 16:24:58 -0000 --_000_BY2PR13MB07892B8E9249E59ED7CE692AE5E90BY2PR13MB0789namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ________________________________ From: Joe Clarke Sent: Friday, May 5, 2017 10:41 AM To: ops-dir@ietf.org Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@ietf.org Subject: Opsdir early review of draft-ietf-idr-sla-exchange-10 Reviewer: Joe Clarke Review result: Has Issues I have been asked to do a review of this draft as a representative of OPS-DIR. This draft lays out a means to exchange SLA/QoS policies via BGP UPDATE messages. Overall, I found this draft a bit difficult to read. There are grammatical issues such as the user of "thru" instead of "through", odd commas, and missing articles. But this is not a grammatical overview. I think this draft would benefit from some examples that show what some practical QoS policies would look like that convey the required classes within the maximum BGP message size (that is, in section 7 add more specific examples of what policies may look like in the ADVERTISE messages). What do the authors feel typical uses of this would look like from the UPDATE message perspective? What kind of processing overhead can one typically expect if a router, for example, will be the QoS Attribute Speaker and SLA Consumer? Below are some specific per-section questions and issues: Section 2: You state that a BGP Speaker need not be a QoS Attribute Speaker, but even if the QoS data is opaque to the BGP Speaker, it would still need to know that the QoS Attribute Speaker exists and there is data to be added to the UPDATE. So why the two entities don't need to be co-resident in the same process, a BGP Speaker needs to be QoS aware to some extent in order for this exchange to work. Additionally, why are SLA Producer and Consumer broken out whereas QoS and BGP just have "speakers?" For consistency, maybe you just state that there exists an SLA-aware QoS Attribute Speaker. You do not define NLRI and AFI/SAFI in your terminology. =3D=3D=3D Section 3.2: Why the need to have the SLA SubType Flags be set to 0? Couldn't you just as easily set the Source AS and Destination AS Counts to 0? You state that a value of 0 for Source AS when flags are 1 is illegal, so I believe this would work. For SLA ID, you state: The SLA ID applies to aggregate traffic to prefixes for a given AFI/SAFI that share the same Source AS and SLA ID. The SLA ID applies to aggregate traffic that shares the same SLA ID? This seems circular to me. I'm not really clear on how I would allocate an SLA ID and how I align that with the intended QoS policies. Would the intent of having a 0-length SLA Content be to remove the policy for the given prefixes? I'm not clear exactly as to that use case. I'm confused a bit as to how the Destination AS List works. Initially, I thought this would only be set by the sending AS to indicate to which external ASes the content applies. However, each QoS Attribute Speaker can update the Destination AS List. In Sections 4.1.2, 5.1 and 5.2 you attempt to address this, but it is still not clear what kind of updating or trimming of the Destination AS list should be done (and in Section 5.2 you allude to rules to trim the Destination AS List, but I did not see those rules). This could be clarified with an example of what can happen at various hops in the network. =3D=3D=3D Section 3.3: Related to a point above, if the SLA Content needs to be set per direction, would I use the same SLA ID to do that? I don't think that's clear enough in the current text. You state: Any Traffic Class Element advertised in the QoS Attribute only applies to the advertised AFI/SAFI NLRI within the BGP UPDATE message the QoS Attribute is contained in. However, if I understand correctly, I could specify IPFIX attributes of sourceIPv6Prefix and/or destinationIPv6Prefix that does not line up with the NLRIs, would that not constitute an error? Or Maybe my AFI/SAFI are 1/1, and I'm trying to match IPv6. This seems more like an error, but you only state what to do if the AFI/SAFI is not supported. =3D=3D=3D Section 3.3.2.2: Why have such a huge range for length here? I can specify that the number of bytes to specify the amount of L2 overhead to use is 255. Why not advise that length should be 4, and then use an IEEE FP number like you did for the TSPEC? At the very least, I think this should be reined in a bit. =3D=3D=3D Section 3.3.2.7: I think you have a typo in precedence. I think you want to say: - MINRATE_IN_PROFILE_MARKING takes highest precedence (that is over MAXRATE_IN_PROFILE_MARKING), - MAXRATE_IN_PROFILE_MARKING takes precedence over MINRATE_OUT_PROFILE_MARKING, and - MINRATE_OUT_PROFILE_MARKING takes precedence over MAXRATE_OUT_PROFILE_MARKING =3D=3D=3D Section 5.2 What I did not see is what the actual SLA Consumer should do after it processes the SLA Content. I realize this can delve into implementation details, but perhaps it's worth mentioning that the SLA Consumer can use protocols like NETCONF or RESTCONF to configure the policies on the necessary interfaces. --_000_BY2PR13MB07892B8E9249E59ED7CE692AE5E90BY2PR13MB0789namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable




From: Joe Clarke <jcla= rke@cisco.com>
Sent: Friday, May 5, 2017 10:41 AM
To: ops-dir@ietf.org
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org; ietf@iet= f.org
Subject: Opsdir early review of draft-ietf-idr-sla-exchange-10
 
Reviewer: Joe Clarke
Review result: Has Issues

I have been asked to do a review of this draft as a representative of
OPS-DIR.  This draft lays out a means to exchange SLA/QoS policies via=
BGP UPDATE messages.

Overall, I found this draft a bit difficult to read.  There are
grammatical issues such as the user of "thru" instead of "th= rough",
odd commas, and missing articles.  But this is not a grammatical
overview.

I think this draft would benefit from some examples that show what
some practical QoS policies would look like that convey the required
classes within the maximum BGP message size (that is, in section 7 add
more specific examples of what policies may look like in the ADVERTISE
messages).  What do the authors feel typical uses of this would look like from the UPDATE message perspective?  What kind of processing
overhead can one typically expect if a router, for example, will be
the QoS Attribute Speaker and SLA Consumer?

Below are some specific per-section questions and issues:

Section 2:

You state that a BGP Speaker need not be a QoS Attribute Speaker, but
even if the QoS data is opaque to the BGP Speaker, it would still need
to know that the QoS Attribute Speaker exists and there is data to be
added to the UPDATE.  So why the two entities don't need to be
co-resident in the same process, a BGP Speaker needs to be QoS aware
to some extent in order for this exchange to work.

Additionally, why are SLA Producer and Consumer broken out whereas QoS
and BGP just have "speakers?"  For consistency, maybe you ju= st state
that there exists an SLA-aware QoS Attribute Speaker.

You do not define NLRI and AFI/SAFI in your terminology.

=3D=3D=3D

Section 3.2:

Why the need to have the SLA SubType Flags be set to 0?  Couldn't you<= br> just as easily set the Source AS and Destination AS Counts to 0?  You<= br> state that a value of 0 for Source AS when flags are 1 is illegal, so
I believe this would work.

For SLA ID, you state:

The SLA ID applies to aggregate traffic to prefixes for a given
AFI/SAFI that share the same Source AS and SLA ID.

The SLA ID applies to aggregate traffic that shares the same SLA ID?
This seems circular to me.  I'm not really clear on how I would
allocate an SLA ID and how I align that with the intended QoS
policies.

Would the intent of having a 0-length SLA Content be to remove the
policy for the given prefixes?  I'm not clear exactly as to that use case.

I'm confused a bit as to how the Destination AS List works.
Initially, I thought this would only be set by the sending AS to
indicate to which external ASes the content applies.  However, each QoS Attribute Speaker can update the Destination AS List.  In Sections=
4.1.2, 5.1 and 5.2 you attempt to address this, but it is still not
clear what kind of updating or trimming of the Destination AS list
should be done (and in Section 5.2 you allude to rules to trim the
Destination AS List, but I did not see those rules).  This could be clarified with an example of what can happen at various hops in the
network.

=3D=3D=3D

Section 3.3:

Related to a point above, if the SLA Content needs to be set per
direction, would I use the same SLA ID to do that?  I don't think
that's clear enough in the current text.

You state:

Any Traffic Class Element advertised in the QoS Attribute only
applies to the advertised AFI/SAFI NLRI within the BGP UPDATE
message the QoS Attribute is contained in.

However, if I understand correctly, I could specify IPFIX attributes
of sourceIPv6Prefix and/or destinationIPv6Prefix that does not line up
with the NLRIs, would that not constitute an error?  Or Maybe my
AFI/SAFI are 1/1, and I'm trying to match IPv6.  This seems more like<= br> an error, but you only state what to do if the AFI/SAFI is not
supported.

=3D=3D=3D

Section 3.3.2.2:

Why have such a huge range for length here?  I can specify that the number of bytes to specify the amount of L2 overhead to use is 255.
Why not advise that length should be 4, and then use an IEEE FP number
like you did for the TSPEC?  At the very least, I think this should be=
reined in a bit.

=3D=3D=3D

Section 3.3.2.7:

I think you have a typo in precedence.  I think you want to say:

- MINRATE_IN_PROFILE_MARKING takes highest precedence (that is
    over MAXRATE_IN_PROFILE_MARKING),

- MAXRATE_IN_PROFILE_MARKING takes precedence over
   MINRATE_OUT_PROFILE_MARKING, and

- MINRATE_OUT_PROFILE_MARKING takes precedence over
   MAXRATE_OUT_PROFILE_MARKING

=3D=3D=3D

Section 5.2

What I did not see is what the actual SLA Consumer should do after it
processes the SLA Content.  I realize this can delve into
implementation details, but perhaps it's worth mentioning that the SLA
Consumer can use protocols like NETCONF or RESTCONF to configure the
policies on the necessary interfaces.


--_000_BY2PR13MB07892B8E9249E59ED7CE692AE5E90BY2PR13MB0789namp_-- From nobody Sun May 7 14:53:29 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE7C126B7F; Sun, 7 May 2017 14:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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.001, 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 9qDG-ajqE2fv; Sun, 7 May 2017 14: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 1B79F12009C; Sun, 7 May 2017 14:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8330; q=dns/txt; s=iport; t=1494194006; x=1495403606; h=from:subject:to:cc:references:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=AxM1amj0/11O9jS37mItZyVcdyQwDEhs6IRez8zdsqQ=; b=UugkxZtuAxm/YJXRh77TrXiYFzDzEm6sPJKiawIUS8/WaxvEGYFc2wGs 1VjWV7agbM+2c1SwvHy7dN/YH7SJxVOZ3Igac6uSldQEKDAbFJTaAChVY rmjTn8Cau1hEoXJdskWy0z+6HQVHl+cI/HWFxL9VL6f5E9GM8OOJ875ZF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAAASlg9Z/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1WPbpFUcpUAgg+GJAKEST8YAQIBAQEBAQEBayiFFQEBAQECAXk?= =?us-ascii?q?FCwsYLlcGDQgBAYoUCLIEil0BAQEBAQEBAQIBAQEBAQEBIYZfgV4rgjw0ikwBB?= =?us-ascii?q?JZmhxOKT4hJggSFPINDI4ZGiHyLQh84gQpPIRVGhHEDHIF/JIceK4IQAQEB?= X-IronPort-AV: E=Sophos;i="5.38,305,1491264000"; d="scan'208";a="240503394" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 May 2017 21:53:25 +0000 Received: from [10.118.87.89] (rtp-jclarke-nitro8.cisco.com [10.118.87.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v47LrO98019739; Sun, 7 May 2017 21:53:24 GMT From: Joe Clarke To: Shitanshu Shah Cc: idr@ietf.org, draft-ietf-idr-sla-exchange.all@ietf.org References: <149400246349.8370.5477015906856459639@ietfa.amsl.com> Organization: Cisco Message-ID: <804fa340-7cba-e27a-e115-f5e675948396@cisco.com> Date: Sun, 7 May 2017 17:53:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] Opsdir early review of draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 21:53:28 -0000 [Correcting typo for idr@] Thank you for your reply, Shitanshu. Re-adding authors and WG. Please see my inline comments below. On 5/7/17 13:29, Shitanshu Shah wrote: > > I think this draft would benefit from some examples that show what > some practical QoS policies would look like that convey the required > classes within the maximum BGP message size (that is, in section 7 add > more specific examples of what policies may look like in the ADVERTISE > messages). > > ##svshah, The moment we get into defining QoS policies, it gets into > vendor specifics. The draft purposefully, as one of its motivation, > wants to stay away from vendor specifics in SLA exchange. Is there > anything in specific you have in mind without getting into > implementation or vendor specifics? I thought the purpose of the draft was to provide a vendor-neutral way of exchanging QoS/SLA policies. What I was specifically asking for is an example of what the fields within the packets may look like for a given exchange. That is, take some of the IPFIX parameters and specify a specific example exchange of attributes. I don't see how doing this would be vendor-specific. > > > What do the authors feel typical uses of this would look > like from the UPDATE message perspective? What kind of processing > overhead can one typically expect if a router, for example, will be > the QoS Attribute Speaker and SLA Consumer? > > ##svshah, one possible implementation can be is to asynchronously > enqueue/dequeue messages from QoS Attribute Speaker to actual QoS > functional component and thus limiting inline processing overhead to > simply forming or parsing of QoS Attribute messages. Parsing of messages > would be function of scale and frequency of SLA policy updates in a > use-case. Not sure if this answers your question? My overall point was that I feel some text should be added to the draft to help an operator know what they might expect from added overhead. Given that there are operators as authors of this draft, perhaps there are recommendations to implementors of what operators expect for the overhead involved with this capability. > > > > Below are some specific per-section questions and issues: > > Section 2: > > You state that a BGP Speaker need not be a QoS Attribute Speaker, but > even if the QoS data is opaque to the BGP Speaker, it would still need > to know that the QoS Attribute Speaker exists and there is data to be > added to the UPDATE. So why the two entities don't need to be > co-resident in the same process, a BGP Speaker needs to be QoS aware > to some extent in order for this exchange to work. > > ##svshah, The intention is to have a logical separation, that defines > functional responsibility separation, between BGP Speaker and QoS > Attribute Speaker. It does not necessarily mandate them to be in a > separate process. With appropriate modularity, they can reside in a same > process for a given implementation. I completely understand that. My point was that a BGP Speaker does need to be _aware_ of a QoS Attribute Speaker. > > > > Additionally, why are SLA Producer and Consumer broken out whereas QoS > and BGP just have "speakers?" For consistency, maybe you just state > that there exists an SLA-aware QoS Attribute Speaker. > > ##svshah, Producer and Consumer are broken out to explicitly define > function of QoS Attribute Speaker at the node that is creating and > sending a message vs at the node that is receiving and consuming a message. Understood. I just thought it was odd to specifically list those two when you could have done the same for QoS Attribute Speaker. This isn't a big deal, mainly semantics, but I wanted to point it out. > For SLA ID, you state: > > The SLA ID applies to aggregate traffic to prefixes for a given > AFI/SAFI that share the same Source AS and SLA ID. > > The SLA ID applies to aggregate traffic that shares the same SLA ID? > This seems circular to me. I'm not really clear on how I would > allocate an SLA ID and how I align that with the intended QoS > policies. > > ##svshah, Taking an example, what it means to suggest is that if a > Source AS first had advertised an SLA with SLA ID s1 for prefix x.x.x.x. > And then later some time if same Source AS advertises SLA ID s1 for > prefix x.x.y.y then SLA for ID s1 is applicable to the aggregate traffic > x.x.x.x+x.x.y.y Got it. This is the kind of thing adding a specific example of the packet contents would help clarify. Still, I think the wording is confusing. Perhaps you want to say something like: Using a common SLA ID allows traffic with a given AFI/SAFI from different prefixes to be treated as an aggregate. > > > Would the intent of having a 0-length SLA Content be to remove the > policy for the given prefixes? I'm not clear exactly as to that use > case. > > ##svshah, We provide a provision of removing SLA content if there need > to be. I personally do not have any specific use-case where SLA to be > removed once established. May be a QOS SLA Producer implement > modification in two steps which removes followed by an addition? It could be that one AS no longer trusts another in terms of SLA. In any event, what is the intent of having a 0-length SLA Content? > I'm confused a bit as to how the Destination AS List works. > Initially, I thought this would only be set by the sending AS to > indicate to which external ASes the content applies. However, each > QoS Attribute Speaker can update the Destination AS List. In Sections > 4.1.2, 5.1 and 5.2 you attempt to address this, but it is still not > clear what kind of updating or trimming of the Destination AS list > should be done (and in Section 5.2 you allude to rules to trim the > Destination AS List, but I did not see those rules). This could be > clarified with an example of what can happen at various hops in the > network. > > ##svshah, ok. we will take a look at to address it. Thanks. > You state: > > Any Traffic Class Element advertised in the QoS Attribute only > applies to the advertised AFI/SAFI NLRI within the BGP UPDATE > message the QoS Attribute is contained in. > > However, if I understand correctly, I could specify IPFIX attributes > of sourceIPv6Prefix and/or destinationIPv6Prefix that does not line up > with the NLRIs, would that not constitute an error? > > ##svshah, we do not define that as an error. This is a QoS Producer > defined SLA and if content of produced SLA is no-op or how meaningful it > is, is completely scope of QOS SLA Producer. The SLA exchange mechanism > does not need to read SLA content to validate meaning of the SLA content. But given your text that if my QoS Attribute traffic class definition uses prefixes that are out of range from the NLRI, that would be an error? > Section 3.3.2.2: > > Why have such a huge range for length here? I can specify that the > number of bytes to specify the amount of L2 overhead to use is 255. > Why not advise that length should be 4, and then use an IEEE FP number > like you did for the TSPEC? At the very least, I think this should be > reined in a bit. > > ##svshah, sure. Infact this field is changed based on comments/feed-back > from David's review. And in the new definition of that field, we > have/will take care of as per your suggestion. Thanks. > > Section 5.2 > > What I did not see is what the actual SLA Consumer should do after it > processes the SLA Content. I realize this can delve into > implementation details, but perhaps it's worth mentioning that the SLA > Consumer can use protocols like NETCONF or RESTCONF to configure the > policies on the necessary interfaces. > > ##svshah, yeah, as you state it, this would get into implementation > details. Besides netconf/restconf, infact implementations may be in the > NOS itself (it does not necessarily need netconf/restconf interface) > just like it can be in the case of flow-spec implementations. Can you add a small bit of text to this effect? To me, I read through this whole draft and was surprised there wasn't any direct mention of what is done with the processed SLA. Thanks. Joe From nobody Sun May 7 19:35:13 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A2F126C2F; Sun, 7 May 2017 19:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, 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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 cFHGG5j3zR7m; Sun, 7 May 2017 19:35:08 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-oln040092001069.outbound.protection.outlook.com [40.92.1.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 9350A1243F3; Sun, 7 May 2017 19:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KI8la2o5saZneFViC0lnRJqBl+hVbsgY36ob63HRrDk=; b=EsmP5Hw4+mwlkikyzqBgFhlK6Q4OTnYZl2bCMJEDszqC32+1cGnSy6oB+nDzIIapPaba0XZzWS4YB0W0+V+DWzH3YIWEdzYmvZcfX5DE+WGNUzSoQSr79ImPZ0X7RTdd1o/lyWUqA/PGQeBdesZCECmPtjfrnWeJQHw0JbcMJzeaJMCT/mkxhDkfEB35SAVpG2ggflyOdvfajrMrRHcG+kEneA6QnNfXSKyuQSpa1qWKxxzpLZE3Bpxhnt0XvXQGvIsUxyHWEs21mqtisKW+xCYq4NxFEXQrnJ5gAc6uN0ywsWXn2ulAjTp64BYS4mnOMDFbFvITPYqydYVHhYusGg== Received: from BN3NAM01FT020.eop-nam01.prod.protection.outlook.com (10.152.66.56) by BN3NAM01HT038.eop-nam01.prod.protection.outlook.com (10.152.66.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1047.9; Mon, 8 May 2017 02:35:07 +0000 Received: from BY2PR13MB0789.namprd13.prod.outlook.com (10.152.66.54) by BN3NAM01FT020.mail.protection.outlook.com (10.152.67.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.9 via Frontend Transport; Mon, 8 May 2017 02:35:07 +0000 Received: from BY2PR13MB0789.namprd13.prod.outlook.com ([10.164.169.9]) by BY2PR13MB0789.namprd13.prod.outlook.com ([10.164.169.9]) with mapi id 15.01.1084.015; Mon, 8 May 2017 02:35:07 +0000 From: Shitanshu Shah To: Joe Clarke CC: "idr@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" Thread-Topic: Opsdir early review of draft-ietf-idr-sla-exchange-10 Thread-Index: AQHSxb5nxADcrfnZeka1+vZACdnIwqHpEXF3gABbxQCAAETs5g== Date: Mon, 8 May 2017 02:35:07 +0000 Message-ID: References: <149400246349.8370.5477015906856459639@ietfa.amsl.com> , <804fa340-7cba-e27a-e115-f5e675948396@cisco.com> In-Reply-To: <804fa340-7cba-e27a-e115-f5e675948396@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:359665FA20C8CDBEEBFAD12268C5E134AE4F9053E68AD351CD36CE2D230F5288; UpperCasedChecksum:03D9CCF792B5761B1CAD3838D81CAE8B294FCEB96A1FD6D714370DF36BF02D7B; SizeAsReceived:8475; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [fUceTCcL9gszE8MV05tMp6F3F19AdLsL] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM01HT038; 5:vCCBVdT0mVVB+3Oq3znhKQauUbwlQ8ZMVbKMxT2ELVV0FuIoDdKVbbjnkIm+XfhiJ4XSvOylD48nI8Z8jjUgEhURwD0VkSHHw7qzgXGyPurXnt7PlkNd5FvvpazOWxgoOpBg0iHnpf84ogJVapFD+w==; 24:qgopqybVDKlwrjtBcaycpjVJHvmCUih2ZMDeAOxsZdQhUPX4cQEXEHWuCYqrC8ZjCGPvkBkF9HWWysy6vpUgT91IO/h6aK19yr0tmXg5MOw=; 7:Uz3LdqB/+pADNCmFBS8wzYPKlKaJ4+rkoG7/o585G8ly94WtDmt8RMrxeJkbPot0kcpjXn5W4f+M5m50fQf8mLPp/2rx52qsx4QLSkqKXGSxbPI2/mE4PmkSY9MbAlgy87/yipeKFjwGHaGR+wGRP56iMM7cnh5CgHjvlYmYkM8o/BW/9aLN8NPP7EYtFyb+t562qlnBkSFtvPoO3sCKCJhY13Y/tEPAaqEjO5PBXD8VnUIBChcAG+dd4mUw5kn33OhH0aCMYGsVNQyq1UhOJst3GGVUGFFq/CpRcGR6EClH282nGK7oFvapOfESw+lc x-incomingheadercount: 46 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT038; H:BY2PR13MB0789.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: d1c1f68e-6368-4559-a32b-08d495bad753 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:BN3NAM01HT038; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BN3NAM01HT038; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT038; x-forefront-prvs: 0301360BF5 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR13MB0789AB36F5F3E51DC5129C61E5EE0BY2PR13MB0789namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2017 02:35:07.3558 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT038 Archived-At: Subject: Re: [Idr] Opsdir early review of draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 02:35:11 -0000 --_000_BY2PR13MB0789AB36F5F3E51DC5129C61E5EE0BY2PR13MB0789namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joe, Please find response inline ##svshah2 ________________________________ From: Joe Clarke Sent: Sunday, May 7, 2017 3:53 PM To: Shitanshu Shah Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org Subject: Re: Opsdir early review of draft-ietf-idr-sla-exchange-10 [Correcting typo for idr@] Thank you for your reply, Shitanshu. Re-adding authors and WG. Please see my inline comments below. On 5/7/17 13:29, Shitanshu Shah wrote: > > I think this draft would benefit from some examples that show what > some practical QoS policies would look like that convey the required > classes within the maximum BGP message size (that is, in section 7 add > more specific examples of what policies may look like in the ADVERTISE > messages). > > ##svshah, The moment we get into defining QoS policies, it gets into > vendor specifics. The draft purposefully, as one of its motivation, > wants to stay away from vendor specifics in SLA exchange. Is there > anything in specific you have in mind without getting into > implementation or vendor specifics? I thought the purpose of the draft was to provide a vendor-neutral way of exchanging QoS/SLA policies. What I was specifically asking for is an example of what the fields within the packets may look like for a given exchange. That is, take some of the IPFIX parameters and specify a specific example exchange of attributes. I don't see how doing this would be vendor-specific. ##svshah2, got it. I think example in this form certainly can be added. > > > What do the authors feel typical uses of this would look > like from the UPDATE message perspective? What kind of processing > overhead can one typically expect if a router, for example, will be > the QoS Attribute Speaker and SLA Consumer? > > ##svshah, one possible implementation can be is to asynchronously > enqueue/dequeue messages from QoS Attribute Speaker to actual QoS > functional component and thus limiting inline processing overhead to > simply forming or parsing of QoS Attribute messages. Parsing of messages > would be function of scale and frequency of SLA policy updates in a > use-case. Not sure if this answers your question? My overall point was that I feel some text should be added to the draft to help an operator know what they might expect from added overhead. Given that there are operators as authors of this draft, perhaps there are recommendations to implementors of what operators expect for the overhead involved with this capability. ##svshah2, sure, we can add such a text. Do you have suggestion on exactly = which section should such a text go to? > > > > Below are some specific per-section questions and issues: > > Section 2: > > You state that a BGP Speaker need not be a QoS Attribute Speaker, but > even if the QoS data is opaque to the BGP Speaker, it would still need > to know that the QoS Attribute Speaker exists and there is data to be > added to the UPDATE. So why the two entities don't need to be > co-resident in the same process, a BGP Speaker needs to be QoS aware > to some extent in order for this exchange to work. > > ##svshah, The intention is to have a logical separation, that defines > functional responsibility separation, between BGP Speaker and QoS > Attribute Speaker. It does not necessarily mandate them to be in a > separate process. With appropriate modularity, they can reside in a same > process for a given implementation. I completely understand that. My point was that a BGP Speaker does need to be _aware_ of a QoS Attribute Speaker. > > > > Additionally, why are SLA Producer and Consumer broken out whereas QoS > and BGP just have "speakers?" For consistency, maybe you just state > that there exists an SLA-aware QoS Attribute Speaker. > > ##svshah, Producer and Consumer are broken out to explicitly define > function of QoS Attribute Speaker at the node that is creating and > sending a message vs at the node that is receiving and consuming a messag= e. Understood. I just thought it was odd to specifically list those two when you could have done the same for QoS Attribute Speaker. This isn't a big deal, mainly semantics, but I wanted to point it out. > For SLA ID, you state: > > The SLA ID applies to aggregate traffic to prefixes for a given > AFI/SAFI that share the same Source AS and SLA ID. > > The SLA ID applies to aggregate traffic that shares the same SLA ID? > This seems circular to me. I'm not really clear on how I would > allocate an SLA ID and how I align that with the intended QoS > policies. > > ##svshah, Taking an example, what it means to suggest is that if a > Source AS first had advertised an SLA with SLA ID s1 for prefix x.x.x.x. > And then later some time if same Source AS advertises SLA ID s1 for > prefix x.x.y.y then SLA for ID s1 is applicable to the aggregate traffic > x.x.x.x+x.x.y.y Got it. This is the kind of thing adding a specific example of the packet contents would help clarify. Still, I think the wording is confusing. Perhaps you want to say something like: Using a common SLA ID allows traffic with a given AFI/SAFI from different prefixes to be treated as an aggregate. ##svshah2, sounds good. thanks for the suggested text. > > > Would the intent of having a 0-length SLA Content be to remove the > policy for the given prefixes? I'm not clear exactly as to that use > case. > > ##svshah, We provide a provision of removing SLA content if there need > to be. I personally do not have any specific use-case where SLA to be > removed once established. May be a QOS SLA Producer implement > modification in two steps which removes followed by an addition? It could be that one AS no longer trusts another in terms of SLA. In any event, what is the intent of having a 0-length SLA Content? ##svshah2, sorry, I realize that my previous response did not address your = original question completely. Regarding intent of having 0-legnth SLA content, If Producer (a specific Source AS) had advertised SLA ID s1, with SLA conte= nt, to a specific prefix before. And now, if same Producer intents to adver= tise exact same SLA ID s1 for additional prefix, then Producer should not r= equire to send SLA content again which was already sent before. 0-length SL= A content exactly achieves the same. > I'm confused a bit as to how the Destination AS List works. > Initially, I thought this would only be set by the sending AS to > indicate to which external ASes the content applies. However, each > QoS Attribute Speaker can update the Destination AS List. In Sections > 4.1.2, 5.1 and 5.2 you attempt to address this, but it is still not > clear what kind of updating or trimming of the Destination AS list > should be done (and in Section 5.2 you allude to rules to trim the > Destination AS List, but I did not see those rules). This could be > clarified with an example of what can happen at various hops in the > network. > > ##svshah, ok. we will take a look at to address it. Thanks. > You state: > > Any Traffic Class Element advertised in the QoS Attribute only > applies to the advertised AFI/SAFI NLRI within the BGP UPDATE > message the QoS Attribute is contained in. > > However, if I understand correctly, I could specify IPFIX attributes > of sourceIPv6Prefix and/or destinationIPv6Prefix that does not line up > with the NLRIs, would that not constitute an error? > > ##svshah, we do not define that as an error. This is a QoS Producer > defined SLA and if content of produced SLA is no-op or how meaningful it > is, is completely scope of QOS SLA Producer. The SLA exchange mechanism > does not need to read SLA content to validate meaning of the SLA content. But given your text that if my QoS Attribute traffic class definition uses prefixes that are out of range from the NLRI, that would be an error? ##svshah2, Just taking an example if Producer advertises SLA where traffic = class definition is for prefix 172.x.x.x for the NLRI meant for 152.x.x.x,= then that has no operational effect in actual forwarding. This kind of thi= ngs can be categorized into what we would typically call "mis-configuration= " in the Producer's SLA definition. We don't want to look into decoding val= id/invalid meaning of such SLA content. Another example, if SLA content def= inition was to advertised a rate that is higher than actual underlying forw= arding interface rate (where SLA is received from). so forth. > Section 3.3.2.2: > > Why have such a huge range for length here? I can specify that the > number of bytes to specify the amount of L2 overhead to use is 255. > Why not advise that length should be 4, and then use an IEEE FP number > like you did for the TSPEC? At the very least, I think this should be > reined in a bit. > > ##svshah, sure. Infact this field is changed based on comments/feed-back > from David's review. And in the new definition of that field, we > have/will take care of as per your suggestion. Thanks. > > Section 5.2 > > What I did not see is what the actual SLA Consumer should do after it > processes the SLA Content. I realize this can delve into > implementation details, but perhaps it's worth mentioning that the SLA > Consumer can use protocols like NETCONF or RESTCONF to configure the > policies on the necessary interfaces. > > ##svshah, yeah, as you state it, this would get into implementation > details. Besides netconf/restconf, infact implementations may be in the > NOS itself (it does not necessarily need netconf/restconf interface) > just like it can be in the case of flow-spec implementations. Can you add a small bit of text to this effect? To me, I read through this whole draft and was surprised there wasn't any direct mention of what is done with the processed SLA. ##svshah2, We have intended to highlight the scope in the 4th paragraph in = the Introduction section. The SLA by the Consumer may be processed to imple= ment forwarding policy or Consumer may do something less or more than that.= It is not scope of this document though. Hopefully, the highlighted paragr= aph is clearer in that. Regards, Shitanshu Thanks. Joe --_000_BY2PR13MB0789AB36F5F3E51DC5129C61E5EE0BY2PR13MB0789namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


Hi Joe,


Please find response inline ##svshah2



From: Joe Clarke <jcla= rke@cisco.com>
Sent: Sunday, May 7, 2017 3:53 PM
To: Shitanshu Shah
Cc: idr@ietf.org; draft-ietf-idr-sla-exchange.all@ietf.org
Subject: Re: Opsdir early review of draft-ietf-idr-sla-exchange-10
 
[C= orrecting typo for idr@]

Thank you for your reply, Shitanshu.

Re-adding authors and WG.  Please see my inline comments below.

On 5/7/17 13:29, Shitanshu Shah wrote:
>
> I think this draft would benefit from some examples that show what
> some practical QoS policies would look like that convey the required > classes within the maximum BGP message size (that is, in section 7 add=
> more specific examples of what policies may look like in the ADVERTISE=
> messages).
>
> ##svshah, The moment we get into defining QoS policies, it gets into > vendor specifics. The draft purposefully, as one of its motivation, > wants to stay away from vendor specifics in SLA exchange. Is there
> anything in specific you have in mind without getting into
> implementation or vendor specifics?

I thought the purpose of the draft was to provide a vendor-neutral way
of exchanging QoS/SLA policies.  What I was specifically asking for is=
an example of what the fields within the packets may look like for a
given exchange.  That is, take some of the IPFIX parameters and specif= y
a specific example exchange of attributes.  I don't see how doing this=
would be vendor-specific.

##svshah2, got it. I think example in this form certainly can be added= .

>
>
>   What do the authors feel typical uses of this would look > like from the UPDATE message perspective?  What kind of processin= g
> overhead can one typically expect if a router, for example, will be > the QoS Attribute Speaker and SLA Consumer?
>
> ##svshah, one possible implementation can be is to asynchronously
> enqueue/dequeue messages from QoS Attribute Speaker to actual QoS
> functional component and thus limiting inline processing overhead to > simply forming or parsing of QoS Attribute messages. Parsing of messag= es
> would be function of scale and frequency of SLA policy updates in a > use-case. Not sure if this answers your question?

My overall point was that I feel some text should be added to the draft
to help an operator know what they might expect from added overhead.
Given that there are operators as authors of this draft, perhaps there
are recommendations to implementors of what operators expect for the
overhead involved with this capability.

##svshah2, sure, we can add such a text. Do you have suggestion on exactly = which section should such a text go to?

>
>
>
> Below are some specific per-section questions and issues:
>
> Section 2:
>
> You state that a BGP Speaker need not be a QoS Attribute Speaker, but<= br> > even if the QoS data is opaque to the BGP Speaker, it would still need=
> to know that the QoS Attribute Speaker exists and there is data to be<= br> > added to the UPDATE.  So why the two entities don't need to be > co-resident in the same process, a BGP Speaker needs to be QoS aware > to some extent in order for this exchange to work.
>
> ##svshah, The intention is to have a logical separation, that defines<= br> > functional responsibility separation, between BGP Speaker and QoS
> Attribute Speaker. It does not necessarily mandate them to be in a
> separate process. With appropriate modularity, they can reside in a sa= me
> process for a given implementation.

I completely understand that.  My point was that a BGP Speaker does ne= ed
to be _aware_ of a QoS Attribute Speaker.

>
>
>
> Additionally, why are SLA Producer and Consumer broken out whereas QoS=
> and BGP just have "speakers?"  For consistency, maybe y= ou just state
> that there exists an SLA-aware QoS Attribute Speaker.
>
> ##svshah, Producer and Consumer are broken out to explicitly define > function of QoS Attribute Speaker at the node that is creating and
> sending a message vs at the node that is receiving and consuming a mes= sage.

Understood.  I just thought it was odd to specifically list those two<= br> when you could have done the same for QoS Attribute Speaker.  This isn= 't
a big deal, mainly semantics, but I wanted to point it out.

> For SLA ID, you state:
>
> The SLA ID applies to aggregate traffic to prefixes for a given
> AFI/SAFI that share the same Source AS and SLA ID.
>
> The SLA ID applies to aggregate traffic that shares the same SLA ID? > This seems circular to me.  I'm not really clear on how I would > allocate an SLA ID and how I align that with the intended QoS
> policies.
>
> ##svshah, Taking an example, what it means to suggest is that if a
> Source AS first had advertised an SLA with SLA ID s1 for prefix x.x.x.= x.
> And then later some time if same Source AS advertises SLA ID s1 for > prefix x.x.y.y then SLA for ID s1 is applicable to the aggregate traff= ic
> x.x.x.x+x.x.y.y

Got it.  This is the kind of thing adding a specific example of the packet contents would help clarify.  Still, I think the wording is
confusing.  Perhaps you want to say something like:

Using a common SLA ID allows traffic with a given AFI/SAFI from
different prefixes to be treated as an aggregate.

##svshah2, sounds good. thanks for the suggested text.

>
>
> Would the intent of having a 0-length SLA Content be to remove the
> policy for the given prefixes?  I'm not clear exactly as to that = use
> case.
>
> ##svshah, We provide a provision of removing SLA content if there need=
> to be. I personally do not have any specific use-case where SLA to be<= br> > removed once established. May be a QOS SLA Producer implement
> modification in two steps which removes followed by an addition?

It could be that one AS no longer trusts another in terms of SLA.  In<= br> any event, what is the intent of having a 0-length SLA Content?
##= svshah2, sorry, I realize that my previous response did not address yo= ur original question completely.
Re= garding intent of having 0-legnth SLA content,
If= Producer (a specific Source AS) had advertised SLA ID s1, with SLA content= , to a specific prefix before. And now, if same Producer intents to adverti= se exact same SLA ID s1 for additional prefix, then Producer should not require to send SLA content again which w= as already sent before. 0-length SLA content exactly achieves the same.
> I'm confused a bit as to how the Destination AS List works.
> Initially, I thought this would only be set by the sending AS to
> indicate to which external ASes the content applies.  However, ea= ch
> QoS Attribute Speaker can update the Destination AS List.  In Sec= tions
> 4.1.2, 5.1 and 5.2 you attempt to address this, but it is still not > clear what kind of updating or trimming of the Destination AS list
> should be done (and in Section 5.2 you allude to rules to trim the
> Destination AS List, but I did not see those rules).  This could = be
> clarified with an example of what can happen at various hops in the > network.
>
> ##svshah, ok. we will take a look at to address it.

Thanks.

> You state:
>
> Any Traffic Class Element advertised in the QoS Attribute only
> applies to the advertised AFI/SAFI NLRI within the BGP UPDATE
> message the QoS Attribute is contained in.
>
> However, if I understand correctly, I could specify IPFIX attributes > of sourceIPv6Prefix and/or destinationIPv6Prefix that does not line up=
> with the NLRIs, would that not constitute an error?
>
> ##svshah, we do not define that as an error. This is a QoS Producer > defined SLA and if content of produced SLA is no-op or how meaningful = it
> is, is completely scope of QOS SLA Producer. The SLA exchange mechanis= m
> does not need to read SLA content to validate meaning of the SLA conte= nt.

But given your text that if my QoS Attribute traffic class definition
uses prefixes that are out of range from the NLRI, that would be an error?<= /div>
##svshah2, Just taking an example= if Producer advertises SLA where traffic class definition is for prefix 172.x.x.x for the NLRI meant for  152.x.x.x= , then that has no operational effect in actual forwarding. This kind of things can be categorized into what we would typically&nbs= p;call "mis-configuration" in the Producer's SLA= definition. We don't want to look into decoding valid/invalid meaning of s= uch SLA content. Another example, if SLA content definition was to adv= ertised a rate that is higher than actual underlying forwarding interface rate (where SLA is received from).  so fort= h.

> Section 3.3.2.2:
>
> Why have such a huge range for length here?  I can specify that t= he
> number of bytes to specify the amount of L2 overhead to use is 255. > Why not advise that length should be 4, and then use an IEEE FP number=
> like you did for the TSPEC?  At the very least, I think this shou= ld be
> reined in a bit.
>
> ##svshah, sure. Infact this field is changed based on comments/feed-ba= ck
> from David's review. And in the new definition of that field, we
> have/will take care of as per your suggestion.

Thanks.

>
> Section 5.2
>
> What I did not see is what the actual SLA Consumer should do after it<= br> > processes the SLA Content.  I realize this can delve into
> implementation details, but perhaps it's worth mentioning that the SLA=
> Consumer can use protocols like NETCONF or RESTCONF to configure the > policies on the necessary interfaces.
>
> ##svshah, yeah, as you state it, this would get into implementation > details. Besides netconf/restconf, infact implementations may be in th= e
> NOS itself (it does not necessarily need netconf/restconf interface) > just like it can be in the case of flow-spec implementations.

Can you add a small bit of text to this effect?  To me, I read through=
this whole draft and was surprised there wasn't any direct mention of
what is done with the processed SLA.
##= svshah2, We have intended to highlight the scope in the 4th paragraph in th= e Introduction section. The SLA by the Consumer may be processed to impleme= nt forwarding policy or Consumer may do something less or more than that. It is not scope of this document thou= gh. Hopefully, the highlighted paragraph is clearer in that.
Re= gards,
Sh= itanshu

Thanks.

Joe
--_000_BY2PR13MB0789AB36F5F3E51DC5129C61E5EE0BY2PR13MB0789namp_-- From nobody Sun May 7 20:44:10 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A903412025C; Sun, 7 May 2017 20:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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.001, 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 N95JqMe6N0Un; Sun, 7 May 2017 20:43:58 -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 E1CF8120046; Sun, 7 May 2017 20:43:57 -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=1494215038; x=1495424638; h=subject:references:cc:to:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=LYH46W9o2esjrq0H0tHZcx/6S3jShixYQ4+vB29E5gY=; b=EHbGSokBplOCQKk5tEHZG6vFHHN2hQsE6WAGfqwWzEH8UPkD5Iu9h6kS 0u6mWj4m1mze9clX4nDRjKxKytdZsnOE+33A8zM9N8Am2KtJkcKLJBDk6 FvBUEvf4OY1I1Ngt/0HdtMa2LHdtuMuJ5Y216mIjXQnxgriIGjnMw2Hk+ Q=; X-IronPort-AV: E=Sophos;i="5.38,307,1491264000"; d="scan'208";a="418118842" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2017 03:43:57 +0000 Received: from [10.24.44.82] ([10.24.44.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v483hurm014391; Mon, 8 May 2017 03:43:56 GMT References: <149400686065.8457.16928207738917615877.idtracker@ietfa.amsl.com> Cc: draft-ietf-idr-shutdown@ietf.org, idr@ietf.org, idr-chairs@ietf.org, Enke Chen To: ietf@ietf.org From: Enke Chen Message-ID: <9d8cf31a-fc21-096b-543e-58750894a22a@cisco.com> Date: Sun, 7 May 2017 20:43:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149400686065.8457.16928207738917615877.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] Last Call: (BGP Administrative Shutdown Communication) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 03:44:00 -0000 Hi, Folks: Just spotted this (apologies for not catching it earlier): The draft specifies only 0 - 128 as valid in the one-octet length field. Not sure if there is a strong reason for such an apparent over-specification. It seems to me that the spec can and should be simplified by removing the restriction, that is, to allow any value (0 - 255) to be valid. That would also eliminate one error condition for the implementation. Thanks. -- Enke --- 2. Shutdown Communication Length: this 8-bit field represents the length of the Shutdown Communication field in octets. The length value MUST range from 0 to 128 inclusive. 4. Error Handling If a Shutdown Communication with an invalid Length value, ---- On 5/5/17 10:54 AM, The IESG wrote: > > The IESG has received a request from the Inter-Domain Routing WG (idr) to > consider the following document: > - 'BGP Administrative Shutdown Communication' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2017-05-19. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document enhances the BGP Cease NOTIFICATION message > "Administrative Shutdown" and "Administrative Reset" subcodes for > operators to transmit a short freeform message to describe why a BGP > session was shutdown or reset. This document updates RFC 4486. > > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nobody Sun May 7 22:59:07 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A36B124281 for ; Sun, 7 May 2017 22:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 zmxUqPrOmB8i for ; Sun, 7 May 2017 22:59: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 A67EC126E3A for ; Sun, 7 May 2017 22:59:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGE21375; Mon, 08 May 2017 05:58:59 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 8 May 2017 06:58:58 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.200]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 8 May 2017 13:58:46 +0800 From: "Dongjie (Jimmy)" To: "'idr wg'" Thread-Topic: IPR call for draft-ietf-idr-bgp-gr-notification-11 Thread-Index: AdLFP86oaKjGl+mITKe2x11y9XRPSQAAxvmvAJ81sKA= Date: Mon, 8 May 2017 05:58:46 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9279368ED50@NKGEML515-MBS.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9279368DCF4@NKGEML515-MBS.china.huawei.com> <11C8D6F3-208C-444E-A6B1-89024015AE2F@cisco.com> In-Reply-To: <11C8D6F3-208C-444E-A6B1-89024015AE2F@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C9279368ED50NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59100924.005A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.200, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b5cb10a0eaa73e495c6c6a7cde2b9bd5 Archived-At: Subject: [Idr] FW: IPR call for draft-ietf-idr-bgp-gr-notification-11 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 05:59:05 -0000 --_000_76CD132C3ADEF848BD84D028D243C9279368ED50NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Forwarding IPR statement. -Jie From: Rex Fernando (rex) [mailto:rex@cisco.com] Sent: Friday, May 05, 2017 9:57 AM To: Dongjie (Jimmy) Cc: John Scudder ; Susan Hares Subject: Re: IPR call for draft-ietf-idr-bgp-gr-notification-11 Thanks Jie. I am not aware of any IPR related to this draft. Cheers, Rex --_000_76CD132C3ADEF848BD84D028D243C9279368ED50NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Forward= ing IPR statement.

&n= bsp;

-Jie

&n= bsp;

From: Rex Fernando (rex) [mailto:rex@cisco.com]
Sent: Friday, May 05, 2017 9:57 AM
To: Dongjie (Jimmy) <jie.dong@huawei.com>
Cc: John Scudder <jgs@juniper.net>; Susan Hares <shares@ndz= h.com>
Subject: Re: IPR call for draft-ietf-idr-bgp-gr-notification-11=

 

Thanks Jie. I am not aware of any IPR related to this draft.

Cheers, <= /span>

Rex

=

 

--_000_76CD132C3ADEF848BD84D028D243C9279368ED50NKGEML515MBSchi_-- From nobody Mon May 8 04:46:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28AF127137 for ; Mon, 8 May 2017 04:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=highloadlab-com.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 K2Eu_QAiUoqR for ; Mon, 8 May 2017 04:46:10 -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 A573D127077 for ; Mon, 8 May 2017 04:46:10 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id e193so9461346pfh.0 for ; Mon, 08 May 2017 04:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highloadlab-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7upMlaJ5XN9WJHdKVuEM5xR2nhOfGNBmZU2ge4qr1ko=; b=fwbemYonk87X5QiKBd2vxE3N+EHO/a03cGVPtEeH2lyC4XxyZLz/BcYUiQDeEkcWeY swjVuyC6KWBlsXTMrhCeF2Sek2eP9ZIZIzmveWCG9u+D+c3cBj4Ochc5h+dm7GLf5Ecd JP59XlzRS4lkkVAj3NOZ/xdzx7vEaL7dxzhV0MqEWYjLHKoU0YJQwSpxNl/OcYGosmoE vysvkfnTNZ/HjncHAiAkhu6zaLTLwHtMzNi9Kvzsi2xCPKyRa0CgV2w2HLyH9XluWt9H +cXEqEihNnAgwAblaUNwx+N3WefzKFK3/PRdwF6JEdWr2BwN2HsxpFu8TXBPeAM6dohc 5/oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7upMlaJ5XN9WJHdKVuEM5xR2nhOfGNBmZU2ge4qr1ko=; b=qpkXhcbTfPzknjU1azN3LrmnZ+uF5rk9wIXnMowBfBelnSr3T3FULHeUhSLYUX+/dG TVKS3plZo11m3hyDm3ze+NA1xkpSYmxVEMJZCXEBK5nuffiW3+1N/H+enPEJN0Pa7mr8 FN24KeGPd8eELQTvDgJFEojW4zojhMswhpZpX7SRLwyQOUMa1rQ9mxN3Y0tc11BYyOJG hTeH10jpc+ap1beeK+UoS6D/6yAAARBgfqIiZGEh/OrRHPmLQSCoRKqHVh3vUNgYXXVr 2HrCAoyOwgaWuEmiCAuGjiEFPxpwaGFkYpZhkIIRH+6ZasdN8Dx+q+c7muuEBMQO51je 06xA== X-Gm-Message-State: AN3rC/6/S4PqwoO3QdtuS0q8UfSD4NDiCU8KcApnzVL7opfGb5Js3cvm YXBTXwcyrHSJPvGJJwdvCWWzDNJDUw== X-Received: by 10.84.218.205 with SMTP id g13mr67317351plm.38.1494243970286; Mon, 08 May 2017 04:46:10 -0700 (PDT) MIME-Version: 1.0 Sender: aa@highloadlab.com Received: by 10.100.166.74 with HTTP; Mon, 8 May 2017 04:46:09 -0700 (PDT) X-Originating-IP: [2001:67c:64:42:4407:a3c2:df97:195f] In-Reply-To: References: <83ea4c7c-5d17-b92d-19a4-cfa572b3f070@cisco.com> From: Alexander Azimov Date: Mon, 8 May 2017 14:46:09 +0300 X-Google-Sender-Auth: 2t8yQIuYBUvnCWn_9NP7oRRrE7g Message-ID: To: "John G. Scudder" Cc: idr wg Content-Type: multipart/alternative; boundary=f403045d133a0eb2fc054f01c9b3 Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 11:46:13 -0000 --f403045d133a0eb2fc054f01c9b3 Content-Type: text/plain; charset=UTF-8 Hi John, > alex azimov -- 'it'll just result in empty policy' and 'route leaks are > rare anyway', both later rebutted and not replied (so, "in the rough") > Just in case: I meant to say that full table leaks are rare. I do not oppose this draft - while I'm still not sure it will solve problem of full table leaks, I like the concept, and I can see this proposal as part of solution of general route leak problem. But this brings next question: I hope that the meaning of "Import/Export Policy was configured" is just *configured*, no matter by user or automatically, am I right? (I'm trying to understand how it can stack with BGP roles). -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 <+7%20499%20241-81-92> | mob.: +7 915 360 08 86 <+7%20915%20360-08-86> | skype: mitradir | mailto: aa@qrator.net | visit: www.qrator.net --f403045d133a0eb2fc054f01c9b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,
=C2=A0
alex azimov -- 'it'll just result in empty policy' and &= #39;route leaks are rare anyway', both later rebutted and not replied (= so, "in the rough")
Just in case: I meant to= say that full table leaks are rare.=C2=A0

I do no= t oppose this draft - while I'm still not sure it will solve problem of= full table leaks, I like the concept, and I can see this proposal as part = of solution of general route leak problem.

But thi= s brings next question: I hope that the meaning of "Import/Export Poli= cy was configured" is just configured, no matter by user or aut= omatically, am I right? (I'm trying to understand how it can stack with= BGP roles).

--=C2=A0
| Alexander Azimov =C2=A0| HLL l QRATOR
= | skype: mitradir
| mailto:=C2=A0aa@qrator.net
| visit:=C2=A0www.qrator.net
--f403045d133a0eb2fc054f01c9b3-- From nobody Mon May 8 05:11:19 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1D312944E for ; Mon, 8 May 2017 05:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2y7KlSUNm13 for ; Mon, 8 May 2017 05:11:14 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0110.outbound.protection.outlook.com [104.47.33.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 E510012944B for ; Mon, 8 May 2017 05:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EP32n9bUb/8ZfcDm5oq11icMdjimM3GUadCoV2JW8+4=; b=RfT+sN1UyRDgdIwAHm5RNHAJGjDUxA38BAVy8hFqoaDV6w2uJBnqmqzsEQZfkVSm/YElsKghz9Q5BOK8LkOoNavOBkKfVkvWJpjGEGYGhTEGiRhjTaQxvM7ai294TteaXCfM5H5wBNWL4EfvaNr3N+jOp1mrOFM+eUA41owszfE= Authentication-Results: qrator.net; dkim=none (message not signed) header.d=none;qrator.net; dmarc=none action=none header.from=juniper.net; Received: from pboucek-sslvpn-nc.jnpr.net (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_128_CBC_SHA256_P256) id 15.1.1084.7; Mon, 8 May 2017 12:11:12 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_FC0FCD7F-9518-4498-BC55-8A2F3DDB4E3D" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Mon, 8 May 2017 08:11:07 -0400 CC: idr wg Message-ID: References: <83ea4c7c-5d17-b92d-19a4-cfa572b3f070@cisco.com> To: Alexander Azimov X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN6PR14CA0040.namprd14.prod.outlook.com (10.171.172.154) To BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f2fd2d44-1a9a-49d3-7944-08d4960b51e3 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 3:4HiWgEyVbFyOAt+c0eoJW11qi1zkZdIrEtk1YTm9hv5pHealtaVrs9Ma0u3Rb2mhKlzO0oKH7732hVFZ/RywMuBYkD3KDbCsewYescS1ZyRavUiNmA6YCcF1cgaLkjlDxgEZJCB3elvdUmBVLn1c/JGX9ZeedhDP6cP6xDd8WvjAo6ZQj7BaytmepFBX/runYjejerlcqERnZyL+/dWZNw1wkBkh60CMK2U0ju/DGVvBJBrmRg20XlKucVKLqVUq7f1Cb/Qw6rC8smLlwLP+uc2zb7GwbNSL5dJyxNU8iaOK0OypJjuzWRxMYDp1WUKdCYGWO8COzr/QnMKJp4P48d3cRagxaigU896uWM6HH8M=; 25:t7v1uwh+vIX1Rz9Gwk23R6rg+hDCA+ON6P6H3uS0XhgjFpaU7rTL+DUzZpUbXiE1GKIqj7dWG67iUCiOsU2iXMI7PHJk+MnauY+Ln2+/S6XLwnn9WKMupNvSdfkunI76+zcgESMUa6ZwZQEpRVj5/j1A7qrijAS1bjw/S3Itb/X0rqkOHqOufnfSQbzBhJ/XEEm30eiA2eTU3kj6n+ahVm3FiWUt8yG8+GmedoewfmRzyT9BL+VaDmhl9nmur6RQN4cfb786Gw64EayInexieyOjYWmYoLhHNFACp8acYkbcLwsz7ziNl5Eixl/7vEyedwwl++btRIMInVsBE9kqk4P+D514jC8qO8w/MHwHCYlQk68TRmiHSKD0aXyxSG5dg0PE6y5ZWpj5/uivcFBttH9NXPmuBqQbeQ6s/7TCQTAR0CCxMlsu7l4wy24t5JvOW7Zn5DliA/6owOoqQfAiUEANUBdpJRzkUf9eTYktU08= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 31:uPpVHf/uTIYFu6A7OIcdLFF+pft5Gvm32CR6Pg6wcHVrVkg7Lrg5fjia5stNBMZje81rytJC7m56sPP3V6ifim+tgLmLHopL3U7YC1VCtukvC/gyGAp+YIOdRKYzr74LI1A15isSJY2X8QGLtE4Gs/RlGRsZ2HjOFd+iv+QtXAMAHBbA9hBslI+6WN6hmmZr/br6R030rNlWOQTYNQKLpoGM0ANtRfnwQLHQBHLWQXrBv4oN0kDsD3nKEafD4KEpR+HM+p5ZrvLPvP2mRy8YmA==; 20:zRr+EmocXRpXPv+bskba5lqXjCh8QNh7G8BCU8YF9mqw5q4L1DoXcalAGHYgUX4BHDeu0LA9Ka1kR4Eucysd3dMyFIQ7V85jNmj+HYAtpTw+WSBZL5QcwKsIzuWg8RDGrgoP9ztTZBs++6wwW3SIB5vY8H/WHS6v1pxgM1J8nzZdsqHTYHLfTfchv09JxUUHsLs+GShqwtq7JCIo068S0quHGCHS5QvcByZt6FvR1SxK6uNto6CyimTPOgnN59Ihp6prduna+6aoeF2Cbz0Ke15LH8xMnx8NgVstpf4BU9RhGOn126Iiug3KxSxwYO284iqNJI1yToHWDlIWndT61r3jzo7nSyUHe9DOLPBUi+YknfS2u6A/PpAa6PQcRf83du+4fVvI/OEOgvLKvHnwBsDt52ynIj3oAsyi0QIDNH80lygW1agnnvON1RyOHbl+a1EIeP7LwEG8U4lem75x86dehKYNwcM9JoAuTATnpOnBVsU+3yu8RD5YC6xKYmhcuMV/L9u4j4aKxFhRDfA2SZTmSxhO9q+y2MjKGaAvSdj8zDqTCgwPGjh1zeRI6H4T0jV3aPsBtE/UPSSmMbgHaMxWalRmU1UEGV/uNar8UtQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148); SRVR:BN3PR05MB2497; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 4:3tOm+Rl8Nn9lHULz5SSc5t7ngtrKGkimMDSoX7mObNBrMQihbPIReZLU3CPoa5eCnGIkx+159QZacal4rDs3mXE8/2GEQkN5LiBric2zLVnknCmKm5VE6mAOL6OVw0WgYDehEPH2U7ehf4nnPytimSYRQrjVC7xP9YYAn7JbZHRVgolf83kpNM1j3yUpn+BqFxkMbTN52kbWXROLVbmi7gH2BUEmIPhX5iDJEFlAk3qw55+2CgVzFsYK8k08osU7pZVeP19JUm08ve/d78aGL9Dn8YWUBoM8MCsdWcL9wzh6o8yn1ZXIGmWYbcCnTdfjN2ehEAuWqaYyn2uIAccSZTd0wcPwvA7Uf5PkeXC5FTTH8yFASsdbZ5q0wIJ2DO16ToNn7HR/SBsenF/YsCQwi7IGWhN9kmooYxKd7+oR95zyZe7LC4HtIMqPkVyXugxo783jien8+zKrVhNNsftaycBgh/lX/ZJZpMVJwpKesj5KV5Snj6okmvVY3P6I+0Jvn63STY64hlpYTZprL7Dob8y6GastNNllYB1H6oh9HhvLnVLUBVdm0gQQfSxUMLYV0IwxkfhV9OfMSN2F/pbF7/Xh3wb89jgG30VxU6whcqpAH/nMzeVTafAOsNfyc1a/JDJBT2MDETbkexjza2DVmkcqAlg7fXxLjylF+qRZLhGOHypwPzrlxTKhsv6D2Xu3q8ogV/Jqy1J5xsnisdCpmh5eZ68KC9AyrCOdAKHuo0o2exZN/p3wopiz+uakyd8uXvqHcJgOeYDfyRQSQPKNXFwTaHMCVGuu6UrslDIvqmSU49oIX7eXOrrvFCIidSrK X-Forefront-PRVS: 0301360BF5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(39400400002)(377454003)(24454002)(38730400002)(512954002)(83716003)(8676002)(110136004)(230783001)(33656002)(66066001)(81166006)(76176999)(50986999)(6246003)(53936002)(6512007)(57306001)(6486002)(6506006)(25786009)(82746002)(86362001)(84326002)(4326008)(50226002)(236005)(3846002)(478600001)(7736002)(6916009)(2950100002)(6666003)(93886004)(2906002)(260700001)(42186005)(36756003)(229853002)(6116002)(189998001)(5660300001)(53416004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2497; H:pboucek-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2497; 23:ba1AY6j1G+r5OqRQoTEyzjjdJ4eaFr2rP7/ideH44?= =?us-ascii?Q?NbXCayUF8qJENfY7vPSKp2jY72xFgeZ9laBpqSrJdDnEshU9GhAslD0Hsnfa?= =?us-ascii?Q?MoyQ7D+c+lwwuqk2textfx6bYjFg+W7GwSmClVoelthluN96rno0hbrzxRzc?= =?us-ascii?Q?EkFdrJ0GE6lYwB0fSXUfxD8OMJRNdPpkk+w512PousvmhpoTHPMxFxM/un3f?= =?us-ascii?Q?guApwUwzGz+ra6JPXpZN5eF5mX74n8QF/PXQ9X9sDa1irl5ZBLvE4mvYgo8V?= =?us-ascii?Q?5O+SLFRVGSI7YN3TBPplULErdEhhq/hJK7cUNu2uJNRZPeiKhrCpUcWJiRei?= =?us-ascii?Q?A7aRR01XorHB7LjOuHeE5rYZRYzSqMX82i2BRoacX8zom9PYa5ERonosgq0J?= =?us-ascii?Q?ivZiEa/QSSbxnBL+uovODX5pYXwEMTX+Hz31l9FdrLMfmmTCxowylFLzjrrj?= =?us-ascii?Q?q9rCAZX+pB/f5tGMaTUbzZserJlRcltydEAJgRHTp7Zs/GipqjPNfOP3PM/p?= =?us-ascii?Q?rakdmaoZq1fMtWjX7srjFL0nS5zl+Ylje7QJUq1879J8f7siNjnuAhXV/ev6?= =?us-ascii?Q?5PuSlDZDPAQaoH+Q1phbA2+Ar7W1zDXVNOTVPHdVbqn+i53dqPHk0abY5KCT?= =?us-ascii?Q?vRcxgcTSMyNxdvIZ+BTZK9aV83Bq3qROyMxYioivcFc1v8R7NOrLoecz6AAt?= =?us-ascii?Q?LcStkAPzlM5GXKtAYmtqa/wb7vCvS86CKmrvMqgv/GQgD/+Z41KhRZ0BbBxp?= =?us-ascii?Q?RNC7i2e0cJZZZ/ik7N9zGQZL5Gd/EWOT/kQdKZFzE7pOtDsvYcF9Kw+l6mZ5?= =?us-ascii?Q?WMfsvkPaZ3Ovri+2wnWkCsBexpGlkzjbRBgFGt9EfyetLAmglclAgIK698is?= =?us-ascii?Q?pWuCiVak6xlh4EjzRc2P0eXUaDySgExBw1ZCJR2epBRIkR4PQMw6BtgHRAnn?= =?us-ascii?Q?KcyhqFfBjl56yINF6zpT4GWGjlPSQiR9+J3IfcjUfqIfe0AZchFYCyssmYio?= =?us-ascii?Q?E1BXuq8nFKsYmuuY2uIVFa6YpsWL3kkKoS5rPp2kMp587u1RgeiiqWPfAhzC?= =?us-ascii?Q?Gp0gYa9587ZeJ5cr1Yk7/xUzbZfkDivH+wJoJWybILpyWiuo+CR/pIoszsf6?= =?us-ascii?Q?wza4GgTd/uTigSiV8UGOOrmjy/jRoA1N1Fip0/GqIQlzb6yuf5SThsjYiyhW?= =?us-ascii?Q?PaTmXJrvNAfSh4HAohqHdRapXn7Aj2UV95tehZSEwWA8QMNHG1H3cOXrQ=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 6:4A0YJ8mzGYOjbL8CxQWmlKlvCpuQ5McNAd/Z3gzcnlfHGVOKVhi5H5liTB+MFVIO6VDXURqVklflScwgwkFVRtIGDNm/u5GMEOt7nPRqgBXREZ6p9ZTJiSc6Nk/Oi02CxS8/IRGEAdxqKnJO/CzHFXE6vObuGqOtSmIhkB0wpdpLDH9bQ5PF/2CWAzzmPrYau1zsYYTuQVQ9SXo1rT27uUV+Ocm7JPZRE3WfJ5G1v33WIfz1hOLv/wvwcoOFRWvv7lr36r2iE0A7DOx57urabHLGeQqt9ZvdTvNQnmL4In9d2Q8rxKphIuKvaoVyt7jCGaHOVOt3OXXC09zteKD/itY2baS0oaYx4/DQ6fM4IzE9CP6TvXjnX0Gu8FbtGOCtIHhBO1r6z9CacJ0R82uYBRladi5CuTZ9rwYFaa29ZzDAFjckiZQPHAvBI2NufBaul3TK0wJCZ/Yy/rjv3CMX1AS5Qtw8H3SIXoBi4jUsy9Lko8Gs1XE9xJfpcCVkGwquv937hpqNBCI0WEYU4qRQXtmHn3BnWa7ZbG9BmkLr5Ec=; 5:Hjv72VF81ykhXU/mxvEy4uaKX717GXmD9x0iHk6LfbFlYuGQjVryy4Fgo4ZammRVmsObspoGdl8dHu1dVvXUmx5GTTl8CTu5Co65/6z93mrerUD7ErjcqY6huMX2/NYvjX1/KHCuPBp2EHKSh1bWOA==; 24:kEFeZpIK6s8Ey6fzQPdO9sMmCJ0YPDddw3FW5fyW/6SG6CJ6lVcT7PbspJn68XApwK+RU6rEagX9OnOaxiacXfyI/jH4IpXsYeI49UXBfqs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 7:w4GYmLFeKDWNsT1U5E2azS4/TEauM4ePo0rNBxc/Aa3FymqdqVf2zV7PimnePkUMna2k2MaNnaSEgCl76OXCu5Gcd5ScSlxk10VD3reqL3DWTRF4ROhmtw7lQOug17TWR6+0qPnGXDHGV17+dA9vhqTydEO8wUqdiq2AN8VNyKiXrn5UQW+ntwjOveyQAauZyI4I3YkE50UZgbP8iUxi6vo2v6OmgXksaaKDhzRomN3cLk3F5992lWsy9h+HDBcgOxnYAV2ZOLuzWrFZ4Te3dGZ+/HY08ugwssmWnNSE13Xbo5pjOeEQBI/9ICKdeG3yf6yLsCNwJp2Tnoz/1VVEnA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2017 12:11:12.6189 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2497 Archived-At: Subject: Re: [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 12:11:18 -0000 --Apple-Mail=_FC0FCD7F-9518-4498-BC55-8A2F3DDB4E3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" #individual_contributor > On May 8, 2017, at 7:46 AM, Alexander Azimov wrote: >=20 > I hope that the meaning of "Import/Export Policy was configured" is = just configured, no matter by user or automatically, am I right? (I'm = trying to understand how it can stack with BGP roles). That's how I read it. --John= --Apple-Mail=_FC0FCD7F-9518-4498-BC55-8A2F3DDB4E3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" #individual_contributor

On = May 8, 2017, at 7:46 AM, Alexander Azimov <aa@qrator.net> = wrote:

I hope that the meaning of "Import/Export Policy = was configured" is just configured, no matter by user or = automatically, am I right? (I'm trying to understand how it can stack = with BGP roles).

That's how I read it.

--John
= --Apple-Mail=_FC0FCD7F-9518-4498-BC55-8A2F3DDB4E3D-- From nobody Mon May 8 06:30:27 2017 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 638DF127843; Mon, 8 May 2017 06:30:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149425022536.27632.12204873443849653826@ietfa.amsl.com> Date: Mon, 08 May 2017 06:30:25 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-rtc-no-rt-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 13:30:25 -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 : Route Target Constrained Distribution of Routes with no Route Targets Authors : Eric C. Rosen Keyur Patel Jeffrey Haas Robert Raszuk Filename : draft-ietf-idr-rtc-no-rt-07.txt Pages : 7 Date : 2017-05-08 Abstract: There are a variety of BGP-enabled services in which the originator of a BGP route may attach one or more "Route Targets" to the route. By means of a procedure known as "RT Constrained Distribution" (RTC), a given BGP speaker (call it "B") can announce the set of RTs in which it has interest. The implication is that if a particular route (call it "R") carries any RTs at all, BGP speaker B wants to receive route R if and only if B has announced interest in one of the RTs carried by R. However, if route R does not carry any RTs at all, prior specifications do not make it clear whether B's use of RTC implies that it does not want to receive route R. This has caused interoperability problems in the field, as some implementations of RTC do not allow B to receive R, but some services presuppose that B will receive R. This document updates RFC 4684 by clarifying the effect of the RTC mechanism on routes that do not have any RTs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rtc-no-rt/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-rtc-no-rt-07 https://datatracker.ietf.org/doc/html/draft-ietf-idr-rtc-no-rt-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rtc-no-rt-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 Mon May 8 07:00:31 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0837129471; Mon, 8 May 2017 07:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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.001, 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 t2Qnm48OONM7; Mon, 8 May 2017 07:00:27 -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 09753127444; Mon, 8 May 2017 07:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4236; q=dns/txt; s=iport; t=1494252026; x=1495461626; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=XrB6Oi0Uat2X7zL0TVJxDQ9C6Gx+CoLxFhKXIfgMmno=; b=R7wV7KSbUMTGL2nCu6DrFpoNGZd8iZBf8JCROegdbOuYBKb1bjlH/ZGd MX58rZkcs1YkxGqeWxdI9nksm97qGCsa0qSBLNy4m4jSzbsaNXI6nkWRF Z+ZtBE7JagT4Ov9ox76I+J7Iz0f/OH8bPN5UPJbdSgOWBSOQtZQsgvVBa Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAABZeRBZ/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1WPbpFWlXKCD4YkAoRfPxgBAgEBAQEBAQFrKIUVAQEBAQIBMgF?= =?us-ascii?q?GBQsLGBUZVwYNCAEBihQItFmKYwEBAQEBAQEBAQEBAQEBAQEBIYZfgV4rgnCFI?= =?us-ascii?q?oUqAQSdeZMYggSIfyOGRoh8i0IfOIEKTyEVRoR0HIF/JIZkB4I2AQEB?= X-IronPort-AV: E=Sophos;i="5.38,309,1491264000"; d="scan'208";a="232197897" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 May 2017 14:00:25 +0000 Received: from [10.118.87.89] (rtp-jclarke-nitro8.cisco.com [10.118.87.89]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v48E0Phv030479; Mon, 8 May 2017 14:00:25 GMT To: Shitanshu Shah Cc: "idr@ietf.org" , "draft-ietf-idr-sla-exchange.all@ietf.org" References: <149400246349.8370.5477015906856459639@ietfa.amsl.com> <804fa340-7cba-e27a-e115-f5e675948396@cisco.com> From: Joe Clarke Organization: Cisco Message-ID: <25fefae3-6f4e-f9f4-a198-c45ef6190fb3@cisco.com> Date: Mon, 8 May 2017 10:00:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Idr] Opsdir early review of draft-ietf-idr-sla-exchange-10 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 14:00:29 -0000 On 5/7/17 22:35, Shitanshu Shah wrote: > I thought the purpose of the draft was to provide a vendor-neutral way > of exchanging QoS/SLA policies. What I was specifically asking for is > an example of what the fields within the packets may look like for a > given exchange. That is, take some of the IPFIX parameters and specify > a specific example exchange of attributes. I don't see how doing this > would be vendor-specific. > > ##svshah2, got it. I think example in this form certainly can be added. Excellent. Thanks! > My overall point was that I feel some text should be added to the draft > to help an operator know what they might expect from added overhead. > Given that there are operators as authors of this draft, perhaps there > are recommendations to implementors of what operators expect for the > overhead involved with this capability. > > ##svshah2, sure, we can add such a text. Do you have suggestion on > exactly which section should such a text go to? This could fit in Deployment Considerations, IMHO. > It could be that one AS no longer trusts another in terms of SLA. In > any event, what is the intent of having a 0-length SLA Content? > > ##svshah2, sorry, I realize that my previous response did not address > your original question completely. > > Regarding intent of having 0-legnth SLA content, > If Producer (a specific Source AS) had advertised SLA ID s1, with SLA > content, to a specific prefix before. And now, if same Producer intents > to advertise exact same SLA ID s1 for additional prefix, then Producer > should not require to send SLA content again which was already sent > before. 0-length SLA content exactly achieves the same. Ah! Now I follow, especially with your clarification around SLA ID. I think that perhaps the text might be clearer here. Additionally, what would be the purpose of _never_ sending SLA Content. That is, what did you mean by: If there does not exist any prior SLA Content to relate to the advertised SLA ID, then receiver, SLA Consumer, can ignore the SLA advertisement and it may simply update Destination AS count and Destination AS list. Why wouldn't this be an error? > But given your text that if my QoS Attribute traffic class definition > uses prefixes that are out of range from the NLRI, that would be an error? > > ##svshah2, Just taking an example if Producer advertises SLA where > traffic class definition is forprefix 172.x.x.x for the NLRI meant > for 152.x.x.x, then that has no operational effect in actual > forwarding. This kind of things can be categorized into what we would > typically call "mis-configuration" in the Producer's SLA definition. We > don't want to look into decoding valid/invalid meaning of such SLA > content. Another example, if SLA content definition was to advertised a > rate that is higher than actual underlying forwarding interface rate > (where SLA is received from). so forth. I'm clear on your latter example. However, for the former, since you have text that explicitly states: Any Traffic Class Element advertised in the QoS Attribute only applies to the advertised AFI/SAFI NLRI within the BGP UPDATE message the QoS Attribute is contained in. I feel you should address what an SLA Consumer would do with such a mismatch. And that could account for your latter example as well. If the SLA Consumer is instructed simply to throw away such mis-configurations, I think that would be acceptable. > > Can you add a small bit of text to this effect? To me, I read through > this whole draft and was surprised there wasn't any direct mention of > what is done with the processed SLA. > > ##svshah2, We have intended to highlight the scope in the 4th paragraph > in the Introduction section. The SLA by the Consumer may be processed to > implement forwarding policy or Consumer may do something less or more > than that. It is not scope of this document though. Hopefully, the > highlighted paragraph is clearer in that. I vaguely remember that paragraph :-). I re-read the introduction, and you also mention the vendor-specific configuration in the second paragraph. This is sufficient. Joe From nobody Mon May 8 12:13:52 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925C0129649; Mon, 8 May 2017 12:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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.001, 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 i55sqf4HX5Vd; Mon, 8 May 2017 12:13:42 -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 A9F2A124D37; Mon, 8 May 2017 12:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3004; q=dns/txt; s=iport; t=1494270821; x=1495480421; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wukmENlBzFNd+y7ItLBkWrEfBo13BiixpOu4wRuuwgo=; b=aORqdZWKQHC3y3jFJ1IpyH1F23EO0OBCYFVI2yHhwhzlFWNPpCiJUjr7 PfcORmzI0n3I3pVy59z/HJPjVSDaRdPwIYmyW7XhvptZr4UFgO/TTnaq1 xziP8gP8PltmqNefroOumSVsT9TXhpLPXUc8Yovp8E4ZuFhgOn8lh7dq0 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAACCwhBZ/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHjXmRV5Vygg8hC4V4AoRlPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQMBATg0CwwEAgEIEQQBAQEeBQsnCx0IAgQBDQUIihgOtX+KdQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhl+BXoMbikwFnXkBhxuLc4INhTyKLJQ9AR84gQpwFUZ?= =?us-ascii?q?AhGmBSnaHXgGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,310,1491264000"; d="scan'208";a="245740763" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 May 2017 19:13:40 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v48JDeuZ013631 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 May 2017 19:13:40 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 8 May 2017 14:13: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; Mon, 8 May 2017 14:13:39 -0500 From: "Jakob Heitz (jheitz)" To: "Enke Chen (enkechen)" , "ietf@ietf.org" CC: "draft-ietf-idr-shutdown@ietf.org" , "idr@ietf.org" , "idr-chairs@ietf.org" Thread-Topic: [Idr] Last Call: (BGP Administrative Shutdown Communication) to Proposed Standard Thread-Index: AQHSxciggI3I1x2tSEiYPH6G0J5TkKHqIuMAgACuc/A= Date: Mon, 8 May 2017 19:13:39 +0000 Message-ID: References: <149400686065.8457.16928207738917615877.idtracker@ietfa.amsl.com> <9d8cf31a-fc21-096b-543e-58750894a22a@cisco.com> In-Reply-To: <9d8cf31a-fc21-096b-543e-58750894a22a@cisco.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: [128.107.151.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Last Call: (BGP Administrative Shutdown Communication) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 19:13:44 -0000 It is deliberately kept short to minimize the potential for abuse. We could have argued about the length. Should it be 100, 120, 127, but it's not an argument worth wasting time on. Not using the whole range of the length byte opens the door to using the rest of the range to indicate a future new information field. Thanks, Jakob. > -----Original Message----- > From: Enke Chen (enkechen) > Sent: Sunday, May 07, 2017 8:44 PM > To: ietf@ietf.org > Cc: draft-ietf-idr-shutdown@ietf.org; idr@ietf.org; idr-chairs@ietf.org; = Enke Chen (enkechen) > Subject: Re: [Idr] Last Call: (BGP Admin= istrative Shutdown Communication) to > Proposed Standard >=20 > Hi, Folks: >=20 > Just spotted this (apologies for not catching it earlier): >=20 > The draft specifies only 0 - 128 as valid in the one-octet length field. > Not sure if there is a strong reason for such an apparent over-specificat= ion. >=20 > It seems to me that the spec can and should be simplified by removing the > restriction, that is, to allow any value (0 - 255) to be valid. That wou= ld > also eliminate one error condition for the implementation. >=20 > Thanks. -- Enke >=20 > --- > 2. Shutdown Communication >=20 > Length: this 8-bit field represents the length of the Shutdown > Communication field in octets. The length value MUST range from 0 > to 128 inclusive. >=20 > 4. Error Handling >=20 > If a Shutdown Communication with an invalid Length value, > ---- >=20 > On 5/5/17 10:54 AM, The IESG wrote: > > > > The IESG has received a request from the Inter-Domain Routing WG (idr) = to > > consider the following document: > > - 'BGP Administrative Shutdown Communication' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2017-05-19. Exceptionally, comments may = be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document enhances the BGP Cease NOTIFICATION message > > "Administrative Shutdown" and "Administrative Reset" subcodes for > > operators to transmit a short freeform message to describe why a BGP > > session was shutdown or reset. This document updates RFC 4486. > > > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > From nobody Mon May 8 12:30:54 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFF4127871 for ; Mon, 8 May 2017 12:30:50 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 ItL9QDzpu3eH for ; Mon, 8 May 2017 12:30: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 0235E124234 for ; Mon, 8 May 2017 12:30:49 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d7oMm-0002F4-K0 (job@us.ntt.net) for idr@ietf.org; Mon, 08 May 2017 19:30:48 +0000 Received: by mail-wr0-f177.google.com with SMTP id z52so52850127wrc.2 for ; Mon, 08 May 2017 12:30:44 -0700 (PDT) X-Gm-Message-State: AN3rC/464YAS8Tu73rCZbuTzBtxk5vTq7of9kNayFfK752eE6gNrfSTX 1Yp1JTJHWAZsP6kgCDDRgPQ9Vjwy9Q== X-Received: by 10.223.131.67 with SMTP id 61mr38212742wrd.37.1494271843197; Mon, 08 May 2017 12:30:43 -0700 (PDT) MIME-Version: 1.0 References: <149400686065.8457.16928207738917615877.idtracker@ietfa.amsl.com> <9d8cf31a-fc21-096b-543e-58750894a22a@cisco.com> In-Reply-To: From: Job Snijders Date: Mon, 08 May 2017 19:30:32 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "Enke Chen (enkechen)" , "Jakob Heitz (jheitz)" , "ietf@ietf.org" Cc: "draft-ietf-idr-shutdown@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0d1078697ec5054f084638 Archived-At: Subject: Re: [Idr] Last Call: (BGP Administrative Shutdown Communication) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 19:30:50 -0000 --94eb2c0d1078697ec5054f084638 Content-Type: text/plain; charset=UTF-8 Dear Jakob, Enke Enke raised an interesting point. I've received no feedback from anyone that 128 isn't sufficient. This work was circulated at NANOG, APRICOT, GPF and UKNOF to get feedback. Due to lack of demand for anything bigger it doesn't seem worth it to go back and change the existing implementations. The implementation complexity is very low already. You can review Peter van Dijk's implemention report to get a sense of how things are done. https://mailarchive.ietf.org/arch/msg/idr/8ueDFbC4ZBd1WwolRS78aFA8oyw Kind regards, Job On Mon, 8 May at 21:13, Jakob Heitz (jheitz) wrote: > It is deliberately kept short to minimize the potential for abuse. > We could have argued about the length. Should it be 100, 120, 127, > but it's not an argument worth wasting time on. > Not using the whole range of the length byte opens the door to using > the rest of the range to indicate a future new information field. > > Thanks, > Jakob. > > > > -----Original Message----- > > From: Enke Chen (enkechen) > > Sent: Sunday, May 07, 2017 8:44 PM > > To: ietf@ietf.org > > Cc: draft-ietf-idr-shutdown@ietf.org; idr@ietf.org; idr-chairs@ietf.org; > Enke Chen (enkechen) > > Subject: Re: [Idr] Last Call: (BGP > Administrative Shutdown Communication) to > > Proposed Standard > > > > Hi, Folks: > > > > Just spotted this (apologies for not catching it earlier): > > > > The draft specifies only 0 - 128 as valid in the one-octet length field. > > Not sure if there is a strong reason for such an apparent > over-specification. > > > > It seems to me that the spec can and should be simplified by removing the > > restriction, that is, to allow any value (0 - 255) to be valid. That > would > > also eliminate one error condition for the implementation. > > > > Thanks. -- Enke > > > > --- > > 2. Shutdown Communication > > > > Length: this 8-bit field represents the length of the Shutdown > > Communication field in octets. The length value MUST range from 0 > > to 128 inclusive. > > > > 4. Error Handling > > > > If a Shutdown Communication with an invalid Length value, > > ---- > > > > On 5/5/17 10:54 AM, The IESG wrote: > > > > > > The IESG has received a request from the Inter-Domain Routing WG (idr) > to > > > consider the following document: > > > - 'BGP Administrative Shutdown Communication' > > > as Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, and solicits > > > final comments on this action. Please send substantive comments to the > > > ietf@ietf.org mailing lists by 2017-05-19. Exceptionally, comments > may be > > > sent to iesg@ietf.org instead. In either case, please retain the > > > beginning of the Subject line to allow automated sorting. > > > > > > Abstract > > > > > > > > > This document enhances the BGP Cease NOTIFICATION message > > > "Administrative Shutdown" and "Administrative Reset" subcodes for > > > operators to transmit a short freeform message to describe why a BGP > > > session was shutdown or reset. This document updates RFC 4486. > > > > > > > > > > > > > > > > > > The file can be obtained via > > > https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ > > > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ballot/ > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > > > > _______________________________________________ > > > Idr mailing list > > > Idr@ietf.org > > > https://www.ietf.org/mailman/listinfo/idr > > > > --94eb2c0d1078697ec5054f084638 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Jakob, Enke

Enke raised an interesting p= oint.=C2=A0

I've received no feedback from any= one that 128 isn't sufficient. This work was circulated at NANOG, APRIC= OT, GPF and UKNOF to get feedback. Due to lack of demand for anything bigge= r it doesn't seem worth it to go back and change the existing implement= ations. =C2=A0

The implementation complexity is ve= ry low already. You can review Peter van Dijk's implemention report to = get a sense of how things are done.=C2=A0https://mailarchive.ietf.or= g/arch/msg/idr/8ueDFbC4ZBd1WwolRS78aFA8oyw

Kin= d regards,

Job

On Mon, 8 May at 21:13, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
It is deliberately kept short to minimize the = potential for abuse.
We could have argued about the length. Should it be 100, 120, 127,
but it's not an argument worth wasting time on.
Not using the whole range of the length byte opens the door to using
the rest of the range to indicate a future new information field.

Thanks,
Jakob.


> -----Original Message-----
> From: Enke Chen (enkechen)
> Sent: Sunday, May 07, 2017 8:44 PM
> To: ietf@ietf.org
> Cc: draft-ietf-idr-shutdown@ietf.org; idr@ietf.org; idr-chairs@ietf.org; Enke Chen (enkechen) <enkechen@cisco.com>=
> Subject: Re: [Idr] Last Call: <draft-ietf-idr-shutdown-08.txt> (= BGP Administrative Shutdown Communication) to
> Proposed Standard
>
> Hi, Folks:
>
> Just spotted this (apologies for not catching it earlier):
>
> The draft specifies only 0 - 128 as valid in the one-octet length fiel= d.
> Not sure if there is a strong reason for such an apparent over-specifi= cation.
>
> It seems to me that the spec can and should be simplified by removing = the
> restriction, that is, to allow any value (0 - 255) to be valid.=C2=A0 = That would
> also eliminate one error condition for the implementation.
>
> Thanks.=C2=A0 -- Enke
>
> ---
> 2.=C2=A0 Shutdown Communication
>
> Length:=C2=A0 this 8-bit field represents the length of the Shutdown >=C2=A0 =C2=A0 =C2=A0 =C2=A0Communication field in octets.=C2=A0 The len= gth value MUST range from 0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to 128 inclusive.
>
> 4.=C2=A0 Error Handling
>
>=C2=A0 =C2=A0 If a Shutdown Communication with an invalid Length value,=
> ----
>
> On 5/5/17 10:54 AM, The IESG wrote:
> >
> > The IESG has received a request from the Inter-Domain Routing WG = (idr) to
> > consider the following document:
> > - 'BGP Administrative Shutdown Communication'
> >=C2=A0 =C2=A0<draft-ietf-idr-shutdown-08.txt> as Proposed St= andard
> >
> > The IESG plans to make a decision in the next few weeks, and soli= cits
> > final comments on this action. Please send substantive comments t= o the
> > ietf@ietf.org<= /a> mailing lists by 2017-05-19. Exceptionally, comments may be
> > sent to iesg@i= etf.org instead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >=C2=A0 =C2=A0 This document enhances the BGP Cease NOTIFICATION me= ssage
> >=C2=A0 =C2=A0 "Administrative Shutdown" and "Admini= strative Reset" subcodes for
> >=C2=A0 =C2=A0 operators to transmit a short freeform message to de= scribe why a BGP
> >=C2=A0 =C2=A0 session was shutdown or reset.=C2=A0 This document u= pdates RFC 4486.
> >
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/= draft-ietf-idr-shutdown/
> >
> > IESG discussion can be tracked via
> > https://datatracker.ietf.o= rg/doc/draft-ietf-idr-shutdown/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> >
--94eb2c0d1078697ec5054f084638-- From nobody Mon May 8 12:36:21 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F032127871; Mon, 8 May 2017 12:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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.001, 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 Xi0S2dg-oNA7; Mon, 8 May 2017 12:36:09 -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 7451F124234; Mon, 8 May 2017 12:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3758; q=dns/txt; s=iport; t=1494272169; x=1495481769; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=q+rOZMsfuFZzy/l3jKmrznGQl1OMCDLEtYRGlivGmR8=; b=XxMMNLvIB044Kq374y0i219pqZTLouaIsZcxJq7kolmv1EGX2KyQv8S6 08jm7thE5nO1qcl/fWeSGlXThKWCK2R1qeCi62/WxbulZoJWxbbtjoh+T /FetC/ml0q+/P9vZZ2xpCE7MQ+kHM90BWkBB9FBJ7udk+W/peyFzXdwUT U=; X-IronPort-AV: E=Sophos;i="5.38,310,1491264000"; d="scan'208";a="24769386" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2017 19:36:08 +0000 Received: from [10.41.60.195] ([10.41.60.195]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v48Ja7ot010806; Mon, 8 May 2017 19:36:08 GMT To: "Jakob Heitz (jheitz)" References: <149400686065.8457.16928207738917615877.idtracker@ietfa.amsl.com> <9d8cf31a-fc21-096b-543e-58750894a22a@cisco.com> Cc: "ietf@ietf.org" , "draft-ietf-idr-shutdown@ietf.org" , "idr@ietf.org" , "idr-chairs@ietf.org" , Enke Chen From: Enke Chen Message-ID: <6a3bfb3a-fd06-4291-b3f2-abb92f70ec04@cisco.com> Date: Mon, 8 May 2017 12:36:07 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] Last Call: (BGP Administrative Shutdown Communication) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 19:36:12 -0000 Jakob, Hi, Jakob: I understand this is not a good use of time. But since it is in the spec, I would like to understand the reasons. If there are good reasons for doing things differently, then they should be documented in the spec so that people do not question again. On 5/8/17 12:13 PM, Jakob Heitz (jheitz) wrote: > It is deliberately kept short to minimize the potential for abuse. 128 is ok, and 129- 255 would be considered abuse? In protocol design we have had so many mistakes related to small length fields. There is rarely an issue because one field has an extra byte. > We could have argued about the length. Should it be 100, 120, 127, > but it's not an argument worth wasting time on. Yes, that is precisely the reason that this value "128" should not be specified. > Not using the whole range of the length byte opens the door to using > the rest of the range to indicate a future new information field. You mean "129-255" are reserved rather than "invalid"? Then that should be made clear in the spec. Thanks. -- Enke > > Thanks, > Jakob. > > >> -----Original Message----- >> From: Enke Chen (enkechen) >> Sent: Sunday, May 07, 2017 8:44 PM >> To: ietf@ietf.org >> Cc: draft-ietf-idr-shutdown@ietf.org; idr@ietf.org; idr-chairs@ietf.org; Enke Chen (enkechen) >> Subject: Re: [Idr] Last Call: (BGP Administrative Shutdown Communication) to >> Proposed Standard >> >> Hi, Folks: >> >> Just spotted this (apologies for not catching it earlier): >> >> The draft specifies only 0 - 128 as valid in the one-octet length field. >> Not sure if there is a strong reason for such an apparent over-specification. >> >> It seems to me that the spec can and should be simplified by removing the >> restriction, that is, to allow any value (0 - 255) to be valid. That would >> also eliminate one error condition for the implementation. >> >> Thanks. -- Enke >> >> --- >> 2. Shutdown Communication >> >> Length: this 8-bit field represents the length of the Shutdown >> Communication field in octets. The length value MUST range from 0 >> to 128 inclusive. >> >> 4. Error Handling >> >> If a Shutdown Communication with an invalid Length value, >> ---- >> >> On 5/5/17 10:54 AM, The IESG wrote: >>> >>> The IESG has received a request from the Inter-Domain Routing WG (idr) to >>> consider the following document: >>> - 'BGP Administrative Shutdown Communication' >>> as Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2017-05-19. Exceptionally, comments may be >>> sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> This document enhances the BGP Cease NOTIFICATION message >>> "Administrative Shutdown" and "Administrative Reset" subcodes for >>> operators to transmit a short freeform message to describe why a BGP >>> session was shutdown or reset. This document updates RFC 4486. >>> >>> >>> >>> >>> >>> The file can be obtained via >>> https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ >>> >>> IESG discussion can be tracked via >>> https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ballot/ >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>> From nobody Mon May 8 12:47:08 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E8F129A8E for ; Mon, 8 May 2017 12:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 bnJgCfovflNf for ; Mon, 8 May 2017 12:47:06 -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 0BE75128D2E for ; Mon, 8 May 2017 12:47:06 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d7ocb-0004C8-1i (job@us.ntt.net) for idr@ietf.org; Mon, 08 May 2017 19:47:05 +0000 Received: by mail-wm0-f54.google.com with SMTP id 142so77097677wma.1 for ; Mon, 08 May 2017 12:47:04 -0700 (PDT) X-Gm-Message-State: AODbwcBOaeXl907z8XrFt1VtfKn9bZvHUYR3pxQKA9jzWsPoD4DBRnz3 6NiVJ+8uO010cx8aXpDm22Lx4+kmuQ== X-Received: by 10.28.68.195 with SMTP id r186mr10971907wma.22.1494272823839; Mon, 08 May 2017 12:47:03 -0700 (PDT) MIME-Version: 1.0 References: <149400686065.8457.16928207738917615877.idtracker@ietfa.amsl.com> <9d8cf31a-fc21-096b-543e-58750894a22a@cisco.com> <6a3bfb3a-fd06-4291-b3f2-abb92f70ec04@cisco.com> In-Reply-To: <6a3bfb3a-fd06-4291-b3f2-abb92f70ec04@cisco.com> From: Job Snijders Date: Mon, 08 May 2017 19:46:53 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Enke Chen , "Jakob Heitz (jheitz)" Cc: "draft-ietf-idr-shutdown@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=001a1148f4fcdd104d054f088097 Archived-At: Subject: Re: [Idr] Last Call: (BGP Administrative Shutdown Communication) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 19:47:07 -0000 --001a1148f4fcdd104d054f088097 Content-Type: text/plain; charset=UTF-8 On Mon, 8 May 2017 at 21:36, Enke Chen wrote: > I understand this is not a good use of time. But since it is in the > spec, I would like to understand the reasons. If there are good reasons > for doing things differently, then they should be documented in the spec > so that people do not question again. In the security section: "This specification minimizes the effects of visual spoofing by limiting the length of the Shutdown Communication." On 5/8/17 12:13 PM, Jakob Heitz (jheitz) wrote: > > It is deliberately kept short to minimize the potential for abuse. > > 128 is ok, and 129- 255 would be considered abuse? Those are an error according to the draft. Kind regards, Job --001a1148f4fcdd104d054f088097 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, 8 May 2017 at 21:36, Enke Chen = <enkechen@cisco.com> wrote:=
I understand this is not a good us= e of time.=C2=A0 But since it is in the
spec, I would like to understand the reasons.=C2=A0 If there are good reaso= ns
for doing things differently, then they should be documented in the spec so that people do not question again.


<= /div>
In the security section: "This= =C2=A0specification minimizes the effe= cts of visual spoofing by limiting=C2=A0the length of the Shutdown Communication."

On 5/8/17 12:13 PM, Jakob Heitz (jheitz) wrote:
> It is deliberately kept short to minimize the potential for abuse.

128 is ok, and 129- 255 would be considered abuse?

Those are an error according to the draft.

Kind regards,

Job

--001a1148f4fcdd104d054f088097-- From nobody Mon May 8 13:28:22 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36811293DA; Mon, 8 May 2017 13:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[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, URIBL_BLOCKED=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 oz5Qv3oaVLxz; Mon, 8 May 2017 13:28:18 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001: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 505E51292D3; Mon, 8 May 2017 13:28:18 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id o12so29669340iod.3; Mon, 08 May 2017 13:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9bz4778u3tAdINKkilzof8aC9cTy6j0Nj061hu0vhZU=; b=Vzh5F+glCP+kvY4Eb5K5F5AunwHzwb3NciDABtAk+rDOcBXiKqdUJLyXgGvHNEDas2 6xfVaD+2AI/12wkoratGYoN8vD8n7KCllIVrQIZio8S2cBDD+oKavKw0noyV2fNJD8da 9+KtK+nyzzHM7utw/N/N6IHjdGZxsJswTRy69dKtPJocGWpQZlCULP2K7psw3On5hnMH 1P5CtrMrDKds2bazWAVi5NsjT3bxL1RSNJKMzAzDOSKW8O3pamkKzVf8nPjSpSzypdmz GW5bwKWHkRBrBY3sz6q1FNuHujYWlfwI4dXpXJE6ryD66TjbcgLE450TF3azFtEHo5+d nLYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9bz4778u3tAdINKkilzof8aC9cTy6j0Nj061hu0vhZU=; b=qx4c6K4GwsLxN5M6yyo2HnneR443WCDAN7x3g+gDoXD1cH6IW7PmwZam/vvsm4PpYT RWICUxlTKTGls1oEN79Kpjht3fcFjnIbGwxnmberXOXiscK8OG8yZlGuXUqBkOJnrRc6 bcDzqk9lJoR6ILHGkEMSYS5IP6bTeBYqqTlIt9JTs+MY9EMyWJM6NKTsG7zlCu8tsa5f 5WMObSrQNj+lPGk1c/F7M3w7OEmmwlDQvIMcZJvU4W9x0NxrGyR1D5UCde5JKffjd5qN 0W6BImWNSREJjyJUF6oaJPIhoFi/bkGboaLMuSzJitBEj1rIWHPoGHFHrY747zt0Vfe/ 5owA== X-Gm-Message-State: AN3rC/7QFhDF7J7DfLPH0bDVVg89NDa000FCfj9jW5wQwUA2M21HhQrz czdZ0uMNQ+Jz7gI3xFZ/plvKVhkZFQ== X-Received: by 10.107.5.12 with SMTP id 12mr51093111iof.186.1494275297668; Mon, 08 May 2017 13:28:17 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Mon, 8 May 2017 13:28:17 -0700 (PDT) In-Reply-To: References: <149400686065.8457.16928207738917615877.idtracker@ietfa.amsl.com> <9d8cf31a-fc21-096b-543e-58750894a22a@cisco.com> <6a3bfb3a-fd06-4291-b3f2-abb92f70ec04@cisco.com> From: Robert Raszuk Date: Mon, 8 May 2017 22:28:17 +0200 X-Google-Sender-Auth: ErD8-fwp6ULT4WHrzOccW_b0vec Message-ID: To: Job Snijders Cc: Enke Chen , "Jakob Heitz (jheitz)" , "idr-chairs@ietf.org" , "draft-ietf-idr-shutdown@ietf.org" , "ietf@ietf.org" , "idr@ietf.org" Content-Type: multipart/alternative; boundary=001a113ef634507513054f091401 Archived-At: Subject: Re: [Idr] Last Call: (BGP Administrative Shutdown Communication) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 20:28:20 -0000 --001a113ef634507513054f091401 Content-Type: text/plain; charset=UTF-8 Hi Job, Assuming that by "visual spoofing" you really mean this: http://websec.github.io/unicode-security-guide/visual-spoofing/ how does limiting the length of the field helps to minimize it ? It is UTF which is a problem here regardless of the length. Ok so we leave 129-255 for further use .. brilliant. Assume someone comes tomorrow and has a great use case for sending one byte of information in the cease. So he defines length 129 right ? And even if operator did not type anything for the "shutdown case" ... first 128 bytes goes empty, then goes one newly defined octet. Is this really how protocol encoding should be done in 2017 ? Is concept of TLV so complex ? Cheers, R. On Mon, May 8, 2017 at 9:46 PM, Job Snijders wrote: > > On Mon, 8 May 2017 at 21:36, Enke Chen wrote: > >> I understand this is not a good use of time. But since it is in the >> spec, I would like to understand the reasons. If there are good reasons >> for doing things differently, then they should be documented in the spec >> so that people do not question again. > > > > In the security section: "This specification minimizes the effects of > visual spoofing by limiting the length of the Shutdown Communication." > > On 5/8/17 12:13 PM, Jakob Heitz (jheitz) wrote: >> > It is deliberately kept short to minimize the potential for abuse. >> >> 128 is ok, and 129- 255 would be considered abuse? > > > Those are an error according to the draft. > > Kind regards, > > Job > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a113ef634507513054f091401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Job,

Assuming that by "visual spoofing" you real= ly mean this:=C2=A0http://websec.github.io/unicode-security-guide/visual-s= poofing/ how does limiting the length of the field helps to minimize it= ?=C2=A0

It is UTF whi= ch is a problem here regardless of the length.=C2=A0

Ok so we leave 129-255 for further use .. br= illiant. Assume someone comes tomorrow and has a great use case for sending= one byte of information in the cease. So he defines length 129 right ? And= even if operator did not type anything for the "shutdown case" .= .. first 128 bytes goes empty, then goes one newly defined octet. Is this r= eally how protocol encoding should be done in 2017 ? Is concept of TLV so c= omplex ?=C2=A0

Cheers,=
R.


On Mon, May 8, 2017 at 9= :46 PM, Job Snijders <job@ntt.net> wrote:

On Mon, 8 Ma= y 2017 at 21:36, Enke Chen <enkechen@cisco.com> wrote:
I understand this is not a good use of time.=C2=A0 But since it = is in the
spec, I would like to understand the reasons.=C2=A0 If there are good reaso= ns
for doing things differently, then they should be documented in the spec so that people do not question again.


<= /div>
In the security section: "This=C2=A0specification minimizes t= he effects of visual spoofing by limiting=C2=A0the length of the Shutdown Communication."

On 5/8/17 12:13 PM, Jakob Heitz (jheitz) wrote:
> It is deliberately kept short to minimize the potential for abuse.

128 is ok, and 129- 255 would be considered abuse?

Those are an error according to the draft.

Kind regards,

Job


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


--001a113ef634507513054f091401-- From nobody Mon May 8 13:36:53 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D221293E8 for ; Mon, 8 May 2017 13:36:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 NZDSVIXYSyc8 for ; Mon, 8 May 2017 13:36:39 -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 DF9E6129A8E for ; Mon, 8 May 2017 13:36:34 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d7pOU-0009WV-9B (job@us.ntt.net) for idr@ietf.org; Mon, 08 May 2017 20:36:34 +0000 Received: by mail-wm0-f52.google.com with SMTP id 142so78489642wma.1 for ; Mon, 08 May 2017 13:36:34 -0700 (PDT) X-Gm-Message-State: AODbwcCDKEVO9pQd4pztIGGbjuV4r8TIE63yiF2zLZrMpXTmEVfLpJKN VkZO/ycSxKgVLZacaDph7RYzh2l2og== X-Received: by 10.28.68.195 with SMTP id r186mr11079898wma.22.1494275792520; Mon, 08 May 2017 13:36:32 -0700 (PDT) MIME-Version: 1.0 References: <149400686065.8457.16928207738917615877.idtracker@ietfa.amsl.com> <9d8cf31a-fc21-096b-543e-58750894a22a@cisco.com> <6a3bfb3a-fd06-4291-b3f2-abb92f70ec04@cisco.com> In-Reply-To: From: Job Snijders Date: Mon, 08 May 2017 20:36:21 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Job Snijders , Robert Raszuk Cc: Enke Chen , "Jakob Heitz (jheitz)" , "draft-ietf-idr-shutdown@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=001a1148f4fccf5e57054f09310e Archived-At: Subject: Re: [Idr] Last Call: (BGP Administrative Shutdown Communication) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 20:36:40 -0000 --001a1148f4fccf5e57054f09310e Content-Type: text/plain; charset=UTF-8 Hi Robert, The reference is to a different type of visual spoofing. The idea was to limit the string length to prevent spoofing of additional syslog messages or other fake cli output. We already covered the extensibility aspect in the working group. Kind regards, Job On Mon, 8 May 2017 at 22:28, Robert Raszuk wrote: > Hi Job, > > Assuming that by "visual spoofing" you really mean this: > http://websec.github.io/unicode-security-guide/visual-spoofing/ how does > limiting the length of the field helps to minimize it ? > > It is UTF which is a problem here regardless of the length. > > Ok so we leave 129-255 for further use .. brilliant. Assume someone comes > tomorrow and has a great use case for sending one byte of information in > the cease. So he defines length 129 right ? And even if operator did not > type anything for the "shutdown case" ... first 128 bytes goes empty, then > goes one newly defined octet. Is this really how protocol encoding should > be done in 2017 ? Is concept of TLV so complex ? > > Cheers, > R. > > > On Mon, May 8, 2017 at 9:46 PM, Job Snijders wrote: > >> >> On Mon, 8 May 2017 at 21:36, Enke Chen wrote: >> >>> I understand this is not a good use of time. But since it is in the >>> spec, I would like to understand the reasons. If there are good reasons >>> for doing things differently, then they should be documented in the spec >>> so that people do not question again. >> >> >> >> In the security section: "This specification minimizes the effects of >> visual spoofing by limiting the length of the Shutdown Communication." >> >> On 5/8/17 12:13 PM, Jakob Heitz (jheitz) wrote: >>> > It is deliberately kept short to minimize the potential for abuse. >>> >>> 128 is ok, and 129- 255 would be considered abuse? >> >> >> Those are an error according to the draft. >> >> Kind regards, >> >> Job >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> --001a1148f4fccf5e57054f09310e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robert,

The reference is to a different ty= pe of visual spoofing. The idea was to limit the string length to prevent s= poofing of additional syslog messages or other fake cli output.=C2=A0
=

We already covered the extensibility aspect in the work= ing group.=C2=A0

Kind regards,

Job

On Mon, 8 May 2017 = at 22:28, Robert Raszuk <robert@ras= zuk.net> wrote:
Hi Job,

As= suming that by "visual spoofing" you really mean this:=C2=A0http://websec.github.io/unicode-security-guide/visual-spoofin= g/ how does limiting the length of the field helps to minimize it ?=C2= =A0

It is UTF which is= a problem here regardless of the length.=C2=A0
Ok so we leave 129-255 for further use .. brillia= nt. Assume someone comes tomorrow and has a great use case for sending one = byte of information in the cease. So he defines length 129 right ? And even= if operator did not type anything for the "shutdown case" ... fi= rst 128 bytes goes empty, then goes one newly defined octet. Is this really= how protocol encoding should be done in 2017 ? Is concept of TLV so comple= x ?=C2=A0

Cheers,
R.


On Mon, May 8, 2017 at 9:46 PM, Job = Snijders <job@ntt= .net> wrote:

On Mon, 8 May 2017 at 21:36, Enke Chen <enkechen@cisco.com> wrote= :
I understand this is not a good u= se of time.=C2=A0 But since it is in the
spec, I would like to understand the reasons.=C2=A0 If there are good reaso= ns
for doing things differently, then they should be documented in the spec so that people do not question again.


<= /div>
In the security section: "This=C2=A0specification minimizes t= he effects of visual spoofing by limiting=C2=A0the length of the Shutdown Communication."
=

On 5/8/17 12:13 PM, Jakob Heitz (jheitz) wrote:
> It is deliberately kept short to minimize the potential for abuse.

128 is ok, and 129- 255 would be considered abuse?

Those are an error according to the draft.

Kind regards,

Job


____________________________________= ___________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--001a1148f4fccf5e57054f09310e-- From nobody Mon May 8 13:39:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E17E1293DF; Mon, 8 May 2017 13:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[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, URIBL_BLOCKED=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 LKH2AvEdCakK; Mon, 8 May 2017 13:39:20 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 44A611292D3; Mon, 8 May 2017 13:39:20 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id p24so58308533ioi.0; Mon, 08 May 2017 13:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MRE7dw18+GPlLwDWi4N28Hk57UnqG8rMuNVlRWHwWhw=; b=kg08J0L0uLMMi+kil20V443s0QKMbez1hT9qSXm5c/60Rtc22lsQOUOEPDSTOKDBmI X9MLtm0xz89mXApzFE0FqWufrJ0LDnUzglANRrKX0giZk1iez+MhMdIEHJf+/nbHuKw7 eOEqC1+ZUdEokZoJH4prIYXHYZsrcPUoQTyJED+7S/junUGpu6UfNr0Hj4Z3fqFgDGcZ JX+5FHFTHDprVxzKyz0wOC92EODSIQbb2cCpWDQgjU1RUh5yb/FL/vo/JisUXALj/aRg cVQI2tFaNiV/FUDNj3WSrsHCKw/pMtwu/K8DjVAcAZ8RbTH9RVsGZloPRrTgsgdkvAUi VRjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MRE7dw18+GPlLwDWi4N28Hk57UnqG8rMuNVlRWHwWhw=; b=cr6Ev7TVmqCSrkfAFD6/wxHlNpqYA2g/iqHl5KYLGRuzUE7ieC6gYF+JZRr3W1C2dv gPDgAdWmIWB+RWDxOj/mj/gTJdeSGF0t38Q/5uiIdEH5OBVZsYIHfHJASqNjnba9liDm hUsHF6XMs1gpCSbkLmfn3xffn8vNeJb1hZS8b3DPzXJcaPbZLl56ar81fjWZwiCH9sd3 NmKrCtLoJ2u3qFRrhURXO9slTnvUOUAnb+th6OBIzVANk/QvBlhjEqucB6mBFIAl3LGF zWBLWLT7i7ms8nsROpuRv55LWjDSISvl82PcAwTwTNpmwErKHPPBMcfZbXfqgaOeY1VC l0SA== X-Gm-Message-State: AN3rC/5WgAy0oTh0iMAZF/ONSJBJjH4hlnvLqymF5y4xFI2paGdAm3cg rc9tr1VnI2/Ol1MSXWgpiFGgiHJk/g== X-Received: by 10.107.5.12 with SMTP id 12mr51133662iof.186.1494275959595; Mon, 08 May 2017 13:39:19 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Mon, 8 May 2017 13:39:18 -0700 (PDT) In-Reply-To: References: <149400686065.8457.16928207738917615877.idtracker@ietfa.amsl.com> <9d8cf31a-fc21-096b-543e-58750894a22a@cisco.com> <6a3bfb3a-fd06-4291-b3f2-abb92f70ec04@cisco.com> From: Robert Raszuk Date: Mon, 8 May 2017 22:39:18 +0200 X-Google-Sender-Auth: Xwm23bC7F9km8ZNxdoY823dGNtE Message-ID: To: Job Snijders Cc: Enke Chen , "Jakob Heitz (jheitz)" , "draft-ietf-idr-shutdown@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=001a113ef634c4ab8e054f093b04 Archived-At: Subject: Re: [Idr] Last Call: (BGP Administrative Shutdown Communication) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 20:39:22 -0000 --001a113ef634c4ab8e054f093b04 Content-Type: text/plain; charset=UTF-8 Then this is not "visual spoofing" ... you are just protecting from forms of "visual attacks" Best, R. On Mon, May 8, 2017 at 10:36 PM, Job Snijders wrote: > Hi Robert, > > The reference is to a different type of visual spoofing. The idea was to > limit the string length to prevent spoofing of additional syslog messages > or other fake cli output. > > We already covered the extensibility aspect in the working group. > > Kind regards, > > Job > > On Mon, 8 May 2017 at 22:28, Robert Raszuk wrote: > >> Hi Job, >> >> Assuming that by "visual spoofing" you really mean this: >> http://websec.github.io/unicode-security-guide/visual-spoofing/ how does >> limiting the length of the field helps to minimize it ? >> >> It is UTF which is a problem here regardless of the length. >> >> Ok so we leave 129-255 for further use .. brilliant. Assume someone comes >> tomorrow and has a great use case for sending one byte of information in >> the cease. So he defines length 129 right ? And even if operator did not >> type anything for the "shutdown case" ... first 128 bytes goes empty, then >> goes one newly defined octet. Is this really how protocol encoding should >> be done in 2017 ? Is concept of TLV so complex ? >> >> Cheers, >> R. >> >> >> On Mon, May 8, 2017 at 9:46 PM, Job Snijders wrote: >> >>> >>> On Mon, 8 May 2017 at 21:36, Enke Chen wrote: >>> >>>> I understand this is not a good use of time. But since it is in the >>>> spec, I would like to understand the reasons. If there are good reasons >>>> for doing things differently, then they should be documented in the spec >>>> so that people do not question again. >>> >>> >>> >>> In the security section: "This specification minimizes the effects of >>> visual spoofing by limiting the length of the Shutdown Communication." >>> >>> On 5/8/17 12:13 PM, Jakob Heitz (jheitz) wrote: >>>> > It is deliberately kept short to minimize the potential for abuse. >>>> >>>> 128 is ok, and 129- 255 would be considered abuse? >>> >>> >>> Those are an error according to the draft. >>> >>> Kind regards, >>> >>> Job >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>> >>> --001a113ef634c4ab8e054f093b04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Then this = is not "visual spoofing" =C2=A0... you are just protecting from f= orms of "visual attacks"

Best,
R.

On Mon, May 8, 2017 at 10:36 PM, J= ob Snijders <job@ntt.net> wrote:
Hi Robert,

The reference is to a different t= ype of visual spoofing. The idea was to limit the string length to prevent = spoofing of additional syslog messages or other fake cli output.=C2=A0

We already covered the extensibility aspect in the wor= king group.=C2=A0

Kind regards,

Job

On Mon, 8 May 2017 at 22:28, Robert Raszuk <robert@raszuk.net> = wrote:
Hi J= ob,

Assuming that by &= quot;visual spoofing" you really mean this:=C2=A0ht= tp://websec.github.io/unicode-security-guide/visual-spoofing/= how does limiting the length of the field helps to minimize it ?=C2=A0

It is UTF which is a prob= lem here regardless of the length.=C2=A0

=
Ok so we leave 129-255 for further use .. brilliant. Ass= ume someone comes tomorrow and has a great use case for sending one byte of= information in the cease. So he defines length 129 right ? And even if ope= rator did not type anything for the "shutdown case" ... first 128= bytes goes empty, then goes one newly defined octet. Is this really how pr= otocol encoding should be done in 2017 ? Is concept of TLV so complex ?=C2= =A0

Cheers,
R.


On Mon, May 8, 2017 at 9:46 PM, Job Snijders= <job@ntt.net= > wrote:

=
On Mon, 8 May 2017 at 21:36, Enke Chen <enkechen@cisco.com> wrote:
I understand this is not a good use of ti= me.=C2=A0 But since it is in the
spec, I would like to understand the reasons.=C2=A0 If there are good reaso= ns
for doing things differently, then they should be documented in the spec so that people do not question again.


<= /div>
In the security section: "This=C2=A0specification minimizes t= he effects of visual spoofing by limiting=C2=A0the length of the Shutdown Communication."
=

On 5/8/17 12:13 PM, Jakob Heitz (jheitz) wrote:
> It is deliberately kept short to minimize the potential for abuse.

128 is ok, and 129- 255 would be considered abuse?

Those are an error according to the draft.

Kind regards,

Job


_______________________________= ________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--001a113ef634c4ab8e054f093b04-- From nobody Mon May 8 13:49:39 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241DB129AA0 for ; Mon, 8 May 2017 13:49:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 H2PfJPJ-DKzN for ; Mon, 8 May 2017 13:49:31 -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 C285C129A9C for ; Mon, 8 May 2017 13:49:29 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d7paz-000FAW-Jc (job@us.ntt.net) for idr@ietf.org; Mon, 08 May 2017 20:49:29 +0000 Received: by mail-wm0-f43.google.com with SMTP id m123so78358522wma.0 for ; Mon, 08 May 2017 13:49:29 -0700 (PDT) X-Gm-Message-State: AN3rC/5BNmnA1XdYOdANjdqo6TYkjxIXHeyGKgmEeA6WZ2nLXWttYavn 8+DQBNmJ6VUXbXAf3jcHzMCvttzK3g== X-Received: by 10.28.185.211 with SMTP id j202mr12992783wmf.65.1494276567947; Mon, 08 May 2017 13:49:27 -0700 (PDT) MIME-Version: 1.0 References: <149400686065.8457.16928207738917615877.idtracker@ietfa.amsl.com> <9d8cf31a-fc21-096b-543e-58750894a22a@cisco.com> <6a3bfb3a-fd06-4291-b3f2-abb92f70ec04@cisco.com> In-Reply-To: From: Job Snijders Date: Mon, 08 May 2017 20:49:17 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Job Snijders , Robert Raszuk Cc: Enke Chen , "Jakob Heitz (jheitz)" , "draft-ietf-idr-shutdown@ietf.org" , "idr-chairs@ietf.org" , "idr@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=001a1148db1c0778c1054f096044 Archived-At: Subject: Re: [Idr] Last Call: (BGP Administrative Shutdown Communication) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 20:49:33 -0000 --001a1148db1c0778c1054f096044 Content-Type: text/plain; charset=UTF-8 Hi Robert, If you (and others) think that "visual attack" is a better phrasing, I'd be happy to change "visual spoofing" to "visual attacks" in the security section. Kind regards, Job On Mon, 8 May 2017 at 22:39, Robert Raszuk wrote: > > Then this is not "visual spoofing" ... you are just protecting from forms > of "visual attacks" > > Best, > R. > > On Mon, May 8, 2017 at 10:36 PM, Job Snijders wrote: > >> Hi Robert, >> >> The reference is to a different type of visual spoofing. The idea was to >> limit the string length to prevent spoofing of additional syslog messages >> or other fake cli output. >> >> We already covered the extensibility aspect in the working group. >> >> Kind regards, >> >> Job >> >> On Mon, 8 May 2017 at 22:28, Robert Raszuk wrote: >> >>> Hi Job, >>> >>> Assuming that by "visual spoofing" you really mean this: >>> http://websec.github.io/unicode-security-guide/visual-spoofing/ how >>> does limiting the length of the field helps to minimize it ? >>> >>> It is UTF which is a problem here regardless of the length. >>> >>> Ok so we leave 129-255 for further use .. brilliant. Assume someone >>> comes tomorrow and has a great use case for sending one byte of information >>> in the cease. So he defines length 129 right ? And even if operator did not >>> type anything for the "shutdown case" ... first 128 bytes goes empty, then >>> goes one newly defined octet. Is this really how protocol encoding should >>> be done in 2017 ? Is concept of TLV so complex ? >>> >>> Cheers, >>> R. >>> >>> >>> On Mon, May 8, 2017 at 9:46 PM, Job Snijders wrote: >>> >>>> >>>> On Mon, 8 May 2017 at 21:36, Enke Chen wrote: >>>> >>>>> I understand this is not a good use of time. But since it is in the >>>>> spec, I would like to understand the reasons. If there are good >>>>> reasons >>>>> for doing things differently, then they should be documented in the >>>>> spec >>>>> so that people do not question again. >>>> >>>> >>>> >>>> In the security section: "This specification minimizes the effects of >>>> visual spoofing by limiting the length of the Shutdown Communication." >>>> >>>> On 5/8/17 12:13 PM, Jakob Heitz (jheitz) wrote: >>>>> > It is deliberately kept short to minimize the potential for abuse. >>>>> >>>>> 128 is ok, and 129- 255 would be considered abuse? >>>> >>>> >>>> Those are an error according to the draft. >>>> >>>> Kind regards, >>>> >>>> Job >>>> >>>> >>>> _______________________________________________ >>>> Idr mailing list >>>> Idr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idr >>>> >>>> > --001a1148db1c0778c1054f096044 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robert,

If you (and others) think tha= t "visual attack" is a better phrasing, I'd be happy to chang= e "visual spoofing" to "visual attacks" in the security= section.=C2=A0

Kind regards,

=
Job

On Mon, 8 May 2017 a= t 22:39, Robert Raszuk <robert@rasz= uk.net> wrote:

Then this is not "visual spoof= ing" =C2=A0... you are just protecting from forms of "visual atta= cks"

Best,
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">R.

On Mon, May 8, 2017 at 10:36 PM, Job Snijders <job@ntt.net> w= rote:
Hi Robert,

The reference is to a different type of visual spoofing. The idea was= to limit the string length to prevent spoofing of additional syslog messag= es or other fake cli output.=C2=A0

We already cove= red the extensibility aspect in the working group.=C2=A0

Kind regards,

Job

On Mon, 8 May 2017 at 22:28, Robert Raszuk <= robert@raszuk.net> wrote:
It is UTF which is a problem = here regardless of the length.=C2=A0

Ok so we leave 129-255 for further use .. brilliant. Assume = someone comes tomorrow and has a great use case for sending one byte of inf= ormation in the cease. So he defines length 129 right ? And even if operato= r did not type anything for the "shutdown case" ... first 128 byt= es goes empty, then goes one newly defined octet. Is this really how protoc= ol encoding should be done in 2017 ? Is concept of TLV so complex ?=C2=A0

Cheers,
R.


<= div class=3D"gmail_quote">On Mon, May 8, 2017 at 9:46 PM, Job Snijders <job@ntt.net><= /span> wrote:

On Mon, 8 May 2017 at 21:36, Enke Chen <enkechen@cisco.com> wrote:
I understand this is not a good use of time.= =C2=A0 But since it is in the
spec, I would like to understand the reasons.=C2=A0 If there are good reaso= ns
for doing things differently, then they should be documented in the spec so that people do not question again.


<= /div>
In the security section: "This=C2=A0specification minimizes t= he effects of visual spoofing by limiting=C2=A0the length of the Shutdown Communication."
=

On 5/8/17 12:13 PM, Jakob Heitz (jheitz) wrote:
> It is deliberately kept short to minimize the potential for abuse.

128 is ok, and 129- 255 would be considered abuse?

Those are an error according to the draft.

Kind regards,

Job


____________________________________= ___________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--001a1148db1c0778c1054f096044-- From nobody Tue May 9 08:09:08 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48050129487; Tue, 9 May 2017 08:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gs5--VjpKsUk; Tue, 9 May 2017 08:09:02 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0091.outbound.protection.outlook.com [104.47.36.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BC53127867; Tue, 9 May 2017 08:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=If955CjyrQZFenHU99Q4uUiALxoGy5+OssNVOCH0WjQ=; b=C85ZLLVSd7CYBpjWIji7ER0x9zJv6L9NVpLWme5DGgZNcg4dAsntnDkvYb55rlYJvbs3ILJigEZi/0TGQE+CAj6369/Bxyllgs6YWzjIrlyU6EiphPEGuv07jldACo/r+4iD3nmABEDBpQncwiKgfgh/UU5DPA+0f0cg18D+f78= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.37.32] (66.129.241.10) by BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Tue, 9 May 2017 15:09:00 +0000 To: BESS WG , IDR WG From: Eric C Rosen Message-ID: Date: Tue, 9 May 2017 11:08:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------E246575E0BB9CB288EDF6331" X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BN6PR11CA0048.namprd11.prod.outlook.com (10.173.25.34) To BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c39f2b15-0a52-4b4c-874a-08d496ed52f6 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 3:sg40FE2j64B1nYPoRydCTEIjtOfowc3jotKN5vu5kpy2xP6J0mFswgsBj8vk9py7EiJz0IEATtjVJUshhtddP/R2x4qkrUpn9BjuEOrnRT6IlPv1QolYsqt0Rjhglhz8BG/fBn3Qaert8DoOja8giFtydbwunA19mCeRXYiwK2Dcre4rAhrEltTYA5nnbtG8n2lnZMxjJE8m0NGhc9gQ/eDy6c98xKLwROCME7gzicTufKqIdMTmNbqLDu9/ae8ucco7l6+sRziMwAOuYINedFWe4Jb4Pj1++C9QsDZbGZF66BlT8ua8jpmVhI4/ZLnNgNMXwOciHAuAoWdtmoIfBvOeDe9SoEI3q72qesRkk00= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 25:fGpYUXqv0z9mu8dho36+bewPS+HF+Q1CEVRXNZUpKg3K7JbLtEdbqpigXcmNsYTqVJRPKHMRSyGrkW1fgyTEzsnTEtbyMXok1VClau0HJ3245rrgp6GViF+FJKVqFJHDrzMYfQs6rtT38tIzw7adegAlJxsclUyYjvue0VDPFH2s1YSdD98U7TX2EY8lfXDw3L6yj0ipAXH8BkbANenI6Wsz7wWyyVUgMc3rAmQVGG2pSUok6Vts0gqvkM4/CLVEO29z/Ea/1Cn4qUKmatvQVBUtdr10xQ7NJR3OvpWRO49WVd2iWfMPgaBteUvoY5yQImMQaEbRUH27ZaBleUXUlLsAESd6nrLIx/tRhAflQfNLqWoW2HOsk4rWathfjliV71eIaQKA8HCNbRpd/mDkuNnNj16P1zHNk9beTc8dlCioU0TGqtkCWEVEt/phyP9lCOED4h6rB5NZTyY4msCCK6qvySZqtMMbvNi6w2WZDjVNbNTr74/uX7jE7aYzzDK0v+8l5dscX2FMI1EoJ8cLbYS+LRPtjBHHY+9cr/eX8nIb2yp3dfscbX+y4r0JQiJcc4r1oQdT4o2b4xD3m4Id9WXY+5ao0NZhMq/wmOQ+zVbhp7Dny2EqYayY+EoXxfuHkXN7l1d8GCLzwPEiPzWSRQ== X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 31:kD/pwZoVf6fFAYY3N2EXzt4rPcCEkMPfQZ0KVHLGDA0nNI5jTnQNNmMhhRMJeWxZnGAHE/CpFP8LDT5DBDx9g9A2Y/x4TKxIN4LhA/NSlTwiQm97hMdy4syaH7/Z6u2jE79rGHqA4lKe6J6iP+O4DUpDdGPug8Od9JGcFHqx3NuV1gPrvt5VpdYjCJwpKAJBPHDxCnn1pKkSsWIDFdZl3ipgkiXtRemi2FNrOpBvOGeCOWxJHnJ1aHmUzjeAPU4uEnlBOpaKax6bG45hQsENg0oMTmpLzeTnTAV11v8Ah1k=; 20:2Y8JW2L8uEtgLfK9PP3avAc11AhEeD1ah5oqvhXerz0GhZltH81vJigc+OAqOQcaUcZo83FjMBwTnUUSwAO4JpdKKYaOgWYqWRD9R0KcQ5rxPlbN2M/AWwzLVLIVKl5iQizgTKzt5xK+yskOF1eGbo9ZXGONfGEm6JD7REBbgumx+YKP+t78Xa5pq8q7JSjHkOSz0TQo7Sf4ilyTUB75HzwU4cugjjovXS4jsPd6c0cfiQDN9LMiRCPEkkrnFjeeoSY8LEtDFMlg0hms/mSV9k96tBNMQ4TyuWYFQKcefxDBvufNlc8dobbN5tOALCWsq+CBO45vEmSurO0n7X8GRF8FSS3YuDdhfyP/OgVesYhvvJurPOn/97hPi0Yw83qDA7k1SKk8ZAm9AbQuLs4YYO3hyJ3exkyVODiiHof4OEvunJ/9eY88uG8JdwehfRoA1DEGRAx9a/Gzw2s9yPpq+bPeFwuI2AMf1yMLzk0kBsRweNt9EOo17DVwDbYnRwjYKLmgMzw9YQCU+Ey4j7q7L+N0vtGTMUNxnJuRhXAf500d2KPaqxeHOMNajzWHJ85XHJ103GUBH2G0oTfEYmompa2QPf7spiMYhxVDQ/gTUN0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148); SRVR:BL2PR05MB2180; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 4:MjSSv82YrQ7oFfAjIxEDXNBrWpwm5/neyPT7LRk7yfHAanqDJ7JViV18GgEGran1dTJTh3L4BqgooP271x/+TvG2XXl4usSbqzKUuAABc6o9czxBOxNWPAxaJf3qMgQNYGkBUV25s/rDlhGrXxFd4CwOFyIo+gU2XiSynQ1xoGHo3+ZUFN2VJde9Y3XrxxwAFR+KopnwmsfuiKpHrT7yfU218774Bt+ainmbLIvQk4XIAv2/gsyGzWxTuo6XsL4vKBzDPsaTQ2xs2wc0IpbWNyjN0BdkzJXIDx9QzXkObtAZGPKa1kOuro0WgqfkNb+5uA547mUeJ11gDiZ0MWPGiMoF/QPPL0WCN5xyqWXdA7s/Gx/OP6Tkd0uc3/n5EILeJpANDo9zeXa7Hd0Y6V+53f/XStKrWnesCumrE2JdbFyVqBXiSduhDPuX1sHJhONokd388nUjty5dmLS47eMezY6D2ADkIvGg38rCdKCcHqZg9djEeY8GzM6k2G5O8gfN5foWp685O0ZGsIwMGOYE/+qsYJT9+n6B6OlWYSlrOwe4C4L3hT4/m/Tsdzb+cbrnXweBPGnT0SxUcOgZVRNpdN7gLsj1flt3FOtpCzV2pAzn/KBWS9bxFe7O3WSNH8knGDO9/drp3aQoWL4GKzwQBc6BVXEfKK6MT9jAaOqHO/5brzOn+T14hY/GiCqF6zu4u/cQzW47XBfAV9FgG5DShnFEa2wekObXVt6jpWirIK++Oe4wXYqJBr2yNypY9WaNHS7fVS8NCyqL7nxF4qYTP6cs1zqsZnPCnik0iN9ATHA7P6BFvnCiCDXzyX3EfxTpCBdqHko1QeVlehgOSQEXdA== X-Forefront-PRVS: 0302D4F392 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(39450400003)(39400400002)(39850400002)(39860400002)(39840400002)(39410400002)(77096006)(31686004)(5660300001)(86362001)(450100002)(2476003)(4001350100001)(50986999)(568964002)(512874002)(54356999)(53936002)(6666003)(31696002)(270700001)(3260700006)(25786009)(65826007)(5890100001)(3846002)(83506001)(478600001)(66066001)(2906002)(6116002)(38730400002)(42186005)(6486002)(564344004)(305945005)(84326002)(189998001)(36756003)(4810100001)(8676002)(4610100001)(33646002)(64126003)(81166006)(5000100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2180; H:[172.29.37.32]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR05MB2180; 23:fBPB0RkotOrjRJO0jxOJa0uza6yphDLpmvQS1U0gE?= =?us-ascii?Q?WX0nyOP6dcR2ldbYu61w71hiIm3O/cCjC3v8Pga0odv23E8hOYE7i96oU1Yb?= =?us-ascii?Q?Q2LKhJk95b0JdRAJv5+BDWWepMaE012vM1P4auYUPKF4UphtVOi5fTJdtFwp?= =?us-ascii?Q?jNbZIqGJ71wqZBSkczcfdsZ4pXpiMNn+brZnh2UTNnqn8hMprkfBQMk87JDE?= =?us-ascii?Q?3NweAmnKXVJqqKymUKDXVw58h8mP5zHLvoY5UpyrEHfuRH66v6r8RmRamXsV?= =?us-ascii?Q?Zv2oX6NvO4ccO7sECNbRH7otMyVqoELjPe/57mjiECKxnxydOcrVNZC4oXxU?= =?us-ascii?Q?wlh/VwvqRnI4EYB7N+NOudLyxCozmH2FlRfjvxc/dvfAL6uavD10/MvJGlAl?= =?us-ascii?Q?40b/PL+wSeI/flNTyJ4biAlvRQYzHpfCB2ULFg9FX/4ZYg/7rv4eQdV5Ww4N?= =?us-ascii?Q?lcVZAA1iz4Lzso/Any8OJorUn/dZCOgzijiaN4+ZnfqEI71aalw74S0qvo8F?= =?us-ascii?Q?oQtIzW/7fQXz9/wqmL6el8Z3oPhWSe92Wi6yCNRp6BCvK6WlkQluxsjCFUQb?= =?us-ascii?Q?M5yA8zwD3Wqd/0a0vWbipbkatFJMo9/pq7xuvtpRpiC2UnNFCSsoJhwKIZs/?= =?us-ascii?Q?bwxUps95rNYuV+4jgVUt8sYZPdnFp5L3MTpjD3u3ldkWREqlm3qgHgwJiJRc?= =?us-ascii?Q?E1Vs98dVE88xw9lCpTdToUIDDwYA1p/wYl3/7CcS4q9w/moZr8bMEYQ1NHWg?= =?us-ascii?Q?wHuoXefPTZ3jtXslkKoTzZ7i9PAFEpPQk0C50kAsDwtEzF2lJmjjkbl9+jUY?= =?us-ascii?Q?CBFyUnEdxs8B6Ap/5rpbJaieJMcxa6FmfTsEqrhGxVmTydon3tIHYGeLTj4Z?= =?us-ascii?Q?Ju17qPvNWI/P0g8d8nOllaRw9nr6jb0udarZEZCzVJfizXbzc5oCObEag/6r?= =?us-ascii?Q?5FK3UmZUydbG5YugqmilPKYx4Kok+k6GcqsgwGWTXq/+Ert48P0CtQtbY+ai?= =?us-ascii?Q?SyoPJByXkK2rFoeE6V+ddCII9cRviluNYafCsPRkJ+IBWNam1szliqcUvS7t?= =?us-ascii?Q?CqbuVcxdIqF/rkhmTDFzuCE2da1fq1Tkrz8cbr/pqPYVNqUxlHTzR2hVZACW?= =?us-ascii?Q?ZDgDkpNlZMtSsxafd3Z7F4tZdRBHQhAHh19GGAMSOo/k+XcY2QNSZFEKpS+Q?= =?us-ascii?Q?WMAaVrB+Iwryk2Nzont3WieLGjlnvkXvGmTjQ0cBElSibs98sMmmrMOFv6Xd?= =?us-ascii?Q?objTzfDVWUFMvzVWSs=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 6:6tHG8s0nX2c2BVDTUnLLvY6YYqSADmZ/V7CwHVM+FBnLIfBWFIw1ecYiXt37W8S+J1XSryhEyPAFR/OQav1nBrNnsyxrD4Cjj0G1vtCmkiRAUBBoTKK+6A5MkSt+p/A51/hX0OOkFmc7DfUXAp4jwQX2j4zu9uTrkxU0s5BULRggJqvletg2dL12FGgG3SI9e8V44qBmgKlL2qsIf3wtslt1vVzXfWp+jbzCyR5daH63sNv1cBQF3bW9Ydeog8dZpTpDVsvNdxQzMDAPjLKw2ODcnY8ysDRSrOKjHIYrfNZX+rM6zf7QiXSOnY407WVWb8rmvLPOZhzxW4pmc+Nb1rJ5TfGt2xvqaUbfCOzHlFuIo2QvDAY5N9/Uij06XLNgKyzTRgfARoX8Lycw81xHaSn1RTrbUhyoVM/AMX9+jfpdoGgZ3sRJuspU6g7M372KKVqskXm8gm5MvHadOrJqHlZPzYVDAFQ/wL037wdWOOPlw3rGR5x1I1+QM3lptiUDtj3VMOqu6dGBZZAZlUqtFTF++gXwYW6FV5axbhJXmTQ=; 5:WQxFTffZ+edFJVa2SGW2PtnG3/yrS7cq3LNMyjmQ5SGrKPQMyYAgvwcG3HjeFAlDWl3Y3cwjkpYfzgtqA1Hs7ETTlI8FIvhqhEme0NnL6qMKITlyNUzu5umPClSRrUDefvOOeesmUBVh2ivVmp+olg==; 24:taziGIbHIq07gNbLJ/J9Q6Axe0JfZCZZ7cUxH+X4GrXa/gNu+8W6ZCsc1p8CaZKqAG+wjRS9i801xoK8RdFMHoxbTtcGVEygjt1Ib3RCuSg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 7:OXPFWjCwZE71cXDR+jLE+xkkMLanEeCLhPe0KU55f2dtvY95TlURja5DNsEMg/66BjNqPdW9Z7Dc8U/LVkHEM4bY1bRw/eHJgP6PTaILylbidg+egl8KnPBshFGh8Zq8n9x/d/tewMq0rUP8p+6i7OXf0rrRnu7DyVdurj9Bbc+wnbYX5VacmrVXJ9M5bLLXQA4N5A1kK8WIGTPnthHTLpHP/1yum4/d7C1MeYCmXLuNSwN9utAW7cCDHsIYIwLM9tYRG+rMvkECKC+aXyCIQSC4VOzXErllt2c9rQSO8zqnwMqs74IHFBEjtBqce8twBPlXkn50R+uW2SqAxI5IMQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2017 15:09:00.5162 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2180 Archived-At: Subject: [Idr] 3107bis LC discussion on MPLS list X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 15:09:06 -0000 --------------E246575E0BB9CB288EDF6331 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit This discussion (see the attached messages) really should have been cc'ed to BESS and IDR. --------------E246575E0BB9CB288EDF6331 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Received: from BY2PR05MB2183.namprd05.prod.outlook.com (10.166.112.11) by BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6 via Mailbox Transport; Thu, 27 Apr 2017 13:04:01 +0000 Received: from DM2PR0501CA0019.namprd05.prod.outlook.com (10.162.29.157) by BY2PR05MB2183.namprd05.prod.outlook.com (10.166.112.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Thu, 27 Apr 2017 13:04:00 +0000 Received: from BY2NAM05FT017.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::206) by DM2PR0501CA0019.outlook.office365.com (2a01:111:e400:5148::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1 via Frontend Transport; Thu, 27 Apr 2017 13:04:00 +0000 Authentication-Results: spf=softfail (sender IP is 4.31.198.44) smtp.mailfrom=metaswitch.com; juniper.net; dkim=pass (signature was verified) header.d=metaswitch.com;juniper.net; dmarc=pass action=none header.from=metaswitch.com; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning metaswitch.com discourages use of 4.31.198.44 as permitted sender) Received: from mail.ietf.org (4.31.198.44) by BY2NAM05FT017.mail.protection.outlook.com (10.152.100.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1019.24 via Frontend Transport; Thu, 27 Apr 2017 13:03:59 +0000 Received: by ietfa.amsl.com (Postfix, from userid 65534) id 741E61294A1; Thu, 27 Apr 2017 06:03:59 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mpls-rfc3107bis@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mpls-rfc3107bis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3C612949D; Thu, 27 Apr 2017 06:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.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 7JmdsJXNDcNN; Thu, 27 Apr 2017 06:03:56 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0102.outbound.protection.outlook.com [104.47.40.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D53129412; Thu, 27 Apr 2017 06:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q4xGS640pHMcxB1W1HodFwGQAgEL5OXas2xOYSBRC1I=; b=Wz6aajMnlV/cIQtrbXuhmkuSi0KaWhmXODB04OZrvttv2NUVZWJegI+pbA0xcMQASEMLOJRtJROyQ/+atQS7yWq7QpNhe+Ujr18XQTqb5ou1jVQN5kfJSgAZqIcAXJ1Buc9Msm1oJWlKYvXRElthfElj3cucpLhIrPGBulHikfM= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1911.namprd02.prod.outlook.com (10.163.75.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Thu, 27 Apr 2017 13:03:54 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.1047.021; Thu, 27 Apr 2017 13:03:53 +0000 From: Jonathan Hardwick To: "draft-ietf-mpls-rfc3107bis@ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" CC: "rtg-dir@ietf.org" Subject: Routing directorate review of draft-ietf-mpls-rfc3107-bis Thread-Topic: Routing directorate review of draft-ietf-mpls-rfc3107-bis Thread-Index: AdK/UgoPnMchP/X0SOKBF6US5Kr0Pw== Date: Thu, 27 Apr 2017 13:03:53 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [2620:104:4001:73:ada5:fc11:9d82:f5fe] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; BY2PR0201MB1911; 7:czp3mFeOOkx9I5b/i5cMBW5LYJU8V26gONvGcjmOzZ2cdNIZDVvxQ3lJe3+qMmPCAvBj1e3lpbfJITNEnmTH9Y7NB1S3OSKszoy1aHHC0dtrXHI7lm/sH2A/ts7ann3rSVi9K5NPu2DbpaLjLjL38n+TolK5NjZ63zTMGZSfaMpazDs8F9ZzVTcrrRkZ512lTrQlppnrwtZtK3LSRgK2NAF3LVZwUSu0xkq0uDXSQ3LDLIaJ0IOpZre4qVgzLGMHsbpmfkSQvYQpzRtAAWJounD9cRkC8zwA5NluMk30Hi6lSt0ZA6rKfQGMLPndi1kkx1Yb6F6C5yH5Qz2Zwb01Ng== X-MS-Office365-Filtering-Correlation-Id: 41d093ba-cfd7-413a-0a0c-08d48d6ddf09 X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BY2PR0201MB1911; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155);UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:BY2PR0201MB1911; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1911; BCL:0;PCL:0;RULEID:(601004)(2401047)(13018025)(8121501046)(13016025)(9101536074)(93006095)(93005095)(10201501046)(3002001);SRVR:BY2PR05MB2183;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB2183; x-forefront-prvs: 029097202E X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(39400400002)(39840400002)(39450400003)(39850400002)(39410400002)(38730400002)(53936002)(4326008)(345774005)(8936002)(236005)(3660700001)(2501003)(81166006)(2906002)(9686003)(86362001)(25786009)(2201001)(7696004)(450100002)(2900100001)(3280700002)(790700001)(6116002)(102836003)(7906003)(74316002)(5660300001)(55016002)(606005)(6506006)(77096006)(122556002)(54896002)(8676002)(6436002)(54356999)(99286003)(230783001)(33656002)(9326002)(50986999)(6306002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1911; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB19109FB5D0BF1F2FC02B8E5284100BY2PR0201MB1910_" X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1911 Resent-From: Resent-To: Resent-Message-ID: <20170427130359.741E61294A1@ietfa.amsl.com> Resent-Date: Thu, 27 Apr 2017 06:03:59 -0700 Return-Path: Jonathan.Hardwick@metaswitch.com X-MS-Exchange-Organization-Network-Message-Id: 41d093ba-cfd7-413a-0a0c-08d48d6ddf09 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: bea78b3c-4cdb-4130-854a-1d193232e5f4:0 X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-Exchange-Transport-CrossTenantHeadersStripped: BY2NAM05FT017.eop-nam05.prod.protection.outlook.com X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:4.31.198.44;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(8076002)(2980300002)(189002)(199003)(7696004)(2900100001)(9326002)(25786009)(356003)(77096006)(4326008)(50986999)(33656002)(54356999)(1096003)(189998001)(956001)(5660300001)(2501003)(8676002)(37156001)(106466001)(512874002)(105596002)(46386002)(107886003)(7636002)(90966002)(345774005)(230783001)(54896002)(6306002)(122556002)(84326002)(8666007)(6116002)(102836003)(790700001)(606005)(86362001)(9686003)(99286003)(2201001)(45336002)(55016002)(7596002)(6506006)(81446001)(1720100001)(61614004)(7906003)(236005)(14003)(74316002);DIR:INB;SFP:;SCL:1;SRVR:BY2PR05MB2183;H:mail.ietf.org;FPR:;SPF:SoftFail;MLV:sfv;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2NAM05FT017;1:d9QIg+pFemw3XbqFyabFBvES2hltx6ii9db78Tuv0SkAMo83ObIvi+2viMsKuZKC8WTYAs83eiaWuE6t/kfcKlZeYin3zfdJf/N0td3XgHLNRdpT1N4Xlts6E/rN+ZLqtak18CISPzcG5hiulvgzGBFdotK+wT/mwUVvpvUy9exC+85QcqMNdzILSeMYMQswxybM12gY2DxY2A5ZH81kdG3USSe1IqeCp/DALLiVn7QR8AkhB6BLKkWxwZxQDYFg6G/Dl+JQkrbEtdzBmfOzm/iy7LN9VjfQeLVMGW1/4gRpQduhkL0r2rLrqo0dIvFr8HaR0+2MiGElrLAqBX700bWLSl6hvz9JYE6r30SID1dgjVQ5zoIUuZNWFkoorid4cmL9Jr/TYHOrPKWHOLgYknlVhUtYhGyRk7hD3NAgCdFCGAwpZ2JBkDADEnWU9R43WNVo9V/2g2F+tXeKjgoMB+KbP0n8jV9W6Nb/zhWJQzFVIvooc+bFYUhmwME93MSyWRtnQXSU+X/Oztz7fu4V7AcJTmmXNqIAv1wngevHfvHucNI8Swq4GbDZfctL373RvyRY7Zlql+3S+ZThqM2QrKN0NZOTbyXxWDQLO3/LPsE= X-DkimResult-Test: Passed X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(81800236)(8251501002)(3001016)(3010002)(71702078);SRVR:BY2PR05MB2183; X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB2183;3:8jX58JYKhIz3u+uoCRQZ3ohfiQXguS1imi9ktbR4rgmvodAUpUfBs9oa/iJBd7lRCHeVURj8VCJtLbK6sNYTfnOyBfDefvu5mKCQpphgX07TXvBtBMAI6AlrINFGLu5RYcXDvdArlZzjs4uslA9zCOf2OzDO4ekeC778RVa3nGoonv8S/yhKu1HojFNYWYNhWa19gtaZaBhE1gb6TfIfG4dhBGVvLXMRhdhVI3W9Yqyx5i8NjPuWVQjV2VuvTnEAGv+DgOeUCao5fNUwZrLkoZ26z7PKHC5nmhhv6GPl+3nyPKGg+ziEvRCJxCTJuu7vk5XWDWBCuduShc2GmrFnc32UaaBFLN02U2XRfUAALDJmWHimUxtaxBb2VZmDsk+N1sl9ywmL/W28lqJAt+cTPWFvC3YUlXr3R5TWvudD+emjVY5HPZbboVpk0fYd0w0JXtoOYiY2BSX0U0WJi5JPNA== X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB2183;25:P0qLlxP5O/50gcqyOjPIHL1GVanVg9u6ngM7MIIQbDFiRGROrnZFs1CvuT0KPGszmcuUiUOJfyBSqSpz8EJkSdv/nU5O5N2j5bXr9gZKin0qgs/ijkvtyhzn72WFFQzxSfQnH3zl92T9StUAHrggCyu6ffHokTTNMaKgtXD7ZXJK78IDHBB5mqAoFV83eva1DLC0gHFFKEUbNG8480ed2NhVXOVQtglN4OTtJAr9Kt+yQ8hQWH9KUCPkP5bz7D966LhsyRds9HeaOyM0FkDYTpXMHcAj327j1x9l0ubkmEd+5W4fsgvf6LTYa9wMf+mN6BOZBehmw8PpncQn9YI18zoo3XkA9E3vS7MGsOBCflS4Nt5HYoCEBX5wvNTlQZ8hrR56q0h+Mg3n+0nwqSX+KF14pLgSAgMJdsNYsopjOvCYAiQ2/N3/RamSA//5pEQo/KL7SZ2g4LVYQia3VJWcRm1dOGbR2OozimS03NN1mtqcP0yLagZYAOXstjFHUk6k;31:dvAGoH/ZJX8n0TLFQ9XV6jUPNYXq6jexEX8g8Kried82hzXI04VhG83Ogbzxk0WjKmHAa3HZae6O4ZxUymfNCVMPT4yYO6aqUHeDivUSKg3TENEblaL2s9aiiImqkoWOSwr81JJZA67iJuSWAQpOU9zrCBF2B60s8mpX3Qo7Ap+QP+pVM8f0hZMNFb/PV9aSUPwZnEuFQrCGEXYr33+uODrFV74V7o6IdkZ3lXjVFXyQWsUynFiE4EXtchUKNhO+87/ERPrr3NLJJZ2DJc15Lw== X-JNPR-Received-From: outside X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB2183;20:goR20fF1+jNH9/xz4CqWh/uFFrODEd+HYIicRHSBwehH7k8+clkizYui/9S9jTenhSfUijxGVoDAFW4wmlt7sEOyEm8Yw1lr+KeHIYqXid2zeqNoqp7k6ZdVUxus9X9Ald3tnSNDD2bYe6Ug5ENf/5rzuAl9OrWZVKz3UTxRFQZA/j7/wJShbUXphE9wxEleHgM/4lTR9546AkRXL5CjxOGkRjvxw8E6mkddlp2nHQedduTOXIe1tChdbVZ4NyudKOXsMwanFAJeGqqGX9iuoyrbV5aaUrtYutQXs0gICS8fAPhGMhSQZ0pGtBxnepRx9RPzM8lnhvNhuwOcK9BDYpizUVZG8axFm5NNadRQB5bA4ALSjC9QZttQmta4xrelmd5PSzD4TR7XsHRRxTUSTqxNvyRrPV89FaRnuSwdLTy/qUOrpOi9KwcqTtm0LUVMBahZV+GODBB6vTsikA9d4U86OCvJtNxx+lumSHPI8rPAw8UvmiQ/oCUbAb+M2mQf X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB2183;4:0LxbNHNXDkhEw4w1ssh9R2tSWo946TmHqsoGUfmQb/n+0TgfO5aRGUULDqILNzbHzwiTHRuUna7UsxVNSBRUkHt1hZgTyvZZHYqMb+XO3z0FPWPW9oWPZDm7Oog0Z4in68cUkeANOaP/5jtl7nvGX6EpG2qN3safS46f3dYr2YpofDMX+v6bRgqOO1cR1O0cI8yTe6H3YnVykLHQAW49CD7x6SgcMAEDtyBydXXrvF41MvJ1TND+qgjk9zVMFC4Bb7cO+MIJnxFMY8bUfTEkvjmJWJS2dNjtL71OWf8xbOAFR6QoMs/WDAhqeHz0fPOn2RP6CIFoSoKzto0hQyl47+e3qI3Aj60685s+8WDoqrFW+ughaGl7pyQJe7h1mQNwtEsZCE6/8HBCeZsqKD2/m+MBlqByrJfQYr6rq2kaXXGnGxsv5ytfT3S5uvVXXpn2KkrWrcp3ZgwZozd5Za5jmUZrD1aqNDYYAIUY+kyT4rr+51M0vpjJ6wmh4SQTwlzsdAGcWQjrZaAyZfzUHx4er4vRijKAD2wHGOFtBqg2KjU= X-MS-Exchange-Organization-SCL: 1 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY2PR05MB2183;23:qE0MQxSDAILD7AKGry3gBF0m3m5ikTOuFn8aC70zs?= =?us-ascii?Q?wwDULm4GF7l3wr3e5LglNkEORiYdeP3pUIRSO5vH2j6CgtcP50r1CLKwGiJr?= =?us-ascii?Q?cDkIm0DLwUQJ4i+zZ1o42zfAsqP7cN2Pc7+GN7G+GNhi4LODLujfVyhb1r5s?= =?us-ascii?Q?029XVUrZIRf3MlDruccaPU3CdzXPiSPUumv2uiPTS3r4t0lVLTvycWGAamv7?= =?us-ascii?Q?D+1w1WOHWl10FN1ht5tKjvu7OW3yYZQT1D9i2mFJZja5NaK0PUZku3ME4wAX?= =?us-ascii?Q?0oBlS7DV0aEEPDvXIHedkmdX0gVsxeWFWeomjFFRfvajbe0Ycq0HXo1xbNmW?= =?us-ascii?Q?rF25dsiNYNwcVLGgHYAy8czC0mLsEPtMk6pAG2FEiyl6c6j5kSJl6B/H+nzx?= =?us-ascii?Q?NaENP2ZlMctzySYBvX8E49T5fxwPKu3x/2aVE1V2j8yTwiLLNfezWVfhFbcg?= =?us-ascii?Q?lhE/d2MV8NMFq7LxN9DsOhqC4zeDW/DRuwYq3JyUvONcW3xtwPuVAKutgWZJ?= =?us-ascii?Q?/z+xSnO308z2VuXQ5vFsAqFQMeD5eU5mDu1b2tJ2MVuhZqZPRQ4xMaH4FDD0?= =?us-ascii?Q?65E5MD5oFaCKYzNGOABRT6Xdqp/G2rO4rIYq1zAkcFmyAfxZoBGHv34TcQuv?= =?us-ascii?Q?mLJEvgTS4he3EcZnvA6/YsjPmBgL1ZJUuoFrYd7wiDU6er7AKlGmoAbMGx15?= =?us-ascii?Q?zUWtxa+0r2mkULwTPEc+k3Lzni4jUIeiKnjc/f1m7wlq6izypcKI2JHnSsuc?= =?us-ascii?Q?vOR0V7Jg7QgwaRHYWb97LF40li9h1I22oXJ718cGKi9y2nnWy5ksn0Y2mwvM?= =?us-ascii?Q?SueXfRsAJejuo9EN+J0FcEAJxXK6dDAqGh6BweP6PxeXSOh+iRedYACpOZ35?= =?us-ascii?Q?O+Q0mApp3X+nQ1Vn3+LUSRz+k1iB1b07iOjcGA5LU3HrpDlajGtATIv1Oh4J?= =?us-ascii?Q?dnAEfAjpg1hVUsgPAC/sm0FxqNFxZtwMtZyZGecMhkiKNIOrI1uLVROKRbpy?= =?us-ascii?Q?8k537CRQB7iXB46fZE3H9LqgtMydKkD34GtyMd9i8bbs0oEp8yu00XQ2xzk6?= =?us-ascii?Q?zsG7p/Iwv6PDzvdb6bZIqj2VveX8VRD4G7QjXgSZoQ+iJjH1HCnfNlNWGZxo?= =?us-ascii?Q?va2JZf5pQSEbWTMtSnb5v2ofVOXIzncaJYOYq+9IQBCfOUKlq4I1n5/OHcZF?= =?us-ascii?Q?dPVwWjr0YmKBFjT4vKKhjQ454jQZX3DB/VWa7Sv9zEyGrsjR8EAnR1BpjuuF?= =?us-ascii?Q?YnO+w0SmSPUJgdiYVg=3D?= X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB2183;6:cMRYyH8C1GqCiPhbhSD5dJX7iyszE0NcnNPKpehFoTzfGC3/8Xv2jKxodZPJSuge3v7Phaec4Gt1rYBRIML7ideCTIyQRc/GrZWmIu3J/qsUqaEpXoCT3eA6cyQUYfl0mTIcB7MRxjkMvo6cJb+HELr66H+hIy3UtSDrur2TEWqzEb6roXod7RNBvntm12MLcWyFHZyszuc8r0elv3+piOqMGq2qyTpWZTpN9C4H5w6mqhiq+9mqYym18w6VZm/3Kkn//essjCHrlzx6/7JYO/stQdP+AahQBQX9PEhLJZO/N8RHPf/fmTGmgO3Bg0czMhY9IOp10jhkiXM9FJ7KSvre5VFuuPofy4U+vXLmZCoIzWztLUKTu0PO97KmnCZn9eUONvyecsMa0gJME1BvXOss+WhyGJylPY/EMqvzqAtJnJi4nhuUIGdokLm2bi1nIbliq1cB53Bsy3g6CTepDQ==;5:EDPdxvPWvd7UVIeqV0j2ueQos6k0X9/DeuvyZ/fYkIbC/orh4rfLqTg/kfkptJPrJcUSBT3OTiq7in/EWbv1IIMKjtngg2cXGpxJWDR4mFqtVc960P/LVCx2tzma8c/Tmkcpon12AgeuTE3RfCpAWg==;24:YPuAW/3DgvPYROjsvdtGGkBw7T3IuaEnQPmqxnpaB2rUfY7gbFLpmufeQDRtk6vshujzBV/AucjNgkME7Le+Gh6OB8/Te3Lpb6tRxTKIHlg= X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB2183;7:m5KsdXrKP/onpJpVEM1uBJZMXUuf+jxSveYsPRZ90J8PgAeugAxyqMbPe9NdeE/FEmQjqgIhMgAvWMPvbB5aedy5GjUcDEL3OSEpgXtK+l9iU2CzsGIU65nwrjonroa4gsSEycm6xlfxLpYrmd1J5deshD1E3XkrbwIMqxMJqzj9kw4INWj8yuq85MDKHV4vC70tLcoS9UoZQ7IbcU55VtL9o/9sqfnVgaeAOQEA1OC98MJkMIL5qkktUGtoZG1GEb7JvKZw9vCpWYew+uEN4lG7zanZglqxjExYoIDjkWUw8N2qS/2bMwjI46bLuvAhnofz8yO4kpvT/pwQhiInGKINclmVyMv/IhyNdNqFQ5FoqJrr1F/HzkSESNDcSmGTAQZ6UZddsKkemv0nn5PpHw== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2017 13:03:59.7568 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2183 X-MS-Exchange-Organization-AuthSource: BY2NAM05FT017.eop-nam05.prod.protection.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Transport-EndToEndLatency: 00:00:01.7914814 X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;27:UO3IEkxDe3v8azEc71Znz33RtjiYbR0ox6QdAmIEa8qqHpu3wGU4ly65BRVygiZ2RyKKtHYvFDU8RsvIIPdBZcc0NivU2bjWLBCnopCaV8bdRB5d3d13BxaKrvn8FDicVM8LKVzF8UiWHauyUohvoQ== MIME-Version: 1.0 --_000_BY2PR0201MB19109FB5D0BF1F2FC02B8E5284100BY2PR0201MB1910_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;27:UO3IEkxDe3v8azEc71Znz33RtjiYbR0ox6QdAmIEa8qqHpu3wGU4ly65BRVygiZ2RyKKtHYvFDU8RsvIIPdBZcc0NivU2bjWLBCnopCaV8bdRB5d3d13BxaKrvn8FDicVM8LKVzF8UiWHauyUohvoQ== SGVsbG8NCg0KDQpJIGhhdmUgYmVlbiBzZWxlY3RlZCB0byBkbyBhIHJvdXRpbmcgZGlyZWN0b3Jh dGUg4oCcZWFybHnigJ0gcmV2aWV3IG9mIHRoaXMgZHJhZnQuDQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtcmZjMzEwN2Jpcy8NCg0KDQpUaGUgcm91dGlu ZyBkaXJlY3RvcmF0ZSB3aWxsLCBvbiByZXF1ZXN0IGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgY2hh aXIsIHBlcmZvcm0gYW4g4oCcZWFybHnigJ0gcmV2aWV3IG9mIGEgZHJhZnQgYmVmb3JlIGl0IGlz IHN1Ym1pdHRlZCBmb3IgcHVibGljYXRpb24gdG8gdGhlIElFU0cuICBUaGUgZWFybHkgcmV2aWV3 IGNhbiBiZSBwZXJmb3JtZWQgYXQgYW55IHRpbWUgZHVyaW5nIHRoZSBkcmFmdOKAmXMgbGlmZXRp bWUgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiAgVGhlIHB1cnBvc2Ugb2YgdGhlIGVhcmx5 IHJldmlldyBkZXBlbmRzIG9uIHRoZSBzdGFnZSB0aGF0IHRoZSBkb2N1bWVudCBoYXMgcmVhY2hl ZC4gIEFzIHRoaXMgZG9jdW1lbnQgaXMgaW4gd29ya2luZyBncm91cCBsYXN0IGNhbGwsIG15IGZv Y3VzIGZvciB0aGUgcmV2aWV3IHdhcyB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgZG9jdW1lbnQg aXMgcmVhZHkgdG8gYmUgcHVibGlzaGVkLiAgUGxlYXNlIGNvbnNpZGVyIG15IGNvbW1lbnRzIGFs b25nIHdpdGggdGhlIG90aGVyIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQoN Cg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBs ZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtp L1J0Z0Rpcg0KDQoNCg0KQmVzdCByZWdhcmRzDQoNCkpvbg0KDQoNCg0KRG9jdW1lbnQ6IGRyYWZ0 LWlldGYtbXBscy1yZmMzMTA3LTAxDQoNClJldmlld2VyOiBKb25hdGhhbiBIYXJkd2ljaw0KDQpS ZXZpZXcgRGF0ZTogMjcgQXByaWwgMjAxNw0KDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBU cmFjaw0KDQoNCg0KU3VtbWFyeQ0KVGhhbmsgeW91IGZvciB3cml0aW5nIHRoaXMgZG9jdW1lbnQu ICBJdCBwcm92aWRlcyBtdWNoLW5lZWRlZCBjbGFyaXR5IHRvIHRoZSBvcmlnaW5hbCBSRkMgMzEw Ny4NClRoaXMgZG9jdW1lbnQgaXMgdmVyeSB3ZWxsIHdyaXR0ZW4uICBJIHRoaW5rIHRoYXQgaXQg aXMgcmVhZHkgdG8gYmUgcHVibGlzaGVkLCBidXQgdGhlcmUgYXJlIGEgZmV3IHBvaW50cyBiZWxv dyB0aGF0IEkgd291bGQgbGlrZSB0byBkaXNjdXNzIGZvciBjbGFyaWZpY2F0aW9uLg0KSSBhbHNv IHNwb3R0ZWQgYSBmZXcgbml0cyB0aGF0IHNob3VsZCBiZSBmaXhlZCBhdCBzb21lIHBvaW50IGJl Zm9yZSBwdWJsaWNhdGlvbi4NCg0KQ29tbWVudHMgYW5kIFF1ZXN0aW9ucw0KDQoxKSBJbiBzZWN0 aW9uIDIuMSBpdCBzYXlzOg0K4oCcICAgSWYgdGhlIE11bHRpcGxlIExhYmVscyBDYXBhYmlsaXR5 IGZvciBhIGdpdmVuIEFGSS9TQUZJIGhhZCBiZWVuDQogICBleGNoYW5nZWQgb24gdGhlIGZhaWxl ZCBzZXNzaW9uLCBidXQgaXMgbm90IGV4Y2hhbmdlZCBvbiB0aGUNCiAgIHJlc3RhcnRlZCBzZXNz aW9uLCB0aGVuIGFueSBwcmVmaXhlcyBhZHZlcnRpc2VkIGluIHRoYXQgQUZJL1NBRkkgd2l0aA0K ICAgbXVsdGlwbGUgbGFiZWxzIE1VU1QgYmUgZXhwbGljaXRseSB3aXRoZHJhd24u4oCdDQoNCklm IEkgaGF2ZSB1bmRlcnN0b29kIHRoaXMgY29ycmVjdGx5LCBpdCByZXF1aXJlcyBhIHNwZWFrZXIg dG8gd2l0aGRyYXcgTkxSSSB0aGF0IGl0IHNlbnQgb24gdGhlIHByZXZpb3VzIHNlc3Npb24gYnV0 IHRoYXQgaXQgaGFzIG5vdCBzZW50IG9uIHRoZSByZXN0YXJ0ZWQgc2Vzc2lvbiAoYmVjYXVzZSB0 aGUgbmVnb3RpYXRlZCBzZXNzaW9uIGNhcGFiaWxpdGllcyBjaGFuZ2VkKS4NCihhKSBXaHkgZG9l cyBpdCBuZWVkIHRvIGRvIHRoYXQg4oCTIGlzbuKAmXQgdGhlIE5MUkkgaW1wbGljaXRseSB3aXRo ZHJhd24gd2hlbiB0aGUgRU9SIG1hcmtlciBpcyBzZW50Pw0KKGIpIFRoaXMgc2VlbXMgdG8gY29u dHJhZGljdCBzZWN0aW9uIDIuNCB3aGljaCBzYXlzIOKAnE5vdGUgdGhhdCBsYWJlbC9wcmVmaXgg YmluZGluZ3MgdGhhdCB3ZXJlIG5vdCBhZHZlcnRpc2VkIG9uIHRoZSBnaXZlbiBzZXNzaW9uIGNh bm5vdCBiZSB3aXRoZHJhd24gYnkgdGhpcyBtZXRob2Qu4oCdDQoNCg0KMikgSW4gc2VjdGlvbiAy LjEgaXQgc2F5czoNCuKAnEEgQkdQIHNwZWFrZXIgU0hPVUxEIE5PVCBzZW5kIGFuIFVQREFURSB0 aGF0IGJpbmRzIG1vcmUgbGFiZWxzIHRvIGEgZ2l2ZW4gcHJlZml4IHRoYW4gaXRzIHBlZXIgaXMg Y2FwYWJsZSBvZiByZWNlaXZpbmfigJ0g4oCTIHdoeSBpc27igJl0IHRoYXQgTVVTVCBOT1Q/DQoN Cg0KMykgSW4gc2VjdGlvbiAyLjQgaXQgc2F5czoNCuKAnFRvIGRvIHNvLCBpdCBtYXkgc2VuZCBh IEJHUCBVUERBVEUgbWVzc2FnZSB3aXRoIGFuIE1QX1VOUkVBQ0hfTkxSSSBhdHRyaWJ1dGUu4oCd DQpTaG91bGQgdGhhdCBiZSDigJxpdCBNVVNUIHNlbmTigJ0/DQoNCg0KNCkgSW4gc2VjdGlvbiA1 OiBhbHRob3VnaCBzb21lIGltcGxlbWVudGF0aW9ucyB0cmVhdCBTQUZJIDEgYW5kIFNBRkkgNCBy b3V0ZXMgYXMgY29tcGFyYWJsZSwgSSBiZWxpZXZlIHRoYXQgdGhleSBzaG91bGQgYWx3YXlzIGJl IHRyZWF0ZWQgYXMgaW5kZXBlbmRlbnQsIGluIHRoZSBmb2xsb3dpbmcgc2Vuc2U6DQpTdXBwb3Nl IGEgc3BlYWtlciBTMSBzZW5kcyBhIFNBRkkgMSByb3V0ZSBhbmQgdGhlbiBhIFNBRkkgNCByb3V0 ZSB0byB0aGUgc2FtZSBwcmVmaXggUC4gIFRoZSBTQUZJIDQgcm91dGUgTVVTVCBOT1QgYmUgdHJl YXRlZCBieSB0aGUgcmVjZWl2aW5nIHNwZWFrZXIgYXMgYW4gaW1wbGljaXQgd2l0aGRyYXcgb2Yg dGhlIFNBRkkgMSByb3V0ZS4gIElmIFMxIHN1YnNlcXVlbnRseSBzZW5kcyBhbiBleHBsaWNpdCB3 aXRoZHJhdyBvZiB0aGUgU0FGSSA0IHJvdXRlLCB0aGlzIE1VU1QgTk9UIGltcGxpY2l0bHkgd2l0 aGRyYXcgdGhlIFNBRkkgMSByb3V0ZSwgYW5kIHZpY2UgdmVyc2EuDQpBbSBJIGNvcnJlY3Q/ICBJ IGhhdmUgc2VlbiBpbXBsZW1lbnRhdGlvbnMgdGhhdCB2aW9sYXRlIHRoaXMgc28gSSB0aGluayBp dCBpcyB3b3J0aCBzcGVsbGluZyBvdXQgc29tZXdoZXJlIGluIHRoaXMgc2VjdGlvbi4NCg0KDQo1 KSBJbiBzZWN0aW9uIDcgaXQgc2F5czoNCuKAnCBJZiBhIEJHUCBpbXBsZW1lbnRhdGlvbiwgbm90 IGNvbmZvcm1hbnQgd2l0aCB0aGUgY3VycmVudCBkb2N1bWVudCwNCmVuY29kZXMgbXVsdGlwbGUg bGFiZWxzIGluIHRoZSBOTFJJIGJ1dCBoYXMgbm90IHNlbnQgYW5kIHJlY2VpdmVkIHRoZQ0KIk11 bHRpcGxlIExhYmVscyIgQ2FwYWJpbGl0eSwgYSBCR1AgaW1wbGVtZW50YXRpb24gdGhhdCBkb2Vz IGNvbmZvcm0NCndpdGggdGhlIGN1cnJlbnQgZG9jdW1lbnQgd2lsbCBsaWtlbHkgcmVzZXQgdGhl IEJHUCBzZXNzaW9uLuKAnQ0KDQpXb3VsZG7igJl0IHRoYXQgcHJldmVudCBpbmNyZW1lbnRhbCBk ZXBsb3ltZW50IG9mIHRoaXMgUkZDIGludG8gYSBuZXR3b3JrIHRoYXQgaXMgaW5pdGlhbGx5IGNv bXBvc2VkIG9mIHN1Y2ggaW1wbGVtZW50YXRpb25zPyAgQmVjYXVzZSBpdCBzZWVtcyB0byByZXF1 aXJlIHRoYXQgYm90aCBlbmRzIG9mIGVhY2ggQkdQIHNlc3Npb24gbXVzdCBiZSB1cGdyYWRlZCBz aW11bHRhbmVvdXNseSwgb3IgZWxzZSB0aGUgQkdQIHNlc3Npb25zIHdpbGwgYWxsIHJlc2V0Lg0K DQoNCk5pdHMNCg0KU2VjdGlvbiAyOiBNaXNzaW5nIGNsb3NlLXBhcmVudGhlc2lzIG9uIOKAnChb UkZDNDc2MF3igJ0g4oCTIHRoaXMgb2NjdXJzIHR3aWNlIGluIHRoaXMgc2VjdGlvbg0KU2VjdGlv biAyLjE6IHMvIGFuIHByZWZpeGVzIGFkdmVydGlzZWQvIGFueSBwcmVmaXhlcyBhZHZlcnRpc2Vk Lw0KU2VjdGlvbiAyLjE6IEZpZ3VyZSAxIGFwcGVhcnMgcXVpdGUgYSBsb25nIHdheSBkaXN0YW50 IGZyb20gdGhlIHRleHQgdGhhdCByZWZlcmVuY2VzIGl0LiAgSSBzdWdnZXN0IG1vdmluZyBpdCB0 byBpbW1lZGlhdGVseSBhZnRlciB0aGUgcGFyYWdyYXBoIGl0IGlzIHJlZmVyZW5jZWQgZnJvbS4N ClNlY3Rpb24gMi4xOiBzL01VU1QgQkUvTVVTVCBiZS8NClNlY3Rpb24gMy4xOiBzL2RpZmZlcmVu dCBwYXRoIGlkZW50aWZpZXJzLi4vZGlmZmVyZW50IHBhdGggaWRlbnRpZmllcnMuLyAgKGkuZS4g cmVtb3ZlIHN0cmF5IGV4dHJhIHBlcmlvZCkNClNlY3Rpb24gMy4yLjE6IOKAnHVzaW5nIHRoZSBw cm9jZWR1cmUgb2YgRmlndXJlIDTigJ0gc2hvdWxkIGJlIOKAnHVzaW5nIHRoZSBwcm9jZWR1cmUg b2YgU2VjdGlvbiAyLjTigJ0uDQpEaXR0byBpbiBzZWN0aW9uIDMuMi4yLg0KU2VjdGlvbiA0OiBz L1MgYSBsYXllciAyIGVuY2Fwc3VsYXRpb24vYSBsYXllciAyIGVuY2Fwc3VsYXRpb24vIChpLmUu IGRlbGV0ZSBzdHJheSDigJhT4oCZKQ0KDQo= --_000_BY2PR0201MB19109FB5D0BF1F2FC02B8E5284100BY2PR0201MB1910_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;27:UO3IEkxDe3v8azEc71Znz33RtjiYbR0ox6QdAmIEa8qqHpu3wGU4ly65BRVygiZ2RyKKtHYvFDU8RsvIIPdBZcc0NivU2bjWLBCnopCaV8bdRB5d3d13BxaKrvn8FDicVM8LKVzF8UiWHauyUohvoQ== PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3Ii IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48 IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJD YW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0 O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRl eHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFy Z2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCglt YXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVM7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQ bGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhlbGxvPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIHRvIGRvIGEgcm91dGluZyBkaXJlY3RvcmF0ZSDigJxl YXJseeKAnSByZXZpZXcgb2YgdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtbXBscy1yZmMzMTA3YmlzLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1tcGxzLXJmYzMxMDdiaXMvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5UaGUgcm91dGluZyBkaXJlY3RvcmF0ZSB3aWxsLCBvbiByZXF1ZXN0IGZyb20gdGhlIHdvcmtp bmcgZ3JvdXAgY2hhaXIsIHBlcmZvcm0gYW4g4oCcZWFybHnigJ0gcmV2aWV3IG9mIGEgZHJhZnQg YmVmb3JlIGl0IGlzIHN1Ym1pdHRlZCBmb3IgcHVibGljYXRpb24gdG8gdGhlIElFU0cuJm5ic3A7 IFRoZSBlYXJseSByZXZpZXcgY2FuIGJlIHBlcmZvcm1lZCBhdCBhbnkgdGltZSBkdXJpbmcgdGhl IGRyYWZ04oCZcyBsaWZldGltZQ0KIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4mbmJzcDsg VGhlIHB1cnBvc2Ugb2YgdGhlIGVhcmx5IHJldmlldyBkZXBlbmRzIG9uIHRoZSBzdGFnZSB0aGF0 IHRoZSBkb2N1bWVudCBoYXMgcmVhY2hlZC4mbmJzcDsgQXMgdGhpcyBkb2N1bWVudCBpcyBpbiB3 b3JraW5nIGdyb3VwIGxhc3QgY2FsbCwgbXkgZm9jdXMgZm9yIHRoZSByZXZpZXcgd2FzIHRvIGRl dGVybWluZSB3aGV0aGVyIHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBiZSBwdWJsaXNoZWQuJm5i c3A7IFBsZWFzZQ0KIGNvbnNpZGVyIG15IGNvbW1lbnRzIGFsb25nIHdpdGggdGhlIG90aGVyIHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5Gb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwg cGxlYXNlIHNlZSDigIs8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0 Zy90cmFjL3dpa2kvUnRnRGlyIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90 cmFjL3dpa2kvUnRnRGlyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CZXN0IHJl Z2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkpvbjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Eb2N1bWVudDogZHJhZnQtaWV0Zi1tcGxzLXJmYzMxMDct MDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJldmlld2VyOiBKb25h dGhhbiBIYXJkd2ljazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UmV2 aWV3IERhdGU6IDI3IEFwcmlsIDIwMTc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlN1bW1hcnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rIHlvdSBmb3Igd3JpdGluZyB0aGlzIGRvY3VtZW50LiZuYnNwOyBJdCBwcm92aWRlcyBt dWNoLW5lZWRlZCBjbGFyaXR5IHRvIHRoZSBvcmlnaW5hbCBSRkMgMzEwNy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZG9jdW1lbnQgaXMgdmVyeSB3ZWxsIHdyaXR0 ZW4uJm5ic3A7IEkgdGhpbmsgdGhhdCBpdCBpcyByZWFkeSB0byBiZSBwdWJsaXNoZWQsIGJ1dCB0 aGVyZSBhcmUgYSBmZXcgcG9pbnRzIGJlbG93IHRoYXQgSSB3b3VsZCBsaWtlIHRvIGRpc2N1c3Mg Zm9yIGNsYXJpZmljYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGFsc28gc3BvdHRlZCBhIGZldyBuaXRzIHRoYXQgc2hvdWxkIGJlIGZpeGVkIGF0IHNvbWUgcG9p bnQgYmVmb3JlIHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db21tZW50cyBh bmQgUXVlc3Rpb25zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIEluIHNlY3Rpb24gMi4xIGl0 IHNheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJwmbmJzcDsmbmJz cDsgSWYgdGhlIE11bHRpcGxlIExhYmVscyBDYXBhYmlsaXR5IGZvciBhIGdpdmVuIEFGSS9TQUZJ IGhhZCBiZWVuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsgZXhjaGFuZ2VkIG9uIHRoZSBmYWlsZWQgc2Vzc2lvbiwgYnV0IGlzIG5vdCBleGNoYW5nZWQg b24gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsg cmVzdGFydGVkIHNlc3Npb24sIHRoZW4gYW55IHByZWZpeGVzIGFkdmVydGlzZWQgaW4gdGhhdCBB RkkvU0FGSSB3aXRoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsgbXVsdGlwbGUgbGFiZWxzIE1VU1QgYmUgZXhwbGljaXRseSB3aXRoZHJhd24u4oCdPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIEkgaGF2ZSB1bmRlcnN0b29kIHRoaXMgY29ycmVjdGx5 LCBpdCByZXF1aXJlcyBhIHNwZWFrZXIgdG8gd2l0aGRyYXcgTkxSSSB0aGF0IGl0IHNlbnQgb24g dGhlIHByZXZpb3VzIHNlc3Npb24gYnV0IHRoYXQgaXQgaGFzIG5vdCBzZW50IG9uIHRoZSByZXN0 YXJ0ZWQgc2Vzc2lvbiAoYmVjYXVzZSB0aGUgbmVnb3RpYXRlZCBzZXNzaW9uIGNhcGFiaWxpdGll cyBjaGFuZ2VkKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihhKSBXaHkg ZG9lcyBpdCBuZWVkIHRvIGRvIHRoYXQg4oCTIGlzbuKAmXQgdGhlIE5MUkkgaW1wbGljaXRseSB3 aXRoZHJhd24gd2hlbiB0aGUgRU9SIG1hcmtlciBpcyBzZW50PzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+KGIpIFRoaXMgc2VlbXMgdG8gY29udHJhZGljdCBzZWN0aW9uIDIu NCB3aGljaCBzYXlzIOKAnE5vdGUgdGhhdCBsYWJlbC9wcmVmaXggYmluZGluZ3MgdGhhdCB3ZXJl IG5vdCBhZHZlcnRpc2VkIG9uIHRoZSBnaXZlbiBzZXNzaW9uIGNhbm5vdCBiZSB3aXRoZHJhd24g YnkgdGhpcyBtZXRob2Qu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgSW4gc2VjdGlvbiAyLjEgaXQgc2F5czo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnEEgQkdQIHNwZWFrZXIgU0hP VUxEIE5PVCBzZW5kIGFuIFVQREFURSB0aGF0IGJpbmRzIG1vcmUgbGFiZWxzIHRvIGEgZ2l2ZW4g cHJlZml4IHRoYW4gaXRzIHBlZXIgaXMgY2FwYWJsZSBvZiByZWNlaXZpbmfigJ0g4oCTIHdoeSBp c27igJl0IHRoYXQgTVVTVCBOT1Q/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MykgSW4gc2VjdGlvbiAyLjQgaXQgc2F5 czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnFRvIGRvIHNvLCBpdCBt YXkgc2VuZCBhIEJHUCBVUERBVEUgbWVzc2FnZSB3aXRoIGFuIE1QX1VOUkVBQ0hfTkxSSSBhdHRy aWJ1dGUu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG91bGQgdGhh dCBiZSDigJxpdCBNVVNUIHNlbmTigJ0/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NCkgSW4gc2VjdGlvbiA1OiBhbHRo b3VnaCBzb21lIGltcGxlbWVudGF0aW9ucyB0cmVhdCBTQUZJIDEgYW5kIFNBRkkgNCByb3V0ZXMg YXMgY29tcGFyYWJsZSwgSSBiZWxpZXZlIHRoYXQgdGhleSBzaG91bGQgYWx3YXlzIGJlIHRyZWF0 ZWQgYXMgaW5kZXBlbmRlbnQsIGluIHRoZSBmb2xsb3dpbmcgc2Vuc2U6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdXBwb3NlIGEgc3BlYWtlciBTMSBzZW5kcyBhIFNBRkkg MSByb3V0ZSBhbmQgdGhlbiBhIFNBRkkgNCByb3V0ZSB0byB0aGUgc2FtZSBwcmVmaXggUC4mbmJz cDsgVGhlIFNBRkkgNCByb3V0ZSBNVVNUIE5PVCBiZSB0cmVhdGVkIGJ5IHRoZSByZWNlaXZpbmcg c3BlYWtlciBhcyBhbiBpbXBsaWNpdCB3aXRoZHJhdyBvZiB0aGUgU0FGSSAxIHJvdXRlLiZuYnNw OyBJZiBTMSBzdWJzZXF1ZW50bHkgc2VuZHMgYW4gZXhwbGljaXQgd2l0aGRyYXcNCiBvZiB0aGUg U0FGSSA0IHJvdXRlLCB0aGlzIE1VU1QgTk9UIGltcGxpY2l0bHkgd2l0aGRyYXcgdGhlIFNBRkkg MSByb3V0ZSwgYW5kIHZpY2UgdmVyc2EuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BbSBJIGNvcnJlY3Q/Jm5ic3A7IEkgaGF2ZSBzZWVuIGltcGxlbWVudGF0aW9ucyB0aGF0 IHZpb2xhdGUgdGhpcyBzbyBJIHRoaW5rIGl0IGlzIHdvcnRoIHNwZWxsaW5nIG91dCBzb21ld2hl cmUgaW4gdGhpcyBzZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUpIEluIHNlY3Rpb24gNyBpdCBzYXlzOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLUdCIj7igJwgSWYgYSBCR1AgaW1wbGVtZW50YXRpb24sIG5vdCBjb25m b3JtYW50IHdpdGggdGhlIGN1cnJlbnQgZG9jdW1lbnQsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LUdCIj5lbmNvZGVzIG11bHRpcGxlIGxhYmVscyBpbiB0aGUgTkxSSSBidXQgaGFzIG5vdCBzZW50 IGFuZCByZWNlaXZlZCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPiZxdW90O011bHRp cGxlIExhYmVscyZxdW90OyBDYXBhYmlsaXR5LCBhIEJHUCBpbXBsZW1lbnRhdGlvbiB0aGF0IGRv ZXMgY29uZm9ybTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+d2l0aCB0aGUgY3VycmVudCBk b2N1bWVudCB3aWxsIGxpa2VseSByZXNldCB0aGUgQkdQIHNlc3Npb24u4oCdPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Xb3VsZG7igJl0IHRoYXQgcHJldmVudCBpbmNyZW1lbnRhbCBk ZXBsb3ltZW50IG9mIHRoaXMgUkZDIGludG8gYSBuZXR3b3JrIHRoYXQgaXMgaW5pdGlhbGx5IGNv bXBvc2VkIG9mIHN1Y2ggaW1wbGVtZW50YXRpb25zPyZuYnNwOyBCZWNhdXNlIGl0IHNlZW1zIHRv IHJlcXVpcmUgdGhhdCBib3RoIGVuZHMgb2YgZWFjaCBCR1Agc2Vzc2lvbiBtdXN0IGJlIHVwZ3Jh ZGVkIHNpbXVsdGFuZW91c2x5LCBvciBlbHNlIHRoZSBCR1ANCiBzZXNzaW9ucyB3aWxsIGFsbCBy ZXNldC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5OaXRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gMjog TWlzc2luZyBjbG9zZS1wYXJlbnRoZXNpcyBvbiDigJwoW1JGQzQ3NjBd4oCdIOKAkyB0aGlzIG9j Y3VycyB0d2ljZSBpbiB0aGlzIHNlY3Rpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNlY3Rpb24gMi4xOiBzLyBhbiBwcmVmaXhlcyBhZHZlcnRpc2VkLyBhbnkgcHJlZml4 ZXMgYWR2ZXJ0aXNlZC88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rp b24gMi4xOiBGaWd1cmUgMSBhcHBlYXJzIHF1aXRlIGEgbG9uZyB3YXkgZGlzdGFudCBmcm9tIHRo ZSB0ZXh0IHRoYXQgcmVmZXJlbmNlcyBpdC4mbmJzcDsgSSBzdWdnZXN0IG1vdmluZyBpdCB0byBp bW1lZGlhdGVseSBhZnRlciB0aGUgcGFyYWdyYXBoIGl0IGlzIHJlZmVyZW5jZWQgZnJvbS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gMi4xOiBzL01VU1QgQkUv TVVTVCBiZS88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gMy4x OiBzL2RpZmZlcmVudCBwYXRoIGlkZW50aWZpZXJzLi4vZGlmZmVyZW50IHBhdGggaWRlbnRpZmll cnMuLyZuYnNwOyAoaS5lLiByZW1vdmUgc3RyYXkgZXh0cmEgcGVyaW9kKTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiAzLjIuMTog4oCcdXNpbmcgdGhlIHByb2Nl ZHVyZSBvZiBGaWd1cmUgNOKAnSBzaG91bGQgYmUg4oCcdXNpbmcgdGhlIHByb2NlZHVyZSBvZiBT ZWN0aW9uIDIuNOKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRpdHRv IGluIHNlY3Rpb24gMy4yLjIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T ZWN0aW9uIDQ6IHMvUyBhIGxheWVyIDIgZW5jYXBzdWxhdGlvbi9hIGxheWVyIDIgZW5jYXBzdWxh dGlvbi8gKGkuZS4gZGVsZXRlIHN0cmF5IOKAmFPigJkpPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_BY2PR0201MB19109FB5D0BF1F2FC02B8E5284100BY2PR0201MB1910_-- --------------E246575E0BB9CB288EDF6331 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="Attached Message" Received: from BY2PR05MB2184.namprd05.prod.outlook.com (10.166.112.12) by BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1 via Mailbox Transport; Wed, 3 May 2017 18:23:09 +0000 Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.213] (66.129.241.14) by BY2PR05MB2184.namprd05.prod.outlook.com (10.166.112.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Wed, 3 May 2017 18:23:07 +0000 Subject: Re: Routing directorate review of draft-ietf-mpls-rfc3107-bis To: Jonathan Hardwick , "draft-ietf-mpls-rfc3107bis@ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" References: CC: "rtg-dir@ietf.org" From: Eric C Rosen Message-ID: <9913c8e1-50fe-34c1-a8d5-2d5efefafc5e@juniper.net> Date: Wed, 3 May 2017 14:23:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B904B5417489A850A8D161CD" X-MS-Exchange-Organization-Network-Message-Id: 7a60a971-f7d5-4636-ea42-08d4925172f0 X-MS-Exchange-Organization-AuthSource: BY2PR05MB2184.namprd05.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 06 X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BN6PR1301CA0021.namprd13.prod.outlook.com (10.174.84.162) To BY2PR05MB2184.namprd05.prod.outlook.com (10.166.112.12) Return-Path: erosen@juniper.net X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7a60a971-f7d5-4636-ea42-08d4925172f0 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(48565401081)(201703131423075)(201703031133081);SRVR:BY2PR05MB2184; X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB2184;3:fq0dx/bnVtlnzVUATiiGIUCkA43jXrXmQAib/C1+r5nDI/DdKTsUQiaEvLLu31wS+rJk5uiZjzjblnF4Eg24Qmnr6GV/PnjmoppBGM0AzedTjmG2CIpxSFgyNQTenNC/a6kb7P9GcuKve7IWBsDjaP+WhXk4zDnjNs7BVOn5fLXsZe7ueMVH8cX3c8JnQb25Gj+wASBy40pDzwdFViD3TR2ztDM+6sGmOq5Ng6GrJZtLC2JgiuO1j/bhLWE+ZtKfTnMhd25+P+6rCVEAWnldnmuA3zvzUob+gyema1f45OuPmEw6THda1H4oD95gIzbuhPk+kDHTSdV6i180MJtzNL0ESSoxZ9iQSIj6t+ygNAM=;25:jXapHb/8lyo2uqlMZINhFlUfQgVCCaSkSqqSajwbxFs1z3EwJ8cQ+LZTTAZFfo3J9IFvJbFGT55+wPR06DshYHWuW8tY3lrNwUHyBZ3bC80XshMRBcpA+iH6LCHmE743rVoyeOwFo+rwzvjEq+oZjvon6dpcehr8us8XrPrec2qYfQstMtJ/ULNoa5y7atC4zJ0pqNHBoo76u1JFIackuDAOi4cBPtjDYFy5X1DGt84xQSAPZFbyFrlyXo0SMBd92nyJIYasrhiHNx1lvRZeIwv1R4deKjm2iHFjKyVEphPp1iSy3qEL2HIg6UDfmYctvzmGSrltYWrNMKr5t9HwCQ0fx1bK4N50GV3+e90mNMCbfV4nWtZgoz04NHiYhMYjMpUdROtN8xS+gW3rdm8zDt6NMKZUSmGNcKLyWOUEPd3a5S8T4rzaNlIFJ0SwR6fHR0KWcSekidgnaz7LR85dHTNVBIP4nrdNw/N5Kc5PVP0= X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB2184;31:qR9pHLgGCjvAp/B3day5JpKkF13QpVCq2SmQFnQpQwMmN9Pp+wXTpJgYY3jLeGqvy/KVIxdWAyfsAe3EoJ7f2BQmdoR1mMvde9rVs9c7rfO+yf9vs3+iW8C8vS30a0Faan3xFXcBkFPBqYjvQfGZXuxLmxche+fq03epqy+Iowf7DqnLLN/auSZR4CtykleGWCPoCTikbyhz/VfolUTgxGXDNY646cNM+hRFXG8kMQ7BXcqtVJaMn1uPbnEMBUh6saSx8aBefMbt+78hREwNIhvQ3qMb5gsL9RApXrRFfy8=;20:Wv+RXv6VfQdKI55qULD8UIYs7MiiWt4qz0Vj6/Adz7EzWRQ1WGhZ0WcImbueEmYirzUY+eHLvH06wLxGhNynBHxDL/ggbZNvLIi6WYyks8T6eFz0VoNReazJ3NlI5rsWc6dcRATOFvJeatiATqwIzH5BJ6Hlb0v4NvLBqUX0lyomc7EukigMjts+Fe+hdSnXA8mCxwlPqg8OHhwGyRdHix1waORl9lC0n2Jkpr5Cwx7UjS+3133wN/J8z9H9SyG+fI2uzzN6BRu132grJOqdE679pzUM1E0pUAFTYm/UA7UkBAOAsXot68Q9CNkr/Mmj0p5wBMc1YiooS8XZZD3xTK3W6Upy1pHWkdRjP87pwWwDB/62/lq3dkGr1xwfbl/yGCfrs/7xxSpk3L2vVvC3cDkdflf1+1JSHEGAgG5QGjeu6QUkGLogpWXuKwHrWnCvSIDEkzvG3s1/C2FcXQAKqbnXQ4IHe/kCiWHBeW0xea74rtPY9MXB1vcI2vrbx6GsqjbSUD9QlKoSxwkNkwJzcBw31+TC5aaWVfgogDMialCYXWCc+w755OP2RhAbA5VvgA4jtbPvosiDUbfp/XWsWX3+Po5o30P1ITGEw7ct4wM= X-MS-Exchange-Organization-SCL: -1 X-Exchange-Antispam-Report-Test: UriScan:(189930954265078)(35073007944872); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(9101524173)(601004)(2401047)(8121501046)(10201501046)(3002001)(93006095)(93001095);SRVR:BY2PR05MB2184;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB2184; X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB2184;4:5RbeNXomndJj3t6rf/CkWYIqxkHbiHyqcbxpIblERUp24fc0//z2blHfOIGrkr2dAOnAChhaRnhRdEarp6AWj9+CkxMpjoLbckO1W7NDMXSfqkr9D5A3/8IQDE9L6FeB8KCAmXVskintTVVYI5srvDBXZ5XLazydVbZQbyPfEZjCJWvxODnLpdTLIbtFf145W8JmmCjd84nHh8WFgjAnKECA8xo8aceLzRXCa0zn3UVM+U/QcR96wQNVfbVnzjhoC0BODsXm3+kzjRJnfULw6OUw+DcTg/z4v8nPEE2iURi5h0UwcD/xXCxXh0lMzBltXQfNhbU0UkF/tw74FJZRtRI/RFg51o+51muf8SxMon5bnBAxxV5K4Wc/IuB3HE/wk76CNyUfopymoh+GOTbBdgrt8CIU8DEGL8TVzG0QoD3lwk0uJ/T7RSskGex7g67GqAUgKh35eDT2E7Q9KzSvVCaZLCTTSM5boPBjHsu1ozBkG8vPyoer5dBeWQBRQ9NVj47+a4jIm3XXl1VBh951Ow==;23:msTnqaTyRpTlFWoR1dULXXGU9mjYXYLne3vcPkNff7exwz6wh3W0Sew9JE/xhwcAql2+Yluz9rU+c4KzgHv70OVQ6XwM8WE2AfgUkJ9QkDL7FXBKFpQgofLqKJF8jE8I/ZuflI8G4tFniWkkCF51HA== X-Forefront-Antispam-Report: SFV:SKI;SFS:;DIR:INB;SFP:;SCL:-1;SRVR:BY2PR05MB2184;H:[172.29.35.213];FPR:;SPF:None;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB2184;6:SG2FvAQfgJo8mCyAHrldMvRSA4bIwe7SFaxbpboR3e3/Vw9C0v98BMct4W/2MFXDlilzkd7ssg79DfXvpOkVoPv+bzOP2wlzgMKv6WGfXRz5HJUqEvNG1uQwNxbfSR69gcxHvl2YN6J9j+3zJphTAxY1bHwW9AXnPdwB49no1mss2TqmNzOeJhn5DQqIXUB1d4IXiftP9bChWa5P5ix/+7qQIxdHCbLSwiO6e/Z54TMFkhIeJVVKjfym7C9zCdmA+5eswcDLQdnx2trbepMyz/t/BzI1xx3Vz2keLjAfQjs/qMupHdZJ4buHbpK8eo84CLy132EnELP0waLzbwjChOFRePeZCsBqUTHvfwTma3GELR7IgUchVTW3okEn3oKq5CDAMazH/hYA/g+kza7VX1DgnlTJCSpm46R+2TRLEAg=;5:rUEd+M2zDY3xCLzbNXCS2FgfyBs0qCTMss0CTCj+MQ7XDxA+tBh6scdz8Nju6mTcUadzzbJjxfCZWfP9vi5/29opIlLFE5sgCExL43iHxYqDCjlNUa3ElO8t8dDK9MHc2xJ9itAs10vhk2Jfv93/uQ==;24:53AnpWJHdEejnjHrn3mXPMpqfcqy55UTbCsflERnBKhd73wQAg0ox9DLrs7z6ZNxq5fnPa5j74j8cQH0k7GE4nN1+IidxbMqiU/r1VFDRcs= SpamDiagnosticOutput: 1:0 X-Microsoft-Exchange-Diagnostics: 1;BY2PR05MB2184;7:V+gCOL2K6pinw7yigwDEthJDd92GlgC/DlXTNEGljh8CvbcqNiIbhLAV2jUn2XBrNsu1LduRXgVeTjWVH4+LqoPSAVDRgNnmMExXDUARW7s9zplvh9iWBkd3woOXtnVkGMjPa+Xb68hOxhrAwLdCWhnmjNS1gUK/tUefx62yXSRykUUFAXpFJ0/IU6VukylTLdu7H5oPstwgxBnDZyfCcugRYRNjGZvwyTS5q3+ptRiPXSMfxPOtd3Wh1Jj3JmriHgfoi/1AO48XbmyOwq9ReEOOTNoB/nqfCRg4fmLXsQyaLBFJTRM9IRMcTy/+DVZs0va38Rdv4ObB48cfEA+Sog== X-MS-Exchange-Organization-Recipient-P2-Type: Bcc X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 May 2017 18:23:07.4167 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2184 X-MS-Exchange-Organization-MessageDirectionality: Originating X-MS-Exchange-Transport-EndToEndLatency: 00:00:02.5406125 X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;27:A+plyzssEjXwmTtFbIPUnkigUkFQc0juxJA3k23yg5TTLElTRfve51Z3kx6Mi/bAYItZPVnzuamCLFhGEAQ0Ab9yuCeXLzUuLRIDQVhV/EyKl11TNCrqfk2Yd5OrHEhwfXU0FLL8LIkfUekm33NoZA== MIME-Version: 1.0 --------------B904B5417489A850A8D161CD Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;27:A+plyzssEjXwmTtFbIPUnkigUkFQc0juxJA3k23yg5TTLElTRfve51Z3kx6Mi/bAYItZPVnzuamCLFhGEAQ0Ab9yuCeXLzUuLRIDQVhV/EyKl11TNCrqfk2Yd5OrHEhwfXU0FLL8LIkfUekm33NoZA== Thanks for your review! On 4/27/2017 9:03 AM, Jonathan Hardwick wrote: > > I also spotted a few nits that should be fixed at some point before > publication. > I have fixed the nits. > Comments and Questions > > 1) In section 2.1 it says: > > “ If the Multiple Labels Capability for a given AFI/SAFI had been > > exchanged on the failed session, but is not exchanged on the > > restarted session, then any prefixes advertised in that AFI/SAFI with > > multiple labels MUST be explicitly withdrawn.†> > If I have understood this correctly, it requires a speaker to withdraw > NLRI that it sent on the previous session but that it has not sent on > the restarted session (because the negotiated session capabilities > changed). > > (a) Why does it need to do that – isn’t the NLRI implicitly withdrawn > when the EOR marker is sent? > The theory here is that the label stack in the stale routes is known to be invalid, so you really don't want your peer to hold on to them until EOR is received. > (b) This seems to contradict section 2.4 which says “Note that > label/prefix bindings that were not advertised on the given session > cannot be withdrawn by this method.†> I added the following text to section 2.4 right after the quoted sentence: (However, if the bindings were advertised on a previous session with the same peer, and the current session is the result of a "graceful restart" ([RFC4724]) of the previous session, then this withdrawal method may be used.) > > 2) In section 2.1 it says: > > “A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a > given prefix than its peer is capable of receiving†– why isn’t that > MUST NOT? > Section 2.1 also requires the receiving speaker to apply "treat-as-withdraw" to such updates, which does imply that the sending speaker must not send them. So I've changed "SHOULD NOT" to "MUST NOT". > 3) In section 2.4 it says: > > “To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI > attribute.†> > Should that be “it MUST send� > I think the non-normative (non-RFC2119) language is fine here. > 4) In section 5: although some implementations treat SAFI 1 and SAFI 4 > routes as comparable, I believe that they should always be treated as > independent, in the following sense: > > Suppose a speaker S1 sends a SAFI 1 route and then a SAFI 4 route to > the same prefix P. The SAFI 4 route MUST NOT be treated by the > receiving speaker as an implicit withdraw of the SAFI 1 route. If S1 > subsequently sends an explicit withdraw of the SAFI 4 route, this MUST > NOT implicitly withdraw the SAFI 1 route, and vice versa. > > Am I correct? I have seen implementations that violate this so I > think it is worth spelling out somewhere in this section. > From Section 1: This document also addresses the issue of the how UPDATEs that bind labels to a given prefix interact with UPDATEs that advertise paths to that prefix but do not bind labels to it. However, for backwards compatibility, it declares most of these interactions to be matters of local policy. Different deployed implementations have different behavior, and I think it is better to advance the document as is rather than derail it with the inevitable food fight that would occur if we wanted to try to get the IETF to say which implementation is better than which other implementation. The deployed implementations have been around for many years, and people seem to have adapted to the differences. > 5) In section 7 it says: > > “ If a BGP implementation, not conformant with the current document, > > encodes multiple labels in the NLRI but has not sent and received the > > "Multiple Labels" Capability, a BGP implementation that does conform > > with the current document will likely reset the BGP session.†> > Wouldn’t that prevent incremental deployment of this RFC into a > network that is initially composed of such implementations? Because > it seems to require that both ends of each BGP session must be > upgraded simultaneously, or else the BGP sessions will all reset. > This issue was discussed at great length when the draft was first submitted. The vast majority of deployments do not check the S bit. That is, the de facto standard is to assume that a received update has only one label. If any existing deployment were transmitting updates with multiple labels encoded into the NLRI, it would already be causing BGP session resets. (Even iff this were a real problem, it wouldn't require both ends of a session to be upgraded simultaneously. It would just require one end to have a knob allowing it to accept both old and new behavior from its peer, and a knob telling it whether to use old or new behavior when sending to its peer. But since the defacto standard doesn't use multiple labels, I don't think we have to worry much about this.) --------------B904B5417489A850A8D161CD Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;27:A+plyzssEjXwmTtFbIPUnkigUkFQc0juxJA3k23yg5TTLElTRfve51Z3kx6Mi/bAYItZPVnzuamCLFhGEAQ0Ab9yuCeXLzUuLRIDQVhV/EyKl11TNCrqfk2Yd5OrHEhwfXU0FLL8LIkfUekm33NoZA==

Thanks for your review!


On 4/27/2017 9:03 AM, Jonathan Hardwick wrote:

I also spotted a few nits that should be fixed at some point before publication.


I have fixed the nits.

 

Comments and Questions

 

1) In section 2.1 it says:

“   If the Multiple Labels Capability for a given AFI/SAFI had been

   exchanged on the failed session, but is not exchanged on the

   restarted session, then any prefixes advertised in that AFI/SAFI with

   multiple labels MUST be explicitly withdrawn.â€

 

If I have understood this correctly, it requires a speaker to withdraw NLRI that it sent on the previous session but that it has not sent on the restarted session (because the negotiated session capabilities changed).

(a) Why does it need to do that – isn’t the NLRI implicitly withdrawn when the EOR marker is sent?


The theory here is that the label stack in the stale routes is known to be invalid, so you really don't want your peer to hold on to them until EOR is received.

(b) This seems to contradict section 2.4 which says “Note that label/prefix bindings that were not advertised on the given session cannot be withdrawn by this method.â€


I added the following text to section 2.4 right after the quoted sentence:
 (However, if the bindings were advertised on a previous session with the same peer, and the current session is the result of a "graceful restart" ([RFC4724]) of the previous session, then this withdrawal method may be used.)


2) In section 2.1 it says:

“A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a given prefix than its peer is capable of receiving†– why isn’t that MUST NOT?


Section 2.1 also requires the receiving speaker to apply "treat-as-withdraw" to such updates, which does imply that the sending speaker must not send them.  So I've changed "SHOULD NOT" to "MUST NOT". 

 

3) In section 2.4 it says:

“To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI attribute.â€

Should that be “it MUST send�


I think the non-normative (non-RFC2119) language is fine here. 

 

 

4) In section 5: although some implementations treat SAFI 1 and SAFI 4 routes as comparable, I believe that they should always be treated as independent, in the following sense:

Suppose a speaker S1 sends a SAFI 1 route and then a SAFI 4 route to the same prefix P.  The SAFI 4 route MUST NOT be treated by the receiving speaker as an implicit withdraw of the SAFI 1 route.  If S1 subsequently sends an explicit withdraw of the SAFI 4 route, this MUST NOT implicitly withdraw the SAFI 1 route, and vice versa.

Am I correct?  I have seen implementations that violate this so I think it is worth spelling out somewhere in this section.


From Section 1:
This document also addresses the issue of the how UPDATEs that bind labels to a given prefix interact with UPDATEs that advertise paths to that prefix but do not bind labels to it.  However, for backwards compatibility, it declares most of these interactions to be matters of local policy.
Different deployed implementations have different behavior, and I think it is better to advance the document as is rather than derail it with the inevitable food fight that would occur if we wanted to try to get the IETF to say which implementation is better than which other implementation.  The deployed implementations have been around for many years, and people seem to have adapted to the differences.

 

 

5) In section 7 it says:

“ If a BGP implementation, not conformant with the current document,

encodes multiple labels in the NLRI but has not sent and received the

"Multiple Labels" Capability, a BGP implementation that does conform

with the current document will likely reset the BGP session.â€

 

Wouldn’t that prevent incremental deployment of this RFC into a network that is initially composed of such implementations?  Because it seems to require that both ends of each BGP session must be upgraded simultaneously, or else the BGP sessions will all reset.

 


This issue was discussed at great length when the draft was first submitted.  The vast majority of deployments do not check the S bit.  That is, the de facto standard is to assume that a received update has only one label.   If any existing deployment were transmitting updates with multiple labels encoded into the NLRI, it would already be causing BGP session resets.

(Even iff this were a real problem, it wouldn't require both ends of a session to be upgraded simultaneously.  It would just require one end to have a knob allowing it to accept both old and new behavior from its peer, and a knob telling it whether to use old or new behavior when sending to its peer.  But since the defacto standard doesn't use multiple labels, I don't think we have to worry much about this.)

--------------B904B5417489A850A8D161CD-- --------------E246575E0BB9CB288EDF6331 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Received: from SN1PR05MB2192.namprd05.prod.outlook.com (10.169.124.140) by BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1 via Mailbox Transport; Thu, 4 May 2017 17:37:36 +0000 Received: from CY1PR05CA0028.namprd05.prod.outlook.com (10.166.186.166) by SN1PR05MB2192.namprd05.prod.outlook.com (10.169.124.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Thu, 4 May 2017 17:37:35 +0000 Received: from DM3NAM05FT045.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::201) by CY1PR05CA0028.outlook.office365.com (2a01:111:e400:c5a4::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Thu, 4 May 2017 17:37:36 +0000 Authentication-Results: spf=pass (sender IP is 104.47.34.117) smtp.mailfrom=metaswitch.com; juniper.net; dkim=pass (signature was verified) header.d=metaswitch.com;juniper.net; dmarc=pass action=none header.from=metaswitch.com; Received-SPF: Pass (protection.outlook.com: domain of metaswitch.com designates 104.47.34.117 as permitted sender) receiver=protection.outlook.com; client-ip=104.47.34.117; helo=NAM01-BY2-obe.outbound.protection.outlook.com; Received: from NAM01-BY2-obe.outbound.protection.outlook.com (104.47.34.117) by DM3NAM05FT045.mail.protection.outlook.com (10.152.98.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.12 via Frontend Transport; Thu, 4 May 2017 17:37:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rD3Injx8f7qmDia8xsf0R6dSjaKKl9xEYk8cgfNDJTk=; b=QuC1ztuaFolXIST+gpINVeC9tSV1Gnul2KZmiGjteTY9bxnbh+zjD8Fk64HYeFdrQzJGIwMf1/a6m9vNq5dzBYB4uZcVY1cNmMr7+iZiJyr73eVj+IqICEtUhB1MZ5z964CP9vhWCBYgDmiNsapt75lXW/o2/9x9rUKMfAnYzqw= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1912.namprd02.prod.outlook.com (10.163.75.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Thu, 4 May 2017 17:37:34 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.1075.010; Thu, 4 May 2017 17:37:34 +0000 From: Jonathan Hardwick To: Eric C Rosen , "draft-ietf-mpls-rfc3107bis@ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" CC: "rtg-dir@ietf.org" Subject: RE: Routing directorate review of draft-ietf-mpls-rfc3107-bis Thread-Topic: Routing directorate review of draft-ietf-mpls-rfc3107-bis Thread-Index: AdK/UgoPnMchP/X0SOKBF6US5Kr0PwE6EMqAAC5SQVA= Date: Thu, 4 May 2017 17:37:34 +0000 Message-ID: References: <9913c8e1-50fe-34c1-a8d5-2d5efefafc5e@juniper.net> In-Reply-To: <9913c8e1-50fe-34c1-a8d5-2d5efefafc5e@juniper.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [86.175.167.173] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1;BY2PR0201MB1912;7:nTxF7YELHQXk3O3PWOLT36Y9IfxTa1mFpgwWSpcohue2eH2jIo4xS5+u5qW60nr88pf4yKcAsAzF92/yCtrPsL3qOABRVABbkicMR6opwdCa7/XwoWSW/I2EEWStK+TI2Bdmaxpsf+1M/HjbzLDgm5Tj9DgU5kv+nG881eNpId+3P32KP4826iD/iytMWsxKmFRhubo2IZFFwrFEv8Axz2Ujk9xscgTz/Zd+QzzeBBCHmJ95OtLAmmwoU/GnXfGo26zZKRhV54bn6CnbX9EejKQR8BFIB1D9yzh8Us2f/gpdfZpDYgejdNbSUpM6ETxe30wFAfY2oIAL8OHxXSW/LA== X-MS-Office365-Filtering-Correlation-Id: 58e083c9-903c-4618-1e42-08d4931440ac X-Microsoft-Antispam-Untrusted: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075);SRVR:BY2PR0201MB1912; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(35073007944872)(138986009662008)(21748063052155);UriScan:(35073007944872)(138986009662008)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148);SRVR:BY2PR0201MB1912;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1912;BCL:0;PCL:0;RULEID:(601004)(2401047)(13024025)(13018025)(13016025)(8121501046)(9101536074)(93006095)(93005095)(3002001)(10201501046);SRVR:SN1PR05MB2192;BCL:0;PCL:0;RULEID:;SRVR:SN1PR05MB2192; x-forefront-prvs: 02973C87BC X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(10019020)(6009001)(39840400002)(39400400002)(39410400002)(39450400003)(24454002)(51444003)(377454003)(51914003)(2906002)(478600001)(189998001)(7696004)(76176999)(50986999)(54356999)(229853002)(3280700002)(2950100002)(3660700001)(230783001)(74316002)(5660300001)(2900100001)(6436002)(77096006)(6506006)(122556002)(33656002)(81166006)(8676002)(66066001)(8936002)(9686003)(54896002)(6306002)(55016002)(8666007)(99286003)(38730400002)(7736002)(53936002)(25786009)(53546009)(86362001)(2201001)(2501003)(3846002)(790700001)(102836003)(6116002)(4326008);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR0201MB1912;H:BY2PR0201MB1910.namprd02.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB19109734BAE5CFFB0E7DD70C84EA0BY2PR0201MB1910_" X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1912 Return-Path: Jonathan.Hardwick@metaswitch.com X-MS-Exchange-Organization-Network-Message-Id: 58e083c9-903c-4618-1e42-08d4931440ac X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: bea78b3c-4cdb-4130-854a-1d193232e5f4:0 X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-Exchange-Transport-CrossTenantHeadersStripped: DM3NAM05FT045.eop-nam05.prod.protection.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersPromoted: DM3NAM05FT045.eop-nam05.prod.protection.outlook.com X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:104.47.34.117;IPV:NLI;CTRY:;EFV:NLI;SFV:NSPM;SFS:(6009001)(8156002)(2980300002)(438002)(199003)(51444003)(51914003)(189002)(377454003)(24454002)(54356999)(356003)(2950100002)(956001)(76176999)(229853002)(106466001)(50986999)(2900100001)(86362001)(230783001)(8676002)(7696004)(33656002)(2201001)(8666007)(122556002)(6506006)(512874002)(25786009)(77096006)(53546009)(4326008)(7636002)(7736002)(3846002)(790700001)(6116002)(102836003)(107886003)(189998001)(53946003)(99286003)(16003)(84326002)(55016002)(9686003)(3720700001)(6306002)(54896002)(61614004)(6436002)(1096003)(2501003)(66066001)(5660300001)(74316002);DIR:INB;SFP:;SCL:1;SRVR:SN1PR05MB2192;H:NAM01-BY2-obe.outbound.protection.outlook.com;FPR:;SPF:Pass;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;DM3NAM05FT045;1:40exng5naT5H6sp88Vy6pj51y52FVjEEvPXTQdXNxJelVupHlkUkp4oRVepOCTeLDquwj8iF8uiq59dI2TJI+xP0xl7Mzp1TS1wNnf0A3Bh+sErOC1Uck3/aehhXlquDPdmXqy3J8KO3+8knLwb/au28qnMNBA1f6tXRlQm+ypjNPDoTlkS+Nv2SjYpsE47vvT2fy7IhK/FkSG4MpfIjYg4+2Q/Y90tOy8pupniPNqHTunBsz7aquYs+iHQzQ/Pq2h3Ib1rebpeHbJSYTMWna0ZUSJzudPHphVLSbflkbpUJ75QXPvx4iIba0weDJbZqnWekD15NMWKsEqzNTKsJhlJhPZY4egsuYFk3ZSBgDb0Goavzysp+DOGCz5gtvmDc1jBA34SOKk10C/salgVOwnQBmT05vLa3rhndCtj7tVLeHuwySqgA6h96OLXJSYPgaQKYRuoPN5hNRjdgOMtA+OhGpyZkcUlmAWuqjqJyimqN1ud7ZtKwcDK1jYhCq6QhAC3GXX3E8mrtLJR61s/Re8WsqB1iBv+O2j2UxeivQqf+NunvQUOMZDXnJOgy8Dc3DmIsfDIui5vFw4aXfy1jmv+nMAzu0l/zdvhHAdiZKjqBd77Gu+f2CpJtfNKDGZc+ X-DkimResult-Test: Passed X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(81800236)(8251501002)(3001016)(3010002)(71702078);SRVR:SN1PR05MB2192; X-Microsoft-Exchange-Diagnostics: 1;SN1PR05MB2192;3:hZpYywVmVJ93My8ThvPOFcH+Me6oexYJ/HeykKp1eThJybM7rpd8bz7BGWGtiKo/JJR23ATte2O/lkX3dRiGpKSD9H1K/rGnuYKLmB+JH221l0QpLGAOtM+knvV3xI+r569/NVMvW/IWVNS7rnamH17oG0xS9b4W2ZBxxigcr2lGP74yoPE1AsS7NgD3DigjaPoXRjeD4LT/HVF5xzHzP1l8oe//NDXVi4ekZTny/FkGb0M6ghj4KdaO3w/VrgsW5ZqxwgiCmjWY4fAB24hqsBRMvWzqQrpNcdNYdwFrmPKapLcJkIL5uw4w0l3+mHuaVfnQROMnHk0WcaUI7YQxKq6d1AJ5seJu+4pStk8GYjX4ixTvuyV8JdMLHi+MuqxplhH0V4s2fPvrLuSOfJBR61gKTgs4hPBDhLU/9m8eNwo40hwCEs7A2mMU1XgpeuYTqc1IQUDYMCdonWveyBpXCQ== X-Microsoft-Exchange-Diagnostics: 1;SN1PR05MB2192;25:8Mx16pT/5Cw1iHyayFVEn7zbO2A66ZoZsO/jglhAVWSQPxd5GRFQgnczUcHidY/LPxoTTqMUOBh+lSFsI4LaRgj0uBFWasGro3Wm1uGFuK2R1hLzG4xwZAJo6mT5e04JEy8f/glFYS2EmDI/V7z33VAdYYyII7XuuAneD35P4NMQNQnsufbZChOeZqfeVBN1EjIl114UU5N2U9c5iV4u1SaPcBpXovRKpGztDWCMETyCs0hRZCdDh208YjqAqnapcmQa6g5FnS9UeN7h0O0/uR2RZuMnJfSu2KCiMJJjQ0YMFoNdmDOyQ/evlvjsdoqtKUNOtGxdmHVg2fc7FYaaW95m2m6AOM1EtJ/W9H3YCC2ya0UIKpTuyg2Rt9NfILDb9kWAYY1H/GwF6u0nZN0RAsb6ITIwgISaRQxprPHNVIOWEzhBaDu/3lSLKMWzdhKBKWnz+okiaKEvPpzrFURXgk1H/8IsT/wLIicHSxwiyMg=;31:zZGk9QL/XfM516LES8fr4oknTHMbWIh8ArvH0lvAsr2vwmMhaefsD1IGSoZWqVxWlinsH2qbRWncJmNL04ym9cXF9g4ESAQbg/EHRJvMMU8KLRFzv7th8TpFpjZb/ClruGknPBW8cylEBN4RWLnqDP9Jyqppmy99/wDzJSY7UcPLFFjqp1LCQ0ChIa2azPstUDjnfxjlbnQF+blGkDBewXxOgt5ygGuRCBLC2yl1v8RInXIwsLLmJbE0LEKg9R8msqB5lsfUU9e5W3LXUrqkmCF4te/5/hP77dHyC8XRYZ5BzpUT3P0UgbozA7vQSzc+KqzSu2f9ruZ9kMtLsTBq9w== X-JNPR-Received-From: outside X-Microsoft-Exchange-Diagnostics: 1;SN1PR05MB2192;20:ksMKh0v+p+RvrTKwlE8dsb2E5A4LxM8pIqCW7Ng+vHwhSRX45Q21a2A1qLbWPj5GWrWEWNywaDuruiG4/hCG1uPjx9j2FfcyK9qWzmq2qW0F5CofiMaKsYc4VFOtuL4qKPevLPPYgFzd3/L4oKV4ecrTLV6TQGPiQGeWO6/xAfB8e21fy6H5cR6cL1IeLol8kY78HKMzzwhxsz32qyzx1XDqUqH2l9ZpMjo08d+VTircEprVIEIGjGpNXOhqftR+cbkMKv+2zfb4uoFKLhERt/53UBQl18k7/a5HRfzBHZOaJk/sc+waJex2uLQpAuctCSX0GZipilSxqtBX7yluhOSDHHNUeY9ZEKULFa3QuzNMrMSM7cvQmgc1amdyDq+KXACTuv0qZxnq0GvzTVDSZ+3Iw4f2gHskHAC/6fw6dEYes0PVqjqH/8H1KmtiLzReCi5VqZ3DTGVlFUQLgm1potnkTsrTA1OWzMTlzWYMcxOzwYsxdBQOlDtef5bo2G9L X-Microsoft-Exchange-Diagnostics: 1;SN1PR05MB2192;4:WV9diwIy9fo/WnQXCYVX+somTHtGG0T+ySmKBK926ae79vIFElnA0iRxIKU6psC8H6pCHWMQxIP1H6VOsDKbbmdPc4KivhLexpkhU0+1EmEktuowvA1wvUXSlFyt85SkMO0FuqQ3pXQUqQya1+9I1+aDkSMdzvykJfhnUZE0jVxMqKT91AgRG1sFumiY8A/IcouGAOBzIhdv95SWp3Z60a2P8fSLrd3O4vtLa8rp3W7APU+V2ArGqlKZtFn34xAdZG8O5zzBxkEJRfSCU+kpYpvXdLeZQW2qLTzk/rDFTV+yV6FsiOZBI3z5Mu52jkbHHYYf4FvXFLHv92MPAFDMhKWI4X6OHZ13iopo1RdOpda57Bqv7gXYV5wF7PJz62wsEmvZEW5uTnm+J8rckasnGshdHqRsQ/MfYenfd4QG0t08fAiTs+mRg9QzVP+1Ek73AY339ub8eOoVcmlhDsIUD3jC776k9KSuMrbfw5DBEEx73bonoyLBjyiCpWqKv4DNr97jYJ4p0YnG19bQiyxtXZ1beQ9AS1RZf03xq0F8ZH8rf5PJh6P5wh7CUgwSGWZhwiI3xAhT7eo7s6Bv7V6GtPEIklG4ajSFvZwsSDTWPOY= X-MS-Exchange-Organization-SCL: 1 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;SN1PR05MB2192;23:vcQF72I57mjVSIjP6idN/bIJQvafTd1ESFfcC9X4G?= =?us-ascii?Q?AyQNZrCDGNOg9RhjdBbDwhx9DtRI4Gm7e+aw03vdFUoN4E8PmmPAtlZs0vxF?= =?us-ascii?Q?zULGCp3ET81feqBLvciHE3yoYlGr/94K3gic6Tr8eivZ/8uSh5zffSTKGLr+?= =?us-ascii?Q?l3EueM5ucpIUzjNgWwYB7l2Dwp33QhGVL2B5VETRn8zHy9Bl+PdflljLHpBt?= =?us-ascii?Q?YsreUw0EkoqZYMCU7fLtbXjaJCIR/YuNbyRWzS5CtRDtJQv2lwJP2rlhzvoP?= =?us-ascii?Q?zBhzYMBujY9zImKJTxxnqev7mms6MdE/8Fk9dbOyvTLEbSuDbMxwq2VAET94?= =?us-ascii?Q?OBx/5Cihbw9ACj5YdIKtCqfSsydBf10nRnnKLhd5mOoo1fLVwmUWvVWLTUO7?= =?us-ascii?Q?P4NJ7hv4c/Du+wZ9PcRIzlsci9k6mFuvx+SBBakmESrN3M90vMxFdAqheLL1?= =?us-ascii?Q?rpjSX42w2kKwrLHV2fHhxMle7xe/Vr+rlz8bt95jdfpTLnRHwClbOTYA9VZh?= =?us-ascii?Q?a6gRz9yqS1DK0Ot12VR+xIY/knCO/27TUicYGF3LsI6mt9ROgz5J64h/ckgE?= =?us-ascii?Q?n15HMZuP7wAjdSG901Oz2DgKjkF+953HV+RWtj3QS5Q0MFnjVkycszqVHV+A?= =?us-ascii?Q?OXVoeKDNMIp3V+cLnBUt7Xzz2zVrqpX2AHwNflmy933nlIiZwcQ6QSpXKkvX?= =?us-ascii?Q?D4LE5Jy4jRI9LhS2tg4qgeXnNccZEYNVnbOn0llVcvYGsCfrLw2cvp3fnapA?= =?us-ascii?Q?9punaqkp0ShUnRMT/6+4EGv6dyGZgXMMAyM8cvr7/JcCzHl4FObY6/pbrs6b?= =?us-ascii?Q?0zYTMNaCJzLWbEoBrSK766usRQgIfLw9WP5mrYwgXMZ9Ua3P+0GGTzWOWAs4?= =?us-ascii?Q?yOlrU5wSVbEO3Figz8KrnRfyUUmWOpkO3889PO46Rxb1u3lo/AiafI7+3eR2?= =?us-ascii?Q?ol4Fr5KMkhOGM5KcFUqnDgembhFRxKpUeImCDK4Oe+NsW3mk2Rr+Hvfn9d0M?= =?us-ascii?Q?zdP3vkQa8G5KUSnCuivcIlCLhz5FHk2sUBS1vvU5FNyM9qGbO1yekTqLff3D?= =?us-ascii?Q?QnjXn/1UuTSoBjjrub2De5eFF6ykNkXZL4x1MMiqEvaR+Zyq7nkVdwbnHUFX?= =?us-ascii?Q?vSPOvu3ZE25XO8/CawnabNWbddsLqayifjlfHUDO9bSt6rX7uGV40gY1WmXI?= =?us-ascii?Q?UkOMMYPL6Bqxewcdd2gQwoo5up3rICr/fuzOMgVCes63uiFZWbc+nSkbYNqq?= =?us-ascii?Q?DUK6jUjboyUf9rZxdYKPj9Oy9gwmKAjeq8RZzQj2vuVVYkm5SHMenNuIaVdq?= =?us-ascii?Q?qhoUqI9aB0d2SGq81wUmF0=3D?= X-Microsoft-Exchange-Diagnostics: 1;SN1PR05MB2192;6:b6YBbGN6ZX3VlF+28l4tARf87YgswkjcfMCA58Va0Qap1SQZ5o4f+N2FeCUHKkjWZ0b3VI+MCgB/KdSLhZK9VWbJm7glMzDaNAwy4IQcvYF9AjkJxddEFLRJ+4PblwBm5D7unypphTRjq+2hxpbjR60/nxV2+jm7PVfWZei/RN16MaU4LphRtjc5CDlRKNC9CNzFGsZRJUfz3YTqB2zVhqGmS65KFJrJ80STtwWVWLf1dYx7J/Y1vr9H1bVuN1rM3/qRQqYsT3veWEjFBHAPqFvMRY+tTPa+OxfWN0c+Kd/stZgA6IDzFLpqMCep5a7GXnYyhWzcLXmUCLuvtLMAMHiM/Zs7UPoSqJqPm//cHe7MqyzU+MLNS87zhcAQ2+/ABzKxYBqNaSkks7CjmbrlEqxaFRBA0Vz6lR+5Q4vf4HtiUaKiPM3frG7QxEizrym6DRZVSAeO+jLH1ITmnPht4g==;5:IkxwLqv8cD1872xUspdpx8T/+6KQDUnBTKfoIUXM3QUkfz6ce54KqBgvn1IKBSjVOw/oeHnjSU8IWx+NA/DhFG+8CbZ4NZb2kKl4BNCoKjxwRLAVqBSSeTatRDiBWFBo37P2tge7Yq+8evEXo14ZXA==;24:cquI5y5ZfHofgX5vWPfSDOzFIqzqoT/zTkxf2kOziL0UJ73VXg57dW1oRdvhJmfO5WrEK9gYSFDTFzRYofH7waHcDdBqVAmpTd8fZtziTR4= X-Microsoft-Exchange-Diagnostics: 1;SN1PR05MB2192;7:sPWp1HJgPQALsYA083JZmsuxYfbUmd4i3pL7JNr16GYYXCQFjNgIns+DpJVeatO8XoEKz8tL0kpqkCoTMC/ztGDGz0pUVrMdU6nNJUJ+c6JEsQF+R6Qdm/bEZwwT/RXR08j1AEhnndNtZGaJp3jOZMjueY/r9oIjWrF0Z+K5xwTiCdZrRwzB63xyJe6A5lsnUE/xE+T0hr//nezpwu69RRzRSRE7D3sUzeknGP5qP6l3/A+l9EbYyZQUS32gG3OVSOPKaX8jemSmQes0H4fXZ6CRqzHrJIj2AQlXb/hW9QaoE2LbZkUzmFfE3+sZfzOTueEKH/Tqmh3Hs5QmOK43rh6yyHonr6+cZ6nns05gw6RmQBGr/RtvE39r5/T7aGtmcWdRnwfeB1OJMcdjCeh7iQ== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2017 17:37:35.7816 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2192 X-MS-Exchange-Organization-AuthSource: DM3NAM05FT045.eop-nam05.prod.protection.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Transport-EndToEndLatency: 00:00:01.3427382 X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;27:rwKa5c3PHr9RGx4O2ul8Jd6ujIOkEzVqig3iV4Nkhg4znE3QIQ1nK8xjfdIU2dNXpY4Piipz9SsMDKWN5xJZi8G1EgvpF4SXL/zFHBDvxDj7TLxmIAQewqqKdtppOQkEobk7RqzFv3U2NM4aeoS4EA== MIME-Version: 1.0 --_000_BY2PR0201MB19109734BAE5CFFB0E7DD70C84EA0BY2PR0201MB1910_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;27:rwKa5c3PHr9RGx4O2ul8Jd6ujIOkEzVqig3iV4Nkhg4znE3QIQ1nK8xjfdIU2dNXpY4Piipz9SsMDKWN5xJZi8G1EgvpF4SXL/zFHBDvxDj7TLxmIAQewqqKdtppOQkEobk7RqzFv3U2NM4aeoS4EA== SGkgRXJpYw0KDQpUaGFua3MgZm9yIHRoZSByZXBsaWVzIOKAkyBwbGVhc2Ugc2VlIFtKb25dIGlu bGluZS4NCg0KQ2hlZXJzDQpKb24NCg0KRnJvbTogRXJpYyBDIFJvc2VuIFttYWlsdG86ZXJvc2Vu QGp1bmlwZXIubmV0XQ0KU2VudDogMDMgTWF5IDIwMTcgMTk6MjMNClRvOiBKb25hdGhhbiBIYXJk d2ljayA8Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb20+OyBkcmFmdC1pZXRmLW1wbHMt cmZjMzEwN2Jpc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcN CkNjOiBydGctZGlyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogUm91dGluZyBkaXJlY3RvcmF0ZSBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLXJmYzMxMDctYmlzDQoNCg0KVGhhbmtzIGZvciB5b3Vy IHJldmlldyENCg0KT24gNC8yNy8yMDE3IDk6MDMgQU0sIEpvbmF0aGFuIEhhcmR3aWNrIHdyb3Rl Og0KSSBhbHNvIHNwb3R0ZWQgYSBmZXcgbml0cyB0aGF0IHNob3VsZCBiZSBmaXhlZCBhdCBzb21l IHBvaW50IGJlZm9yZSBwdWJsaWNhdGlvbi4NCg0KSSBoYXZlIGZpeGVkIHRoZSBuaXRzLg0KDQoN Cg0KQ29tbWVudHMgYW5kIFF1ZXN0aW9ucw0KDQoxKSBJbiBzZWN0aW9uIDIuMSBpdCBzYXlzOg0K 4oCcICAgSWYgdGhlIE11bHRpcGxlIExhYmVscyBDYXBhYmlsaXR5IGZvciBhIGdpdmVuIEFGSS9T QUZJIGhhZCBiZWVuDQogICBleGNoYW5nZWQgb24gdGhlIGZhaWxlZCBzZXNzaW9uLCBidXQgaXMg bm90IGV4Y2hhbmdlZCBvbiB0aGUNCiAgIHJlc3RhcnRlZCBzZXNzaW9uLCB0aGVuIGFueSBwcmVm aXhlcyBhZHZlcnRpc2VkIGluIHRoYXQgQUZJL1NBRkkgd2l0aA0KICAgbXVsdGlwbGUgbGFiZWxz IE1VU1QgYmUgZXhwbGljaXRseSB3aXRoZHJhd24u4oCdDQoNCklmIEkgaGF2ZSB1bmRlcnN0b29k IHRoaXMgY29ycmVjdGx5LCBpdCByZXF1aXJlcyBhIHNwZWFrZXIgdG8gd2l0aGRyYXcgTkxSSSB0 aGF0IGl0IHNlbnQgb24gdGhlIHByZXZpb3VzIHNlc3Npb24gYnV0IHRoYXQgaXQgaGFzIG5vdCBz ZW50IG9uIHRoZSByZXN0YXJ0ZWQgc2Vzc2lvbiAoYmVjYXVzZSB0aGUgbmVnb3RpYXRlZCBzZXNz aW9uIGNhcGFiaWxpdGllcyBjaGFuZ2VkKS4NCihhKSBXaHkgZG9lcyBpdCBuZWVkIHRvIGRvIHRo YXQg4oCTIGlzbuKAmXQgdGhlIE5MUkkgaW1wbGljaXRseSB3aXRoZHJhd24gd2hlbiB0aGUgRU9S IG1hcmtlciBpcyBzZW50Pw0KDQpUaGUgdGhlb3J5IGhlcmUgaXMgdGhhdCB0aGUgbGFiZWwgc3Rh Y2sgaW4gdGhlIHN0YWxlIHJvdXRlcyBpcyBrbm93biB0byBiZSBpbnZhbGlkLCBzbyB5b3UgcmVh bGx5IGRvbid0IHdhbnQgeW91ciBwZWVyIHRvIGhvbGQgb24gdG8gdGhlbSB1bnRpbCBFT1IgaXMg cmVjZWl2ZWQuDQoNCltKb25dIE9LLCB0aGF04oCZcyBmaW5lLg0KDQooYikgVGhpcyBzZWVtcyB0 byBjb250cmFkaWN0IHNlY3Rpb24gMi40IHdoaWNoIHNheXMg4oCcTm90ZSB0aGF0IGxhYmVsL3By ZWZpeCBiaW5kaW5ncyB0aGF0IHdlcmUgbm90IGFkdmVydGlzZWQgb24gdGhlIGdpdmVuIHNlc3Np b24gY2Fubm90IGJlIHdpdGhkcmF3biBieSB0aGlzIG1ldGhvZC7igJ0NCg0KSSBhZGRlZCB0aGUg Zm9sbG93aW5nIHRleHQgdG8gc2VjdGlvbiAyLjQgcmlnaHQgYWZ0ZXIgdGhlIHF1b3RlZCBzZW50 ZW5jZToNCiAoSG93ZXZlciwgaWYgdGhlIGJpbmRpbmdzIHdlcmUgYWR2ZXJ0aXNlZCBvbiBhIHBy ZXZpb3VzIHNlc3Npb24gd2l0aCB0aGUgc2FtZSBwZWVyLCBhbmQgdGhlIGN1cnJlbnQgc2Vzc2lv biBpcyB0aGUgcmVzdWx0IG9mIGEgImdyYWNlZnVsIHJlc3RhcnQiIChbUkZDNDcyNF0pIG9mIHRo ZSBwcmV2aW91cyBzZXNzaW9uLCB0aGVuIHRoaXMgd2l0aGRyYXdhbCBtZXRob2QgbWF5IGJlIHVz ZWQuKQ0KDQoNCjIpIEluIHNlY3Rpb24gMi4xIGl0IHNheXM6DQrigJxBIEJHUCBzcGVha2VyIFNI T1VMRCBOT1Qgc2VuZCBhbiBVUERBVEUgdGhhdCBiaW5kcyBtb3JlIGxhYmVscyB0byBhIGdpdmVu IHByZWZpeCB0aGFuIGl0cyBwZWVyIGlzIGNhcGFibGUgb2YgcmVjZWl2aW5n4oCdIOKAkyB3aHkg aXNu4oCZdCB0aGF0IE1VU1QgTk9UPw0KDQpTZWN0aW9uIDIuMSBhbHNvIHJlcXVpcmVzIHRoZSBy ZWNlaXZpbmcgc3BlYWtlciB0byBhcHBseSAidHJlYXQtYXMtd2l0aGRyYXciIHRvIHN1Y2ggdXBk YXRlcywgd2hpY2ggZG9lcyBpbXBseSB0aGF0IHRoZSBzZW5kaW5nIHNwZWFrZXIgbXVzdCBub3Qg c2VuZCB0aGVtLiAgU28gSSd2ZSBjaGFuZ2VkICJTSE9VTEQgTk9UIiB0byAiTVVTVCBOT1QiLg0K DQpbSm9uXSBUaGFua3MuICBOb3RlIHRoYXQgdGhlIHNhbWUgY2hhbmdlIGFsc28gYXBwbGllcyBp biBzZWN0aW9uIDMuMi4xDQoNCiAgIOKAnFNpbWlsYXJseSwgYSBnaXZlbiByb3V0ZSBTSE9VTEQg Tk9UIGJlDQogICBwcm9wYWdhdGVkIHRvIGEgZ2l2ZW4gcGVlciBpZiB0aGUgcm91dGUncyBOTFJJ IGhhcyBtb3JlIGxhYmVscyB0aGFuDQogICB0aGUgcGVlciBoYXMgYW5ub3VuY2Vk4oCdDQoNCuKA pmFuZCBhbHNvIGluIHNlY3Rpb24gMy4yLjINCg0K4oCcQSBCR1Agc3BlYWtlciBNVVNUIE5PVCBz ZW5kIG11bHRpcGxlDQoNCiAgIGxhYmVscyB0byBhIHBlZXIgd2l0aCB3aGljaCBpdCBoYXMgbm90 IGV4Y2hhbmdlZCB0aGUgIk11bHRpcGxlDQoNCiAgIExhYmVscyIgQ2FwYWJpbGl0eSwgYW5kIFNI T1VMRCBOT1Qgc2VuZCBtb3JlIGxhYmVscyB0byBhIGdpdmVuIHBlZXINCg0KICAgdGhhbiB0aGUg cGVlciBoYXMgYW5ub3VuY2Vk4oCdDQoNCg0KMykgSW4gc2VjdGlvbiAyLjQgaXQgc2F5czoNCuKA nFRvIGRvIHNvLCBpdCBtYXkgc2VuZCBhIEJHUCBVUERBVEUgbWVzc2FnZSB3aXRoIGFuIE1QX1VO UkVBQ0hfTkxSSSBhdHRyaWJ1dGUu4oCdDQpTaG91bGQgdGhhdCBiZSDigJxpdCBNVVNUIHNlbmTi gJ0/DQoNCkkgdGhpbmsgdGhlIG5vbi1ub3JtYXRpdmUgKG5vbi1SRkMyMTE5KSBsYW5ndWFnZSBp cyBmaW5lIGhlcmUuDQoNCltKb25dIEl0IGp1c3QgamFycmVkIHdpdGggbWUgYSBsaXR0bGUuICBJ 4oCZbSBub3QgZ29pbmcgdG8gZGlnIGluIG9uIHRoaXMgcG9pbnQsIGJ1dCBsZXQgbWUgZXhwbGFp biB3aGVyZSBJIHdhcyBjb21pbmcgZnJvbS4gIFdoZW4geW91IHNheSDigJxpdCBtYXkgc2VuZOKA nSB0aGUgd29yZCDigJxtYXnigJ0gbWFrZXMgaXQgc291bmQgbGlrZSBpdCBpcyBub3Qgb2JsaWdl ZCB0byBkbyBpdCB0aGlzIHdheS4gIEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhbnkgb3RoZXIg d2F5IHRvIHdpdGhkcmF3IHRoZSByb3V0ZSAoc2hvcnQgb2YgY2xvc2luZyB0aGUgc2Vzc2lvbikg c28gSSB0aGluayB0aGF0IHdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGlzIHRoZSBvYmxpZ2F0b3J5 IHdheSB0byB3aXRoZHJhdyB0aGUgcm91dGUuICBGb3IgdGhhdCByZWFzb24gSeKAmWQgcHJlZmVy IGVpdGhlciDigJxpdCBzZW5kc+KAnSBvciDigJxpdCBNVVNUIHNlbmTigJ0uDQoNCg0KNCkgSW4g c2VjdGlvbiA1OiBhbHRob3VnaCBzb21lIGltcGxlbWVudGF0aW9ucyB0cmVhdCBTQUZJIDEgYW5k IFNBRkkgNCByb3V0ZXMgYXMgY29tcGFyYWJsZSwgSSBiZWxpZXZlIHRoYXQgdGhleSBzaG91bGQg YWx3YXlzIGJlIHRyZWF0ZWQgYXMgaW5kZXBlbmRlbnQsIGluIHRoZSBmb2xsb3dpbmcgc2Vuc2U6 DQpTdXBwb3NlIGEgc3BlYWtlciBTMSBzZW5kcyBhIFNBRkkgMSByb3V0ZSBhbmQgdGhlbiBhIFNB RkkgNCByb3V0ZSB0byB0aGUgc2FtZSBwcmVmaXggUC4gIFRoZSBTQUZJIDQgcm91dGUgTVVTVCBO T1QgYmUgdHJlYXRlZCBieSB0aGUgcmVjZWl2aW5nIHNwZWFrZXIgYXMgYW4gaW1wbGljaXQgd2l0 aGRyYXcgb2YgdGhlIFNBRkkgMSByb3V0ZS4gIElmIFMxIHN1YnNlcXVlbnRseSBzZW5kcyBhbiBl eHBsaWNpdCB3aXRoZHJhdyBvZiB0aGUgU0FGSSA0IHJvdXRlLCB0aGlzIE1VU1QgTk9UIGltcGxp Y2l0bHkgd2l0aGRyYXcgdGhlIFNBRkkgMSByb3V0ZSwgYW5kIHZpY2UgdmVyc2EuDQpBbSBJIGNv cnJlY3Q/ICBJIGhhdmUgc2VlbiBpbXBsZW1lbnRhdGlvbnMgdGhhdCB2aW9sYXRlIHRoaXMgc28g SSB0aGluayBpdCBpcyB3b3J0aCBzcGVsbGluZyBvdXQgc29tZXdoZXJlIGluIHRoaXMgc2VjdGlv bi4NCg0KRnJvbSBTZWN0aW9uIDE6DQpUaGlzIGRvY3VtZW50IGFsc28gYWRkcmVzc2VzIHRoZSBp c3N1ZSBvZiB0aGUgaG93IFVQREFURXMgdGhhdCBiaW5kIGxhYmVscyB0byBhIGdpdmVuIHByZWZp eCBpbnRlcmFjdCB3aXRoIFVQREFURXMgdGhhdCBhZHZlcnRpc2UgcGF0aHMgdG8gdGhhdCBwcmVm aXggYnV0IGRvIG5vdCBiaW5kIGxhYmVscyB0byBpdC4gIEhvd2V2ZXIsIGZvciBiYWNrd2FyZHMg Y29tcGF0aWJpbGl0eSwgaXQgZGVjbGFyZXMgbW9zdCBvZiB0aGVzZSBpbnRlcmFjdGlvbnMgdG8g YmUgbWF0dGVycyBvZiBsb2NhbCBwb2xpY3kuDQpEaWZmZXJlbnQgZGVwbG95ZWQgaW1wbGVtZW50 YXRpb25zIGhhdmUgZGlmZmVyZW50IGJlaGF2aW9yLCBhbmQgSSB0aGluayBpdCBpcyBiZXR0ZXIg dG8gYWR2YW5jZSB0aGUgZG9jdW1lbnQgYXMgaXMgcmF0aGVyIHRoYW4gZGVyYWlsIGl0IHdpdGgg dGhlIGluZXZpdGFibGUgZm9vZCBmaWdodCB0aGF0IHdvdWxkIG9jY3VyIGlmIHdlIHdhbnRlZCB0 byB0cnkgdG8gZ2V0IHRoZSBJRVRGIHRvIHNheSB3aGljaCBpbXBsZW1lbnRhdGlvbiBpcyBiZXR0 ZXIgdGhhbiB3aGljaCBvdGhlciBpbXBsZW1lbnRhdGlvbi4gIFRoZSBkZXBsb3llZCBpbXBsZW1l bnRhdGlvbnMgaGF2ZSBiZWVuIGFyb3VuZCBmb3IgbWFueSB5ZWFycywgYW5kIHBlb3BsZSBzZWVt IHRvIGhhdmUgYWRhcHRlZCB0byB0aGUgZGlmZmVyZW5jZXMuDQoNCltKb25dIEkgYWdyZWUgdGhh dCB0aGlzIGRvY3VtZW50IGNhbuKAmXQgcmV0cm9zcGVjdGl2ZWx5IGRlcHJlY2F0ZSBleGlzdGlu Zywgd2lkZWx5IGRlcGxveWVkIGJlaGF2aW91cnMuICBJbiBzZWN0aW9uIDUgeW91IHNheQ0KDQoN CuKAnE90aGVyIGltcGxlbWVudGF0aW9ucyBtYXkgdHJlYXQgdGhlIFNBRkktMSBhbmQgU0FGSS00 IHJvdXRlcyBmb3IgYSBnaXZlbiBwcmVmaXggYXMgY29tcGFyYWJsZeKAnQ0KDQoNCg0KSW1hZ2lu ZSB0aGF0IHRoZSBTQUZJIDEgYW5kIFNBRkkgNCByb3V0ZXMgd2VyZSByZWNlaXZlZCBmcm9tIHRo ZSBzYW1lIHBlZXIgb24gdGhlIHNhbWUgc2Vzc2lvbi4gIFdoYXQgZG8geW91IG1lYW4gYnkg4oCc Y29tcGFyYWJsZeKAnSBpbiB0aGlzIGNvbnRleHQ/ICBJdCBoYXMgYmVlbiBpbnRlcnByZXRlZCBp biBpbmNvbXBhdGlibGUgd2F5cyBieSBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zLg0KDQotICAg ICAgICBFaXRoZXI6IHRoZSByb3V0ZXMgYXJlIGluZGVwZW5kZW50IGluIHRoZSBBZGotUklCLUlu IGJ1dCBjb21wYXJhYmxlIGluIHRoZSBMT0MtUklCIChhIHNpbmdsZSBiZXN0IG9uZSBpcyBzZWxl Y3RlZCwgdGhlIG90aGVyIGlzIHJldGFpbmVkIGluIG1lbW9yeSkNCg0KLSAgICAgICAgT3I6IFRo ZSByb3V0ZXMgYXJlIGNvbXBhcmFibGUgaW4gdGhlIEFkai1SSUItSW4gaS5lLiBvbmUgaW1wbGlj aXRseSB3aXRoZHJhd3MgdGhlIG90aGVyLg0KDQoNCg0KQm90aCBvZiB0aGVzZSBiZWhhdmlvdXJz IGFyZSBpbXBsZW1lbnRlZCBhbmQgZGVwbG95ZWQuICBUaGUgaXNzdWUgaXMgdGhhdCB0aGV5IGRv IG5vdCBpbnRlcm9wZXJhdGUgaWYgU0FGSSAxIGFuZCBTQUZJIDQgYXJlIGVuYWJsZWQgb24gdGhl IHNhbWUgc2Vzc2lvbi4gIEZvciBpbnN0YW5jZSwgaWYgYW4gaW1wbGVtZW50YXRpb24gb2YgdGhl IGZpcnN0IHR5cGUgd2l0aGRyYXdzIGl0cyBTQUZJIDQgcm91dGUgdGhlbiBhbiBpbXBsZW1lbnRh dGlvbiBvZiB0aGUgc2Vjb25kIHR5cGUgaXMgbGVmdCB3aXRoIG5vIFNBRkkgMSByb3V0ZSB3aXRo IHdoaWNoIHRvIGZvcndhcmQgdHJhZmZpYy4gIFlvdSBkZXNjcmliZSB0aGlzIGFzIGEgbWF0dGVy IG9mIHBvbGljeSwgd2hpY2ggSSBjYW4gbGl2ZSB3aXRoLCBidXQgd2l0aG91dCBmdXJ0aGVyIGRp c2N1c3Npb24gaXQgZ2l2ZXMgbm8gY2x1ZSB0byB0aGUgbGFjayBvZiBpbnRlcm9wZXJhYmlsaXR5 Lg0KDQoNCg0KSSB1bmRlcnN0YW5kIHRoYXQgaXQgaXMgdG9vIGxhdGUgdG8gc2F5IHRoYXQgb25l IG9mIHRoZXNlIGlzIHdyb25nIGFuZCBvbmUgaXMgcmlnaHQsIGJ1dCB0aGUgbGFjayBvZiBpbnRl cm9wZXJhYmlsaXR5IGlzIGFuIGltcG9ydGFudCBkZXBsb3ltZW50IGNvbnNpZGVyYXRpb24gYW5k IEkgZG9u4oCZdCB0aGluayB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSBzaWxlbnQgb24gaXQuICBJ TU8gdGhpcyBpcyBhbiBpbXBvcnRhbnQgZGV0YWlsIGZvciBpbXBsZW1lbnRlcnMsIHdobyBuZWVk IHRvIGJlIGF3YXJlIHRoYXQgYm90aCBpbnRlcnByZXRhdGlvbnMgb2Yg4oCcY29tcGFyYWJsZeKA nSBleGlzdC4gIE5ldyBpbXBsZW1lbnRhdGlvbnMgbWF5IHdpc2ggdG8gaGF2ZSBhIOKAnGNvbXBh dGliaWxpdHkgc2V0dGluZ+KAnSB0aGF0IGVtdWxhdGVzIG9uZSBvciB0aGUgb3RoZXIgYmVoYXZp b3VyIG9uIGEgcGFydGljdWxhciBzZXNzaW9uLCBzbyB0aGF0IHRoZXkgY2FuIGludGVyb3BlcmF0 ZS4NCg0KDQoNCk15IHN1Z2dlc3Rpb246IGNhbiB3ZSBleHBhbmQgc2VjdGlvbiA1IHNsaWdodGx5 IHRvIGNsYXJpZnkgdGhhdCB0aGVyZSBhcmUgdHdvIHdheXMgaW4gd2hpY2ggaW1wbGVtZW50YXRp b25zIGNhbiBjb25zaWRlciBTQUZJIDEgYW5kIFNBRkkgNCByb3V0ZXMgY29tcGFyYWJsZSBvbiBh IGdpdmVuIHNlc3Npb24sIGFzIGFib3ZlLCBhbmQgdGhhdCB0aGUgcmVzdWx0aW5nIGludGVyb3Bl cmFiaWxpdHkgaXNzdWUgY2FuIGJlIGF2b2lkZWQgZWl0aGVyIGJ5IGVtdWxhdGluZyB0aGUgYXBw cm9wcmlhdGUgYmVoYXZpb3VyIG9uIHRoYXQgc2Vzc2lvbiBvciBieSBub3QgcnVubmluZyBTQUZJ IDEgYW5kIFNBRkkgNCBvbiB0aGUgc2FtZSBzZXNzaW9uPw0KDQo1KSBJbiBzZWN0aW9uIDcgaXQg c2F5czoNCuKAnCBJZiBhIEJHUCBpbXBsZW1lbnRhdGlvbiwgbm90IGNvbmZvcm1hbnQgd2l0aCB0 aGUgY3VycmVudCBkb2N1bWVudCwNCmVuY29kZXMgbXVsdGlwbGUgbGFiZWxzIGluIHRoZSBOTFJJ IGJ1dCBoYXMgbm90IHNlbnQgYW5kIHJlY2VpdmVkIHRoZQ0KIk11bHRpcGxlIExhYmVscyIgQ2Fw YWJpbGl0eSwgYSBCR1AgaW1wbGVtZW50YXRpb24gdGhhdCBkb2VzIGNvbmZvcm0NCndpdGggdGhl IGN1cnJlbnQgZG9jdW1lbnQgd2lsbCBsaWtlbHkgcmVzZXQgdGhlIEJHUCBzZXNzaW9uLuKAnQ0K DQpXb3VsZG7igJl0IHRoYXQgcHJldmVudCBpbmNyZW1lbnRhbCBkZXBsb3ltZW50IG9mIHRoaXMg UkZDIGludG8gYSBuZXR3b3JrIHRoYXQgaXMgaW5pdGlhbGx5IGNvbXBvc2VkIG9mIHN1Y2ggaW1w bGVtZW50YXRpb25zPyAgQmVjYXVzZSBpdCBzZWVtcyB0byByZXF1aXJlIHRoYXQgYm90aCBlbmRz IG9mIGVhY2ggQkdQIHNlc3Npb24gbXVzdCBiZSB1cGdyYWRlZCBzaW11bHRhbmVvdXNseSwgb3Ig ZWxzZSB0aGUgQkdQIHNlc3Npb25zIHdpbGwgYWxsIHJlc2V0Lg0KDQoNClRoaXMgaXNzdWUgd2Fz IGRpc2N1c3NlZCBhdCBncmVhdCBsZW5ndGggd2hlbiB0aGUgZHJhZnQgd2FzIGZpcnN0IHN1Ym1p dHRlZC4gIFRoZSB2YXN0IG1ham9yaXR5IG9mIGRlcGxveW1lbnRzIGRvIG5vdCBjaGVjayB0aGUg UyBiaXQuICBUaGF0IGlzLCB0aGUgZGUgZmFjdG8gc3RhbmRhcmQgaXMgdG8gYXNzdW1lIHRoYXQg YSByZWNlaXZlZCB1cGRhdGUgaGFzIG9ubHkgb25lIGxhYmVsLiAgIElmIGFueSBleGlzdGluZyBk ZXBsb3ltZW50IHdlcmUgdHJhbnNtaXR0aW5nIHVwZGF0ZXMgd2l0aCBtdWx0aXBsZSBsYWJlbHMg ZW5jb2RlZCBpbnRvIHRoZSBOTFJJLCBpdCB3b3VsZCBhbHJlYWR5IGJlIGNhdXNpbmcgQkdQIHNl c3Npb24gcmVzZXRzLg0KW0pvbl0gT0suDQoNCihFdmVuIGlmZiB0aGlzIHdlcmUgYSByZWFsIHBy b2JsZW0sIGl0IHdvdWxkbid0IHJlcXVpcmUgYm90aCBlbmRzIG9mIGEgc2Vzc2lvbiB0byBiZSB1 cGdyYWRlZCBzaW11bHRhbmVvdXNseS4gIEl0IHdvdWxkIGp1c3QgcmVxdWlyZSBvbmUgZW5kIHRv IGhhdmUgYSBrbm9iIGFsbG93aW5nIGl0IHRvIGFjY2VwdCBib3RoIG9sZCBhbmQgbmV3IGJlaGF2 aW9yIGZyb20gaXRzIHBlZXIsIGFuZCBhIGtub2IgdGVsbGluZyBpdCB3aGV0aGVyIHRvIHVzZSBv bGQgb3IgbmV3IGJlaGF2aW9yIHdoZW4gc2VuZGluZyB0byBpdHMgcGVlci4gIEJ1dCBzaW5jZSB0 aGUgZGVmYWN0byBzdGFuZGFyZCBkb2Vzbid0IHVzZSBtdWx0aXBsZSBsYWJlbHMsIEkgZG9uJ3Qg dGhpbmsgd2UgaGF2ZSB0byB3b3JyeSBtdWNoIGFib3V0IHRoaXMuKQ0K --_000_BY2PR0201MB19109734BAE5CFFB0E7DD70C84EA0BY2PR0201MB1910_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;27:rwKa5c3PHr9RGx4O2ul8Jd6ujIOkEzVqig3iV4Nkhg4znE3QIQ1nK8xjfdIU2dNXpY4Piipz9SsMDKWN5xJZi8G1EgvpF4SXL/zFHBDvxDj7TLxmIAQewqqKdtppOQkEobk7RqzFv3U2NM4aeoS4EA== PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3Ii IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48 IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oldp bmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjpibGFjazsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUzt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT O30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNzI5NzIxMjY3Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1MjMyOTAwMTIgLTYzMzY5NjIxNCAxMzQ4 MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAx MzQ4MDc1NTUgMTM0ODA3NTU3O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1m b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIEVyaWM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIHJlcGxpZXMg4oCTIHBsZWFz ZSBzZWUgW0pvbl0gaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkpvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdC Ij4gRXJpYyBDIFJvc2VuIFttYWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IDAzIE1heSAyMDE3IDE5OjIzPGJyPg0KPGI+VG86PC9iPiBKb25hdGhhbiBIYXJkd2lj ayAmbHQ7Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb20mZ3Q7OyBkcmFmdC1pZXRmLW1w bHMtcmZjMzEwN2Jpc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5v cmc8YnI+DQo8Yj5DYzo8L2I+IHJ0Zy1kaXJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFJvdXRpbmcgZGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbXBscy1yZmMzMTA3 LWJpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPlRoYW5rcyBmb3IgeW91ciByZXZpZXch PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDQvMjcvMjAxNyA5OjAz IEFNLCBKb25hdGhhbiBIYXJkd2ljayB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFsc28gc3BvdHRlZCBhIGZldyBuaXRzIHRoYXQgc2hvdWxk IGJlIGZpeGVkIGF0IHNvbWUgcG9pbnQgYmVmb3JlIHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48YnI+DQpJIGhhdmUgZml4ZWQgdGhlIG5pdHMu PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1l bnRzIGFuZCBRdWVzdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgSW4gc2VjdGlvbiAy LjEgaXQgc2F5czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnCZuYnNw OyZuYnNwOyBJZiB0aGUgTXVsdGlwbGUgTGFiZWxzIENhcGFiaWxpdHkgZm9yIGEgZ2l2ZW4gQUZJ L1NBRkkgaGFkIGJlZW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyBleGNoYW5nZWQgb24gdGhlIGZhaWxlZCBzZXNzaW9uLCBidXQgaXMgbm90IGV4Y2hh bmdlZCBvbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyByZXN0YXJ0ZWQgc2Vzc2lvbiwgdGhlbiBhbnkgcHJlZml4ZXMgYWR2ZXJ0aXNlZCBpbiB0 aGF0IEFGSS9TQUZJIHdpdGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyBtdWx0aXBsZSBsYWJlbHMgTVVTVCBiZSBleHBsaWNpdGx5IHdpdGhkcmF3bi7i gJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgSSBoYXZlIHVuZGVyc3Rvb2QgdGhpcyBjb3Jy ZWN0bHksIGl0IHJlcXVpcmVzIGEgc3BlYWtlciB0byB3aXRoZHJhdyBOTFJJIHRoYXQgaXQgc2Vu dCBvbiB0aGUgcHJldmlvdXMgc2Vzc2lvbiBidXQgdGhhdCBpdCBoYXMgbm90IHNlbnQgb24gdGhl IHJlc3RhcnRlZCBzZXNzaW9uIChiZWNhdXNlIHRoZSBuZWdvdGlhdGVkIHNlc3Npb24gY2FwYWJp bGl0aWVzIGNoYW5nZWQpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KGEp IFdoeSBkb2VzIGl0IG5lZWQgdG8gZG8gdGhhdCDigJMgaXNu4oCZdCB0aGUgTkxSSSBpbXBsaWNp dGx5IHdpdGhkcmF3biB3aGVuIHRoZSBFT1IgbWFya2VyIGlzIHNlbnQ/PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxicj4NClRoZSB0aGVvcnkgaGVyZSBpcyB0aGF0 IHRoZSBsYWJlbCBzdGFjayBpbiB0aGUgc3RhbGUgcm91dGVzIGlzIGtub3duIHRvIGJlIGludmFs aWQsIHNvIHlvdSByZWFsbHkgZG9uJ3Qgd2FudCB5b3VyIHBlZXIgdG8gaG9sZCBvbiB0byB0aGVt IHVudGlsIEVPUiBpcyByZWNlaXZlZC48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5bSm9uXSBPSywgdGhhdOKAmXMgZmluZS48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48YnI+ DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+KGIpIFRoaXMgc2VlbXMgdG8gY29udHJhZGljdCBzZWN0aW9uIDIuNCB3aGljaCBzYXlzIOKA nE5vdGUgdGhhdCBsYWJlbC9wcmVmaXggYmluZGluZ3MgdGhhdCB3ZXJlIG5vdCBhZHZlcnRpc2Vk IG9uIHRoZSBnaXZlbiBzZXNzaW9uIGNhbm5vdCBiZSB3aXRoZHJhd24gYnkgdGhpcyBtZXRob2Qu 4oCdPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxicj4NCkkgYWRk ZWQgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIHNlY3Rpb24gMi40IHJpZ2h0IGFmdGVyIHRoZSBxdW90 ZWQgc2VudGVuY2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPiZuYnNwOyhI b3dldmVyLCBpZiB0aGUgYmluZGluZ3Mgd2VyZSBhZHZlcnRpc2VkIG9uIGEgcHJldmlvdXMgc2Vz c2lvbiB3aXRoIHRoZSBzYW1lIHBlZXIsIGFuZCB0aGUgY3VycmVudCBzZXNzaW9uIGlzIHRoZSBy ZXN1bHQgb2YgYSAmcXVvdDtncmFjZWZ1bCByZXN0YXJ0JnF1b3Q7DQogKFtSRkM0NzI0XSkgb2Yg dGhlIHByZXZpb3VzIHNlc3Npb24sIHRoZW4gdGhpcyB3aXRoZHJhd2FsIG1ldGhvZCBtYXkgYmUg dXNlZC4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjIpIEluIHNlY3Rpb24gMi4xIGl0IHNheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj7igJxBIEJHUCBzcGVha2VyIFNIT1VMRCBOT1Qgc2VuZCBhbiBVUERBVEUgdGhh dCBiaW5kcyBtb3JlIGxhYmVscyB0byBhIGdpdmVuIHByZWZpeCB0aGFuIGl0cyBwZWVyIGlzIGNh cGFibGUgb2YgcmVjZWl2aW5n4oCdIOKAkyB3aHkgaXNu4oCZdCB0aGF0IE1VU1QgTk9UPzxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj5T ZWN0aW9uIDIuMSBhbHNvIHJlcXVpcmVzIHRoZSByZWNlaXZpbmcgc3BlYWtlciB0byBhcHBseSAm cXVvdDt0cmVhdC1hcy13aXRoZHJhdyZxdW90OyB0byBzdWNoIHVwZGF0ZXMsIHdoaWNoIGRvZXMg aW1wbHkgdGhhdCB0aGUgc2VuZGluZyBzcGVha2VyIG11c3Qgbm90IHNlbmQgdGhlbS4mbmJzcDsg U28gSSd2ZSBjaGFuZ2VkICZxdW90O1NIT1VMRCBOT1QmcXVvdDsgdG8gJnF1b3Q7TVVTVCBOT1Qm cXVvdDsuJm5ic3A7IDxicj48YnI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltKb25dIFRo YW5rcy4mbmJzcDsgTm90ZSB0aGF0IHRoZSBzYW1lIGNoYW5nZSBhbHNvIGFwcGxpZXMgaW4gc2Vj dGlvbiAzLjIuMTxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyDigJw8L3NwYW4+U2ltaWxhcmx5 LCBhIGdpdmVuIHJvdXRlIFNIT1VMRCBOT1QgYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1HQiI+Jm5ic3A7Jm5ic3A7IHByb3BhZ2F0ZWQgdG8gYSBnaXZlbiBwZWVyIGlmIHRoZSBy b3V0ZSdzIE5MUkkgaGFzIG1vcmUgbGFiZWxzIHRoYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLUdCIj4mbmJzcDsmbmJzcDsgdGhlIHBlZXIgaGFzIGFubm91bmNlZDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1HQiI+4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj7igKZhbmQgYWxzbyBp biBzZWN0aW9uIDMuMi4yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PuKAnDwvc3Bhbj5BIEJHUCBzcGVha2VyIE1VU1QgTk9UIHNlbmQgbXVsdGlwbGU8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbGFiZWxzIHRvIGEgcGVlciB3aXRoIHdoaWNoIGl0 IGhhcyBub3QgZXhjaGFuZ2VkIHRoZSAmcXVvdDtNdWx0aXBsZTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBMYWJlbHMmcXVvdDsgQ2FwYWJpbGl0eSwgYW5kIFNIT1VMRCBOT1Qg c2VuZCBtb3JlIGxhYmVscyB0byBhIGdpdmVuIHBlZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgdGhhbiB0aGUgcGVlciBoYXMgYW5ub3VuY2VkPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJ08 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MykgSW4gc2VjdGlvbiAyLjQgaXQgc2F5czo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnFRvIGRvIHNvLCBpdCBtYXkgc2Vu ZCBhIEJHUCBVUERBVEUgbWVzc2FnZSB3aXRoIGFuIE1QX1VOUkVBQ0hfTkxSSSBhdHRyaWJ1dGUu 4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG91bGQgdGhhdCBiZSDi gJxpdCBNVVNUIHNlbmTigJ0/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t R0IiPjxicj4NCkkgdGhpbmsgdGhlIG5vbi1ub3JtYXRpdmUgKG5vbi1SRkMyMTE5KSBsYW5ndWFn ZSBpcyBmaW5lIGhlcmUuJm5ic3A7IDxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+W0pvbl0gSXQganVz dCBqYXJyZWQgd2l0aCBtZSBhIGxpdHRsZS4mbmJzcDsgSeKAmW0gbm90IGdvaW5nIHRvIGRpZyBp biBvbiB0aGlzIHBvaW50LCBidXQgbGV0IG1lIGV4cGxhaW4gd2hlcmUgSSB3YXMgY29taW5nIGZy b20uJm5ic3A7IFdoZW4geW91IHNheSDigJxpdCBtYXkNCiBzZW5k4oCdIHRoZSB3b3JkIOKAnG1h eeKAnSBtYWtlcyBpdCBzb3VuZCBsaWtlIGl0IGlzIG5vdCBvYmxpZ2VkIHRvIGRvIGl0IHRoaXMg d2F5LiZuYnNwOyBJIGRvbuKAmXQgdGhpbmsgdGhlcmUgaXMgYW55IG90aGVyIHdheSB0byB3aXRo ZHJhdyB0aGUgcm91dGUgKHNob3J0IG9mIGNsb3NpbmcgdGhlIHNlc3Npb24pIHNvIEkgdGhpbmsg dGhhdCB3aGF0IHlvdSBhcmUgZGVzY3JpYmluZyBpcyB0aGUgb2JsaWdhdG9yeSB3YXkgdG8gd2l0 aGRyYXcgdGhlIHJvdXRlLiZuYnNwOyBGb3INCiB0aGF0IHJlYXNvbiBJ4oCZZCBwcmVmZXIgZWl0 aGVyIOKAnGl0IHNlbmRz4oCdIG9yIOKAnGl0IE1VU1Qgc2VuZOKAnS48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij40KSBJbiBzZWN0aW9uIDU6IGFsdGhvdWdoIHNvbWUgaW1wbGVtZW50YXRpb25zIHRyZWF0IFNB RkkgMSBhbmQgU0FGSSA0IHJvdXRlcyBhcyBjb21wYXJhYmxlLCBJIGJlbGlldmUgdGhhdCB0aGV5 IHNob3VsZCBhbHdheXMgYmUgdHJlYXRlZCBhcyBpbmRlcGVuZGVudCwgaW4gdGhlIGZvbGxvd2lu ZyBzZW5zZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cHBvc2UgYSBz cGVha2VyIFMxIHNlbmRzIGEgU0FGSSAxIHJvdXRlIGFuZCB0aGVuIGEgU0FGSSA0IHJvdXRlIHRv IHRoZSBzYW1lIHByZWZpeCBQLiZuYnNwOyBUaGUgU0FGSSA0IHJvdXRlIE1VU1QgTk9UIGJlIHRy ZWF0ZWQgYnkgdGhlIHJlY2VpdmluZyBzcGVha2VyIGFzIGFuIGltcGxpY2l0IHdpdGhkcmF3IG9m IHRoZSBTQUZJIDEgcm91dGUuJm5ic3A7IElmIFMxIHN1YnNlcXVlbnRseSBzZW5kcyBhbiBleHBs aWNpdCB3aXRoZHJhdw0KIG9mIHRoZSBTQUZJIDQgcm91dGUsIHRoaXMgTVVTVCBOT1QgaW1wbGlj aXRseSB3aXRoZHJhdyB0aGUgU0FGSSAxIHJvdXRlLCBhbmQgdmljZSB2ZXJzYS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFtIEkgY29ycmVjdD8mbmJzcDsgSSBoYXZlIHNl ZW4gaW1wbGVtZW50YXRpb25zIHRoYXQgdmlvbGF0ZSB0aGlzIHNvIEkgdGhpbmsgaXQgaXMgd29y dGggc3BlbGxpbmcgb3V0IHNvbWV3aGVyZSBpbiB0aGlzIHNlY3Rpb24uPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxicj4NCkZyb20gU2VjdGlvbiAxOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5UaGlzIGRvY3VtZW50IGFsc28gYWRkcmVzc2Vz IHRoZSBpc3N1ZSBvZiB0aGUgaG93IFVQREFURXMgdGhhdCBiaW5kIGxhYmVscyB0byBhIGdpdmVu IHByZWZpeCBpbnRlcmFjdCB3aXRoIFVQREFURXMgdGhhdCBhZHZlcnRpc2UgcGF0aHMgdG8gdGhh dA0KIHByZWZpeCBidXQgZG8gbm90IGJpbmQgbGFiZWxzIHRvIGl0LiZuYnNwOyBIb3dldmVyLCBm b3IgYmFja3dhcmRzIGNvbXBhdGliaWxpdHksIGl0IGRlY2xhcmVzIG1vc3Qgb2YgdGhlc2UgaW50 ZXJhY3Rpb25zIHRvIGJlIG1hdHRlcnMgb2YgbG9jYWwgcG9saWN5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+RGlmZmVyZW50IGRlcGxveWVkIGltcGxl bWVudGF0aW9ucyBoYXZlIGRpZmZlcmVudCBiZWhhdmlvciwgYW5kIEkgdGhpbmsgaXQgaXMgYmV0 dGVyIHRvIGFkdmFuY2UgdGhlIGRvY3VtZW50IGFzIGlzIHJhdGhlciB0aGFuIGRlcmFpbCBpdCB3 aXRoDQogdGhlIGluZXZpdGFibGUgZm9vZCBmaWdodCB0aGF0IHdvdWxkIG9jY3VyIGlmIHdlIHdh bnRlZCB0byB0cnkgdG8gZ2V0IHRoZSBJRVRGIHRvIHNheSB3aGljaCBpbXBsZW1lbnRhdGlvbiBp cyBiZXR0ZXIgdGhhbiB3aGljaCBvdGhlciBpbXBsZW1lbnRhdGlvbi4mbmJzcDsgVGhlIGRlcGxv eWVkIGltcGxlbWVudGF0aW9ucyBoYXZlIGJlZW4gYXJvdW5kIGZvciBtYW55IHllYXJzLCBhbmQg cGVvcGxlIHNlZW0gdG8gaGF2ZSBhZGFwdGVkIHRvIHRoZSBkaWZmZXJlbmNlcy48YnI+DQo8YnI+ DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tR0IiPltKb25dIEkgYWdyZWUgdGhhdCB0aGlzIGRvY3VtZW50IGNhbuKAmXQgcmV0 cm9zcGVjdGl2ZWx5IGRlcHJlY2F0ZSBleGlzdGluZywgd2lkZWx5IGRlcGxveWVkIGJlaGF2aW91 cnMuJm5ic3A7IEluIHNlY3Rpb24gNSB5b3Ugc2F5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAnDwvc3Bhbj5PdGhlciBpbXBsZW1l bnRhdGlvbnMgbWF5IHRyZWF0IHRoZSBTQUZJLTEgYW5kIFNBRkktNCByb3V0ZXMgZm9yIGEgZ2l2 ZW4gcHJlZml4IGFzIGNvbXBhcmFibGU8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+ 4oCdIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5JbWFnaW5lIHRoYXQgdGhlIFNBRkkgMSBhbmQgU0FGSSA0IHJv dXRlcyB3ZXJlIHJlY2VpdmVkIGZyb20gdGhlIHNhbWUgcGVlciBvbiB0aGUgc2FtZSBzZXNzaW9u LiZuYnNwOyBXaGF0IGRvIHlvdSBtZWFuIGJ5IOKAnGNvbXBhcmFibGXigJ0gaW4gdGhpcyBjb250 ZXh0PyZuYnNwOyBJdCBoYXMgYmVlbiBpbnRlcnByZXRlZCBpbiBpbmNvbXBhdGlibGUgd2F5cyBi eSBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FaXRoZXI6IHRoZSByb3V0ZXMgYXJlIGluZGVw ZW5kZW50IGluIHRoZSBBZGotUklCLUluIGJ1dCBjb21wYXJhYmxlIGluIHRoZSBMT0MtUklCIChh IHNpbmdsZSBiZXN0IG9uZSBpcyBzZWxlY3RlZCwgdGhlIG90aGVyIGlzIHJldGFpbmVkIGluIG1l bW9yeSk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+T3I6IFRoZSByb3V0ZXMgYXJlIGNvbXBhcmFibGUgaW4gdGhlIEFkai1SSUItSW4gaS5l LiBvbmUgaW1wbGljaXRseSB3aXRoZHJhd3MgdGhlIG90aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Cb3Ro IG9mIHRoZXNlIGJlaGF2aW91cnMgYXJlIGltcGxlbWVudGVkIGFuZCBkZXBsb3llZC4mbmJzcDsg VGhlIGlzc3VlIGlzIHRoYXQgdGhleSBkbyBub3QgaW50ZXJvcGVyYXRlIGlmIFNBRkkgMSBhbmQg U0FGSSA0IGFyZSBlbmFibGVkIG9uIHRoZSBzYW1lIHNlc3Npb24uJm5ic3A7IEZvciBpbnN0YW5j ZSwgaWYgYW4gaW1wbGVtZW50YXRpb24gb2YgdGhlIGZpcnN0IHR5cGUgd2l0aGRyYXdzIGl0cyBT QUZJIDQgcm91dGUgdGhlbiBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc2Vjb25kIHR5cGUgaXMg bGVmdCB3aXRoIG5vIFNBRkkgMSByb3V0ZSB3aXRoIHdoaWNoIHRvIGZvcndhcmQgdHJhZmZpYy4m bmJzcDsgWW91IGRlc2NyaWJlIHRoaXMgYXMgYSBtYXR0ZXIgb2YgcG9saWN5LCB3aGljaCBJIGNh biBsaXZlIHdpdGgsIGJ1dCB3aXRob3V0IGZ1cnRoZXIgZGlzY3Vzc2lvbiBpdCBnaXZlcyBubyBj bHVlIHRvIHRoZSBsYWNrIG9mIGludGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdW5k ZXJzdGFuZCB0aGF0IGl0IGlzIHRvbyBsYXRlIHRvIHNheSB0aGF0IG9uZSBvZiB0aGVzZSBpcyB3 cm9uZyBhbmQgb25lIGlzIHJpZ2h0LCBidXQgdGhlIGxhY2sgb2YgaW50ZXJvcGVyYWJpbGl0eSBp cyBhbiBpbXBvcnRhbnQgZGVwbG95bWVudCBjb25zaWRlcmF0aW9uIGFuZCBJIGRvbuKAmXQgdGhp bmsgdGhpcyBkb2N1bWVudCBzaG91bGQgYmUgc2lsZW50IG9uIGl0LiZuYnNwOyBJTU8gdGhpcyBp cyBhbiBpbXBvcnRhbnQgZGV0YWlsIGZvciBpbXBsZW1lbnRlcnMsIHdobyBuZWVkIHRvIGJlIGF3 YXJlIHRoYXQgYm90aCBpbnRlcnByZXRhdGlvbnMgb2Yg4oCcY29tcGFyYWJsZeKAnSBleGlzdC4m bmJzcDsgTmV3IGltcGxlbWVudGF0aW9ucyBtYXkgd2lzaCB0byBoYXZlIGEg4oCcY29tcGF0aWJp bGl0eSBzZXR0aW5n4oCdIHRoYXQgZW11bGF0ZXMgb25lIG9yIHRoZSBvdGhlciBiZWhhdmlvdXIg b24gYSBwYXJ0aWN1bGFyIHNlc3Npb24sIHNvIHRoYXQgdGhleSBjYW4gaW50ZXJvcGVyYXRlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5NeSBzdWdnZXN0aW9uOiBjYW4gd2UgZXhwYW5kIHNlY3Rpb24gNSBzbGln aHRseSB0byBjbGFyaWZ5IHRoYXQgdGhlcmUgYXJlIHR3byB3YXlzIGluIHdoaWNoIGltcGxlbWVu dGF0aW9ucyBjYW4gY29uc2lkZXIgU0FGSSAxIGFuZCBTQUZJIDQgcm91dGVzIGNvbXBhcmFibGUg b24gYSBnaXZlbiBzZXNzaW9uLCBhcyBhYm92ZSwgYW5kIHRoYXQgdGhlIHJlc3VsdGluZyBpbnRl cm9wZXJhYmlsaXR5IGlzc3VlIGNhbiBiZSBhdm9pZGVkIGVpdGhlciBieSBlbXVsYXRpbmcgdGhl IGFwcHJvcHJpYXRlIGJlaGF2aW91ciBvbiB0aGF0IHNlc3Npb24gb3IgYnkgbm90IHJ1bm5pbmcg U0FGSSAxIGFuZCBTQUZJIDQgb24gdGhlIHNhbWUgc2Vzc2lvbj88bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj41KSBJbiBzZWN0aW9uIDcgaXQgc2F5czo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1HQiI+4oCcIElmIGEgQkdQIGltcGxlbWVudGF0aW9uLCBub3QgY29uZm9ybWFudCB3aXRoIHRo ZSBjdXJyZW50IGRvY3VtZW50LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+ZW5jb2RlcyBt dWx0aXBsZSBsYWJlbHMgaW4gdGhlIE5MUkkgYnV0IGhhcyBub3Qgc2VudCBhbmQgcmVjZWl2ZWQg dGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4mcXVvdDtNdWx0aXBsZSBMYWJlbHMmcXVv dDsgQ2FwYWJpbGl0eSwgYSBCR1AgaW1wbGVtZW50YXRpb24gdGhhdCBkb2VzIGNvbmZvcm08L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPndpdGggdGhlIGN1cnJlbnQgZG9jdW1lbnQgd2lsbCBs aWtlbHkgcmVzZXQgdGhlIEJHUCBzZXNzaW9uLuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V291bGRu4oCZdCB0aGF0IHByZXZlbnQgaW5jcmVtZW50YWwgZGVwbG95bWVudCBvZiB0 aGlzIFJGQyBpbnRvIGEgbmV0d29yayB0aGF0IGlzIGluaXRpYWxseSBjb21wb3NlZCBvZiBzdWNo IGltcGxlbWVudGF0aW9ucz8mbmJzcDsgQmVjYXVzZSBpdCBzZWVtcyB0byByZXF1aXJlIHRoYXQg Ym90aCBlbmRzIG9mIGVhY2ggQkdQIHNlc3Npb24gbXVzdCBiZSB1cGdyYWRlZCBzaW11bHRhbmVv dXNseSwgb3IgZWxzZSB0aGUgQkdQDQogc2Vzc2lvbnMgd2lsbCBhbGwgcmVzZXQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48YnI+DQpU aGlzIGlzc3VlIHdhcyBkaXNjdXNzZWQgYXQgZ3JlYXQgbGVuZ3RoIHdoZW4gdGhlIGRyYWZ0IHdh cyBmaXJzdCBzdWJtaXR0ZWQuJm5ic3A7IFRoZSB2YXN0IG1ham9yaXR5IG9mIGRlcGxveW1lbnRz IGRvIG5vdCBjaGVjayB0aGUgUyBiaXQuJm5ic3A7IFRoYXQgaXMsIHRoZSBkZSBmYWN0byBzdGFu ZGFyZCBpcyB0byBhc3N1bWUgdGhhdCBhIHJlY2VpdmVkIHVwZGF0ZSBoYXMgb25seSBvbmUgbGFi ZWwuICZuYnNwOyBJZiBhbnkgZXhpc3RpbmcgZGVwbG95bWVudCB3ZXJlDQogdHJhbnNtaXR0aW5n IHVwZGF0ZXMgd2l0aCBtdWx0aXBsZSBsYWJlbHMgZW5jb2RlZCBpbnRvIHRoZSBOTFJJLCBpdCB3 b3VsZCBhbHJlYWR5IGJlIGNhdXNpbmcgQkdQIHNlc3Npb24gcmVzZXRzLjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1HQiI+W0pvbl0gT0suPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1HQiI+PGJyPg0KPGJyPg0KKEV2ZW4gaWZmIHRoaXMgd2VyZSBhIHJlYWwg cHJvYmxlbSwgaXQgd291bGRuJ3QgcmVxdWlyZSBib3RoIGVuZHMgb2YgYSBzZXNzaW9uIHRvIGJl IHVwZ3JhZGVkIHNpbXVsdGFuZW91c2x5LiZuYnNwOyBJdCB3b3VsZCBqdXN0IHJlcXVpcmUgb25l IGVuZCB0byBoYXZlIGEga25vYiBhbGxvd2luZyBpdCB0byBhY2NlcHQgYm90aCBvbGQgYW5kIG5l dyBiZWhhdmlvciBmcm9tIGl0cyBwZWVyLCBhbmQgYSBrbm9iIHRlbGxpbmcgaXQgd2hldGhlciB0 byB1c2Ugb2xkDQogb3IgbmV3IGJlaGF2aW9yIHdoZW4gc2VuZGluZyB0byBpdHMgcGVlci4mbmJz cDsgQnV0IHNpbmNlIHRoZSBkZWZhY3RvIHN0YW5kYXJkIGRvZXNuJ3QgdXNlIG11bHRpcGxlIGxh YmVscywgSSBkb24ndCB0aGluayB3ZSBoYXZlIHRvIHdvcnJ5IG11Y2ggYWJvdXQgdGhpcy4pPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR0201MB19109734BAE5CFFB0E7DD70C84EA0BY2PR0201MB1910_-- --------------E246575E0BB9CB288EDF6331 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Received: from BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) by BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Mailbox Transport; Tue, 9 May 2017 15:03:40 +0000 Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.37.32] (66.129.241.10) by BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Tue, 9 May 2017 15:03:39 +0000 Subject: Re: Routing directorate review of draft-ietf-mpls-rfc3107-bis To: Jonathan Hardwick , "draft-ietf-mpls-rfc3107bis@ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" References: <9913c8e1-50fe-34c1-a8d5-2d5efefafc5e@juniper.net> CC: "rtg-dir@ietf.org" From: Eric C Rosen Message-ID: Date: Tue, 9 May 2017 11:03:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-MS-Exchange-Organization-Network-Message-Id: 10f2962a-95de-4bd8-72a6-08d496ec938e X-MS-Exchange-Organization-AuthSource: BL2PR05MB2180.namprd05.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 06 X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BN6PR11CA0025.namprd11.prod.outlook.com (10.173.25.11) To BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) Return-Path: erosen@juniper.net X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 10f2962a-95de-4bd8-72a6-08d496ec938e X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(48565401081)(201703131423075)(201703031133081);SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;3:ASXXrHhrXJJk3bsxgdz1AuxxuopnQUQhrrxkNUb7FsWYLXNcAnB7sf9jV/QeZvYoFE3eCO6pxppgSgmTXHdx6nUfidCgdPcZBzRB68WvrBVTnTX/8XxWuOSfsGbJoYO2/hnQc+HuPUvk6lCxVGdUVISJy+Q/bmi8VEnaBw3aENJgLbErak7F+gLvPljEXnvIoxo5QQItWRggScnEjkejT1qrD/2rnbU2y0fT6oAey1+pQ6tOHDwQLSgt4/tkaQnsw+lIqVUUmlkE4lyyvuHkQB4pkUWLD+nL2UsKRW04/Hwx9KHRG0lend7zxBQrHeYQlxWrqngKH/tsvjZ3eed+CY2surtQhJp8yoLMhpktaEA=;25:8lWwntXtigkxNbY1cKQrqfC1p2oa+vf2PE2yLE9XER8qP5zwYcqGbpw5j2KzcGPF0y3p4F+MTVtnom3jFap5UZCWEoXVykis62Im529ljBoLv0hchkr7mBBABNV+8tcYbmz9AEZRHDsDdnyu3vTMWfEYXzeYaX9DMIUPBEMrti5XovGB4S3nDCTXybMF+aLR2t1rAn5ED/vNZBIf7uEeQjF/3TNWGhxKstZHlx9wNaUP/oJWxWlWlj8c3UfHflzUQnn2yPj9bsjYMEY2/iwceVeKSjscX/Z8/ZmNai9b5JRt/D41RFWxxhKYJQ2LxpdDN79RDMHkSq3AHv0rRvrY+Xa+WIb/6sQgsZ9BSswD+s/ISYpil+gGhFUsN+N/xkuGRp54kKr1Az04I8QOaPQ5G0sRvSxwDeIMax1oWJRDD5OsbnWe+xPtwTwKpjGe3wvyMPaOG6bNtBwsv3DTnJNvtJJhEtPyuat6wYU5sJql29U= X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;31:D8garSg/cypuKoekApQU8Gm5sdehnxjT1cGAfYd197LxWPWQxf08MhXkZ/wzpmh5VEAI0ER8X8bfNWpSUjI0dEW4KvdIqcmTN/aK9ZxZNTKo56ACJOCJIsIlq1MlIGMuHq9mb4a/LvT7TSDgH/lYocOclMg+2rsQatu2Mg22FAI4FeVGc4EVH1KQp9320YuDjMPDXUJV6EE0re02lsucx3+xU8YQTU4G2YBkzvvBt3s0wlPrTxoECCnB+8XrPsxNsyogsaqeJEKNqKoGndFg4fZQAMEr+HytfLruQBrt+Ho=;20:Ua5bpRHIP23puhYoPi43jaKvy5gXl86/vtUFUpzVZgMKPqPA7EJWI6SoWjvzAglvS33bgGHIjApHevnh7nHefTRSr1NP+cSJON3QzREopyS/u6W59c2gnzLPOckFSG2BuqTQO3S6frdRQocEYcf0x9m59KAhdZe56md2U7eyE83vfQy6D1CnD/8TfSRKt1rjL+KWqTcMS250zdOn0r3CmVMFtmuTqwvacns6j79/LlNAO0nxOAfUlTMIt7cr2I7Inmgnixxs+Si3jon8eQSqTcrI2nhyGQ3CNKr3laxyNf27jZ6s/xpya4mw51O6tR/pNiW/8Ej3QnOd6e6BhsMPYgM/6skqOheKhIz8LXAayxVBCFVxnVZxPJwhx2RLDjnovnoiYsfxFN7IF7oDLpe4fh6tNr3YA9fFCwnk49GmrWc6yBhCvbu1EsJouGkBhkp1tAjyx7DpZNBrkgKRKbExZr+iNUOoHEtO1/82DXbd6OXEXvTDCKMx92SUuhpECn/2NRnH8GrR2B3gHLgJnG5EDC62ovqtA/WkkXCXBtedw0CySP/Nl0s11pD1UwCN5gbm4DjI7GfVtp5jdow0dqr5tPMq77M7NOnu8lKdT9SZ/L0= X-MS-Exchange-Organization-SCL: -1 X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(9101524173)(601004)(2401047)(8121501046)(10201501046)(3002001)(93006095)(93001095);SRVR:BL2PR05MB2180;BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;4:qSwp6IdJqlpmMF3HrFst8WU3zJzFJDp556yIadj3TF1E+rIBj7G8BXIqfHP5HSHlq/awQT1SOM1AMcSZIGMyngQzzsFksgFGuO1vyjLpvZlFLY7ulsyTXjsZoOdmi1VkmSNEPSDs/rcHXkuoU/fbZDZT3Bu9bnUJzCu6/LX7rZpLGJR2+cgJ2/htv7kTqIl8nYzYxMUEBMutFQ0/d1c+R06D9ludunc+sWECtJ+gbRwGDas1e5BCaycA4/2t2YwTBpNGaIQee7GRREO1DGGHBMc3BQlHRaMVG1ZcjAXwHIETNgYKWnXaPhTRjbx4ADCrOiUU9Rl36hBBlNDoh6dI3VBub/S6yTl8BVRAN3u84oVnF1y4tl+rMiUJT67ASJIhRvK7A4J1qL1mT1ncrfAdvltKr7+SsjntjXqnA7F+3dTXUZxaq9sA1ALcVgSLYMZX;23:lSZCC9ieFW+qAxuTqqVPck1V0O9bVRciH9zoDxYxpkoj5zc0s53zEdNvclrLACjXyeSsWuwK5aOFwTKzj3UgULarTdTBYT1nn53RfzjaLStPnOHpItAe3i4+wJV1xABd9yYghWTiRJURwJyWzcqQ6g== X-Forefront-Antispam-Report: SFV:SKI;SFS:;DIR:INB;SFP:;SCL:-1;SRVR:BL2PR05MB2180;H:[172.29.37.32];FPR:;SPF:None;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;6:z2PC5aKn3EZ2EwSdpyio/uXQDECZyoJk+t963fyKch/wZOgDt1eT7P6F2rqfIsACE9oLqTLrwzENXMcBxurcwSs3aW+Zgrp6yIQaZqrNxtI+KhP/35e4HBm3vtsKdWCTlSDzbRHzxumBo6H4ckfPI3Z+m68hr/oKL8+coqT4Ir3jQ4PRYBcZi9/jfyK5KglKiJ1fQzityorzMeOfss+ugbYxOHxAd6ElViI1CfdWOAa5yEhjh9YfTLQ7w8YnDV4aStOnjkH5f4xGn9kA8ksKsBEskvb/yJEltzLzupk9YDFl28gAnux333QXzJtJk8tInMHtEaz/OZJ+PE4KtQ1mFRLEU/nYm8UnNFYG2zWTd7jNBOgsIeQHJIMjFEHZ53MMK5J05zlqYz9oY2gf3/ixLxPoyHb/Bx5qhIE0JXUPkxQ=;5:LOugKvSyXcgpPaFeyCsw4StzS8uQ+xrrnzoYUX7KXr3+yw8Z90yEV6z0J+gbqjX59IqKkyCk6p6h5GFFFdKWuADyapXwr43jUSqELg8t4T6NXa7cAmgxJDYYMEHwdWADulo/8YtKwMY/Ml2QaJQ+dA==;24:Q9ZYhzP5iYCN9tJckR8sSTP55Kppg3kU1CL5rGJhn2e5hmPIILDEvYSI+Fg7UvKv0XS5AfPWGzqRKegjCFHnPbaLQpTZJXu/Gg7GEV47vSo= SpamDiagnosticOutput: 1:0 X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;7:WHvBNPAklK8cnzhonAXdq+aW0ZGLn5pG/NPhfvNvPfS1gvFCn6RKT4bAM/GKZUUjfTMKiBpfwu9rDBkR3cxv+uqnlaI+ey4IqaOSKCHfLbYS6uItBU8+lWRnwC6OhMRyQrBpIgZErR+kl0GN8w3bCS4t4fwlRwbmzFNm6Us673bF681dvtqBqLLaBiJdQHrEPgCl3lPfyE+byg1RclIBU0Ywa4D8JgO8dDxUtTcsNigN3I/3RvQx+0UReXtFDfbd2Vy8OUxykUoGg+txFX8tKGsqkM71874rxqziDYGjauHcKgIX2/ECPIg8+evy2PszqVJuNoSYULDkDdanlhBh6Q== X-MS-Exchange-Organization-Recipient-P2-Type: Bcc X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2017 15:03:39.1631 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2180 X-MS-Exchange-Organization-MessageDirectionality: Originating X-MS-Exchange-Transport-EndToEndLatency: 00:00:01.0959633 X-Microsoft-Exchange-Diagnostics: 1;BL2PR05MB2180;27:SftZ+9DznWITG9p4k8yHPUm6u5RQiQ9jGHbC4xlvHXOxZzJ17giyukTtNih/397K4l1avOTmiRb9W4zuH+c+LxZf/to54yHQesmxCeGhlVGyY7Zk+leEvMxduQfRSV/KOq8ez+p63Eiv70c2zUo4eA== MIME-Version: 1.0 Hi Jon, I've made some modifications to section 5 in response to your comments. While I don't want to get into a lot of details about the implementation differences, I do think it is fair to ask that section 5 point out more clearly that there can be interoperability problems, and that it might not be possible to achieve a desired set of local policies with some implementations or some combinations of implementation. See below for the proposed new contents of Section 5. Eric ---------------------- 5. Relationship Between SAFI-4 and SAFI-1 Routes It is possible that a BGP speaker will receive both a SAFI-1 route for prefix P and a SAFI-4 route for prefix P. Different implementations treat this situation in different ways. For example, some implementations may regard SAFI-1 routes and SAFI-4 routes as completely independent, and may treat them in a "ships in the night" fashion. In this case, bestpath selection for the two SAFIs is independent, and there will be a best SAFI-1 route to P as well as a best SAFI-4 route to P. Which packets get forwarded according to the routes of which SAFI is then a matter of local policy. Other implementations may treat the SAFI-1 and SAFI-4 routes for a given prefix as comparable, such that the best route to prefix P is either a SAFI-1 route or a SAFI-4 route, but not both. In such implementations, if load-balancing is done among a set of equal cost routes, some of the equal cost routes may be SAFI-1 routes and some may be SAFI-4 routes. Whether this is allowed is again a matter of local policy. Some implementations may allow a single BGP session to carry UPDATES of both SAFI-1 and SAFI-4; other implementations may disallow this. Some implementations that allow both SAFIs on the same session may treat the receipt of a SAFI-1 route for prefix P on a given session as an implicit withdrawal of a previous SAFI-4 route for prefix P on that session, and vice versa. Other implementations may have different behavior. A BGP speaker may receive a SAFI-4 route over a given BGP session, but may have other BGP sessions for which SAFI-4 is not enabled. In this case, the BGP speaker MAY convert the SAFI-4 route to a SAFI-1 route and then propagate the result over the session on which SAFI-4 is not enabled. Whether this is done is a matter of local policy. These differences in the behavior of different implementations may result in unexpected behavior or lack of interoperability. In some cases, it may be difficult or impossible to achieve the desired policies with certain implementations or combinations of implementations. --------------E246575E0BB9CB288EDF6331-- From nobody Tue May 9 10:16:24 2017 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 489FC12940E; Tue, 9 May 2017 10:16:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149435018226.22615.11206775054557423490@ietfa.amsl.com> Date: Tue, 09 May 2017 10:16:22 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 17:16:22 -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 : Notification Message support for BGP Graceful Restart Authors : Keyur Patel Rex Fernando John Scudder Jeff Haas Filename : draft-ietf-idr-bgp-gr-notification-12.txt Pages : 7 Date : 2017-05-09 Abstract: The BGP Graceful Restart mechanism defined in RFC 4724 limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document updates RFC 4724 by defining an extension that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message or the Hold Time expires. This document also defines a new BGP NOTIFICATION Cease Error subcode whose effect is to request a full session restart instead of a Graceful Restart. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-12 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-gr-notification-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-gr-notification-12 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 May 9 10:19:05 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D127129501 for ; Tue, 9 May 2017 10:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlnQWvrzfFgF for ; Tue, 9 May 2017 10:19:01 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0102.outbound.protection.outlook.com [104.47.38.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A1F129503 for ; Tue, 9 May 2017 10:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4clge9yyzuAQXfucskbeGJzOzoIui5u33tFkKR2xQm4=; b=KDwmf/5GYApC9gyAPnoM0WmGFtf4hHC0Se/gWD3dG7PNNSETevREWxrdeTEAqWnTfotlYOzTp2obPkh2ivuJUgszHbnjxK/wUpA1jmlnupuWo5g2DvZf80XbTG3tPEyGIbM5lRTTJrluyIJlbDnWrYrOvGj7CYYayayQmKrwqgE= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.36.23] (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_128_CBC_SHA256_P256) id 15.1.1084.7; Tue, 9 May 2017 17:18:59 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 May 2017 13:18:55 -0400 References: <149435018247.22615.12244098952643117082.idtracker@ietfa.amsl.com> To: Message-ID: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BN6PR13CA0030.namprd13.prod.outlook.com (10.171.172.16) To CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e2c0fffa-6992-43fa-46c3-08d496ff7b7c X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR05MB2508; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 3:Pai+CRzUSDVCUwXfZtZ5YGI5o18shD2DUz3E9t1fz/vZ+F8Xli7rZVSywdTciDRnyiNooEK4Wf3Gnm2aool4tGepLTHZp4ibpusniA5GGyIG0gUdFt5qVYPX376GZU/mx7BsECwqk9Pq3fTV3GOGVVNvclLhDA9nvYy9ZrvxU0F49LkQ8sA+9juLVAjSZYaPNlwyMQqRE8UbIaSWSkUfFa0C7EyukCgIdTjn3OUqYiURevuoPMOV6dJ+GiGy2u8R7OFERJZI+4OhtNVo7V8W3nbuNQXHggVBh6v3c+m248O4FZnkdAfLdP77vCGVAv+VvsskLT7DInnRMjOrLvn6aY2ty/al5j+7C2Zk6fsUVAQ=; 25:30p6O426V9ALJ6hpIo8X9Oi8p7lJ5LBGzGftHCqg25Q9/BFJ6Y9cuVUxELWrVF4FBOsSiSPXq/XU8wIO+R1N+ptACrRnjK3jUVcXtmh9ZvidYLojeXn3RS/HS7/8D1XGZsh9rpfRHOnOjb05yATyYTLsgtb1NWALKTEEsL45GI83ZBLb0WvJlf1neQIgt5bI3pHuQNE5epM3FQJWIC+szwQdHtVNVP0krOuR+ovU0f6eq3qREdNYw7j09WpbBp6XYZ7/rGWRo5lE6LG1/BrxoyjvZPBpNHKyyE7EcttY3AedAMaAtQO6p8ZRMMxlGIhqljGIxJWIG+eYUssm9IzcovrlWW/0qJ6q7GF+rDwNSVGOjGMbkGv+uFLoKppuOdZia4yO36LuwyCbWXbR92R3T/VX4yzOv1Rvjs7QoWYx1p4FaeZ4FTtvOobiBIOLsVpyRgh7eAj+nePHgf4zH3woGgQuiPKGsR711cYbXP0B9Ok= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 31:c+Ic2xPnvn2vMCQ+gJKjcpQvUC37LoSmn6RPRIHt7AbcV+T9PVskFgx6LzqmwQZh0xuGppWESni0Pp05Od0SEyPkExlbmr0Lga2Xf7c0Lx8jE+VAZShMo+YQzR/YSw7dV2CkaTweJRJSnHS0L7D6UHiB3juLczDEPKD8//MYFG935z9qBiYxrSqUev1fESkDc4Hzg/PD7wdWKoW1QDk5UydbvyAI1GARNV32+KJrDFvz8MnZP2hwCK5v1DVnhd7H/uYDyF441MfC46VW52riZqgj/qw36GDvfhfb1kGCUhw=; 20:ucAds2O6R4u0n4UVYFP8JlSrFImbL8qnYrOXbOfKaigw5e1mAKecl7bCp9cs0u/U48lOqEIw5PQh19cELyIqVBdQaksQAy1wdzvJvdQFUct4XgObRavTm/0bGOMn46yAPs7RpRnZIbe7K2zsYqUd3ONtrhE5l3NeVjZRJujWCIkGFV/UYnGVvcI91ce5vTxc4KBWc8lGVrSFfyw55Bmm+IlaEeYTkfMUP1pUqcbX6mn0tPkfPvQ+B7oP8YCuXn855E9uEAdnEO7KYwY9AVLKaLLmgF+TZfAHnnxIDrKaXwZ1d7+KhEAYyUzSsZ0zl0B+jz2XhdECITsr8W3yDU209VGYyVhp0fbDMzX1gy2E/CS8i9oCx9Bto9FPC0PAHQ6yw1lvbeCR2pVY2YzXEQrYeY5gFLwE55Gbnj1XGLu/IQ1lm486kXwY8Dc5e/HIT8LUJDceqDK0CV4A6YMKDUdBhudphQCw3sN0ZuV2Q3+ez8Y8TQmvKY5IBhBF69nn4rLJYybi2O6kqkVb6bKMMAK62ju6QhyZkY5Yd9BLsSwp3EpVo3S0OGEWjvNnEw+bZpxDyeJrA5p8LozDIGfcrI/nsbmCtqqQmvZgvvylsxXQrMw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(138986009662008)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:CY1PR05MB2508; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2508; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 4:Mq2JN3V7Ec10XhIwbla7clXQRn9AY+7MtxkU2WjaPIp7hIXJXj4e4g2WAlzf9FjqH3EKZqx6saOf0tqzwqBT9NsSPaXbOmBBC5OdkZl3UiUVakXfwHau0Q6QdvXk2Zt/H8cDTmQ//XJ9QDmtHEPv4ZvYyGHJu2csDq4m5sSlyttay9cD8uxNJatZ3Fvt0DijO62w0VLiDDlkF/B2HRfa7U7mKDphgS787AsVmpu3H9dDYJkCgc+6znMNOykP0Kz8ir82d5f855dYDezVyw2Pv0HuC6pfOgU688cPTEA9fCcIXNg0ob/FWIecbYHtGDgoPayayrG3qGTAOarUbnzG0D9aMaWKcCJmPoMOnzjXZCmu3YWDPodrgUkoMZqV45N0yyGu76uYQIL2kVt930V9nKNMP/xzcSH2hPiH6t2lAuvXKZNWRvmWSm16fPbtSyPBRPekmtnEJREbqT+3oiwhT+fDVTfGVDWe5XVkxSoT01RFflNm8tESAt/8Ery1G1vgq4bnOJ0RIkDN2RGkroSZiOQ0XVe82HMuj1lYqPujByUbLdW+DLP/ERoorRluyaNpfFsENHyZbuy7mhF9kOTe1H6mhFT8CEaMHhPdxf/R9pM2UZtPL/XsJXdNPdjhJFYuwWrE2bAHu9gL0DdfdjiTKQyFHF4XE3YWaWCd21SoqTbBp36x5aTMrVOL7ebue5lD3wTZcexXq/FTNeo2U/z2bd8JVyZmm/fAcOMSmsXYQp9G/vdbSK8oDFbm7XmkdPgj9oswurirJpe78D5mqRWRks2mj/K0mdyGNcVZkaI80v+De9C75QXoeEKzvkYlRIzsW3r6vZkH1BzJ0KCpPsCqegdvD9RQ4YnoFMMjuMmooVmy5M5PcD/oPEx6GffMC6X7U28JFvTHnHb1GbiQOp7im3ppgFzD6gS3Q2BEX2gWZmA= X-Forefront-PRVS: 0302D4F392 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39410400002)(39400400002)(39850400002)(39860400002)(39450400003)(39840400002)(377424004)(53754006)(377454003)(82746002)(66066001)(57306001)(230783001)(5660300001)(50226002)(38730400002)(2906002)(8676002)(8746002)(86362001)(6306002)(23726003)(189998001)(2473003)(46406003)(53936002)(47776003)(81166006)(50466002)(3846002)(6116002)(478600001)(97756001)(77096006)(83716003)(33656002)(90366009)(6486002)(110136004)(25786009)(2351001)(15650500001)(7736002)(305945005)(6666003)(229853002)(36756003)(50986999)(76176999)(6916009)(42186005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2508; H:[172.29.36.23]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2508; 23:imXo48xvpjbReG/sMJLR1HNlj5VgY8Kgm1K3Jev34?= =?us-ascii?Q?8vZJF0Vn4R2wSse+pqmW5YFORWO3B8THY3PSGQb7V4/nudry9WQKn+4p/Qqx?= =?us-ascii?Q?/lBPH51vg2TQ3ZtPYKM7k7hkTRJ9dDCFZdrxBcbomhjmcdlZ/i/VDKNLL4ac?= =?us-ascii?Q?ztOxCp+j8/UF2DDH4ijrrP9toPsOgfAw8q5h7W1juuHsm78pLbzHyXYb0pGP?= =?us-ascii?Q?YqfCDnkz8jlEaojQek72VZvEGLF+GlaOrxOqBvjcJRPK8ctU0Lgpeh5l6w/e?= =?us-ascii?Q?ek+NjHlabHn0XTEfytTDbWSdiKHIjvOUAhUqwlPdhLUF2hzxoQ0EdW8R1Wgy?= =?us-ascii?Q?yrmnuSqdx5jkVYbKrmsqmKj8hdnWKEl4mJ79Mrz7CT1aNdG+CXyZNU5AjSnH?= =?us-ascii?Q?APHnjFybH/7VaVQK/20lLnIP3FzV8mkeh7nQ5jEbIrQW4ap5c6DP3Jiyrjn8?= =?us-ascii?Q?EvgIJtMT5giAxjtv7aJqsoM5k1IklkOvX+pncaDsX2Eo4FY2Iek9ia+/UG7Z?= =?us-ascii?Q?EIGf0nUv4fkWpMj7+u7vUCkUN2Fw+huOEZ8pPP2tzL5lfyBEFwDVKBl/WLSL?= =?us-ascii?Q?+pU9VD6JTA9YMF8vB7RhQyXSCpkRF7UAx/1ZPnpS+kDa77YVg8qVzyqW+5tR?= =?us-ascii?Q?B5RUwtTdtStl6JcctOJq7Ay5Ouv2uafAZ8pjAzik64iQBgAme2rmszID0nbd?= =?us-ascii?Q?NigVJD9DBdWjpigiRTxC6/vJdAuqFUxwaW5U/NcM1XAanlrBHP2C+r1cwD5H?= =?us-ascii?Q?4r8aqBP18R8U0jbo+MM8r139BXk4vMwgC3EwSVwGFy5kjNXZW2G68kt761DR?= =?us-ascii?Q?ujW1ngC6nbP8tEUrkX6pwqVw8VP+WucxQZsJWFy3MgCMWbSHlJJVn767/Gfz?= =?us-ascii?Q?qlxfIXbVoMxzWnovZjJquotcP6x5sviuvUKOq7Bao6oqR6rFhTd+WEdaJl3W?= =?us-ascii?Q?LvGsSWHJRocXOMjk/qhQVHR+RJRr9yXV+uwK1yYYzFyLqYgYkzoBtHYJAt2U?= =?us-ascii?Q?/TLNHi1JkimOy51Y0BbR2gSzJdaefUTGhubVBg6lNRcVAFr9Z0azM4mrjLpa?= =?us-ascii?Q?VxrYoMsQl4gQPXWTxrZ9r2vtdte3G3OiG3ObdpMgZoJz43P6twtq4JY6sh9e?= =?us-ascii?Q?9i0EoSPPSspeSisqntaiot3wBaKKzvRJPFef1WwxlBKQ6tEjSrSBrfDlBgz9?= =?us-ascii?Q?e4T4SkmOg2FoHylI0i4/ZZiEoh1UMlXuMDpJ9iO4TjHFPB+Ra7iaHeqf7Jp/?= =?us-ascii?Q?xutbDgphBhWtQiCRFzBebmtGFA99W+URdgNdayhqTSMi5AC0PNLWAzQuD0ww?= =?us-ascii?Q?K4T3tn4DwLvMUQrzu+LVaC2p/3nqV15wsE6HPLsoj2GO/SpKKE/t178+lIjt?= =?us-ascii?Q?Kb/HQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 6:bkSUg/L0cFZGbyMZLt8z0/24R+Jv4GgW9IXLMyMPe+KcHSTSVFq/wUh9YTazZ5QQKtt2AdohxL+EsLVOaN10tIDTsn8g+mmgOcaiA3HutruBZx5cZZiDK4otEwH50SgKVfGCJ76ythnDax7JKEOSDLIqwI9krIcS7i6cfqYuwtqwqucueM+UhCvnN/BKuHfVxpA03Kmzo4kl5/8lgjPZX1TNH3VvO3Ymvl/2MBYSVehqj3vrGUbKnvb9sbL/2l0WfV1kN4/Do5lKpE4TjqC8yfJIyTqaJGp1pjR1ekgrPHGTp8TzMrUBFht/+pWJ+51XLY9Kjemci33EZE1z2RZ+TDEUVSzPVtI+UMCjaEFJVTjgssxeVMwzItyblEGvrhaYeYE6E0sCkHJTxp/cQgcIUcLiO5fsV9T1ZBXGi9gnNHfbuiOo1D9Iy0+uNArJm2qlxLGw2p8NMeyflvHYLRxQE7ryKdcgvG4LmTP8+Zm8eHFg4tRucgSbJD/0zcclgx8qtXBndSbj+W77X8pDDLZESk3rlgld344fRVnHJzyZ6/M=; 5:7UOItLb/70jg6q+Eur30Q7yTM7jakF3AvIuxmMsQ78TdJs56/zIlMOP9Jq3lH0JaPrrPEsT+B7KVskwyS2mf29/UNhusATBSjWUDu72Zhp59HDSmHcobiLc2NbBNjsejUty8fFlQ549iQ37FKynbXg==; 24:MG00hXvv28JrOSBHg7W1RV4co3hlGbTaeFuodhW6nzNsfSusx3Rr2Gkg+XUrdsq6XvWjURbl4w74L1SqVG0wq/yiW1OO+QYfDqD7HrelhBg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 7:yQyZB7T/+mgZIS+HetK/v14JM9MWCcLSAUc+NfDGaSiCGmSAKAJVIEJzM8b89hpto0MW+UxPafs6VBYn7OYDaVR9zsbj8Bi6/dEK3BwjOFS46czsytkJvT0EKDPsB17Eloo5gIaoGmooj+/joLg1HM5KFaSIs64OKyTCY26VceCwxU7rdG2t4iZNF0GxBFBgfYpRXt8DyAiHthGTVpwCG7aE534QcRzmn/dlGBzCastpE6WCtaDME0vHh/CTllXC9D2B0Hs8AjmUM448p83dbLkWfKVck4ZOoH9Ha5z9WQdu/MCfXtwx4BQrtLY1g4yVGFrf/TIIvsBtv/lmGFkI7g== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2017 17:18:59.5348 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2508 Archived-At: Subject: [Idr] Fwd: New Version Notification for draft-ietf-idr-bgp-gr-notification-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 17:19:04 -0000 Hi All, As part of reviewing the Document Shepherd's report I realized the draft = should be noted as updating RFC 4724. (This is required since we = allocate a bit that's reserved by 4724.) This version corrects that mistake. --John > Begin forwarded message: >=20 > From: > Subject: New Version Notification for = draft-ietf-idr-bgp-gr-notification-12.txt > Date: May 9, 2017 at 1:16:22 PM EDT > To: Jeffrey Haas , , Keyur = Patel , Rex Fernando , Jeff Haas = , John Scudder >=20 >=20 > A new version of I-D, draft-ietf-idr-bgp-gr-notification-12.txt > has been successfully submitted by John Scudder and posted to the > IETF repository. >=20 > Name: draft-ietf-idr-bgp-gr-notification > Revision: 12 > Title: Notification Message support for BGP Graceful = Restart > Document date: 2017-05-09 > Group: idr > Pages: 7 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-gr-notification-12= .txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-12 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-gr-notification-1= 2 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-gr-notification-12 >=20 > Abstract: > The BGP Graceful Restart mechanism defined in RFC 4724 limits the > usage of BGP Graceful Restart to BGP protocol messages other than a > BGP NOTIFICATION message. This document updates RFC 4724 by = defining > an extension that permits the Graceful Restart procedures to be > performed when the BGP speaker receives a BGP NOTIFICATION Message = or > the Hold Time expires. This document also defines a new BGP > NOTIFICATION Cease Error subcode whose effect is to request a full > session restart instead of a Graceful Restart. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 From nobody Thu May 11 09:50:31 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CA31289C3; Thu, 11 May 2017 09:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWqHEw-hOz_V; Thu, 11 May 2017 09:50:28 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0130.outbound.protection.outlook.com [104.47.41.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 F2106127201; Thu, 11 May 2017 09:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ryc7GD4VNhQMA986xapb1G5NC7rMgimtB1IZfTk6kp4=; b=eRep0z60nSyUJp0Uls1AfZGB/nET4Qkh0QMTT8PZForMZ3hzT9u7dPQCa960QOA790uM/VFAt+lz2kmAsdSQyL84wW3Eps6113ZfYPipZEFV8FpN/zlP3pk6MR+vlpuO/WQZ0iFNAsf71S5AlrFSSES8mSsyqOgt2YXO8592Opg= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.36.231] (66.129.241.13) by BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Thu, 11 May 2017 16:45:22 +0000 To: Loa Andersson , "mpls@ietf.org" , , BESS References: <93a6a754-0a2e-2053-542c-a4ce8bf9213b@pi.nu> <61e452c6-80eb-ff94-878d-3152270fc032@pi.nu> CC: "mpls-chairs@ietf.org" , , , "" , From: Eric C Rosen Message-ID: <589f3a5e-b663-cc36-bff4-4f2d9b6c207e@juniper.net> Date: Thu, 11 May 2017 12:45:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <61e452c6-80eb-ff94-878d-3152270fc032@pi.nu> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR05CA0012.namprd05.prod.outlook.com (10.174.92.153) To BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 12d82135-7261-408d-384e-08d4988d1e67 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 3:TcpluUUk1BYSY1RxIwqEKqOq6H4/NZCosGvl1mnSDseyhGD4dBbmX3t6qsI6yixoB36GJNkW1Vg0lHFp5ybv44v9svnbLOBjHC/STByIRwik+tRL3+QRgCn/34vY5e6KftTN70tbCx2cA1BgUPugoTWEUevb0BBsrRImPZzXjjSeqI+CjkoosiKQMat/dbpZv6CRp26JNjZJgUcq4TSBUnPiXHB0Kqc72LKGs3bIDmvJOP6zRQwQ2nKy/jgIo7DVftWtepwdar3WpZ15oGb9ImZMqVrdeuoA56E1kZEMnwJnjLc/E3A3mwk50VG4taQ9WPNWGi6dmYfvc0hI9JTF3VKpBrYsukGPyW7zjkmgf94=; 25:YK8TJ/RSOKuw09C6vEzAo6Yo7kWRa2JkYSdrKIGAs4iuXkSjppCmAA0+7MVWibdAm35S3vAfQVb2ZUNKRlo2gCfotgxvTyv0sYJD0M5Donu8H9Ul7RHb4qlo50lKsxkIvMteCn6u64BniDQRJMfBYKs8x/DbagNMDOYAMCZdnD9ffT0YWB8LXYRpM6YLJ1NqLGB07ThKIM3wE0SZBlkM7MsauIrNTvbt3tjmLRums6/S5WKgodwHjKr+yy0Ta4gv56cfg1qCtck19b0psdtxwuXqcJNOW37fHGdbykhhpY9PUG4zuals0NP2WxH/ALOOl7iv1OcgQSKc4XwBscfpRLk29OJpfPdC7u67XDYq63uQfdXyQsxIT7DrxJUzlMdX2L4tdaAMio3p+cwv/80XuWEHX88qjEhGA2h6GQPjmo0VXQRsepUrHlxri4hmb6kn7FuL3HG76Mr3qJUFmSdkvVcD+R72oZ4QTvWBhxgeu64= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 31:XgY5KcJcVFfl1qE3rJPexwqLfiGXvZs6Rv9rYlhFBmTSJQHoDY3dNw1IrZnJHnBrEFhr+DZRhIVOqblUQoLMLliRC9/QHqq2DdRk+pmkvBuQsXz3XUA1PtryUuAtGC9+WaRJb36ooMorQD//nxyrhH7APnMjxM/T+haOcBlx6fvCqLFmPqAQL0Max9Zwk+FaYjPQ8NS96BNZVLNzhiWqSSNqzHAtc+P+eCPGg0tWk5g=; 20:K30crcLAzUDhpO+IRxO7cHsjRQ3TbDDNnRb070baGVL9Zc+vdIUC8nECo2yUgeQTtkzEcPvezmQdvlY6Z7oG+pgdLkzZTuVGKCMQCKfxwH5Bcf0A0QFFRLt1BFRawpQ/zG4J/ZUqJ++YQAOy18sR3IFkp4mWjMA5HLxQ9vQIewoSDFw+4T4NjSQ3o1UaN87QQuADP7qYsIVX/vMXn7FtxibIr9514NrV69KzBS6xvoXkjNq73onb2A4NseyaVvbZ3gY5iFJW845BjJFYsRyKeReNfdj58TwqTviOXEBrKeM450wP3IPhek9jAYU16cg/tE/oLCRor9hEtElr+KMJcoOu9jwR2wATp108wiDyyXQ4fWxGCFQQLKfl7P+3enHcAuX4RflOtzyS+33t1qlM2lkG/Qglwt/IHQclHEneym+GBYrh4mDMVPaTXf/DyUuSShryMz7IURMb/iIVpOptjJttHihFQhTy0q9pyi6WnlD8uFGWiNhlhZ+sc6TNp35SyIcLz5wtvRoOOj1PoJHXJ64hw9fa+nE0GnAg8zDVVR/h5IlXS4KAedXBKzcA3sTcztR6Z3JLE+3Ptvnw48SU5sVrlcGzfQxrlo2ElrKyu3g= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148); SRVR:BL2PR05MB2180; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 4:SMku9yxcbji8wUEAxWej1ellYzDggA6dSzYcZ3YOPno8C1LW7b1qAp87Ovpw+oCSm2BPylwcT0V/i4rFAlYWIBR2kHUuneqTL50UO6PeIbVwrEt8e0C0/DNQ559mmi+iXGWw2QKIoN4CSQaf/4p/+IX6/fzRrJEGGZGT+/aAugc9JKmz+MSD7vv/zLveKCncfT5jpv3CR+ENmF4FIayxeUoKKCKdFypsvkHszoaHe4U/dLGSRJeo0GvZVfwLzmbxAYMolLISdr2BvYI90ezmqda2Joej0bzezuS075ep4xciNkGhRgKFmdVJJicBkNseolahssVIyMrVlCw/Gm7wOoQNvFvdgvlyw/7MTQwdkEqR3THnGfPskUddZ35AO0nzj6NQV/C3XdV6AX0wMPV0BtOVElIuPydgCXUOtRYcXkesb4jmqbbE0ibV8HsQugiX1buLV1+BIPzogm5GUdL2S0xbTpC9DzB23zh89Vd7Ao9BPrC42TPRVGXp9Bl+0zkfy8gJZcvJgrAOaB1z597EK/b7S/gUpRmt719PSGr0cat+oJ/2lfEmHbFR+xfSp6nFB4e3TQ3TKvTiN+/dWDhf95kLz5NPepMsn/+LuFBlB5SzC8CXUnnFNmTTJL3S5/9gUEWa0kVRZ1SMZT15CabnPQyg6RWl6COFJauVH4d7+K85dqcEdcSZsGYhHNkM3zhXD1s3RDTvOCre+VbelhzvVzKBvYnumubPlC+wPl+Xw7JFgmXEKy1RBHW6Tf71aLT4hg6+OsUWphzHPhytUu0qvfUiUvpevdzkzViZuMjHgac= X-Forefront-PRVS: 0304E36CA3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39860400002)(39840400002)(39450400003)(39410400002)(39400400002)(39850400002)(478600001)(4001350100001)(189998001)(3260700006)(6246003)(25786009)(38730400002)(81166006)(8676002)(229853002)(5660300001)(83506001)(33646002)(36756003)(230783001)(65826007)(65806001)(230700001)(66066001)(6116002)(47776003)(3846002)(305945005)(65956001)(7736002)(50466002)(31686004)(54906002)(42186005)(2201001)(54356999)(50986999)(76176999)(90366009)(53936002)(2950100002)(6666003)(64126003)(2906002)(23676002)(77096006)(6486002)(2501003)(86362001)(4326008)(31696002)(558084003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2180; H:[172.29.36.231]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDJQUjA1TUIyMTgwOzIzOlF2L2p3WFlKcjlEeXZmRmdnTVJJeUpKakN1?= =?utf-8?B?dmUrWG9qWUxuZjloVTVSd1BKYmtvVU5RY2RROWdIZ1NxYzJGZklWck1vTm8x?= =?utf-8?B?S3l6bUdpbERPSVZlOFRiVW8wOGpaZlo4L3VoU1pienJpZ2h5eDF3TFpRRTJG?= =?utf-8?B?eGNPZmx4QW52NUpuUmVsaEJFbXJQdmlQSTFseGVUdW9WSll2azZTN2EwY2dv?= =?utf-8?B?T2R2NHArbjBxbmxlSktlWU5NNHZxdndycEdpYm1xalJVOFVtczAveVF6aUQz?= =?utf-8?B?bHEyVHV1WXRlYUE3aVRrNE4rWmR5RnNDVDlUcGZnWFpxQUpjU3hWRlBzb0NR?= =?utf-8?B?dml3ZTRCRXFVNklZbWZ1RnVmL05lV2ZWNkJiTDlaUXFWSysydjVtdllmbFZB?= =?utf-8?B?UWJWYmJPOFNOZ2lZR3ZOLzdMaythRkQzZnloYTNjYkVrNEJIM1BIcStMVkgr?= =?utf-8?B?TmlIa0NjdkVhdnphaCtRTmdZOW5pVG55bDBkb1BFaWR4KzZaNy95VCt2YU13?= =?utf-8?B?a0JkeS9sKzZrUHpqcXA3eGdKaTdIZWJwZzVETDNBS3YybmZYUzFmWnV2NmVv?= =?utf-8?B?T01yUWNiQitvY2hHb01JaTdtRDNlT2I1TGN3RUErSUFPUSt3VS9Ub08wMG83?= =?utf-8?B?ek9SVXB4MGJGb3pSaG5WYy9aL0wvSzhneEkyZW9uRkJacnA1L0FnWExxTEZz?= =?utf-8?B?Y2NkZDkzTW05SlVkVjdlZWdZeUpDcDhCeGRQTFFYWHVvdzRqQ0JNMEdoa1B3?= =?utf-8?B?UGZubkw2c2FjVm5saEJpRUNsWlpIVk9reDBkSHdNbnJYNGd3QnpaS3JVTEVm?= =?utf-8?B?eXdoU3VkYVZhS1VWN0p1S3VkREFVdStwcFNQSTBkekNQVGNJWDhQcTZqL0RY?= =?utf-8?B?S3R1M1RsbVE5aFRsNzZIZU15SFlwQmtvNGtkVndvR2JZQnVNY3YwY2lac1dW?= =?utf-8?B?Y3ZQS0xlTWJUaURqOS9OZ0x0RUYyWlpHN3ovK1JDelkrakhhVVc4Vmg5Nkd3?= =?utf-8?B?Um9HZVE2RHMxTit1ZHhqZlNyeFBqTXFnWTBKVk1ZcUNnOGVwUzQ5S1RsdDBu?= =?utf-8?B?NEZya3NGZDdwZ3lya2xoWWdZR0lKTXQ1S3RxTkZuTVpWS3hVUUhYcm9CUmQ5?= =?utf-8?B?UVFlK2RhN3BiZVg5b3NuQ1NvZjZyYTc5QkoxOXRVak9wMElqQUtTcVFKUXF3?= =?utf-8?B?MkRzNXJmUGJ2Q3kzSW80M0NLUHdYWU14ZDJGMlorQjlJSlVzNGYxWTl4cCtv?= =?utf-8?B?bDBncC9YUXAxNlB0eXhGWkdGcHUxZGZqanJVK2J5VlM1Q2FzeGpRMURRWjFE?= =?utf-8?B?TFFHRGdhbytrTUVSWk0rSzM3TFJtdUVXbmc3a0dEQjV0YVR3VUI3dlV1OEJz?= =?utf-8?B?cWdkTXJXNVBtN3VSeVhMQnZwVkVmVFQ3M1FWeWdqcEVUZXhMVTY1YkdDbTRP?= =?utf-8?B?WW5RbUNXOEV4Mytla0ZwSkhnMG5TS3lFSVArL0dlb3h4dWtOaVVDY24rc3Mw?= =?utf-8?B?bERzZENEOXhUZnUvMVA2bDNzV1VNMUdUYWlVdnZoTG5yLzhIWVZycVFUT25u?= =?utf-8?B?M3VSblp5Y084UGlwd3dMZWpXL2RReTJkSUFnZjZyZ2ozaGtaZ3lTSjE3T21m?= =?utf-8?B?Ymt3aG13ZmFxRmhJY0w4aGVMcUU4TVBOMDhIYjA2ZVVodnI5NGZRWVdPTDZ6?= =?utf-8?B?MEhTM1YrUldPMnQ5Y1FabUI2M2FDbk0ySEhhZXNpdllJUEVIeUE2S3daSXh2?= =?utf-8?B?OWNVTGo1Z3dQMUcrTFJ6NmhENjhOQjB3MVBMZ3dTWkJDSC8zVWVUQ2xVbEtP?= =?utf-8?B?VzY1RDNoZDNpMFhqWWJGcjRiR05ZRjRKWXB2MXNJZlMrWk1NREJjblNwWXFT?= =?utf-8?Q?5gN/fKMSc8c=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 6:DN45Obo9fjHs6g9VK5mfvypaQqp3Pa/JiTGet+ygjeq/KIK3LBPvyGN0pZTrq32WFzUAwK4ZjdlxWx3b6sHGqTEtH1Qx+zftBwb1wSWltKL5fCa2aGLq9WvVIUSWZjHuSa/BVdAIxB0vIJ6dFIQaptkYrAF8fJ/VyrYM6tYYBsBQVKUVzlRiDOnboflAcG35E1M25ttNMrCH/Un9TcvoJDa1Pby3fasKihwMSd6dBbis/OufBgj3KVPANy+7Mqy5mCLgTtWS4/2hkqFllM/fHk3fpQDrXJRlHpiCRNus6biH3sLi3H4HRCvtMVDRSf3UERdvI+Mwok7ocC76Xf86VS1csyIQ2It31ZPuy0yXsLjdxHIzVwh+/8A27cYmvzwdwjA2OjOsYE175WsmaD0YvQ6wX9JX5Z7GVLK8BUb8ROicwdiEckATc/uwnTVFkhRW89tD23LC1qxoZHMaURazwdPmSJ0gcEubjQUbu5nCjezKhtuuMU7/jH/VCKFt8/LrEhxQPeYynKy0OV7bWpZD8VBhGpo9SbYGCzHtgaF8iv4=; 5:N/TatCJ+Tq2e108FaAe69U180g93fNE6Q5B7uAq/czmWxpLFDoTAGCNabFlbJDxo8Ce01I1VpttYD0yVgRo+iM1Yr5zXlOrCzvC5+w3foHCaQqWaR0bijR1a/W7RsmGw68Ww/309/zp+Oo5FkEbzvg==; 24:cZhWWdhRWtaNxgTVB71QiEI64vbQmnuWppESTXjZ8Z6stfVKm8ELIMeSgDF7EQzcN+p2nYVK1mJ6uwrYctdSPpYt0t6Ycxul7p+RiguvjrM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 7:Sjmi9kcMQYUIVWb4X6bRc0gXiGtrawaq10cofKni75nfcj1nzsROgI6J+JnPlWnxjTvsaxClhDCnJwY/T9Ra59uYWAjZciUqqsGAx6YVyLN9jcpwSHesq/xWWCCw12anUX+XBr6Lpb+7KMkbZIT6dney450qWzxXNGqwFbSBgqpfKt/Xm7lMS4a4Au75wPSS9INEpwId0LilqRDMFoffdlqZc249QmXjVp4c1ou/+236oGqnK6BWc4WM0Eo8WMvoGChm7nFeKuLeFuWUaV6MXcgO8euwBwsxoWpXXFwg+85WkTP8SBeO8KQVABoIXuzTvXLejQizKjuibHA822EPAg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2017 16:45:22.3035 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2180 Archived-At: Subject: Re: [Idr] Closed -- Working Group Last Call on draft-ietf-mpls-rfc3107bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 16:50:30 -0000 I have now posted draft-ietf-mpls-rfc3107bis-02.txt, which I believe addresses the LC comments. From nobody Thu May 11 12:04:59 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5050129407; Thu, 11 May 2017 12:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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.001, 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 CIBzqr_XKQV7; Thu, 11 May 2017 12:04:55 -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 055C0129C39; Thu, 11 May 2017 11:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12759; q=dns/txt; s=iport; t=1494529111; x=1495738711; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=sXd5bPvPSm+ySkGEUkX5cuTT1qNI3qwqmDIWl+DZEow=; b=dtso4fUjD94Z8Da0RdqJ75pEwu3RUakWpHHVBuicPWLL5vmQjfXRc5Zd u1QE0qfCdjmj3GjVCx1hjQuUCHDjIfOeWA3vpwq9BZ5djZIlKJempqtkJ GrYywH6IOFVfXhRSANe/h480WGRRdqCyLxH3HUIrNTIKqnL450udfSNFP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAQAg4xNZ/5ldJa1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuPCtigQwHg2KKGJFYiCWIF4U4gg8shXgCGoRoPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUVAQEBAQMjSxsCAQgOAwMBAiQEAwICAh8RFAkIAgQBEooIAxUOsVGCJ?= =?us-ascii?q?ocwDYM4AQEBAQEBAQEBAQEBAQEBAQEBGwWIPAGDG4JUgWdIBhCCXIJgBYcPgjW?= =?us-ascii?q?UCzsBhxuGYUuEU4IEhTuKLIstiRUBHziBCnAVRoQ9ORwZgUp2iAyBDQEBAQ?= X-IronPort-AV: E=Sophos; i="5.38,322,1491264000"; d="scan'208,217"; a="26210086" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2017 18:58:30 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v4BIwTFh031686 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 May 2017 18:58:29 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 11 May 2017 14:58:29 -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, 11 May 2017 14:58:29 -0400 From: "Acee Lindem (acee)" To: Alia Atlas , OSPF List , "rtgwg@ietf.org" , "idr@ietf. org" Thread-Topic: [OSPF] Fwd: Last Call: (Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard Thread-Index: AQHSxDuzUjI6VH7keUqjK/l8NUEI7aHviKoA Date: Thu, 11 May 2017 18:58:28 +0000 Message-ID: References: <149383397646.4894.14546129703556603533.idtracker@ietfa.amsl.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.206] Content-Type: multipart/alternative; boundary="_000_D53A2B68AEA33aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] [OSPF] Fwd: Last Call: (Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 19:04:58 -0000 --_000_D53A2B68AEA33aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxpYSwNCkkgaGF2ZSByZXZpZXdlZCB0aGUgZG9jdW1lbnQgYW5kIGhhZCBzZXZlcmFsIGNv bnZlcnNhdGlvbnMgd2l0aCB0aGUgYXV0aG9ycy4gSSBiZWxpZXZlIHRoZSBlbmNvZGluZ3MgYXJl IGFkYXB0YWJsZSB0byB0aGUgT1NQRiBTZWdtZW50IFJvdXRpbmcgZXh0ZW5zaW9ucy4gT2YgY291 cnNlLCB3ZeKAmWxsIHVzZSBhIGRpZmZlcmVudCBpZGVudGlmaWVyIHRoYW4gU3lzdGVtIElEIChV c2VkIHRvIGlkZW50aWZ5IExBTi1BZGotU0lEIG5laWdob3JzKS4gT25lIGNvbW1lbnQgSSBoYXZl IGlzIHRoYXQgaXQgd291bGQgYmUgbmljZSB0byBoYXZlIEFTQ0lJIGFydCBncmFwaGljYWxseSBk ZXBpY3RpbmcgdGhlIGZvcm1hdCBvZiB0aGUgbmV3IFN1Yi1UTFZzLg0KDQpUaGFua3MsDQpBY2Vl DQoNCkZyb206IE9TUEYgPG9zcGYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b3NwZi1ib3VuY2Vz QGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPG1h aWx0bzpha2F0bGFzQGdtYWlsLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIE1heSAzLCAyMDE3IGF0 IDI6MzAgUE0NClRvOiBPU1BGIFdHIExpc3QgPG9zcGZAaWV0Zi5vcmc8bWFpbHRvOm9zcGZAaWV0 Zi5vcmc+PiwgUm91dGluZyBXRyA8cnRnd2dAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnQGlldGYub3Jn Pj4sIElEUiBMaXN0IDxpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpTdWJqZWN0 OiBbT1NQRl0gRndkOiBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLWlzaXMtbDJidW5kbGVzLTA0LnR4 dD4gKEFkdmVydGlzaW5nIEwyIEJ1bmRsZSBNZW1iZXIgTGluayBBdHRyaWJ1dGVzIGluIElTLUlT KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQpEZWFyIFJUR1dHLCBPU1BGIFdHICYgSURSIFdHLA0K DQpJJ2QgbGlrZSB0byBicmluZyB0aGlzIElFVEYgTGFzdCBDYWxsIHRvIHlvdXIgYXR0ZW50aW9u LiAgVGhlIG1ldGhvZCBmb3IgYWR2ZXJ0aXNpbmcNCkwyIGJ1bmRsZSBpbmZvcm1hdGlvbiB2aWEg SVMtSVMgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQgbWF5IGJlIG9mIGludGVyZXN0IGZvciBvdGhl cg0KcHJvdG9jb2xzIChPU1BGLCAgQkdQLUxTKSB0aGF0IG1heSB1c2UgaXQgYXMgcHJlY2VkZW50 IGZvciBob3cgdG8gYWR2ZXJ0aXNlDQpzdWNoIGluZm9ybWF0aW9uIGlmIHRoZXJlIGlzIG5lZWQg aW4gdGhlIGZ1dHVyZSBhbmQgY29uc2lzdGVuY3kgaXMgZGVzaXJlZCBhdCB0aGF0IHBvaW50Lg0K DQpSZWdhcmRzLA0KQWxpYQ0KDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0t LS0tLQ0KRnJvbTogVGhlIElFU0cgPGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPG1haWx0bzppZXNn LXNlY3JldGFyeUBpZXRmLm9yZz4+DQpEYXRlOiBXZWQsIE1heSAzLCAyMDE3IGF0IDE6NTIgUE0N ClN1YmplY3Q6IExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtaXNpcy1sMmJ1bmRsZXMtMDQudHh0PiAo QWR2ZXJ0aXNpbmcgTDIgQnVuZGxlIE1lbWJlciBMaW5rIEF0dHJpYnV0ZXMgaW4gSVMtSVMpIHRv IFByb3Bvc2VkIFN0YW5kYXJkDQpUbzogSUVURi1Bbm5vdW5jZSA8aWV0Zi1hbm5vdW5jZUBpZXRm Lm9yZzxtYWlsdG86aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4+DQpDYzogaGFubmVzQGdyZWRsZXIu YXQ8bWFpbHRvOmhhbm5lc0BncmVkbGVyLmF0PiwgaXNpcy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRv OmlzaXMtY2hhaXJzQGlldGYub3JnPiwgaXNpcy13Z0BpZXRmLm9yZzxtYWlsdG86aXNpcy13Z0Bp ZXRmLm9yZz4sIGRyYWZ0LWlldGYtaXNpcy1sMmJ1bmRsZXNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LWlldGYtaXNpcy1sMmJ1bmRsZXNAaWV0Zi5vcmc+LCBha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86 YWthdGxhc0BnbWFpbC5jb20+DQoNCg0KDQpUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0 IGZyb20gdGhlIElTLUlTIGZvciBJUCBJbnRlcm5ldHMgV0cgKGlzaXMpDQp0byBjb25zaWRlciB0 aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KLSAnQWR2ZXJ0aXNpbmcgTDIgQnVuZGxlIE1lbWJlciBM aW5rIEF0dHJpYnV0ZXMgaW4gSVMtSVMnDQogIDxkcmFmdC1pZXRmLWlzaXMtbDJidW5kbGVzLTA0 LnR4dD4gYXMgUHJvcG9zZWQgU3RhbmRhcmQNCg0KVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRl Y2lzaW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywgYW5kIHNvbGljaXRzDQpmaW5hbCBjb21tZW50 cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUgY29tbWVudHMgdG8gdGhl DQppZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGlldGYub3JnPiBtYWlsaW5nIGxpc3RzIGJ5IDIw MTctMDUtMTcuIEV4Y2VwdGlvbmFsbHksIGNvbW1lbnRzIG1heSBiZQ0Kc2VudCB0byBpZXNnQGll dGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPiBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxl YXNlIHJldGFpbiB0aGUNCmJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFsbG93IGF1 dG9tYXRlZCBzb3J0aW5nLg0KDQpBYnN0cmFjdA0KDQoNCiAgIFRoZXJlIGFyZSBkZXBsb3ltZW50 cyB3aGVyZSB0aGUgTGF5ZXIgMyBpbnRlcmZhY2Ugb24gd2hpY2ggSVMtSVMNCiAgIG9wZXJhdGVz IGlzIGEgTGF5ZXIgMiBpbnRlcmZhY2UgYnVuZGxlLiAgRXhpc3RpbmcgSVMtSVMNCiAgIGFkdmVy dGlzZW1lbnRzIG9ubHkgc3VwcG9ydCBhZHZlcnRpc2luZyBsaW5rIGF0dHJpYnV0ZXMgb2YgdGhl IExheWVyDQogICAzIGludGVyZmFjZS4gIElmIGVudGl0aWVzIGV4dGVybmFsIHRvIElTLUlTIHdp c2ggdG8gY29udHJvbCB0cmFmZmljDQogICBmbG93cyBvbiB0aGUgaW5kaXZpZHVhbCBwaHlzaWNh bCBsaW5rcyB3aGljaCBjb21wcmlzZSB0aGUgTGF5ZXIgMg0KICAgaW50ZXJmYWNlIGJ1bmRsZSBs aW5rIGF0dHJpYnV0ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgYnVuZGxlIG1lbWJlcnMNCiAgIGlz IHJlcXVpcmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgdGhlIGFiaWxpdHkgZm9y IElTLUlTIHRvIGFkdmVydGlzZSB0aGUgbGluaw0KICAgYXR0cmlidXRlcyBvZiBsYXllciAyIChM MikgYnVuZGxlIG1lbWJlcnMuDQoNCg0KDQoNCg0KVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZp YQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pc2lzLWwyYnVu ZGxlcy8NCg0KSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pc2lzLWwyYnVuZGxlcy9iYWxsb3QvDQoN ClRoZSBmb2xsb3dpbmcgSVBSIERlY2xhcmF0aW9ucyBtYXkgYmUgcmVsYXRlZCB0byB0aGlzIEkt RDoNCg0KICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMjc5My8NCg0KDQoNCg0K DQoNCg== --_000_D53A2B68AEA33aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7CEBE96907C6FD46B3F5ECFE3A1CF26A@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBBbGlhLCZu YnNwOzwvZGl2Pg0KPGRpdj5JIGhhdmUgcmV2aWV3ZWQgdGhlIGRvY3VtZW50IGFuZCBoYWQgc2V2 ZXJhbCBjb252ZXJzYXRpb25zIHdpdGggdGhlIGF1dGhvcnMuIEkgYmVsaWV2ZSB0aGUgZW5jb2Rp bmdzIGFyZSBhZGFwdGFibGUgdG8gdGhlIE9TUEYgU2VnbWVudCBSb3V0aW5nIGV4dGVuc2lvbnMu IE9mIGNvdXJzZSwgd2XigJlsbCB1c2UgYSBkaWZmZXJlbnQgaWRlbnRpZmllciB0aGFuIFN5c3Rl bSBJRCAoVXNlZCB0byBpZGVudGlmeSBMQU4tQWRqLVNJRCBuZWlnaG9ycykuDQogT25lIGNvbW1l bnQgSSBoYXZlIGlzIHRoYXQgaXQgd291bGQgYmUgbmljZSB0byBoYXZlIEFTQ0lJIGFydCBncmFw aGljYWxseSBkZXBpY3RpbmcgdGhlIGZvcm1hdCBvZiB0aGUgbmV3IFN1Yi1UTFZzLiZuYnNwOzwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2VlJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0 ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsg Qk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxF RlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xp ZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPk9TUEYgJmx0OzxhIGhyZWY9Im1h aWx0bzpvc3BmLWJvdW5jZXNAaWV0Zi5vcmciPm9zcGYtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IG9uIGJlaGFsZiBvZiBBbGlhIEF0bGFzICZsdDs8YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFp bC5jb20iPmFrYXRsYXNAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSwgTWF5IDMsIDIwMTcgYXQgMjozMCBQ TTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPk9TUEYgV0cg TGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9zcGZAaWV0Zi5vcmciPm9zcGZAaWV0Zi5vcmc8L2E+ Jmd0OywgUm91dGluZyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnQGlldGYub3JnIj5ydGd3 Z0BpZXRmLm9yZzwvYT4mZ3Q7LCBJRFIgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRm Lm9yZyI+aWRyQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+U3ViamVjdDogPC9zcGFuPltPU1BGXSBGd2Q6IExhc3QgQ2FsbDogJmx0O2RyYWZ0LWll dGYtaXNpcy1sMmJ1bmRsZXMtMDQudHh0Jmd0OyAoQWR2ZXJ0aXNpbmcgTDIgQnVuZGxlIE1lbWJl ciBMaW5rIEF0dHJpYnV0ZXMgaW4gSVMtSVMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJ QlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQ QURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGly PSJsdHIiPg0KPGRpdj5EZWFyIFJUR1dHLCBPU1BGIFdHICZhbXA7IElEUiBXRyw8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkknZCBsaWtlIHRvIGJyaW5nIHRoaXMgSUVURiBMYXN0IENh bGwgdG8geW91ciBhdHRlbnRpb24uJm5ic3A7IFRoZSBtZXRob2QgZm9yIGFkdmVydGlzaW5nPC9k aXY+DQo8ZGl2PkwyIGJ1bmRsZSBpbmZvcm1hdGlvbiB2aWEgSVMtSVMgZGVzY3JpYmVkIGluIHRo aXMgZHJhZnQgbWF5IGJlIG9mIGludGVyZXN0IGZvciBvdGhlcjwvZGl2Pg0KPGRpdj5wcm90b2Nv bHMgKE9TUEYsICZuYnNwO0JHUC1MUykgdGhhdCBtYXkgdXNlIGl0IGFzIHByZWNlZGVudCBmb3Ig aG93IHRvIGFkdmVydGlzZTwvZGl2Pg0KPGRpdj5zdWNoIGluZm9ybWF0aW9uIGlmIHRoZXJlIGlz IG5lZWQgaW4gdGhlIGZ1dHVyZSBhbmQgY29uc2lzdGVuY3kgaXMgZGVzaXJlZCBhdCB0aGF0IHBv aW50LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+ QWxpYTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpGcm9tOiA8 YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+VGhlIElFU0c8L2I+IDxzcGFuIGRpcj0ibHRyIj4m bHQ7PGEgaHJlZj0ibWFpbHRvOmllc2ctc2VjcmV0YXJ5QGlldGYub3JnIj5pZXNnLXNlY3JldGFy eUBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxicj4NCkRhdGU6IFdlZCwgTWF5IDMsIDIwMTcgYXQg MTo1MiBQTTxicj4NClN1YmplY3Q6IExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtaXNpcy1sMmJ1 bmRsZXMtMDQudHh0Jmd0OyAoQWR2ZXJ0aXNpbmcgTDIgQnVuZGxlIE1lbWJlciBMaW5rIEF0dHJp YnV0ZXMgaW4gSVMtSVMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KVG86IElFVEYtQW5ub3Vu Y2UgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmLWFubm91bmNlQGlldGYub3JnIj5pZXRmLWFubm91 bmNlQGlldGYub3JnPC9hPiZndDs8YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOmhhbm5lc0BncmVk bGVyLmF0Ij5oYW5uZXNAZ3JlZGxlci5hdDwvYT4sIDxhIGhyZWY9Im1haWx0bzppc2lzLWNoYWly c0BpZXRmLm9yZyI+DQppc2lzLWNoYWlyc0BpZXRmLm9yZzwvYT4sIDxhIGhyZWY9Im1haWx0bzpp c2lzLXdnQGlldGYub3JnIj5pc2lzLXdnQGlldGYub3JnPC9hPiwNCjxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLWlzaXMtbDJidW5kbGVzQGlldGYub3JnIj5kcmFmdC1pZXRmLWlzaXMtbDJidW5k bGVzQGlldGYub3JnPC9hPiwNCjxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+YWth dGxhc0BnbWFpbC5jb208L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFU0cgaGFzIHJl Y2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBJUy1JUyBmb3IgSVAgSW50ZXJuZXRzIFdHIChpc2lz KTxicj4NCnRvIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6PGJyPg0KLSAnQWR2ZXJ0 aXNpbmcgTDIgQnVuZGxlIE1lbWJlciBMaW5rIEF0dHJpYnV0ZXMgaW4gSVMtSVMnPGJyPg0KJm5i c3A7ICZsdDtkcmFmdC1pZXRmLWlzaXMtbDJidW5kbGVzLTA0Ljx3YnI+dHh0Jmd0OyBhcyBQcm9w b3NlZCBTdGFuZGFyZDxicj4NCjxicj4NClRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lv biBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0czxicj4NCmZpbmFsIGNvbW1lbnRz IG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGU8 YnI+DQo8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT4gbWFp bGluZyBsaXN0cyBieSAyMDE3LTA1LTE3LiBFeGNlcHRpb25hbGx5LCBjb21tZW50cyBtYXkgYmU8 YnI+DQpzZW50IHRvIDxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3Jn PC9hPiBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0aGU8YnI+DQpiZWdp bm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy48YnI+ DQo8YnI+DQpBYnN0cmFjdDxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGVyZSBhcmUg ZGVwbG95bWVudHMgd2hlcmUgdGhlIExheWVyIDMgaW50ZXJmYWNlIG9uIHdoaWNoIElTLUlTPGJy Pg0KJm5ic3A7ICZuYnNwO29wZXJhdGVzIGlzIGEgTGF5ZXIgMiBpbnRlcmZhY2UgYnVuZGxlLiZu YnNwOyBFeGlzdGluZyBJUy1JUzxicj4NCiZuYnNwOyAmbmJzcDthZHZlcnRpc2VtZW50cyBvbmx5 IHN1cHBvcnQgYWR2ZXJ0aXNpbmcgbGluayBhdHRyaWJ1dGVzIG9mIHRoZSBMYXllcjxicj4NCiZu YnNwOyAmbmJzcDszIGludGVyZmFjZS4mbmJzcDsgSWYgZW50aXRpZXMgZXh0ZXJuYWwgdG8gSVMt SVMgd2lzaCB0byBjb250cm9sIHRyYWZmaWM8YnI+DQombmJzcDsgJm5ic3A7Zmxvd3Mgb24gdGhl IGluZGl2aWR1YWwgcGh5c2ljYWwgbGlua3Mgd2hpY2ggY29tcHJpc2UgdGhlIExheWVyIDI8YnI+ DQombmJzcDsgJm5ic3A7aW50ZXJmYWNlIGJ1bmRsZSBsaW5rIGF0dHJpYnV0ZSBpbmZvcm1hdGlv biBhYm91dCB0aGUgYnVuZGxlIG1lbWJlcnM8YnI+DQombmJzcDsgJm5ic3A7aXMgcmVxdWlyZWQu PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUgYWJp bGl0eSBmb3IgSVMtSVMgdG8gYWR2ZXJ0aXNlIHRoZSBsaW5rPGJyPg0KJm5ic3A7ICZuYnNwO2F0 dHJpYnV0ZXMgb2YgbGF5ZXIgMiAoTDIpIGJ1bmRsZSBtZW1iZXJzLjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NClRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWE8YnI+DQo8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlzaXMtbDJi dW5kbGVzLyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy88d2JyPmRvYy9kcmFmdC1pZXRmLWlzaXMtbDJidW5kbGVzLzwvYT48YnI+ DQo8YnI+DQpJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhPGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pc2lzLWwyYnVuZGxl cy9iYWxsb3QvIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnLzx3YnI+ZG9jL2RyYWZ0LWlldGYtaXNpcy1sMmJ1bmRsZXMvPHdicj5i YWxsb3QvPC9hPjxicj4NCjxicj4NClRoZSBmb2xsb3dpbmcgSVBSIERlY2xhcmF0aW9ucyBtYXkg YmUgcmVsYXRlZCB0byB0aGlzIEktRDo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMjc5My8iIHJlbD0ibm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvPHdicj5pcHIvMjc5 My88L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9kaXY+DQo8YnI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_D53A2B68AEA33aceeciscocom_-- From nobody Thu May 11 13:40:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7F91314F4; Thu, 11 May 2017 13:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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.001, 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 Wu_6FlZZeDwD; Thu, 11 May 2017 13:40:20 -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 3658312EC44; Thu, 11 May 2017 13:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22020; q=dns/txt; s=iport; t=1494534912; x=1495744512; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=goLi8dJoZWgsmusR6kLM5nSkyTrfiCBysLF+wu9oLGs=; b=HDmbDcr+dRAGDPGVTp4qnSwFC8DpzG2xy2b0DzwUqRtBZsKH+V0Kf/fc ZgaYzDxD4EsUNXuqTbdTSv6EeLuRzTXS+gnhepxYl9y1BQpylgUmaTlYE tetSMjjhAR2kabpgIaYl/XirthwrptoKQNMj1NXC25PQRmynxO2FwNToU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAQAg4xNZ/5NdJa1TChoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJuPCtigQwHg2KKGJFYiCWIF4U4gg8shXgCGoRoPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQMjCkEbAgEIEQMBAQEkBAMCAgIfERQJCAIEARIIigADFQ6xUYImh?= =?us-ascii?q?zANgzgBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZfgV0BgxuCVIFnPwkGEIJcgmA?= =?us-ascii?q?Fhw+CNZQLOwGHG4ZhS4RKgg2FO4osiy2JFQEfOIEKcBVGhHYcGYFKdogMgQ0BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos; i="5.38,322,1491264000"; d="scan'208,217"; a="26245520" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2017 20:35:11 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v4BKZBE9006150 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 May 2017 20:35:11 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 11 May 2017 15:35:10 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Thu, 11 May 2017 15:35:10 -0500 From: "Les Ginsberg (ginsberg)" To: "Acee Lindem (acee)" , Alia Atlas , OSPF List , "rtgwg@ietf.org" , "idr@ietf. org" Thread-Topic: [OSPF] Fwd: Last Call: (Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard Thread-Index: AQHSxDYf4022tm3LG0qAyWk0ibB7oaHjQiMAgAyaaAD//8b+0A== Date: Thu, 11 May 2017 20:35:10 +0000 Message-ID: References: <149383397646.4894.14546129703556603533.idtracker@ietfa.amsl.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: [10.32.152.12] Content-Type: multipart/alternative; boundary="_000_a9a5d7223f0448cd8fa55bb1413769fbXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] [OSPF] Fwd: Last Call: (Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 20:40:23 -0000 --_000_a9a5d7223f0448cd8fa55bb1413769fbXCHALN001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWNlZSDigJMNCg0KRGlkIHlvdSBsb29rIGF0IHRoZSBBcHBlbmRpeCDigJMgd2hpY2ggaGFzIEFT Q0lJIGFydCBmb3Igc29tZSBleGFtcGxlIGVuY29kaW5ncz8NCg0KICAgTGVzDQoNCg0KRnJvbTog cnRnd2cgW21haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBM aW5kZW0gKGFjZWUpDQpTZW50OiBUaHVyc2RheSwgTWF5IDExLCAyMDE3IDExOjU4IEFNDQpUbzog QWxpYSBBdGxhczsgT1NQRiBMaXN0OyBydGd3Z0BpZXRmLm9yZzsgaWRyQGlldGYuIG9yZw0KU3Vi amVjdDogUmU6IFtPU1BGXSBGd2Q6IExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtaXNpcy1sMmJ1bmRs ZXMtMDQudHh0PiAoQWR2ZXJ0aXNpbmcgTDIgQnVuZGxlIE1lbWJlciBMaW5rIEF0dHJpYnV0ZXMg aW4gSVMtSVMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCkhpIEFsaWEsDQpJIGhhdmUgcmV2aWV3 ZWQgdGhlIGRvY3VtZW50IGFuZCBoYWQgc2V2ZXJhbCBjb252ZXJzYXRpb25zIHdpdGggdGhlIGF1 dGhvcnMuIEkgYmVsaWV2ZSB0aGUgZW5jb2RpbmdzIGFyZSBhZGFwdGFibGUgdG8gdGhlIE9TUEYg U2VnbWVudCBSb3V0aW5nIGV4dGVuc2lvbnMuIE9mIGNvdXJzZSwgd2XigJlsbCB1c2UgYSBkaWZm ZXJlbnQgaWRlbnRpZmllciB0aGFuIFN5c3RlbSBJRCAoVXNlZCB0byBpZGVudGlmeSBMQU4tQWRq LVNJRCBuZWlnaG9ycykuIE9uZSBjb21tZW50IEkgaGF2ZSBpcyB0aGF0IGl0IHdvdWxkIGJlIG5p Y2UgdG8gaGF2ZSBBU0NJSSBhcnQgZ3JhcGhpY2FsbHkgZGVwaWN0aW5nIHRoZSBmb3JtYXQgb2Yg dGhlIG5ldyBTdWItVExWcy4NCg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiBPU1BGIDxvc3BmLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9zcGYtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBv ZiBBbGlhIEF0bGFzIDxha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWthdGxhc0BnbWFpbC5jb20+ Pg0KRGF0ZTogV2VkbmVzZGF5LCBNYXkgMywgMjAxNyBhdCAyOjMwIFBNDQpUbzogT1NQRiBXRyBM aXN0IDxvc3BmQGlldGYub3JnPG1haWx0bzpvc3BmQGlldGYub3JnPj4sIFJvdXRpbmcgV0cgPHJ0 Z3dnQGlldGYub3JnPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4+LCBJRFIgTGlzdCA8aWRyQGlldGYu b3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW09TUEZdIEZ3ZDogTGFzdCBDYWxs OiA8ZHJhZnQtaWV0Zi1pc2lzLWwyYnVuZGxlcy0wNC50eHQ+IChBZHZlcnRpc2luZyBMMiBCdW5k bGUgTWVtYmVyIExpbmsgQXR0cmlidXRlcyBpbiBJUy1JUykgdG8gUHJvcG9zZWQgU3RhbmRhcmQN Cg0KRGVhciBSVEdXRywgT1NQRiBXRyAmIElEUiBXRywNCg0KSSdkIGxpa2UgdG8gYnJpbmcgdGhp cyBJRVRGIExhc3QgQ2FsbCB0byB5b3VyIGF0dGVudGlvbi4gIFRoZSBtZXRob2QgZm9yIGFkdmVy dGlzaW5nDQpMMiBidW5kbGUgaW5mb3JtYXRpb24gdmlhIElTLUlTIGRlc2NyaWJlZCBpbiB0aGlz IGRyYWZ0IG1heSBiZSBvZiBpbnRlcmVzdCBmb3Igb3RoZXINCnByb3RvY29scyAoT1NQRiwgIEJH UC1MUykgdGhhdCBtYXkgdXNlIGl0IGFzIHByZWNlZGVudCBmb3IgaG93IHRvIGFkdmVydGlzZQ0K c3VjaCBpbmZvcm1hdGlvbiBpZiB0aGVyZSBpcyBuZWVkIGluIHRoZSBmdXR1cmUgYW5kIGNvbnNp c3RlbmN5IGlzIGRlc2lyZWQgYXQgdGhhdCBwb2ludC4NCg0KUmVnYXJkcywNCkFsaWENCg0KDQot LS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206IFRoZSBJRVNHIDxp ZXNnLXNlY3JldGFyeUBpZXRmLm9yZzxtYWlsdG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+Pg0K RGF0ZTogV2VkLCBNYXkgMywgMjAxNyBhdCAxOjUyIFBNDQpTdWJqZWN0OiBMYXN0IENhbGw6IDxk cmFmdC1pZXRmLWlzaXMtbDJidW5kbGVzLTA0LnR4dD4gKEFkdmVydGlzaW5nIEwyIEJ1bmRsZSBN ZW1iZXIgTGluayBBdHRyaWJ1dGVzIGluIElTLUlTKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KVG86 IElFVEYtQW5ub3VuY2UgPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmlldGYtYW5ub3Vu Y2VAaWV0Zi5vcmc+Pg0KQ2M6IGhhbm5lc0BncmVkbGVyLmF0PG1haWx0bzpoYW5uZXNAZ3JlZGxl ci5hdD4sIGlzaXMtY2hhaXJzQGlldGYub3JnPG1haWx0bzppc2lzLWNoYWlyc0BpZXRmLm9yZz4s IGlzaXMtd2dAaWV0Zi5vcmc8bWFpbHRvOmlzaXMtd2dAaWV0Zi5vcmc+LCBkcmFmdC1pZXRmLWlz aXMtbDJidW5kbGVzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWlzaXMtbDJidW5kbGVzQGll dGYub3JnPiwgYWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPg0KDQoN Cg0KVGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBJUy1JUyBmb3IgSVAg SW50ZXJuZXRzIFdHIChpc2lzKQ0KdG8gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudDoN Ci0gJ0FkdmVydGlzaW5nIEwyIEJ1bmRsZSBNZW1iZXIgTGluayBBdHRyaWJ1dGVzIGluIElTLUlT Jw0KICA8ZHJhZnQtaWV0Zi1pc2lzLWwyYnVuZGxlcy0wNC50eHQ+IGFzIFByb3Bvc2VkIFN0YW5k YXJkDQoNClRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcg d2Vla3MsIGFuZCBzb2xpY2l0cw0KZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBsZWFz ZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZQ0KaWV0ZkBpZXRmLm9yZzxtYWlsdG86 aWV0ZkBpZXRmLm9yZz4gbWFpbGluZyBsaXN0cyBieSAyMDE3LTA1LTE3LiBFeGNlcHRpb25hbGx5 LCBjb21tZW50cyBtYXkgYmUNCnNlbnQgdG8gaWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRm Lm9yZz4gaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4gdGhlDQpiZWdpbm5p bmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy4NCg0KQWJz dHJhY3QNCg0KDQogICBUaGVyZSBhcmUgZGVwbG95bWVudHMgd2hlcmUgdGhlIExheWVyIDMgaW50 ZXJmYWNlIG9uIHdoaWNoIElTLUlTDQogICBvcGVyYXRlcyBpcyBhIExheWVyIDIgaW50ZXJmYWNl IGJ1bmRsZS4gIEV4aXN0aW5nIElTLUlTDQogICBhZHZlcnRpc2VtZW50cyBvbmx5IHN1cHBvcnQg YWR2ZXJ0aXNpbmcgbGluayBhdHRyaWJ1dGVzIG9mIHRoZSBMYXllcg0KICAgMyBpbnRlcmZhY2Uu ICBJZiBlbnRpdGllcyBleHRlcm5hbCB0byBJUy1JUyB3aXNoIHRvIGNvbnRyb2wgdHJhZmZpYw0K ICAgZmxvd3Mgb24gdGhlIGluZGl2aWR1YWwgcGh5c2ljYWwgbGlua3Mgd2hpY2ggY29tcHJpc2Ug dGhlIExheWVyIDINCiAgIGludGVyZmFjZSBidW5kbGUgbGluayBhdHRyaWJ1dGUgaW5mb3JtYXRp b24gYWJvdXQgdGhlIGJ1bmRsZSBtZW1iZXJzDQogICBpcyByZXF1aXJlZC4NCg0KICAgVGhpcyBk b2N1bWVudCBpbnRyb2R1Y2VzIHRoZSBhYmlsaXR5IGZvciBJUy1JUyB0byBhZHZlcnRpc2UgdGhl IGxpbmsNCiAgIGF0dHJpYnV0ZXMgb2YgbGF5ZXIgMiAoTDIpIGJ1bmRsZSBtZW1iZXJzLg0KDQoN Cg0KDQoNClRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWENCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXNpcy1sMmJ1bmRsZXMvDQoNCklFU0cgZGlzY3Vzc2lv biBjYW4gYmUgdHJhY2tlZCB2aWENCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtaXNpcy1sMmJ1bmRsZXMvYmFsbG90Lw0KDQpUaGUgZm9sbG93aW5nIElQUiBEZWNs YXJhdGlvbnMgbWF5IGJlIHJlbGF0ZWQgdG8gdGhpcyBJLUQ6DQoNCiAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvaXByLzI3OTMvDQoNCg0KDQoNCg0K --_000_a9a5d7223f0448cd8fa55bb1413769fbXCHALN001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BY2VlIOKAkzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+RGlkIHlvdSBsb29rIGF0IHRoZSBBcHBlbmRpeCDigJMgd2hpY2ggaGFzIEFTQ0lJIGFy dCBmb3Igc29tZSBleGFtcGxlIGVuY29kaW5ncz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBMZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Z3dnIFttYWlsdG86cnRnd2ctYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWNlZSBMaW5kZW0gKGFjZWUpPGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBNYXkgMTEsIDIwMTcgMTE6NTggQU08YnI+DQo8Yj5Ubzo8L2I+IEFs aWEgQXRsYXM7IE9TUEYgTGlzdDsgcnRnd2dAaWV0Zi5vcmc7IGlkckBpZXRmLiBvcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtPU1BGXSBGd2Q6IExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYt aXNpcy1sMmJ1bmRsZXMtMDQudHh0Jmd0OyAoQWR2ZXJ0aXNpbmcgTDIgQnVuZGxlIE1lbWJlciBM aW5rIEF0dHJpYnV0ZXMgaW4gSVMtSVMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkgQWxpYSwmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgaGF2ZSByZXZpZXdlZCB0aGUgZG9jdW1lbnQg YW5kIGhhZCBzZXZlcmFsIGNvbnZlcnNhdGlvbnMgd2l0aCB0aGUgYXV0aG9ycy4gSSBiZWxpZXZl IHRoZSBlbmNvZGluZ3MgYXJlIGFkYXB0YWJsZSB0byB0aGUgT1NQRiBTZWdtZW50IFJvdXRpbmcg ZXh0ZW5zaW9ucy4gT2YNCiBjb3Vyc2UsIHdl4oCZbGwgdXNlIGEgZGlmZmVyZW50IGlkZW50aWZp ZXIgdGhhbiBTeXN0ZW0gSUQgKFVzZWQgdG8gaWRlbnRpZnkgTEFOLUFkai1TSUQgbmVpZ2hvcnMp LiBPbmUgY29tbWVudCBJIGhhdmUgaXMgdGhhdCBpdCB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgQVND SUkgYXJ0IGdyYXBoaWNhbGx5IGRlcGljdGluZyB0aGUgZm9ybWF0IG9mIHRoZSBuZXcgU3ViLVRM VnMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFjZWUmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9t Og0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk9T UEYgJmx0OzxhIGhyZWY9Im1haWx0bzpvc3BmLWJvdW5jZXNAaWV0Zi5vcmciPm9zcGYtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBBbGlhIEF0bGFzICZsdDs8YSBocmVmPSJt YWlsdG86YWthdGxhc0BnbWFpbC5jb20iPmFrYXRsYXNAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8 Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBNYXkgMywgMjAxNyBhdCAyOjMwIFBNPGJyPg0KPGI+VG86 IDwvYj5PU1BGIFdHIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzpvc3BmQGlldGYub3JnIj5vc3Bm QGlldGYub3JnPC9hPiZndDssIFJvdXRpbmcgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpydGd3Z0Bp ZXRmLm9yZyI+cnRnd2dAaWV0Zi5vcmc8L2E+Jmd0OywgSURSIExpc3QgJmx0OzxhIGhyZWY9Im1h aWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPltPU1BGXSBGd2Q6IExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtaXNpcy1sMmJ1bmRsZXMt MDQudHh0Jmd0OyAoQWR2ZXJ0aXNpbmcgTDIgQnVuZGxlIE1lbWJlciBMaW5rIEF0dHJpYnV0ZXMg aW4gSVMtSVMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1y aWdodDowaW4iIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRlYXIgUlRHV0csIE9TUEYgV0cgJmFtcDsgSURS IFdHLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JJ2QgbGlrZSB0byBicmlu ZyB0aGlzIElFVEYgTGFzdCBDYWxsIHRvIHlvdXIgYXR0ZW50aW9uLiZuYnNwOyBUaGUgbWV0aG9k IGZvciBhZHZlcnRpc2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+TDIgYnVuZGxlIGluZm9ybWF0aW9uIHZpYSBJUy1JUyBkZXNjcmliZWQgaW4gdGhpcyBkcmFm dCBtYXkgYmUgb2YgaW50ZXJlc3QgZm9yIG90aGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5wcm90b2NvbHMgKE9TUEYsICZuYnNwO0JHUC1MUykgdGhhdCBtYXkg dXNlIGl0IGFzIHByZWNlZGVudCBmb3IgaG93IHRvIGFkdmVydGlzZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+c3VjaCBpbmZvcm1hdGlvbiBpZiB0aGVyZSBpcyBu ZWVkIGluIHRoZSBmdXR1cmUgYW5kIGNvbnNpc3RlbmN5IGlzIGRlc2lyZWQgYXQgdGhhdCBwb2lu dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFsaWE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0t LS0tLS0tLTxicj4NCkZyb206IDxiPlRoZSBJRVNHPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmll c2ctc2VjcmV0YXJ5QGlldGYub3JnIj5pZXNnLXNlY3JldGFyeUBpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KRGF0ZTogV2VkLCBNYXkgMywgMjAxNyBhdCAxOjUyIFBNPGJyPg0KU3ViamVjdDogTGFzdCBD YWxsOiAmbHQ7ZHJhZnQtaWV0Zi1pc2lzLWwyYnVuZGxlcy0wNC50eHQmZ3Q7IChBZHZlcnRpc2lu ZyBMMiBCdW5kbGUgTWVtYmVyIExpbmsgQXR0cmlidXRlcyBpbiBJUy1JUykgdG8gUHJvcG9zZWQg U3RhbmRhcmQ8YnI+DQpUbzogSUVURi1Bbm5vdW5jZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGYt YW5ub3VuY2VAaWV0Zi5vcmciPmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkNj OiA8YSBocmVmPSJtYWlsdG86aGFubmVzQGdyZWRsZXIuYXQiPmhhbm5lc0BncmVkbGVyLmF0PC9h PiwgPGEgaHJlZj0ibWFpbHRvOmlzaXMtY2hhaXJzQGlldGYub3JnIj4NCmlzaXMtY2hhaXJzQGll dGYub3JnPC9hPiwgPGEgaHJlZj0ibWFpbHRvOmlzaXMtd2dAaWV0Zi5vcmciPmlzaXMtd2dAaWV0 Zi5vcmc8L2E+LA0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaXNpcy1sMmJ1bmRsZXNAaWV0 Zi5vcmciPmRyYWZ0LWlldGYtaXNpcy1sMmJ1bmRsZXNAaWV0Zi5vcmc8L2E+LA0KPGEgaHJlZj0i bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT48YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQpUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIElT LUlTIGZvciBJUCBJbnRlcm5ldHMgV0cgKGlzaXMpPGJyPg0KdG8gY29uc2lkZXIgdGhlIGZvbGxv d2luZyBkb2N1bWVudDo8YnI+DQotICdBZHZlcnRpc2luZyBMMiBCdW5kbGUgTWVtYmVyIExpbmsg QXR0cmlidXRlcyBpbiBJUy1JUyc8YnI+DQombmJzcDsgJmx0O2RyYWZ0LWlldGYtaXNpcy1sMmJ1 bmRsZXMtMDQudHh0Jmd0OyBhcyBQcm9wb3NlZCBTdGFuZGFyZDxicj4NCjxicj4NClRoZSBJRVNH IHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xp Y2l0czxicj4NCmZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJz dGFudGl2ZSBjb21tZW50cyB0byB0aGU8YnI+DQo8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9y ZyI+aWV0ZkBpZXRmLm9yZzwvYT4gbWFpbGluZyBsaXN0cyBieSAyMDE3LTA1LTE3LiBFeGNlcHRp b25hbGx5LCBjb21tZW50cyBtYXkgYmU8YnI+DQpzZW50IHRvIDxhIGhyZWY9Im1haWx0bzppZXNn QGlldGYub3JnIj5pZXNnQGlldGYub3JnPC9hPiBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxl YXNlIHJldGFpbiB0aGU8YnI+DQpiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxv dyBhdXRvbWF0ZWQgc29ydGluZy48YnI+DQo8YnI+DQpBYnN0cmFjdDxicj4NCjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDtUaGVyZSBhcmUgZGVwbG95bWVudHMgd2hlcmUgdGhlIExheWVyIDMgaW50 ZXJmYWNlIG9uIHdoaWNoIElTLUlTPGJyPg0KJm5ic3A7ICZuYnNwO29wZXJhdGVzIGlzIGEgTGF5 ZXIgMiBpbnRlcmZhY2UgYnVuZGxlLiZuYnNwOyBFeGlzdGluZyBJUy1JUzxicj4NCiZuYnNwOyAm bmJzcDthZHZlcnRpc2VtZW50cyBvbmx5IHN1cHBvcnQgYWR2ZXJ0aXNpbmcgbGluayBhdHRyaWJ1 dGVzIG9mIHRoZSBMYXllcjxicj4NCiZuYnNwOyAmbmJzcDszIGludGVyZmFjZS4mbmJzcDsgSWYg ZW50aXRpZXMgZXh0ZXJuYWwgdG8gSVMtSVMgd2lzaCB0byBjb250cm9sIHRyYWZmaWM8YnI+DQom bmJzcDsgJm5ic3A7Zmxvd3Mgb24gdGhlIGluZGl2aWR1YWwgcGh5c2ljYWwgbGlua3Mgd2hpY2gg Y29tcHJpc2UgdGhlIExheWVyIDI8YnI+DQombmJzcDsgJm5ic3A7aW50ZXJmYWNlIGJ1bmRsZSBs aW5rIGF0dHJpYnV0ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgYnVuZGxlIG1lbWJlcnM8YnI+DQom bmJzcDsgJm5ic3A7aXMgcmVxdWlyZWQuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9j dW1lbnQgaW50cm9kdWNlcyB0aGUgYWJpbGl0eSBmb3IgSVMtSVMgdG8gYWR2ZXJ0aXNlIHRoZSBs aW5rPGJyPg0KJm5ic3A7ICZuYnNwO2F0dHJpYnV0ZXMgb2YgbGF5ZXIgMiAoTDIpIGJ1bmRsZSBt ZW1iZXJzLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClRoZSBmaWxlIGNhbiBi ZSBvYnRhaW5lZCB2aWE8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWlzaXMtbDJidW5kbGVzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXNpcy1sMmJ1bmRsZXMvPC9hPjxi cj4NCjxicj4NCklFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWE8YnI+DQo8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlzaXMtbDJidW5k bGVzL2JhbGxvdC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWlzaXMtbDJidW5kbGVzL2JhbGxvdC88L2E+PGJyPg0KPGJyPg0KVGhl IGZvbGxvd2luZyBJUFIgRGVjbGFyYXRpb25zIG1heSBiZSByZWxhdGVkIHRvIHRoaXMgSS1EOjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2lwci8yNzkzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvaXByLzI3OTMvPC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_a9a5d7223f0448cd8fa55bb1413769fbXCHALN001ciscocom_-- From nobody Thu May 11 13:54:31 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA7812F3D5; Thu, 11 May 2017 13:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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.001, 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 cyhpJPewUcym; Thu, 11 May 2017 13:54:26 -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 CCCBD12E039; Thu, 11 May 2017 13:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25873; q=dns/txt; s=iport; t=1494535720; x=1495745320; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=mKKSCPIx9+Gy+7wKVyykoKKVzBtigZ+zCR95p8DRO64=; b=fIkSfG9+ocXV9/4qpW9PYIiPB6l/QBjJ/j4y6D1hptpj5dXOLJF0fZ4o nTVU7yCKKQP6f/52pd8pgvK+77eEy+s0+cJeZrVTK5Fam/DVgTEDbEb9K 5+DpyPLQeZYXEr8Nmh3WSuOS6P5iGwM2ZJXDZ6bR+fE61KrXJwVjK8quv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DpAAAzzRRZ/4YNJK1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuPCtigQwHg2KKGJFaiCWNT4IPLIV4AhqEdj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQEDIwpBGwIBCBEDAQEBJAQDAgICHxEUCQgCBAESigoDFQ6xQYImh?= =?us-ascii?q?zANgzgBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYg8AYMbglSBZz8JBhCCXIJgBYc?= =?us-ascii?q?PgjWUCzsBhxuGYUuEU4IEhTuKLIstiRUBHziBCnAVRoR2HBmBSnaHT4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,325,1491264000"; d="scan'208,217";a="244217638" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2017 20:48:39 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v4BKmdKK000994 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 May 2017 20:48:39 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 11 May 2017 16:48: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; Thu, 11 May 2017 16:48:38 -0400 From: "Acee Lindem (acee)" To: "Les Ginsberg (ginsberg)" , Alia Atlas , OSPF List , "rtgwg@ietf.org" , "idr@ietf. org" Thread-Topic: [OSPF] Fwd: Last Call: (Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard Thread-Index: AQHSxDuzUjI6VH7keUqjK/l8NUEI7aHviKoAgABeFwD//8CwAA== Date: Thu, 11 May 2017 20:48:38 +0000 Message-ID: References: <149383397646.4894.14546129703556603533.idtracker@ietfa.amsl.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.206] Content-Type: multipart/alternative; boundary="_000_D53A461CAEA63aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] [OSPF] Fwd: Last Call: (Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 20:54:29 -0000 --_000_D53A461CAEA63aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGVzLA0KDQpGcm9tOiAiTGVzIEdpbnNiZXJnIChnaW5zYmVyZykiIDxnaW5zYmVyZ0BjaXNj by5jb208bWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgTWF5IDEx LCAyMDE3IGF0IDQ6MzUgUE0NClRvOiBBY2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb208bWFpbHRv OmFjZWVAY2lzY28uY29tPj4sIEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPG1haWx0bzph a2F0bGFzQGdtYWlsLmNvbT4+LCBPU1BGIFdHIExpc3QgPG9zcGZAaWV0Zi5vcmc8bWFpbHRvOm9z cGZAaWV0Zi5vcmc+PiwgUm91dGluZyBXRyA8cnRnd2dAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnQGll dGYub3JnPj4sIElEUiBMaXN0IDxpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSRTogW09TUEZdIEZ3ZDogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1pc2lzLWwyYnVu ZGxlcy0wNC50eHQ+IChBZHZlcnRpc2luZyBMMiBCdW5kbGUgTWVtYmVyIExpbmsgQXR0cmlidXRl cyBpbiBJUy1JUykgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0KQWNlZSDigJMNCg0KRGlkIHlvdSBs b29rIGF0IHRoZSBBcHBlbmRpeCDigJMgd2hpY2ggaGFzIEFTQ0lJIGFydCBmb3Igc29tZSBleGFt cGxlIGVuY29kaW5ncz8NCg0KTm8gIC0gSSBtaXNzZWQgdGhlc2UuIEkgd2FzIGxvb2tpbmcgbW9y ZSBmb3IgdGhlIGZvcm1hdCBpbiBib2R5IHJhdGhlciB0aGFuIGp1c3QgZmllbGQgZGVzY3JpcHRp b25zLiBIb3dldmVyLCB0aGUgZXhhbXBsZXMgYXJlIGFsc28gaGVscGZ1bC4NCg0KVGhhbmtzLA0K QWNlZQ0KDQoNCg0KICAgTGVzDQoNCg0KRnJvbTogcnRnd2cgW21haWx0bzpydGd3Zy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBMaW5kZW0gKGFjZWUpDQpTZW50OiBUaHVyc2Rh eSwgTWF5IDExLCAyMDE3IDExOjU4IEFNDQpUbzogQWxpYSBBdGxhczsgT1NQRiBMaXN0OyBydGd3 Z0BpZXRmLm9yZzxtYWlsdG86cnRnd2dAaWV0Zi5vcmc+OyBpZHJAaWV0Zi4gb3JnDQpTdWJqZWN0 OiBSZTogW09TUEZdIEZ3ZDogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1pc2lzLWwyYnVuZGxlcy0w NC50eHQ+IChBZHZlcnRpc2luZyBMMiBCdW5kbGUgTWVtYmVyIExpbmsgQXR0cmlidXRlcyBpbiBJ Uy1JUykgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0KSGkgQWxpYSwNCkkgaGF2ZSByZXZpZXdlZCB0 aGUgZG9jdW1lbnQgYW5kIGhhZCBzZXZlcmFsIGNvbnZlcnNhdGlvbnMgd2l0aCB0aGUgYXV0aG9y cy4gSSBiZWxpZXZlIHRoZSBlbmNvZGluZ3MgYXJlIGFkYXB0YWJsZSB0byB0aGUgT1NQRiBTZWdt ZW50IFJvdXRpbmcgZXh0ZW5zaW9ucy4gT2YgY291cnNlLCB3ZeKAmWxsIHVzZSBhIGRpZmZlcmVu dCBpZGVudGlmaWVyIHRoYW4gU3lzdGVtIElEIChVc2VkIHRvIGlkZW50aWZ5IExBTi1BZGotU0lE IG5laWdob3JzKS4gT25lIGNvbW1lbnQgSSBoYXZlIGlzIHRoYXQgaXQgd291bGQgYmUgbmljZSB0 byBoYXZlIEFTQ0lJIGFydCBncmFwaGljYWxseSBkZXBpY3RpbmcgdGhlIGZvcm1hdCBvZiB0aGUg bmV3IFN1Yi1UTFZzLg0KDQpUaGFua3MsDQpBY2VlDQoNCkZyb206IE9TUEYgPG9zcGYtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86b3NwZi1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEFs aWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPG1haWx0bzpha2F0bGFzQGdtYWlsLmNvbT4+DQpE YXRlOiBXZWRuZXNkYXksIE1heSAzLCAyMDE3IGF0IDI6MzAgUE0NClRvOiBPU1BGIFdHIExpc3Qg PG9zcGZAaWV0Zi5vcmc8bWFpbHRvOm9zcGZAaWV0Zi5vcmc+PiwgUm91dGluZyBXRyA8cnRnd2dA aWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnQGlldGYub3JnPj4sIElEUiBMaXN0IDxpZHJAaWV0Zi5vcmc8 bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbT1NQRl0gRndkOiBMYXN0IENhbGw6IDxk cmFmdC1pZXRmLWlzaXMtbDJidW5kbGVzLTA0LnR4dD4gKEFkdmVydGlzaW5nIEwyIEJ1bmRsZSBN ZW1iZXIgTGluayBBdHRyaWJ1dGVzIGluIElTLUlTKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQpE ZWFyIFJUR1dHLCBPU1BGIFdHICYgSURSIFdHLA0KDQpJJ2QgbGlrZSB0byBicmluZyB0aGlzIElF VEYgTGFzdCBDYWxsIHRvIHlvdXIgYXR0ZW50aW9uLiAgVGhlIG1ldGhvZCBmb3IgYWR2ZXJ0aXNp bmcNCkwyIGJ1bmRsZSBpbmZvcm1hdGlvbiB2aWEgSVMtSVMgZGVzY3JpYmVkIGluIHRoaXMgZHJh ZnQgbWF5IGJlIG9mIGludGVyZXN0IGZvciBvdGhlcg0KcHJvdG9jb2xzIChPU1BGLCAgQkdQLUxT KSB0aGF0IG1heSB1c2UgaXQgYXMgcHJlY2VkZW50IGZvciBob3cgdG8gYWR2ZXJ0aXNlDQpzdWNo IGluZm9ybWF0aW9uIGlmIHRoZXJlIGlzIG5lZWQgaW4gdGhlIGZ1dHVyZSBhbmQgY29uc2lzdGVu Y3kgaXMgZGVzaXJlZCBhdCB0aGF0IHBvaW50Lg0KDQpSZWdhcmRzLA0KQWxpYQ0KDQoNCi0tLS0t LS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogVGhlIElFU0cgPGllc2ct c2VjcmV0YXJ5QGlldGYub3JnPG1haWx0bzppZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4+DQpEYXRl OiBXZWQsIE1heSAzLCAyMDE3IGF0IDE6NTIgUE0NClN1YmplY3Q6IExhc3QgQ2FsbDogPGRyYWZ0 LWlldGYtaXNpcy1sMmJ1bmRsZXMtMDQudHh0PiAoQWR2ZXJ0aXNpbmcgTDIgQnVuZGxlIE1lbWJl ciBMaW5rIEF0dHJpYnV0ZXMgaW4gSVMtSVMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQpUbzogSUVU Ri1Bbm5vdW5jZSA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aWV0Zi1hbm5vdW5jZUBp ZXRmLm9yZz4+DQpDYzogaGFubmVzQGdyZWRsZXIuYXQ8bWFpbHRvOmhhbm5lc0BncmVkbGVyLmF0 PiwgaXNpcy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmlzaXMtY2hhaXJzQGlldGYub3JnPiwgaXNp cy13Z0BpZXRmLm9yZzxtYWlsdG86aXNpcy13Z0BpZXRmLm9yZz4sIGRyYWZ0LWlldGYtaXNpcy1s MmJ1bmRsZXNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaXNpcy1sMmJ1bmRsZXNAaWV0Zi5v cmc+LCBha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWthdGxhc0BnbWFpbC5jb20+DQoNCg0KDQpU aGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIElTLUlTIGZvciBJUCBJbnRl cm5ldHMgV0cgKGlzaXMpDQp0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KLSAn QWR2ZXJ0aXNpbmcgTDIgQnVuZGxlIE1lbWJlciBMaW5rIEF0dHJpYnV0ZXMgaW4gSVMtSVMnDQog IDxkcmFmdC1pZXRmLWlzaXMtbDJidW5kbGVzLTA0LnR4dD4gYXMgUHJvcG9zZWQgU3RhbmRhcmQN Cg0KVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0IGZldyB3ZWVr cywgYW5kIHNvbGljaXRzDQpmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNl bmQgc3Vic3RhbnRpdmUgY29tbWVudHMgdG8gdGhlDQppZXRmQGlldGYub3JnPG1haWx0bzppZXRm QGlldGYub3JnPiBtYWlsaW5nIGxpc3RzIGJ5IDIwMTctMDUtMTcuIEV4Y2VwdGlvbmFsbHksIGNv bW1lbnRzIG1heSBiZQ0Kc2VudCB0byBpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3Jn PiBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0aGUNCmJlZ2lubmluZyBv ZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFsbG93IGF1dG9tYXRlZCBzb3J0aW5nLg0KDQpBYnN0cmFj dA0KDQoNCiAgIFRoZXJlIGFyZSBkZXBsb3ltZW50cyB3aGVyZSB0aGUgTGF5ZXIgMyBpbnRlcmZh Y2Ugb24gd2hpY2ggSVMtSVMNCiAgIG9wZXJhdGVzIGlzIGEgTGF5ZXIgMiBpbnRlcmZhY2UgYnVu ZGxlLiAgRXhpc3RpbmcgSVMtSVMNCiAgIGFkdmVydGlzZW1lbnRzIG9ubHkgc3VwcG9ydCBhZHZl cnRpc2luZyBsaW5rIGF0dHJpYnV0ZXMgb2YgdGhlIExheWVyDQogICAzIGludGVyZmFjZS4gIElm IGVudGl0aWVzIGV4dGVybmFsIHRvIElTLUlTIHdpc2ggdG8gY29udHJvbCB0cmFmZmljDQogICBm bG93cyBvbiB0aGUgaW5kaXZpZHVhbCBwaHlzaWNhbCBsaW5rcyB3aGljaCBjb21wcmlzZSB0aGUg TGF5ZXIgMg0KICAgaW50ZXJmYWNlIGJ1bmRsZSBsaW5rIGF0dHJpYnV0ZSBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgYnVuZGxlIG1lbWJlcnMNCiAgIGlzIHJlcXVpcmVkLg0KDQogICBUaGlzIGRvY3Vt ZW50IGludHJvZHVjZXMgdGhlIGFiaWxpdHkgZm9yIElTLUlTIHRvIGFkdmVydGlzZSB0aGUgbGlu aw0KICAgYXR0cmlidXRlcyBvZiBsYXllciAyIChMMikgYnVuZGxlIG1lbWJlcnMuDQoNCg0KDQoN Cg0KVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1pc2lzLWwyYnVuZGxlcy8NCg0KSUVTRyBkaXNjdXNzaW9uIGNh biBiZSB0cmFja2VkIHZpYQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1pc2lzLWwyYnVuZGxlcy9iYWxsb3QvDQoNClRoZSBmb2xsb3dpbmcgSVBSIERlY2xhcmF0 aW9ucyBtYXkgYmUgcmVsYXRlZCB0byB0aGlzIEktRDoNCg0KICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9pcHIvMjc5My8NCg0KDQoNCg0KDQo= --_000_D53A461CAEA63aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <24FB9D3386BBFC44A2703E0992C0BEB3@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBMZXMsJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0 ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsg Qk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxF RlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xp ZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZxdW90O0xlcyBHaW5zYmVyZyAo Z2luc2JlcmcpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tIj5n aW5zYmVyZ0BjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXksIE1heSAxMSwgMjAxNyBhdCA0OjM1IFBNPGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+QWNlZSBMaW5kZW0gJmx0 OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSI+YWNlZUBjaXNjby5jb208L2E+Jmd0Oywg QWxpYSBBdGxhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIj5ha2F0bGFz QGdtYWlsLmNvbTwvYT4mZ3Q7LCBPU1BGIFdHIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzpvc3Bm QGlldGYub3JnIj5vc3BmQGlldGYub3JnPC9hPiZndDssIFJvdXRpbmcgV0cgJmx0OzxhIGhyZWY9 Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+cnRnd2dAaWV0Zi5vcmc8L2E+Jmd0OywNCiBJRFIgTGlz dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJFOiBb T1NQRl0gRndkOiBMYXN0IENhbGw6ICZsdDtkcmFmdC1pZXRmLWlzaXMtbDJidW5kbGVzLTA0LnR4 dCZndDsgKEFkdmVydGlzaW5nIEwyIEJ1bmRsZSBNZW1iZXIgTGluayBBdHRyaWJ1dGVzIGluIElT LUlTKSB0byBQcm9wb3NlZCBTdGFuZGFyZDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHls ZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46 MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIg eG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3 PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8v c2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8v d3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYu TXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyI+QWNlZSDigJM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7Ij5EaWQgeW91IGxvb2sgYXQgdGhlIEFwcGVuZGl4IOKAkyB3aGljaCBoYXMg QVNDSUkgYXJ0IGZvciBzb21lIGV4YW1wbGUgZW5jb2RpbmdzPzwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5ObyAmbmJzcDstIEkgbWlzc2VkIHRoZXNlLiBJIHdhcyBsb29raW5nIG1vcmUgZm9y IHRoZSBmb3JtYXQgaW4gYm9keSByYXRoZXIgdGhhbiBqdXN0IGZpZWxkIGRlc2NyaXB0aW9ucy4g SG93ZXZlciwgdGhlIGV4YW1wbGVzIGFyZSBhbHNvIGhlbHBmdWwuJm5ic3A7PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFjZWUmbmJzcDs8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9C TE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzow IDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4 bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwi IHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxkaXYgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOyZu YnNwOyBMZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2Vy aWY7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1m YW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiPiBydGd3ZyBbPGEgaHJlZj0ibWFpbHRvOnJ0Z3dn LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+QWNlZSBMaW5kZW0gKGFjZWUpPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBNYXkgMTEsIDIwMTcgMTE6NTggQU08YnI+DQo8Yj5Ubzo8L2I+IEFsaWEgQXRsYXM7 IE9TUEYgTGlzdDsgPGEgaHJlZj0ibWFpbHRvOnJ0Z3dnQGlldGYub3JnIj5ydGd3Z0BpZXRmLm9y ZzwvYT47IGlkckBpZXRmLiBvcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPU1BGXSBGd2Q6 IExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtaXNpcy1sMmJ1bmRsZXMtMDQudHh0Jmd0OyAoQWR2 ZXJ0aXNpbmcgTDIgQnVuZGxlIE1lbWJlciBMaW5rIEF0dHJpYnV0ZXMgaW4gSVMtSVMpIHRvIFBy b3Bvc2VkIFN0YW5kYXJkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPkhpIEFsaWEsJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IGJsYWNrOyI+SSBoYXZlIHJldmlld2VkIHRoZSBkb2N1bWVudCBhbmQgaGFk IHNldmVyYWwgY29udmVyc2F0aW9ucyB3aXRoIHRoZSBhdXRob3JzLiBJIGJlbGlldmUgdGhlIGVu Y29kaW5ncyBhcmUgYWRhcHRhYmxlIHRvIHRoZSBPU1BGIFNlZ21lbnQgUm91dGluZyBleHRlbnNp b25zLg0KIE9mIGNvdXJzZSwgd2XigJlsbCB1c2UgYSBkaWZmZXJlbnQgaWRlbnRpZmllciB0aGFu IFN5c3RlbSBJRCAoVXNlZCB0byBpZGVudGlmeSBMQU4tQWRqLVNJRCBuZWlnaG9ycykuIE9uZSBj b21tZW50IEkgaGF2ZSBpcyB0aGF0IGl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSBBU0NJSSBhcnQg Z3JhcGhpY2FsbHkgZGVwaWN0aW5nIHRoZSBmb3JtYXQgb2YgdGhlIG5ldyBTdWItVExWcy4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxh Y2s7Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+QWNlZSZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiBibGFjazsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiBibGFjazsiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5P U1BGICZsdDs8YSBocmVmPSJtYWlsdG86b3NwZi1ib3VuY2VzQGlldGYub3JnIj5vc3BmLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQWxpYSBBdGxhcyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0K PGI+RGF0ZTogPC9iPldlZG5lc2RheSwgTWF5IDMsIDIwMTcgYXQgMjozMCBQTTxicj4NCjxiPlRv OiA8L2I+T1NQRiBXRyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86b3NwZkBpZXRmLm9yZyI+b3Nw ZkBpZXRmLm9yZzwvYT4mZ3Q7LCBSb3V0aW5nIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cnRnd2dA aWV0Zi5vcmciPnJ0Z3dnQGlldGYub3JnPC9hPiZndDssIElEUiBMaXN0ICZsdDs8YSBocmVmPSJt YWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 IDwvYj5bT1NQRl0gRndkOiBMYXN0IENhbGw6ICZsdDtkcmFmdC1pZXRmLWlzaXMtbDJidW5kbGVz LTA0LnR4dCZndDsgKEFkdmVydGlzaW5nIEwyIEJ1bmRsZSBNZW1iZXIgTGluayBBdHRyaWJ1dGVz IGluIElTLUlTKSB0byBQcm9wb3NlZCBTdGFuZGFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiIgaWQ9Ik1B Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPkRlYXIg UlRHV0csIE9TUEYgV0cgJmFtcDsgSURSIFdHLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw LjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPkknZCBsaWtlIHRvIGJyaW5nIHRoaXMgSUVU RiBMYXN0IENhbGwgdG8geW91ciBhdHRlbnRpb24uJm5ic3A7IFRoZSBtZXRob2QgZm9yIGFkdmVy dGlzaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+TDIgYnVuZGxlIGluZm9ybWF0aW9uIHZp YSBJUy1JUyBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdCBtYXkgYmUgb2YgaW50ZXJlc3QgZm9yIG90 aGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+cHJvdG9jb2xzIChPU1BGLCAmbmJzcDtCR1At TFMpIHRoYXQgbWF5IHVzZSBpdCBhcyBwcmVjZWRlbnQgZm9yIGhvdyB0byBhZHZlcnRpc2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5zdWNoIGluZm9ybWF0aW9uIGlmIHRoZXJlIGlzIG5lZWQg aW4gdGhlIGZ1dHVyZSBhbmQgY29uc2lzdGVuY3kgaXMgZGVzaXJlZCBhdCB0aGF0IHBvaW50Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsi PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+QWxpYTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiBibGFjazsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVz c2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogPGI+VGhlIElFU0c8L2I+ICZsdDs8YSBocmVmPSJt YWlsdG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmciPmllc2ctc2VjcmV0YXJ5QGlldGYub3JnPC9h PiZndDs8YnI+DQpEYXRlOiBXZWQsIE1heSAzLCAyMDE3IGF0IDE6NTIgUE08YnI+DQpTdWJqZWN0 OiBMYXN0IENhbGw6ICZsdDtkcmFmdC1pZXRmLWlzaXMtbDJidW5kbGVzLTA0LnR4dCZndDsgKEFk dmVydGlzaW5nIEwyIEJ1bmRsZSBNZW1iZXIgTGluayBBdHRyaWJ1dGVzIGluIElTLUlTKSB0byBQ cm9wb3NlZCBTdGFuZGFyZDxicj4NClRvOiBJRVRGLUFubm91bmNlICZsdDs8YSBocmVmPSJtYWls dG86aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZyI+aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpoYW5uZXNAZ3JlZGxlci5hdCI+aGFubmVzQGdyZWRs ZXIuYXQ8L2E+LCA8YSBocmVmPSJtYWlsdG86aXNpcy1jaGFpcnNAaWV0Zi5vcmciPg0KaXNpcy1j aGFpcnNAaWV0Zi5vcmc8L2E+LCA8YSBocmVmPSJtYWlsdG86aXNpcy13Z0BpZXRmLm9yZyI+aXNp cy13Z0BpZXRmLm9yZzwvYT4sDQo8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pc2lzLWwyYnVu ZGxlc0BpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1pc2lzLWwyYnVuZGxlc0BpZXRmLm9yZzwvYT4sDQo8 YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iPmFrYXRsYXNAZ21haWwuY29tPC9hPjxi cj4NCjxicj4NCjxicj4NCjxicj4NClRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJv bSB0aGUgSVMtSVMgZm9yIElQIEludGVybmV0cyBXRyAoaXNpcyk8YnI+DQp0byBjb25zaWRlciB0 aGUgZm9sbG93aW5nIGRvY3VtZW50Ojxicj4NCi0gJ0FkdmVydGlzaW5nIEwyIEJ1bmRsZSBNZW1i ZXIgTGluayBBdHRyaWJ1dGVzIGluIElTLUlTJzxicj4NCiZuYnNwOyAmbHQ7ZHJhZnQtaWV0Zi1p c2lzLWwyYnVuZGxlcy0wNC50eHQmZ3Q7IGFzIFByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KPGJyPg0K VGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywg YW5kIHNvbGljaXRzPGJyPg0KZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBsZWFzZSBz ZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZTxicj4NCjxhIGhyZWY9Im1haWx0bzppZXRm QGlldGYub3JnIj5pZXRmQGlldGYub3JnPC9hPiBtYWlsaW5nIGxpc3RzIGJ5IDIwMTctMDUtMTcu IEV4Y2VwdGlvbmFsbHksIGNvbW1lbnRzIG1heSBiZTxicj4NCnNlbnQgdG8gPGEgaHJlZj0ibWFp bHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+IGluc3RlYWQuIEluIGVpdGhlciBj YXNlLCBwbGVhc2UgcmV0YWluIHRoZTxicj4NCmJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBsaW5l IHRvIGFsbG93IGF1dG9tYXRlZCBzb3J0aW5nLjxicj4NCjxicj4NCkFic3RyYWN0PGJyPg0KPGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoZXJlIGFyZSBkZXBsb3ltZW50cyB3aGVyZSB0aGUgTGF5 ZXIgMyBpbnRlcmZhY2Ugb24gd2hpY2ggSVMtSVM8YnI+DQombmJzcDsgJm5ic3A7b3BlcmF0ZXMg aXMgYSBMYXllciAyIGludGVyZmFjZSBidW5kbGUuJm5ic3A7IEV4aXN0aW5nIElTLUlTPGJyPg0K Jm5ic3A7ICZuYnNwO2FkdmVydGlzZW1lbnRzIG9ubHkgc3VwcG9ydCBhZHZlcnRpc2luZyBsaW5r IGF0dHJpYnV0ZXMgb2YgdGhlIExheWVyPGJyPg0KJm5ic3A7ICZuYnNwOzMgaW50ZXJmYWNlLiZu YnNwOyBJZiBlbnRpdGllcyBleHRlcm5hbCB0byBJUy1JUyB3aXNoIHRvIGNvbnRyb2wgdHJhZmZp Yzxicj4NCiZuYnNwOyAmbmJzcDtmbG93cyBvbiB0aGUgaW5kaXZpZHVhbCBwaHlzaWNhbCBsaW5r cyB3aGljaCBjb21wcmlzZSB0aGUgTGF5ZXIgMjxicj4NCiZuYnNwOyAmbmJzcDtpbnRlcmZhY2Ug YnVuZGxlIGxpbmsgYXR0cmlidXRlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBidW5kbGUgbWVtYmVy czxicj4NCiZuYnNwOyAmbmJzcDtpcyByZXF1aXJlZC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 VGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIHRoZSBhYmlsaXR5IGZvciBJUy1JUyB0byBhZHZlcnRp c2UgdGhlIGxpbms8YnI+DQombmJzcDsgJm5ic3A7YXR0cmlidXRlcyBvZiBsYXllciAyIChMMikg YnVuZGxlIG1lbWJlcnMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KVGhlIGZp bGUgY2FuIGJlIG9idGFpbmVkIHZpYTxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXNpcy1sMmJ1bmRsZXMvIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pc2lzLWwyYnVuZGxl cy88L2E+PGJyPg0KPGJyPg0KSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYTxicj4N CjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXNp cy1sMmJ1bmRsZXMvYmFsbG90LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXNpcy1sMmJ1bmRsZXMvYmFsbG90LzwvYT48YnI+DQo8 YnI+DQpUaGUgZm9sbG93aW5nIElQUiBEZWNsYXJhdGlvbnMgbWF5IGJlIHJlbGF0ZWQgdG8gdGhp cyBJLUQ6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvaXByLzI3OTMvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9pcHIvMjc5My88L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogYmxhY2s7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D53A461CAEA63aceeciscocom_-- From nobody Thu May 18 09:39:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0359912AF77; Thu, 18 May 2017 09:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvgDVce6juXy; Thu, 18 May 2017 09:39:23 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0096.outbound.protection.outlook.com [104.47.38.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96321200ED; Thu, 18 May 2017 09:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LJx0uzYZd8kNC+tmJHOeWirSUxaOxGF3c76b11d/Jkw=; b=TjtrOPM/wfrtkNcA78XO4JwMl4VOwieDXAeIGPLO9yEN5QbfPIeK6UyJPzphEFZcvtJuk/aix4WsA6FFpmnNoU2q2vMEV4PBuzohbTCdCDAOFXsBT8tp+XlA0572XpYVT4Rb32gvqldlP5rN7uldafByuQ84IP/84yzT1WG4JYk= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from pboucek-sslvpn-nc.jnpr.net (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_128_CBC_SHA256_P256) id 15.1.1124.5; Thu, 18 May 2017 16:32:12 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 May 2017 12:32:09 -0400 Message-ID: CC: , 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: BN6PR16CA0010.namprd16.prod.outlook.com (10.172.212.148) To BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PR05MB2497: X-MS-Office365-Filtering-Correlation-Id: 4f6ec1d2-24fb-4660-6d21-08d49e0b7045 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 3:pcJ5bnLnPZ8Hzl0DKlWTYQc/kyIe9C1B4O5pePpPtopcEAHTvco22JQ9wMxDpjg0jLzX4aYFMyuiITbUmE8PI9Y1mxgK/LX0aN45SWpsRh456BhLc8sm/quwRwr6dtr9tgZT4bWeWo8b/ZoVZiZKU0deQEMplZrqqkqbwc1mcUbZfIku8hoOWjK6i/jM40FmbWYnfLYkGDSaCNnfIwdTxWHYZfW/kNL21duMxW+NTOSbLXRi8EcxsN6kS2AyOqdymhMjXckwaLYrKWGvA1xkk04PyG2I6a55zTEuti2ciakSd6ejl1PBvva3rhLJ8S/MLQZJPlyQHJifzEgZoXIpTG49dTiqdKZ+w7rNQwv9l3o=; 25:cUSegfgeWQSy6uUwTmt4OagvkIxjClRJZv46+z/vGed7WZfdA18GMhm5THgR/zMBx/FSGHO74NC5zsJM18/PyNINHDWLDKSMGbuhwj+WNADgHy3IOAJ8pPPRcsbfGHiwyhJ+C+wdB+NyFG+THvCNbQfD++leQHmnDCVBmSb1yfjGY//GDXudl9ZypflXj8PQR7fSZh14CZQ7scN2hwvLnz9odS7Kcfs8epMnd/QxKgbNq81i6nBcE3hb/E90/s4NeqXREwHouVg0wI/1Ir83i1EbzvOeQ+6T+I5PGVaq7uhL7215Yws1LUF7eYBu6aWEk3IqdckpbBgIHc74L3wKHqm87ZDpPQlW4XpPOy9Hzk3ZFr8lEc0VjIjhNmgdqYiCJeLji/7k8KZUrvv8g+3NMw0EVNgjBojWnoxrgF0L4IIl5da72f1vRtyLC6pC2W/rxYCMkAc4NW2iJKaqt52NQIJPAGWO8LX0IVlwvo/W5rE= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 31:db3wpvV1AtErlx6iadHel7N9PVZtnMiaQSsElIMz77/Ek8iq+UMijYwmRvj1QVbue6CAG6vjo2v1uWBs/3F0vOnFsk0/Ai1zJBjy6xOtkNlsfmo24YgbJELzvZyF66+RFVdlsxi2N32s7VY2em5YA+SJQK7kwCIK/71HCQvEkbGS+HqQRcW1fmP0abqXzGguQatd0o9dxsyvrja6ib3ueBN72VdMqK2diah2FIS26MFbSOHSP5MnLVmAYF7VYVFs; 20:vnEguiC8pECH+MyPJ+1lkLxGKBl1ZgSEUUVP7LGUmXYlemSzSwygTv22ftKpNxUkwAq2M3XRdBYjCVbRu+BkJz+5pWCvB0kAyNbTMWGK7eOswh3zbn+jwGEASEAlR0rhDIob7zT3mTjwDdBO6rHuGCQN8bjVqUFzs0reJVL4EupT8HBkpmp8O81L+Iaaujh/mQPEB+6gfaDKvNZ9MQgd+ycn8uxTrXLJY5URCoqQbzS919ltbhyb2735L59zqSLvXqfoiEuBpCfjKuXcOm5P1bAvxn2LWxe4NwidYXwu41HvcaVLj3sjj3YpICXyrOwQmDoqPLUD64BJJ3hDnjgRro2X+dDijA+KS/lp/5fk75uCvKVRID9hD/z3kp+ogdJfpIf0WCsEHoLZsBejajBc5dcVuu+foy9gjfYmV61ohySjJIcs6BKua8BIpRgjtPbA9AxPGXpEBc8g/CRL8EbOmWfvZeqgsSsm7y4CAkfISZntrM0yRmlFxrERSjD0Wli2HLAV07xbbdVLrPv0ACqFRCfBC6heD4U7EfAYFkEOzutnLx0W+ugHQcp69Yb4Hu42cW967pIViu8M3dmG2CWNbRJ8++z8nT6cRvJVKxyltLw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR05MB2497; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 4:2iaFMbKd1Rwu+XXOeSFqkh2DFcLnvRvZUfwbj2INIbHwzi4PbtFOHOHuY2n1ouzQHcguaReJHM5D/NxTOc0s6u8vOeQOxGdGgpjApEc+52ikkUIQu8y3NNI7Q21ctKTgATDfyJtJVBKIcBZbtypg2xc8AjtUki+QJjVW21PUwEBhqE34qQ+U1y0qcVYNxkKsQT24fQ159v6qwA39PaT9AZpnmoNurLJa++s7INTeN6VaPTduuJdaHvaNkI277m2DJbzgdHdXE63xJskAWYfO/bAQzof4P6MZm/uMnJSZwdofBp9Kxnur1AQuegJIv3MANewfDE1shDV4lDUVwDVYT0c1O2DH5zeIaWNGsRwkNGj2G3KsMwGc58jpWXCKVYMhldQghCsuaU3bi30pW1KIUjVBDvogTrcaaAif2MATMFpOGRV8Wzm+IZhEfc3pABUJD0OVfqjOI1m4kczCJepmcANm2EI9JlOY5Kw4Ovxp9iqm+lSykiCQDk4zqgkAWzmUBW9+duh8lbpECRO8umOPnp6m8ZhLhCqSuJlXlQ7jjvJNClyRlWWOv1R8XgInQXoQtuqz4EJhmRKBFFqGQckbWNMheELYx9vgasuj7mr/Rnl9+l1tFj2CuyJpnE7c2hHHFEGR5gMArBFVcjYDrmEuhy3M+quAeOHoL84r3QBZFkxOGhmRg/lEJpe5fwXZ7QDaEQqB4qjN1fx8dPIgKDKAeGhlhtdvEodgZKmQ49HoLK1fGgEZHEHoRFr30/ySuE1ygVaNc1AuxFRxUaGYf4B9Km9KEwCMPvte91iHytv50oii0a9BobzXb7TrEysLIldW9DuJl4YBkXtpq8Sn2dVKR8ByFjGTQ4adAx4wysgwlOA= X-Forefront-PRVS: 0311124FA9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39860400002)(39450400003)(39850400002)(39840400002)(39400400002)(53754006)(2906002)(189998001)(38730400002)(305945005)(50986999)(966005)(478600001)(66066001)(230783001)(7736002)(110136004)(8676002)(25786009)(54906002)(2351001)(97756001)(81166006)(42186005)(8746002)(6512007)(6306002)(33656002)(50226002)(6506006)(46406003)(5660300001)(53936002)(86362001)(6486002)(6916009)(6666003)(23726003)(53416004)(36756003)(4326008)(6116002)(3846002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2497; H:pboucek-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2497; 23:n2+sgE6Y7ThOEL0QMgq7FFwXSJRrA8GH+irzw/HKC?= =?us-ascii?Q?9pHwKpXqO+j1hjnKbNB0YmId6hfSzzKB9Zs8//V0bZ1dKKyXjjt4mSJO0qlB?= =?us-ascii?Q?bHueV827g/n1+qFRE8UEko1xKy8CANTbIRwaDCMTFfmSYuNy4UmGtUYT2jMX?= =?us-ascii?Q?5LW76TDG9En1knZ9m8/QByjKV9MuhWe7UUuyvCAKOS77yGVLDBuL9DizDERG?= =?us-ascii?Q?o2Shmh98Y9RBdPiuOKQ+E2OlxMlxZn/KMXsqbwKFcthKhXXP0DBDyI7VixJn?= =?us-ascii?Q?RTcbEWJ/HHXj+x6h7z6m/M2WeDnmzQjYWk+pFcsxUozr5hyPZ3Ctnql0rFny?= =?us-ascii?Q?eQ4sKQD/AmRmEutxLSCsbfKyr0tUS8Cy8DA5X6QJCZI75JfZ+WRRd8em8v9z?= =?us-ascii?Q?N7x79tq2uyx66+PB0yit/9GKWWSs4TDeCqhgXDnJLujAouOuqVgBTLEbCvL0?= =?us-ascii?Q?NmjHMAySOJl5ncd/9T2CcNdtB/YFXUGWBgBRCbg9ddwYWyYw7EY4hBDNUlUI?= =?us-ascii?Q?3/R+zVHZLXQejOnv058DVJBYjROr9fPnG8ovbQYqbAdFq89GVdN8C0c+YJQK?= =?us-ascii?Q?dNBcu9bnVR/R3kbVwzAFadJz4fP6D21YBAIs666thQvX+EjnEV1aREt+SGHC?= =?us-ascii?Q?7xvMUhvPA1TsZ0fW1rGla67HTTtTHpaulWJC1ozJXWWNr8sEUFa0Z2mTd69n?= =?us-ascii?Q?DZP9m31Rd//hcLoCePD6/enpLrHCPCXeYGNi0U2b8ct4BfAEdx+oPBJT/qkV?= =?us-ascii?Q?Zi/vGsr10JGH4CD6JSNKoovTOQIWzCw8Pyi8st7gxsqDCU6xQB8LE8C/uCDN?= =?us-ascii?Q?UpfIugiMz3L8i/sqgIdYVroi7lw36Ddblpg3UDHS4SuxNjEjx8NgBRP/UDBz?= =?us-ascii?Q?RqIiPZJg66jaU1cidFozw/euMXv4uOdAVzZ3A6kg1o83Ya3FRHi9OCqBeKfX?= =?us-ascii?Q?5zOeiwkX8Hi+XvVLhu6eG9f6yCZuvgpO7ReiaUSEuYwmYas6Ivf/vNfVDS72?= =?us-ascii?Q?i3MoP+UYWAQDy/icfFOilw055PS7q5pI4fJaXW4AKDk3o3M6MtEHjhx1eu69?= =?us-ascii?Q?ikF0aBczrWTrzC/deMqTpzPJPzSjwqABWqb+x7CxPe4zyaAa5VM8SQPpTC4F?= =?us-ascii?Q?+ZQLgaMR8o=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 6:Dk3FE8hGbYzLux2A1jDjtfEqFLFRn4NpBqqUrqQzVY6t7belF6UOQPgxj77/oXw8GJtPZi893ABkzkEZZowYMYrLSMIdgm55EVnFZJG5rS81VnH7rrKmg0nAn578pA3BocMXDlC84MpWPBjXzgnp1ebf9CahKsfp5pSF/iIbbLd4Pb1ctyDXCfyfp9yHhor4XXXkUeLs3zD+m0yLaCT7RCGkqASr1QfYOZTdWrce/JSdnch6QJpZaAPGuM+EXmGM4K8OgkzFVfYAqs5zCU3YHnL3sIK94JatIhGz6D2gep5ISQwY4TZbxZDfesp10aJ52tZFGEfEUZ+nYX9U5IBnEd8Ku1aguZ3sf5/AbNNw0Ii9l53SlOOUJsRuavXi1dYgpHqHo3SAHbd92TYpWstM6a/ysD5P5mJ9Dpod0UqY/6PLcSYVE8uGjGgQgxjXzZN4Rf1y2Wm8zJ0FOWhhoHl9HeYYBHry0BVWqMm0f3kRk1adbOCJcNWD8UqB93MLvhRFcxTcJxHoZSx/GbRQUQVtcJtAOW9ebqr9BPLxJty7Td8=; 5:pcgTbBo9MIDoFgDnnxh5tiYwKpRCtYvS3URRzmHDBl+IK8Zw/dPcQOjaEheqdeBcQSUW5vn2p6z4Bh/7J8rnJOtjZO00FEBJdstIL7p1s5edRlyT4soHKMmCn7ncGKQs/KDNTtLeWRysmgyuAEMYYg==; 24:ftvV967GcVcAUHjIiD4PeqGY6iQ5+1F1oKN81dhzNnyHCb8zXg/su+bWCVRWabyZahO/GuHW2yGncWg/s6bzqxuFgrkICGZ0vrau6rw28es= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 7:iEPc3KVglWRVSSxX+w4YvBDTt6L+Qk99wpdWTrFwbsz8Woz8U/LehNQcUjUOKF1nU2r8hsCWP+AbtVJCSSIVzgL40fI4ARqyNp62qALpviswrlDtQe2lDVWZr98UlFQ1jQ2BXGEYQf5Ay7qNaKMZBDl9CSqQP2IVc2nTDYFKR86/01Jgb1/rzJT5+5Z0AZmVUpFlSgurj6yQ7BAkz3Dc50iKCsLyFlOQlFSnOsF76k1XEV220kW6KkcoIT/W2QYujrB4gJriVXFczAa5csVpTynvc0Feo2YsxyyU48zOijO5V6bxRF6P166GAO67v6sL6nZbbgN7bVleyAM7nyn5rQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2017 16:32:12.8384 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2497 Archived-At: Subject: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 16:39:25 -0000 Hi All, IDR working group adoption has been requested for = draft-decraene-idr-next-hop-capability-03. Please send your comments to = the IDR mailing list before June 2, 2017. Please remember that we need = affirmative support in order to adopt the draft, so don't be shy. draft datatracker page: = https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/ slides from IETF-98: = https://www.ietf.org/proceedings/98/slides/slides-98-idr-08-bgp-next-hop-d= ependent-capabilities-00.pdf Since in part this draft specifies a replacement for the Entropy Label = Capability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 = and deprecated by RFC 7447, I have cc'd the MPLS WG mailing list. Since = the proposed new attribute is a generic container with the ELCA = replacement just the first application, the current draft is targeted to = IDR and not MPLS (this was discussed during IETF-93).=20 Thanks, --John= From nobody Thu May 18 09:42:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A1E1287A7; Thu, 18 May 2017 09:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh1WEEYfnHQA; Thu, 18 May 2017 09:42:35 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0118.outbound.protection.outlook.com [104.47.41.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 1C178129A9F; Thu, 18 May 2017 09:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hAkeEpbqDM0OrAde+Yp4TrR12isYLzeSiJCNQpvgc1k=; b=IRuWzW2IKgToSf05nJmY3cgGBO/WXv0Kf6f787rP44EPfjXo370Cz2ZMtTIrFuSih1mYbo2isVeJ29Ei3hiLsoqSzclnahhhTzWYFjt78v9EP3zfqMznmDka4RBmvkzFXPHwsel7S3xJDKEsTsfc9EUNRifYBkb3k+soBDWhFTU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from pboucek-sslvpn-nc.jnpr.net (66.129.241.11) by SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.8; Thu, 18 May 2017 16:34:55 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 May 2017 12:34:51 -0400 Message-ID: CC: , To: idr wg 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: BN6PR11CA0024.namprd11.prod.outlook.com (10.172.17.34) To SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN2PR05MB2511: X-MS-Office365-Filtering-Correlation-Id: 0f24d004-edf5-47b0-7405-08d49e0bd13f X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:SN2PR05MB2511; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 3:Xm2PBLkOowPfmxMC/VRNzqy+oH1jPjPrSlckB+ZUi0PBSNgIzRRUTG1b7JJ0mi3UuY0CT4LJvzR/AVTPbv6B1WrtBt4bIyQWNiaQNJodYYEjIAmF3C1IgdY6a8YguoHOcq1pBOHHmB8B23Fip4nLX8A803WAs49ioVxqeo6RFlDvTDbyoN6kDVNUYT8w4bsP6zYZrVl97QfB6PexGplbran53ZBj3e7ulVwhjqk8GaSOC4QkQs2L1Makdx6qnrzYb0NfZEd7qRXbwzfrij3TMGDD7zSGI+pcYa+TwcgWYSEGamO2dExJbSf0DZkWrBb1s0Yyg920I02DbS6oqvhq5EuArNCkjGRfOxMhS8J7kHk=; 25:ucbNvhUeWEX7zdIHLrWRA0iS9TcDqcHJKsXAS3LfZ2jZGtOy7lHBZ04V/2xk4af+QNOzrf9/sMk54DvxZPS+xsygL09uurhbboVzqhN73AMqlFlzA6nHwsJHU3SfDpnEVP3sa+/WOhZ5toCCxTgjuNXkLKYz4OBVzW9plJacOR9N6+HfwyGb/Gvu1uKet0iCtyLapNLdu/PWc3WDQCtYWr4gqG5J1g55YgOdm7AJQrW4BABxRZi7HtK6qqHlseOMB9Qw+U5MjY4y+s0XH/GrmFkH70lA4AN91PJuZrtlwGZSeXtlr7JBCDiQUuZWvpZO/3WNflYwjKr7R25VzYt0h5mZbEKrKhjp2NprDHCwHVVKEFnB64YxETyy0773ZA0cYekaZB7kr5RFxadtQiM6mP4FelWOaoCvl/voq4PiN9Ul74V/ybJAtFC64FMketBAyoIFkXeRmnM1Fmake879diWGxHbv43e+Uz2OCCUVIWE= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 31:235ymXanjSxf7dax7dKEllPOC5CD9ipPKNIsc6iiGaofaChgizTx5qbQMPnvI1ODq+ZkqzTDdmteyFv0VKFNcVTBhZoJZAKUrRqi2Scc63angXGYH8b5W7JmFstnl8rdWrsjAhcET+RFxeU7WpGFz03FCkKVKShWVqp5oxBr0/aDtxFGA+MNY7jlfrmnauHpfFnbQf9+S7yMBO5sjx+ISpG744Esu7yat2+qr+R4h/NyfpjeoaFteyZjkUer4brB; 20:gEqr5fNg05CBJ5E1QsdyYcznyq6paZoHpeP1xMKioRQe0dx2EHEoUDV/WAtNFZaXvDIcYTrM4ukhplIT25fTxSo9mavNZObb1owKd0fJYQrqEMLsD5hyEgkci1V1JqvTL1ABEB5E6lMdbR12LeCY6m0yyqgAgW1rhvHr20sTijEv8gGvkF4PQojzA2PTqrTAYJbJbvev2a2GH3UafTZjqZKL6UtqiUlwwkf7J5bQwNbCWj3Kw8r++CSiJdLSFzXoz9wl3zGrLvTiZ5JcIh/7vm9CWbYQ6J6fUlgz/yLDyr+CjH2R9imsomLWsIeNuAvMiIynAoelTGzpC/zZmvoNbdK2Wz8vMr6R6UGRYGmUGxWOnvr60HNohOrQF0mjXWXFutlz5FYQP67GC1l3MLJ5OrvyOTbjorcZP4N3B33bRWhBmOcetFxw2wADer/+4LMxR0Imqfx0RdfbrFHUQ7aD5DZwvFgA8lrQ7FpbzolHGY9vuYfFFPQRP995DEGys1oOV1VRL1uhejbXgpXh0Fza2BtDbRMmCoScqDdmTDrjI/1PZlmPXmSK2VtGRGsoiSBsdJ29Bq37ftXMyi8UfLl6ifPyTqCqjNwwE9n86P62Mh8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:SN2PR05MB2511; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2511; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 4:CAGSZ61X6PlT8ZJRzk5sJXzWiDweY99IAPtmDfAWbsLKC7NjldKrbjMENGpKNZY/YPJkZWPlGb8OPjCQU9Vony802B744M+aFYmBq/MtaY41fdi16xdNuLCN46vL/rI2EUYfthoQageT8PyVV0NkorEt1VP53sI0yVf3tZHU4hKrubJZMp0V1TKKO6kJzcEK5/vQ0DmtGyLdXEC4nP8erdh6PgW1nVVu0Y0XA0I7OZogVeC1haZH4qHvTL/LXn2u4mzHyjwoDCqtt/F9bYBy7GLfC6ZD+lP7zFQaRFPuDGgKpGD52mb8Jk6CeBfOSmhlj/VcaAnsNdY/XvJb4glOk5ftq2p1vpOXQnLa0WIT9SPzUpKJXyYj//8KoIfAb7vvVDZdVqkJnGocS9ZBAEQnJ2bIbGhJwb9LfoCps0gRkSKLuDyf5LqDRw4xpnWHoPHpRY5qUorR5tUrVsF8EvUcdHDZGcmQzU0V2NfBFWMATjt0RScaSKX9HPqSmaCaSoWGTX71W8AblDBiD3fG/aF27JZSjkQPDF/0mvXLT2dkUQ1bqLDGrlUN99+e3hAnGBm4pNOwgfe7MxCMlWW4pcRAEprgw90h2KeGvU/SWzKK57IIbBFo4O77gghlRLofDuQ2EdvdSSpEagbr75Mf0IXzKI9do9Y5FwZlOQunp/Ou42uBob/YiJeODX/xP5Q8nsK4lrocUqHmVnUcy043y9Rg3rsiirOfqhYyLTlHlZQnHyGEtj89S7okP451nfBp7CV590X0ZGWCYK2XgFdcmqZkFWaPWxBHUXeAITloTvzjCrV0XAxPJenLwhjMQqNcJGCGVewr3MucF9dnw7eBoE8AGtlh9YlhpIwAL8ikHMHwYRg= X-Forefront-PRVS: 0311124FA9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39840400002)(39860400002)(39850400002)(39450400003)(39400400002)(53754006)(230783001)(25786009)(4326008)(450100002)(6916009)(6666003)(478600001)(36756003)(46406003)(189998001)(66066001)(2906002)(6506006)(53936002)(6306002)(6512007)(54906002)(966005)(6486002)(81166006)(8676002)(8746002)(50226002)(305945005)(33656002)(5660300001)(7736002)(50986999)(38730400002)(110136004)(97756001)(86362001)(23726003)(42186005)(3846002)(6116002)(53416004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2511; H:pboucek-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2511; 23:ij8a+jUiXesY9Bx3cPo90xEsHiV2YH3rtJOerzxM3?= =?us-ascii?Q?0LzA2ogZ3JYKFNAISGDuFDqOIBuVVuDcQce2gQnsQzm3ItLHYA1zMUPkopPV?= =?us-ascii?Q?zVAWQLtcFxW6+1ug3I/TUbLbPG3QJeZFDDvUyrMl4jKGXBAlfuZTrqGIyLul?= =?us-ascii?Q?VcZjYpDUpdX0qta9tvV559BA9Y2Y1KMkpwHj3/5p8gDvEMDMuXjI2Kyow664?= =?us-ascii?Q?vwEyAP6mICSqmlbazlV/hJUXipW43rgHdUAawGf/M7dTVM0eB+ozfYhjHve0?= =?us-ascii?Q?Bg/EGlkHNOv6p/2IE0pn9Ljn2UmkKAvv1myoN/s/d7ngTql2GmUUg2qlcMrO?= =?us-ascii?Q?+T0I41u0HQ2vebDcj89YtR09Answ1Q4tTc5LGytLul19KFYJo9BKJBfg+dYP?= =?us-ascii?Q?vtyZpJkOasNAk8+HdW4T2lJiMYb0d4tSshvDBBZ4ErLvG0kPP71avTiiKIlG?= =?us-ascii?Q?U4yU295tp3YAbogQToHOFehvQ4gxbmHmCMhComn45HJU1cZ52jwLXOREXvWF?= =?us-ascii?Q?2b7DWFWbKD4cVI8kZsR8Wyh6nEDS2mpRfwATW2Npt8gNHVh1EhV8QTYYRb8z?= =?us-ascii?Q?LJtY3r/LJVTSC6crIHZpCq0wbfINc2rAZTiusmp+Ni09ppbpDIK+xgkGdB3C?= =?us-ascii?Q?1FTAqlFKz/giR/bNsdMo4VGFiUW4heGmPH5msRR/LkJe1+mrHu9Zfz9cYnu5?= =?us-ascii?Q?tpqs68zo/VUpTYohbjfLirP1qjCroRaTvPifTtIeE8CFHO6ckLxqV5Hp1A94?= =?us-ascii?Q?do3swwfIhSlFyZDHy7SS51IiK3lIaZOMSPOkZgMR9EBKwkNOFSLwYYOJ/uXS?= =?us-ascii?Q?AmzpJ7NP7PGLn1KNBShyM6StTxkdnC59/bgZU03AO+nygZ9eeYIetAU1DGqj?= =?us-ascii?Q?iR6sljEKHB3WpdxjyYf/XQRyG2IvgiY5eNkaVSgHWPdiJbSunioaNE+EtnjI?= =?us-ascii?Q?1uKyu5OpXvrOURJpZ/uk85MR2SsS5DBzBGxVOaInF/oorcfNRv4+cilv2joq?= =?us-ascii?Q?YafRna35yBQtdce9MB+9nh6a/jFlWsYzTyFgYnNwKrppPI9rpx3PN2pktZs1?= =?us-ascii?Q?OR+KtWMeAgtgYSw3E0j0JLq6LBQL+povpMHH6q5J8DqKvzQXQklqAnPf/u8m?= =?us-ascii?Q?4Slw0vwGiWVkXe6rWL0bKm1FCcAWKY6?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 6:bJrRDABAFyCx6Jj7x32ZAaeuWlWb0JgRVeKgQGyMUGfu4W/A9qgMaYwkv0vBAsFuWOAVgU3kiac7W+RMq0lDds2jGKfYYOrA/0ArYvg99naFTyZl6SW4RPUp4QHPfV26TfZUpCToFfphA5CFLZGkV3kVtXsCwJuRGHdWsJHT4qle7MShx8QJbMyWP4HOcxDazX+UeEBxZzDURDXaqKCNmbCMmj+lEpVLVDjxzeGErruiWE+clOQ49hupirGJPxHsFYzgV5SX6Kcg3mHsr2m6iP0vG9ljyDioFt6zcsdSbdI2rJx5fZI6yOVSm/lNoucYsxQ41sYPc/Us275lVnMOIq9w2GTJuCQSD5M43UVy+3KkBQUJYOQFoGCTFM4Hu/KRIgjsbpM6Pr2L4CuBizXYL9LY2xsjFxf2a+QHxi06bP14QYeKiFmgQ/KrArYQQRaHQjwyQF/voYI6LeZZN8oGLRmM7ZkYqTBeD+eJ0CchJOKETGdUnCfi+VS4ne/P+ImmS854TeHTVOhgAQAA3AUH8ZRdQiPHBpQgBp+t0KqXAQQ=; 5:JxkPyoRyfF4E01qUXMszhqpfw1J+idBDL2UsRDIlap6UymMkt3pYqBXsO/8fXR/9A9Nny+GhjIJ9lKbQvFkyq16UlK4ojZ6fDaBoQWhNuB+96+4us9DFORzfhuYIW9pTbt/vDXiGcm7sJoTLr3JfVQ==; 24:lGmZIyPNaS6pfKZfE211UsD3tuEhJc9evQb2hAGFHcBYnOfLe6iO/5U71ktplQr48/TXQZQ56j5WErXgSSl/+giSEHYpqeCOadAwsBm6XRw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 7:7IrOF1rWsh8geYLzq00cAtfuZ3EjrnBqUJYPXYayoAKr7rnENfzHfSiFw3vSe4eIXaPd5HDsL/+96AWSTTelQ++llFY8CWj94J4IrdXdB4UnbpoEM81QGNtj3yQVsbzvevqnUeHyOpWYSvcRMJ/2+JBrgWGsL3aMJ12alUKbnDcuuKCYGtGF/9/0OSVQUMdYljJO0QgRfikVJ0xTMmrmTojC/0tVmFAEpP9wXZAyvvH5FlKDGx9wplUR+Mgk8bIH+pb9zrOc4n86bCA9LnoEOR6NmAWLIOE30yPfENjj6R6N8ISz/JUXdI9+msmyztOL8kYdl3Td5XXWHdfWcG53Kg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2017 16:34:55.3984 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2511 Archived-At: Subject: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 16:42:38 -0000 [resending, correcting draft@ietf address] Hi All, IDR working group adoption has been requested for = draft-decraene-idr-next-hop-capability-03. Please send your comments to = the IDR mailing list before June 2, 2017. Please remember that we need = affirmative support in order to adopt the draft, so don't be shy. draft datatracker page: = https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/ slides from IETF-98: = https://www.ietf.org/proceedings/98/slides/slides-98-idr-08-bgp-next-hop-d= ependent-capabilities-00.pdf Since in part this draft specifies a replacement for the Entropy Label = Capability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 = and deprecated by RFC 7447, I have cc'd the MPLS WG mailing list. Since = the proposed new attribute is a generic container with the ELCA = replacement just the first application, the current draft is targeted to = IDR and not MPLS (this was discussed during IETF-93).=20 Thanks, --John= From nobody Thu May 18 09:50:22 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AB3129B5B; Thu, 18 May 2017 09:50:14 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 b3-hmPsERPM0; Thu, 18 May 2017 09:50:11 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 B1B03129B11; Thu, 18 May 2017 09:43:54 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v4IGgsLM031596; Thu, 18 May 2017 12:43:36 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 2ahcqh67e3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 May 2017 12:43:36 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4IGhWno001045; Thu, 18 May 2017 12:43:33 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4IGhPwe000876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 May 2017 12:43:29 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 18 May 2017 16:43:17 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.22]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0319.002; Thu, 18 May 2017 12:43:17 -0400 From: "UTTARO, JAMES" To: "John G. Scudder" , "idr@ietf.org" CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@bgp.nu" Thread-Topic: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/VbbtgMRJCYzUCZ6VS0E4P+OKH6S7fg Date: Thu, 18 May 2017 16:43:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.199.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-18_04:, , 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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705180109 Archived-At: Subject: Re: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 16:50:14 -0000 Support.. Jim Uttaro -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Thursday, May 18, 2017 12:32 PM To: idr@ietf.org Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@bgp.nu Subject: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-= capability-03 Hi All, IDR working group adoption has been requested for draft-decraene-idr-next-h= op-capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please remember that we need affirmative support in order to = adopt the draft, so don't be shy. draft datatracker page: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-= 3A__datatracker.ietf.org_doc_draft-2Ddecraene-2Didr-2Dnext-2Dhop-2Dcapabili= ty_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3Ds7ZzB4JbPv3nYuoSx5Gy8Q&m=3DuE= t9VJjdOq8-CRAQO7tO6Nh_vCyKhYyJhsqSbexoXqM&s=3DlHgIBjcYVBRZZK0HaMd0vxoXEUTG2= KYrTSurKXc4kQQ&e=3D=20 slides from IETF-98: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _www.ietf.org_proceedings_98_slides_slides-2D98-2Didr-2D08-2Dbgp-2Dnext-2Dh= op-2Ddependent-2Dcapabilities-2D00.pdf&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjI= g&r=3Ds7ZzB4JbPv3nYuoSx5Gy8Q&m=3DuEt9VJjdOq8-CRAQO7tO6Nh_vCyKhYyJhsqSbexoXq= M&s=3D_q8MPlyS0Hia3dat0d2Hnk59t5roNiWw8MQMA_A9Dwk&e=3D=20 Since in part this draft specifies a replacement for the Entropy Label Capa= bility Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and dep= recated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the propos= ed new attribute is a generic container with the ELCA replacement just the = first application, the current draft is targeted to IDR and not MPLS (this = was discussed during IETF-93).=20 Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_idr&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3Ds7ZzB4JbPv3nYuoSx5G= y8Q&m=3DuEt9VJjdOq8-CRAQO7tO6Nh_vCyKhYyJhsqSbexoXqM&s=3DCxg9u0gjAhIpPkWIKjD= lSKDLNtsKfnxk2R4kaVnjFjA&e=3D=20 From nobody Thu May 18 11:53:29 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0708012420B; Thu, 18 May 2017 11:53:28 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 UPCI8_50niGP; Thu, 18 May 2017 11:53:26 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 B980912EB1A; Thu, 18 May 2017 11:48:22 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id f27so6703645pfe.0; Thu, 18 May 2017 11:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kpRIb8omIABQFqQf3LnKigb3FP/MPO+fxJdzRvztEYc=; b=KkCW7dc7gwRz+4ohaU4tbiMlZcLLWNgbm00LoBQhY2Bmj795FF4+lRlH8kBtnOQ5JB TmNpXN9tGXw4T3HEwsFj2HqCbeuViEqd35fn1NbcNwYu5umlO02s07+1lVilXU0hFOKe LN+RUToHqvrs8ssxsu8dgf/aM3KBC/O6Q98nTFf0XNMm4STPcXSjKqGv2Bg/KlF4Cznf QFlmfy5AtU0adF7X3iT7vMZXqOab01XnmaYRxiZml1Qe/RirmSAhRYFRdl/cMLJ3dYK7 LeMK8uiCYD34aWEiL/fWwaQ3nbaSFTWSfhPRPEy4Fj/tvsLGJNidVYrqRjBRtZahqc27 +nuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kpRIb8omIABQFqQf3LnKigb3FP/MPO+fxJdzRvztEYc=; b=APei/Lu5JlAsYRL+PQAwHA03P9KRM4ychBczxXeNVgnJTuO1gWJM9Zi4kquLUVBjEk zbrtpI2uKxLFLZTwu9dCare/KRMoL9N57WfQwAeJQ91t/+wmOHAEu8TzOHVJF5GQAFxW GprQFE+Haiu4cyu9nK6fVGLnJFg/mlLG3BdR8iI9rCg/KH2e//r3LQGFOARQZX+q5wA9 hbIXMYvLvi/eOoIGQt5+HVPGK7BQ/azGe0/MpQE10JXzpzW/O2XwhFJMS7p2El4lqojh Z5hICiwa9sCSxMylp8Ap0sMZs9kvofWW+jXDRFU5LocXCRSm89S2bi2+9gdZNNtp7cJP XNEQ== X-Gm-Message-State: AODbwcD4xeHev9kpP0UhUrfLplAwPOHCBqIjxqyLJPyTty29KaN278rI uq0HRN14VmjbANWSHcc= X-Received: by 10.98.138.150 with SMTP id o22mr6056854pfk.120.1495133301861; Thu, 18 May 2017 11:48:21 -0700 (PDT) Received: from ?IPv6:2607:fb90:21a2:5f1d:92e:2836:e74a:ae21? ([2607:fb90:21a2:5f1d:92e:2836:e74a:ae21]) by smtp.gmail.com with ESMTPSA id x80sm12213118pff.105.2017.05.18.11.48.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 11:48:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (14E304) In-Reply-To: Date: Thu, 18 May 2017 11:48:18 -0700 Cc: idr wg , mpls@ietf.org, draft-decraene-idr-next-hop-capability@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <74A5B0E5-5526-454F-B11F-52B8BBFB7500@gmail.com> References: To: "John G.Scudder" Archived-At: Subject: Re: [Idr] [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 18:53:28 -0000 John, Yes/support Regards, Jeff > On May 18, 2017, at 09:34, John G.Scudder wrote: >=20 > [resending, correcting draft@ietf address] >=20 > Hi All, >=20 > IDR working group adoption has been requested for draft-decraene-idr-next-= hop-capability-03. Please send your comments to the IDR mailing list before J= une 2, 2017. Please remember that we need affirmative support in order to ad= opt the draft, so don't be shy. >=20 > draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-id= r-next-hop-capability/ > slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98-= idr-08-bgp-next-hop-dependent-capabilities-00.pdf >=20 > Since in part this draft specifies a replacement for the Entropy Label Cap= ability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and dep= recated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the propose= d new attribute is a generic container with the ELCA replacement just the fi= rst application, the current draft is targeted to IDR and not MPLS (this was= discussed during IETF-93).=20 >=20 > Thanks, >=20 > --John > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu May 18 12:38:37 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E07E129BCE; Thu, 18 May 2017 12:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 XAKMT-hU-r4T; Thu, 18 May 2017 12:38:26 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0120.outbound.protection.outlook.com [104.47.1.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF0D129C39; Thu, 18 May 2017 12:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pU0drFTAxOpm9t4+JUKRj32PUuqEWUGGu/J2lU0NWGo=; b=QLPlGD8GhElPSQ9NB6EXxUb3Dvx2woCeKPxI9aTcw0NN5m3e6TNf2BWXFMLfmRy3a9pS2IeS/+2XBCHg8L/yoYBTr3wxl6E/h1eOaAWIKk1+MTVZzSTfkcKDyxNvB+QudriZkjZOzAzLJSeh5YGYeCg8rbXF0vQpxnVnlakfqS8= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0963.eurprd07.prod.outlook.com (10.162.37.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Thu, 18 May 2017 19:32:43 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::8ca8:abc5:c3c7:9d6d]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::8ca8:abc5:c3c7:9d6d%15]) with mapi id 15.01.1124.007; Thu, 18 May 2017 19:32:43 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: "John G. Scudder" , "idr@ietf.org" CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@bgp.nu" Thread-Topic: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/VTfsG4m8/9b0SvgXKKVya+jKH6ex4h Date: Thu, 18 May 2017 19:32:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [13.69.77.72] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0963; 7:Q6g/PDd4Js7rM75Ycg5P8KzKwBULoUXzTGdUB9A8xFt+FxlRG50KUQgX3IdTsNp0NA/bng7yZQXqp5SDwtShj4fmo4IOFSv+r7/GAKeN6BmRGLCrMQe9rZLqphNQVRFScOd7/ACL7r5jvxRNwst4CFCYWMtXZH1Krm4X3pLHcuGaohrxtHL9NEZrOTjvoQ11lvb2Ctjjt4QuGWkArVcikCQJmd5s/5fhcMKNIy2+sRNg5jtaAak1p7JB9pRhKTtqGuM22Zo26MBowcWFC9UYg75y+uwlD/leaSmDMu+MpsAdC+UGqZRypEaATQAjKa7xrf8VAvXhpUfNyaXm5oeDHA== x-ms-traffictypediagnostic: AM2PR07MB0963: x-ms-office365-filtering-correlation-id: 6cccd0cf-45be-439e-4e9b-08d49e24a760 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM2PR07MB0963; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(138986009662008)(81439100147899); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(6072148); SRVR:AM2PR07MB0963; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0963; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39840400002)(39450400003)(39860400002)(377454003)(53754006)(8936002)(66066001)(53936002)(3846002)(2501003)(99286003)(6116002)(102836003)(55016002)(8666007)(966005)(2906002)(3280700002)(33656002)(230783001)(189998001)(3660700001)(6246003)(606005)(6306002)(45080400002)(74316002)(38730400002)(7696004)(25786009)(53546009)(229853002)(6436002)(478600001)(76176999)(54356999)(7736002)(2950100002)(7906003)(50986999)(8676002)(81166006)(4326008)(86362001)(54896002)(6506006)(5250100002)(9686003)(54906002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0963; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0961C7CEDDBC9B1E33CA1EDC83E40AM2PR07MB0961eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2017 19:32:42.9419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0963 Archived-At: Subject: Re: [Idr] [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 19:38:28 -0000 --_000_AM2PR07MB0961C7CEDDBC9B1E33CA1EDC83E40AM2PR07MB0961eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as coauthor Get Outlook for iOS ________________________________ From: mpls on behalf of John G. Scudder Sent: Thursday, May 18, 2017 6:32:09 PM To: idr@ietf.org Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@bgp.nu Subject: [mpls] Working Group adoption call for draft-decraene-idr-next-hop= -capability-03 Hi All, IDR working group adoption has been requested for draft-decraene-idr-next-h= op-capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please remember that we need affirmative support in order to = adopt the draft, so don't be shy. draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-idr= -next-hop-capability/ slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98-i= dr-08-bgp-next-hop-dependent-capabilities-00.pdf Since in part this draft specifies a replacement for the Entropy Label Capa= bility Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and dep= recated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the propos= ed new attribute is a generic container with the ELCA replacement just the = first application, the current draft is targeted to IDR and not MPLS (this = was discussed during IETF-93). Thanks, --John _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_AM2PR07MB0961C7CEDDBC9B1E33CA1EDC83E40AM2PR07MB0961eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support as coauthor

Get Ou= tlook for iOS
From: mpls <mpls-bounc= es@ietf.org> on behalf of John G. Scudder <jgs@juniper.net>
Sent: Thursday, May 18, 2017 6:32:09 PM
To: idr@ietf.org
Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@bgp.nu
Subject: [mpls] Working Group adoption call for draft-decraene-idr-n= ext-hop-capability-03
 
Hi All,

IDR working group adoption has been requested for draft-decraene-idr-next-h= op-capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please remember that we need affirmative support in order to = adopt the draft, so don't be shy.

draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/
slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98-idr-08-bgp-next-hop-de= pendent-capabilities-00.pdf

Since in part this draft specifies a replacement for the Entropy Label Capa= bility Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and dep= recated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the propos= ed new attribute is a generic container with the ELCA replacement just the first application, the current draft is= targeted to IDR and not MPLS (this was discussed during IETF-93).

Thanks,

--John
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org= /mailman/listinfo/mpls
 --_000_AM2PR07MB0961C7CEDDBC9B1E33CA1EDC83E40AM2PR07MB0961eurp_-- From nobody Thu May 18 20:42:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD6C12EC93; Thu, 18 May 2017 20:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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.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 0iYNT4Vuvsj0; Thu, 18 May 2017 20:42:47 -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 5331912EC05; Thu, 18 May 2017 20:36:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNI51776; Fri, 19 May 2017 03:36:31 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 19 May 2017 04:36:30 +0100 Received: from DGGEML508-MBX.china.huawei.com ([169.254.3.58]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Fri, 19 May 2017 11:36:24 +0800 From: Mach Chen To: "John G.Scudder" , idr wg CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" Thread-Topic: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/XO6alx6m5qqUe3FpQYrOWE/aH7AbaQ Date: Fri, 19 May 2017 03:36:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.591E6840.0065, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.58, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1ada34d609d191a64797e5ab1479bf87 Archived-At: Subject: Re: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 03:42:49 -0000 Hi John, I have read the draft and think it's useful, support the adoption! Best regards, Mach > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G.Scudder > Sent: Friday, May 19, 2017 12:35 AM > To: idr wg > Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@ietf.org > Subject: [Idr] Working Group adoption call for draft-decraene-idr-next-ho= p- > capability-03 >=20 > [resending, correcting draft@ietf address] >=20 > Hi All, >=20 > IDR working group adoption has been requested for draft-decraene-idr- > next-hop-capability-03. Please send your comments to the IDR mailing list > before June 2, 2017. Please remember that we need affirmative support in > order to adopt the draft, so don't be shy. >=20 > draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-i= dr- > next-hop-capability/ > slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98= - > idr-08-bgp-next-hop-dependent-capabilities-00.pdf >=20 > Since in part this draft specifies a replacement for the Entropy Label > Capability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 a= nd > deprecated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the > proposed new attribute is a generic container with the ELCA replacement > just the first application, the current draft is targeted to IDR and not = MPLS > (this was discussed during IETF-93). >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu May 18 23:19:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEC5128959; Thu, 18 May 2017 23:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, 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 iZVPqeAghDEU; Thu, 18 May 2017 23:19:22 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06527129B4C; Thu, 18 May 2017 23:15:17 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 5C8DFC070E; Fri, 19 May 2017 08:15:15 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 365704005B; Fri, 19 May 2017 08:15:15 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0339.000; Fri, 19 May 2017 08:15:14 +0200 From: To: "John G. Scudder" , "idr@ietf.org" CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@bgp.nu" Thread-Topic: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/VUMuKlyuGzfEiqqaYW51iPraH7LoQw Date: Fri, 19 May 2017 06:15:14 +0000 Message-ID: <16074_1495174515_591E8D73_16074_7054_1_88132E969123D14D9BD844E1CD516EDE1435D575@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 06:19:24 -0000 Hi, Support. Cheers, Christian. -----Message d'origine----- De=A0: mpls [mailto:mpls-bounces@ietf.org] De la part de John G. Scudder Envoy=E9=A0: jeudi 18 mai 2017 18:32 =C0=A0: idr@ietf.org Cc=A0: mpls@ietf.org; draft-decraene-idr-next-hop-capability@bgp.nu Objet=A0: [mpls] Working Group adoption call for draft-decraene-idr-next-ho= p-capability-03 Hi All, IDR working group adoption has been requested for draft-decraene-idr-next-h= op-capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please remember that we need affirmative support in order to = adopt the draft, so don't be shy. draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-idr= -next-hop-capability/ slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98-i= dr-08-bgp-next-hop-dependent-capabilities-00.pdf Since in part this draft specifies a replacement for the Entropy Label Capa= bility Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and dep= recated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the propos= ed new attribute is a generic container with the ELCA replacement just the = first application, the current draft is targeted to IDR and not MPLS (this = was discussed during IETF-93).=20 Thanks, --John _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ 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 May 18 23:54:32 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB93127775; Thu, 18 May 2017 23:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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, RP_MATCHES_RCVD=-0.001, 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 4wY6xjAGO3gx; Thu, 18 May 2017 23:54:29 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.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 2382B12EB9B; Thu, 18 May 2017 23:49:58 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 9159D1C03D8; Fri, 19 May 2017 08:49:56 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 6C9854004C; Fri, 19 May 2017 08:49:56 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0339.000; Fri, 19 May 2017 08:49:56 +0200 From: To: John G.Scudder , idr wg CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" Thread-Topic: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/XFR+Oe8TWL5EePssWVkm2tf6H7OE7A Date: Fri, 19 May 2017 06:49:54 +0000 Message-ID: <30171_1495176596_591E9594_30171_3117_1_9E32478DFA9976438E7A22F69B08FF921DDBB1C0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 06:54:31 -0000 Support -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of John G.Scudder Sent: Thursday, May 18, 2017 18:35 To: idr wg Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@ietf.org Subject: [mpls] Working Group adoption call for draft-decraene-idr-next-hop= -capability-03 [resending, correcting draft@ietf address] Hi All, IDR working group adoption has been requested for draft-decraene-idr-next-h= op-capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please remember that we need affirmative support in order to = adopt the draft, so don't be shy. draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-idr= -next-hop-capability/ slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98-i= dr-08-bgp-next-hop-dependent-capabilities-00.pdf Since in part this draft specifies a replacement for the Entropy Label Capa= bility Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and dep= recated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the propos= ed new attribute is a generic container with the ELCA replacement just the = first application, the current draft is targeted to IDR and not MPLS (this = was discussed during IETF-93).=20 Thanks, --John _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ 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 Fri May 19 00:05:03 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6216C129521; Fri, 19 May 2017 00:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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.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 xGUgFURvyWIQ; Fri, 19 May 2017 00:04:58 -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 C7AD012943E; Thu, 18 May 2017 23:59:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGX30328; Fri, 19 May 2017 06:59:57 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 19 May 2017 07:59:56 +0100 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; Fri, 19 May 2017 14:59:49 +0800 From: Lizhenbin To: "John G.Scudder" , idr wg CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" Thread-Topic: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHS0FIOt4Cv3ITG7EuOJlGgfY6Dj6H7OhCw Date: Fri, 19 May 2017 06:59:49 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8DF08365@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.76.77] 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.0A020206.591E97ED.0067, 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: 3a10ae5535c0fae47502216cb648b2a1 Archived-At: Subject: [Idr] =?gb2312?b?tPC4tDogIFdvcmtpbmcgR3JvdXAgYWRvcHRpb24gY2FsbCBm?= =?gb2312?b?b3IgZHJhZnQtZGVjcmFlbmUtaWRyLW5leHQtaG9wLWNhcGFiaWxpdHktMDM=?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 07:05:00 -0000 SGksDQoNClN1cHBvcnQuDQoNCkJlc3QgUmVnYXJkcywNClpoZW5iaW4oUm9iaW4pDQoNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gRy5TY3VkZGVyDQo+IFNlbnQ6IEZyaWRheSwg TWF5IDE5LCAyMDE3IDEyOjM1IEFNDQo+IFRvOiBpZHIgd2cgPGlkckBpZXRmLm9yZz4NCj4gQ2M6 IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWRlY3JhZW5lLWlkci1uZXh0LWhvcC1jYXBhYmlsaXR5QGll dGYub3JnDQo+IFN1YmplY3Q6IFtJZHJdIFdvcmtpbmcgR3JvdXAgYWRvcHRpb24gY2FsbCBmb3Ig DQo+IGRyYWZ0LWRlY3JhZW5lLWlkci1uZXh0LWhvcC0NCj4gY2FwYWJpbGl0eS0wMw0KPiANCj4g W3Jlc2VuZGluZywgY29ycmVjdGluZyBkcmFmdEBpZXRmIGFkZHJlc3NdDQo+IA0KPiBIaSBBbGws DQo+IA0KPiBJRFIgd29ya2luZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9y IGRyYWZ0LWRlY3JhZW5lLWlkci0gDQo+IG5leHQtaG9wLWNhcGFiaWxpdHktMDMuIFBsZWFzZSBz ZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIElEUiBtYWlsaW5nIA0KPiBsaXN0IGJlZm9yZSBKdW5l IDIsIDIwMTcuIFBsZWFzZSByZW1lbWJlciB0aGF0IHdlIG5lZWQgYWZmaXJtYXRpdmUgDQo+IHN1 cHBvcnQgaW4gb3JkZXIgdG8gYWRvcHQgdGhlIGRyYWZ0LCBzbyBkb24ndCBiZSBzaHkuDQo+IA0K PiBkcmFmdCBkYXRhdHJhY2tlciBwYWdlOiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZGVjcmFlbmUtaWRyLQ0KPiBuZXh0LWhvcC1jYXBhYmlsaXR5Lw0KPiBzbGlk ZXMgZnJvbSBJRVRGLTk4OiANCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgv c2xpZGVzL3NsaWRlcy05OC0NCj4gaWRyLTA4LWJncC1uZXh0LWhvcC1kZXBlbmRlbnQtY2FwYWJp bGl0aWVzLTAwLnBkZg0KPiANCj4gU2luY2UgaW4gcGFydCB0aGlzIGRyYWZ0IHNwZWNpZmllcyBh IHJlcGxhY2VtZW50IGZvciB0aGUgRW50cm9weSBMYWJlbCANCj4gQ2FwYWJpbGl0eSBBdHRyaWJ1 dGUgKEVMQ0EpIHRoYXQgd2FzIGRlZmluZWQgYnkgdGhlIE1QTFMgV0cgaW4gUkZDIA0KPiA2Nzkw IGFuZCBkZXByZWNhdGVkIGJ5IFJGQyA3NDQ3LCBJIGhhdmUgY2MnZCB0aGUgTVBMUyBXRyBtYWls aW5nIGxpc3QuIA0KPiBTaW5jZSB0aGUgcHJvcG9zZWQgbmV3IGF0dHJpYnV0ZSBpcyBhIGdlbmVy aWMgY29udGFpbmVyIHdpdGggdGhlIEVMQ0EgDQo+IHJlcGxhY2VtZW50IGp1c3QgdGhlIGZpcnN0 IGFwcGxpY2F0aW9uLCB0aGUgY3VycmVudCBkcmFmdCBpcyB0YXJnZXRlZCANCj4gdG8gSURSIGFu ZCBub3QgTVBMUyAodGhpcyB3YXMgZGlzY3Vzc2VkIGR1cmluZyBJRVRGLTkzKS4NCj4gDQo+IFRo YW5rcywNCj4gDQo+IC0tSm9obg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K From nobody Fri May 19 07:35:52 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75A5128616; Fri, 19 May 2017 07:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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, RP_MATCHES_RCVD=-0.001, 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 5HkPk6g7opTa; Fri, 19 May 2017 07:35:42 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.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 48F181286AB; Fri, 19 May 2017 07:35:42 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id E8F1A16047E; Fri, 19 May 2017 16:35:40 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id C3A5E18006C; Fri, 19 May 2017 16:35:40 +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.0339.000; Fri, 19 May 2017 16:35:40 +0200 From: To: John G.Scudder , idr wg CC: "draft-decraene-idr-next-hop-capability@ietf.org" , "mpls@ietf.org" Thread-Topic: Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/XDMEbdgHHx3UaZwRey+FXRtKH7uesw Date: Fri, 19 May 2017 14:35:39 +0000 Message-ID: <31901_1495204540_591F02BC_31901_10655_1_53C29892C857584299CBF5D05346208A31D1D7CA@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: In-Reply-To: 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: Subject: Re: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 14:35:44 -0000 Support as coauthor > -----Original Message----- > From: John G.Scudder [mailto:jgs@juniper.net] > Sent: Thursday, May 18, 2017 6:35 PM > To: idr wg > Cc: draft-decraene-idr-next-hop-capability@ietf.org; mpls@ietf.org > Subject: Working Group adoption call for draft-decraene-idr-next-hop-cap= ability-03 >=20 > [resending, correcting draft@ietf address] >=20 > Hi All, >=20 > IDR working group adoption has been requested for draft-decraene-idr-nex= t-hop- > capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please > remember that we need affirmative support in order to adopt the draft, s= o don't be shy. >=20 > draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-= idr-next-hop- > capability/ > slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-9= 8-idr-08-bgp-next- > hop-dependent-capabilities-00.pdf >=20 > Since in part this draft specifies a replacement for the Entropy Label C= apability Attribute > (ELCA) that was defined by the MPLS WG in RFC 6790 and deprecated by RFC= 7447, I have > cc'd the MPLS WG mailing list. Since the proposed new attribute is a gen= eric container with > the ELCA replacement just the first application, the current draft is ta= rgeted to IDR and not > MPLS (this was discussed during IETF-93). >=20 > Thanks, >=20 > --John ___________________________________________________________________________= ______________________________________________ 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 Fri May 19 08:40:53 2017 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 E8FA2127A90; Fri, 19 May 2017 08:40:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149520844486.30807.5431009493565553853@ietfa.amsl.com> Date: Fri, 19 May 2017 08:40:44 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-attribute-announcement-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 15:40:45 -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 : Constrain Attribute announcement within BGP Authors : Keyur Patel James Uttaro Bruno Decraene Wim Henderickx Jeff Haas Filename : draft-ietf-idr-bgp-attribute-announcement-01.txt Pages : 9 Date : 2017-05-18 Abstract: [RFC4271] defines four different categories of BGP Path attributes. The different Path attribute categories can be identified by the attribute flag values. These flags help identify if an attribute is optional or well-known, Transitive or non-Transitive, Partial, or of an Extended length type. BGP attribute announcement depends on whether an attribute is a well-known or optional, and whether an attribute is a transitive or non-transitive. BGP implementations MUST recognize all well-known attributes. The well-known attributes are always Transitive. It is not required for BGP implementations to recognise all the Optional attributes. The Optional attributes could be Transitive or Non-Transitive. BGP implementations MUST store and forward any Unknown Optional Transitive attributes and ignore and drop any Unknown Optional Non-Transitive attributes. Currently, there is no way to confine the scope of Path attributes within a given Autonomous System (AS) or a given BGP member-AS in Confederation. This draft defines attribute extensions that help confine the scope of Optional attributes within a given AS or a given BGP member-AS in Confederation The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-attribute-announcement/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-attribute-announcement-01 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-attribute-announcement-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-attribute-announcement-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 Fri May 19 17:43:17 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4289A129B50; Fri, 19 May 2017 17:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.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 UWLFkXRqov0Q; Fri, 19 May 2017 17:43:05 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0041.outbound.protection.outlook.com [104.47.34.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F807129524; Fri, 19 May 2017 17:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IBbB9v9qPJYR7GCQN8KT721TFgjbB4GallD348OpObo=; b=H8CzXHlI/pji3qnHSv4RO5H9LXFVxlotpT4yyR4Aedy/n6/Rnz/v+XHin5Fqwx1EUbpA+h87rep4WMobpgnJCU8KAmSPEzJqOPvIA9WrOHRHACmmXpC1tHqnTu2Kp+YTz9q3azURa6FztaHPGB+6V6z3YyykqXJaPPsKeeLLT0Y= Received: from CY4PR18MB1127.namprd18.prod.outlook.com (10.173.184.14) by CY4PR18MB1125.namprd18.prod.outlook.com (10.173.184.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Sat, 20 May 2017 00:43:03 +0000 Received: from CY4PR18MB1127.namprd18.prod.outlook.com ([10.173.184.14]) by CY4PR18MB1127.namprd18.prod.outlook.com ([10.173.184.14]) with mapi id 15.01.1101.019; Sat, 20 May 2017 00:43:03 +0000 From: Keyur Patel To: "bruno.decraene@orange.com" , John G.Scudder , idr wg CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" Thread-Topic: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHS0QIJYQaYgmju5kW1w24bFzBjqA== Date: Sat, 20 May 2017 00:43:03 +0000 Message-ID: <921E0107-5131-42CC-9EFC-E9A914D9C2FB@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [2601:646:8981:c940:a562:f602:c222:98fd] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR18MB1125; 7:E8EwjOZhKSRGXj7BZMCJWD/gABKqBM8+4utRt/bSTh/nGnLa28nIQSWNiAlDTJi/wsf0VNmI9/4MzCjT5zHNLwZCrs25x8Up2wk9DKOZmFjMJeX78uvvSfhXVVbW+OIEP/N6I312/AjXvshuPyi0slks1OMiLJpjFi/oBkuhzZMTsNvnq9FPJF37nVrOGJPA+/DdPm9oCZWrBY9ulkMbeuDtN/b2PV+q7aYbV6/tngpMiLO++TuIyIdGHNzew5SmyOwABgO8PPo9i7KukLeEsVHOqL2bpZ/zcr8q8+f8BcTCdANWlKvEOQaCG1T2RXM+91SqrrI+13108+KUQ+aA4A== x-ms-traffictypediagnostic: CY4PR18MB1125: x-ms-office365-filtering-correlation-id: d0dc4fce-9e9a-45c6-a1e9-08d49f192c4b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201702281549075); SRVR:CY4PR18MB1125; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201703061421075)(20161123564025)(2016111802025)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(6043046)(6072148); SRVR:CY4PR18MB1125; BCL:0; PCL:0; RULEID:; SRVR:CY4PR18MB1125; x-forefront-prvs: 03137AC81E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(13464003)(24454002)(377454003)(53754006)(6506006)(6436002)(8666007)(54906002)(6512007)(966005)(81166006)(53936002)(99286003)(8676002)(6246003)(189998001)(8936002)(82746002)(6306002)(38730400002)(305945005)(122556002)(229853002)(508600001)(86362001)(230783001)(36756003)(50986999)(3280700002)(102836003)(6116002)(54356999)(83716003)(5660300001)(77096006)(6486002)(2900100001)(25786009)(53546009)(4326008)(2906002)(2501003)(1941001)(33656002)(3660700001)(5890100001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR18MB1125; H:CY4PR18MB1127.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8732224DEFEF7E45A235D451DBB3AE27@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2017 00:43:03.1574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR18MB1125 Archived-At: Subject: Re: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 00:43:08 -0000 U3VwcG9ydC4gSG93ZXZlciwgSXQgd291bGQgYmUgZ3JlYXQgaWYgdGhlIGF0dHJpYnV0ZSBmb3Jt YXQgYWRvcHRzIG5ldyBhdHRyaWJ1dGUgZGVmaW5pdGlvbiBvZiA6IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWJncC1hdHRyaWJ1dGUtYW5ub3VuY2VtZW50 Lw0KDQpUaGlzIHdpbGwgaGVscCBzY29wZSB0aGUgYXR0cmlidXRlIGFubm91bmNlbWVudHMuDQoN ClJlZ2FyZHMsDQpLZXl1cg0KDQpPbiA1LzE5LzE3LCA3OjM1IEFNLCAiSWRyIG9uIGJlaGFsZiBv ZiBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIiA8aWRyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+IHdyb3RlOg0KDQogICAgU3VwcG9ydCBh cyBjb2F1dGhvcg0KICAgIA0KICAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAg ID4gRnJvbTogSm9obiBHLlNjdWRkZXIgW21haWx0bzpqZ3NAanVuaXBlci5uZXRdDQogICAgID4g U2VudDogVGh1cnNkYXksIE1heSAxOCwgMjAxNyA2OjM1IFBNDQogICAgID4gVG86IGlkciB3Zw0K ICAgICA+IENjOiBkcmFmdC1kZWNyYWVuZS1pZHItbmV4dC1ob3AtY2FwYWJpbGl0eUBpZXRmLm9y ZzsgbXBsc0BpZXRmLm9yZw0KICAgICA+IFN1YmplY3Q6IFdvcmtpbmcgR3JvdXAgYWRvcHRpb24g Y2FsbCBmb3IgZHJhZnQtZGVjcmFlbmUtaWRyLW5leHQtaG9wLWNhcGFiaWxpdHktMDMNCiAgICAg PiANCiAgICAgPiBbcmVzZW5kaW5nLCBjb3JyZWN0aW5nIGRyYWZ0QGlldGYgYWRkcmVzc10NCiAg ICAgPiANCiAgICAgPiBIaSBBbGwsDQogICAgID4gDQogICAgID4gSURSIHdvcmtpbmcgZ3JvdXAg YWRvcHRpb24gaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1kZWNyYWVuZS1pZHItbmV4dC1o b3AtDQogICAgID4gY2FwYWJpbGl0eS0wMy4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0 aGUgSURSIG1haWxpbmcgbGlzdCBiZWZvcmUgSnVuZSAyLCAyMDE3LiBQbGVhc2UNCiAgICAgPiBy ZW1lbWJlciB0aGF0IHdlIG5lZWQgYWZmaXJtYXRpdmUgc3VwcG9ydCBpbiBvcmRlciB0byBhZG9w dCB0aGUgZHJhZnQsIHNvIGRvbid0IGJlIHNoeS4NCiAgICAgPiANCiAgICAgPiBkcmFmdCBkYXRh dHJhY2tlciBwYWdlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kZWNy YWVuZS1pZHItbmV4dC1ob3AtDQogICAgID4gY2FwYWJpbGl0eS8NCiAgICAgPiBzbGlkZXMgZnJv bSBJRVRGLTk4OiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85OC9zbGlkZXMvc2xp ZGVzLTk4LWlkci0wOC1iZ3AtbmV4dC0NCiAgICAgPiBob3AtZGVwZW5kZW50LWNhcGFiaWxpdGll cy0wMC5wZGYNCiAgICAgPiANCiAgICAgPiBTaW5jZSBpbiBwYXJ0IHRoaXMgZHJhZnQgc3BlY2lm aWVzIGEgcmVwbGFjZW1lbnQgZm9yIHRoZSBFbnRyb3B5IExhYmVsIENhcGFiaWxpdHkgQXR0cmli dXRlDQogICAgID4gKEVMQ0EpIHRoYXQgd2FzIGRlZmluZWQgYnkgdGhlIE1QTFMgV0cgaW4gUkZD IDY3OTAgYW5kIGRlcHJlY2F0ZWQgYnkgUkZDIDc0NDcsIEkgaGF2ZQ0KICAgICA+IGNjJ2QgdGhl IE1QTFMgV0cgbWFpbGluZyBsaXN0LiBTaW5jZSB0aGUgcHJvcG9zZWQgbmV3IGF0dHJpYnV0ZSBp cyBhIGdlbmVyaWMgY29udGFpbmVyIHdpdGgNCiAgICAgPiB0aGUgRUxDQSByZXBsYWNlbWVudCBq dXN0IHRoZSBmaXJzdCBhcHBsaWNhdGlvbiwgdGhlIGN1cnJlbnQgZHJhZnQgaXMgdGFyZ2V0ZWQg dG8gSURSIGFuZCBub3QNCiAgICAgPiBNUExTICh0aGlzIHdhcyBkaXNjdXNzZWQgZHVyaW5nIElF VEYtOTMpLg0KICAgICA+IA0KICAgICA+IFRoYW5rcywNCiAgICAgPiANCiAgICAgPiAtLUpvaG4N CiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgDQogICAgQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQogICAgcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCiAgICBhIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0K ICAgIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCiAgICANCiAgICBUaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KICAgIHRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLg0KICAgIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLg0KICAgIEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC4NCiAgICBUaGFuayB5b3UuDQogICAgDQogICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBJZHIgbWFpbGluZyBsaXN0DQogICAg SWRyQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZHINCiAgICANCg0K From nobody Fri May 19 17:48:59 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3421293D9; Fri, 19 May 2017 17:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 k_wPo8O3Wv_2; Fri, 19 May 2017 17:48:47 -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 7D5ED126BF6; Fri, 19 May 2017 17:48:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGY49517; Sat, 20 May 2017 00:48:44 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 20 May 2017 01:48:43 +0100 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; Sat, 20 May 2017 08:48:38 +0800 From: "Dongjie (Jimmy)" To: "John G.Scudder" , idr wg CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" Thread-Topic: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/XUX67d8sloskeDYSDEq7Y1FqH8ZX+A Date: Sat, 20 May 2017 00:48:38 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927936BBA12@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.591F926C.005C, 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: 1ea2c9a9dd395df487029a298745cbb0 Archived-At: Subject: Re: [Idr] [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 00:48:50 -0000 Support the adoption.=20 -Jie > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of John G.Scudder > Sent: Friday, May 19, 2017 12:35 AM > To: idr wg > Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@ietf.org > Subject: [mpls] Working Group adoption call for > draft-decraene-idr-next-hop-capability-03 >=20 > [resending, correcting draft@ietf address] >=20 > Hi All, >=20 > IDR working group adoption has been requested for > draft-decraene-idr-next-hop-capability-03. Please send your comments to t= he > IDR mailing list before June 2, 2017. Please remember that we need > affirmative support in order to adopt the draft, so don't be shy. >=20 > draft datatracker page: > https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/ > slides from IETF-98: > https://www.ietf.org/proceedings/98/slides/slides-98-idr-08-bgp-next-hop-= d > ependent-capabilities-00.pdf >=20 > Since in part this draft specifies a replacement for the Entropy Label > Capability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 > and deprecated by RFC 7447, I have cc'd the MPLS WG mailing list. Since t= he > proposed new attribute is a generic container with the ELCA replacement j= ust > the first application, the current draft is targeted to IDR and not MPLS = (this > was discussed during IETF-93). >=20 > Thanks, >=20 > --John > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sat May 20 02:39:41 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E8C128990 for ; Sat, 20 May 2017 02:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.647 X-Spam-Level: *** X-Spam-Status: No, score=3.647 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 f6-pu2ixVJ_h for ; Sat, 20 May 2017 02:39:39 -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 7BA05127333 for ; Sat, 20 May 2017 02:39:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.14.72; From: "Susan Hares" To: "'idr wg'" Date: Sat, 20 May 2017 05:33:52 -0400 Message-ID: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01D2D12A.ABDB8E10" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdLRTCaZKPuw1yo2RQSbPHINWp1hYA== X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017). X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 09:39:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001F_01D2D12A.ABDB8E10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017) The authors should indicate if they know of any IPR related to this document. You can find the document at: https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/ Sue Hares ------=_NextPart_000_001F_01D2D12A.ABDB8E10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy = (5/20 to 6/3/2017)

 

The authors = should indicate if they know of any IPR related to this document. =  You can find the document at:

 

https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/

 

Sue Hares

 

=

------=_NextPart_000_001F_01D2D12A.ABDB8E10-- From nobody Sat May 20 12:40:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DAF1292AE; Sat, 20 May 2017 12:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0whlIItKAD_d; Sat, 20 May 2017 12:40:11 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0135.outbound.protection.outlook.com [104.47.42.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 34E28126C25; Sat, 20 May 2017 12:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UPuJx4GUm5FP2q8NV0DUWc8LuYqN8LfuF6thtSo49qY=; b=UzJ189oRpYe5IllIzSkt2bI7gLACipwD/2J6bUN6K5Ze8YuLdz3PCzdGpHSwxAM8Nv1DF7z1KYTaIR2kMzLwxkwFFI8y1/oV5M6GssaRjKaSIpTCBRZ/eRRIg7wX6gra99NzlsyKW2yzztduKcPGlxKW4z0g0DVh9+SJAtvywpk= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from pboucek-sslvpn-nc.jnpr.net (66.129.241.11) by CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Sat, 20 May 2017 19:40:09 +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: Date: Sat, 20 May 2017 15:40:01 -0400 Cc: mpls@ietf.org, draft-decraene-idr-next-hop-capability@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: idr@ietf.org X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN6PR20CA0072.namprd20.prod.outlook.com (10.171.181.162) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY1PR05MB2507: X-MS-Office365-Filtering-Correlation-Id: d77a4e27-1594-4fbf-817e-08d49fb806de X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 3:Z5oAxVgNPgC60slo7MjjmZXWBwoRgn+iSAB2S25YLXuDZnWPz92sKVVEPEdSUs7f+FA96qiRirteQchb/aNOkAZGugPR2XVqXxZBG4RK9/cA7TrDpdwQVEujRdhlaGTCZpkD4Grcsg07fyDLovUNcXqtDkp9+LZZC014TR03g2LQoa2N0uLp9vc3dEodz3hBdfE+MVMKPu67+GVoyYPwP+SnSdDp6kIEhHw2TcLjV4R53MLE5kvuYYaGlZFh+Q/y0Wf1C8OLdFP00rSQjYD25zzOoev2M+wgHALiUd1yVFatXdvlcspuBDspwSrWBosy7lOW5y+hxtGeRPi59tzzEFUBzLivKZuz+6nmx27093E=; 25:JasVcoQ3v4G0tzdzw7mGRU3D4babf4+MjSQCujgXdO3U+R//qqTDDZHNA84HyWJnDqhJ4xusV81mqaqHW8tTdOrwSdDa4t8+AdApO6EHEOvKWz7NfqMKn+hDNDvyvtwJ20krGYmnSNYgNAIq2g/4dtwqgEznG/5wyprS9JWEbLAX+hR7DdYRLCT8yUuyJ7ZWaKjq5RqkogrLOoe3iV2EFqAZJuEbdDLcjQAkmoxaaSUi8IZx3Z/zILkS0oR3XnrGquDECxUR5IOx37hCU7103Gz0cCRqIdAn/GWGUgp1ShKsgyaej6q/8iGhHZnHzB1CPiATQS2X2DN0HoBxVW5UmjDF8bWT+9N2FlwZV/eZp0ZhcSNUoPaDrvfGqQl31kRLqX+SYQ3lNMGdCK2RohLTiNxreCM2/jMf/AsIjrqnaIrrYl85/Tc7EAl0rcUMdX0Of387YuFOeC4igrqSk4iGzCJKjf6VkSjNqT7pdIBcMqM= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 31:JEFe/SIKZJNLQC+XK0qNKgah4IBZmi/KnNY4dCTaH8t7jkVpr8qa9g8wyHzwE3XI/5rZcbzgwRT7xSYacWoh1pW/3Qej6mOoUxXVMWuCgrpTE5+++05RpG4fbRsbDe/pWzJLT+iE/ZpQ7vUi8+TqvSTjr3aTPbAaGtGQFCRua5AsZncyFG909UoVC0EdabPyyZpKvnPR1lGbYCwe1PFNz1tcvECDnMcRUe3to+SVRHUfyYAe4gmKDz+k8UJTQrVa; 20:VtAeiCnpNbf3VICi4ok8YsLdic6GWDqJiD3I0dtwqvKvkyc7u2RrmYgPTjwvgnSUVxgJ7Lw0p9CB1K1TZtZybKpYb6wzYCaUiNlNF7OQNWt9D2OEy0S8+TpzJCLG2Ss6EgrIOO9pItxKD/6z70vnyHiPVznoXyNqrh2VhatpwZ9zKnun2xtTifgorcTc2oRbsrcJynsq1HNAPyhN9ISUE6AcbQc/eXc5CBUEDn95rSYlbCXI6SyT5VBlaLC4HAu4J2kZnSditkf3wO/YCvSBY15SOc0780VQEkFckkMDKi2d9jkY1x4khysCv1dCPJzvvMaJGOxka/plv0h4W9C7+6UqjVbVT8uhwErUPiIqAnFpPf+VlJQwB6eb76Gl3XrDbXjpDrYsPZA5nUuAuihoSUmidjWf5afiYJ0YByid/VpHhvodxbWJDrkCLAoIs1ABTu7CMTPLDmF86gGxksBXMLXetceRsAK5d9RmhFt/Z7ObE7tJaKOWFDYcY8RzxxSlRE12BM7PQ8opELcCNUVeENYA2kp/xElsnyVT5e+Ryjf6W1jZwUak3EvCgxA6MEXYP7dPiiaNt3MFDAOQx/NPMRpsROnCsoAv9rCiiSDEC4U= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703036)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 4:YUyq9Ezsf5R0apakj97Kkjm9NYB7BvONhIpS6LHpEZ?= =?us-ascii?Q?bnTUXWxOP/C4bR+B81nAJ+xIM5ZPiuuhenlA1YRB/jRPOu2koT2cssVJxtpc?= =?us-ascii?Q?Cbg615V14HgrpfxNjpdSUA6VwqtePJA6WGHwEVZ0oQqFXTwdETKgQf6bNbME?= =?us-ascii?Q?2jwVlISWWCeipJHqBhQfHKm5JdfYKxoN2tRcZHWJgjd6hVMUa5jKHcDbNEHK?= =?us-ascii?Q?uRdPWlRTzb4+gMWNpEm6LzI+bJtTZ2FAW09qS+Q3o9g+r+C2AMgvrZvOqfwL?= =?us-ascii?Q?aiK8/ljiK0sERKWvsEzz6FDCuPssA6T+dvXZy2e7Ah2JU+YWZGJr9GAGrWKX?= =?us-ascii?Q?D3KLr2pHZQje1UAHqTYaTPBgIfquked+hs67G7Udp38xT9PGaNRhK2rzsmPS?= =?us-ascii?Q?XV05a/t9B1PKffx2jNoPA3QI7j9ih5nmud8v7p/x72PFY37V3UD9k50mSxip?= =?us-ascii?Q?90PcEYJBBd+jyaReEp/Oq6/pgL70CectkOtLcpPn6vpGO5iqYdoKnSMNCgJl?= =?us-ascii?Q?wZA7bGL0JSWDSj1KTvGPCx42aj6CkA3/x0V4F4ETeVXGgkgLqJ3LA+Lfe9Aj?= =?us-ascii?Q?WYMge5YpIXEIESfK2GkKCSFvTpoZi38VfuG6mr+G/f8KgC/m977roXAjlkyw?= =?us-ascii?Q?r4sfPx77frhqo3BQ2v6cM6LDs/IUs7GImOHA+ehBybTb+MaWAKxI3c/FHzwu?= =?us-ascii?Q?9ZUBez2YHDDe5tk1LeLEB/PUvfp73Cl94oFmBP36f5GdUPJDi9BWVasqsyNe?= =?us-ascii?Q?mpxHvt0FBp1DBWzVyYADQUhqql1ufXCp2M1SyzIoqjBSPg1ef1Nz/Ml3rQYD?= =?us-ascii?Q?6Sgdtmxt1hN+D7Dnv9OJJ6z+UCMJo1mQxESm7KDS7N7A42weMQFyAZtUYu1j?= =?us-ascii?Q?ReCBEZei2Lu62v8iPadZtTgyksTHU98LffNyqU0YNG21D5y8Z3JhZY+PZzfG?= =?us-ascii?Q?/sQ++V2/RvJaXaQN5Kc/BWdnSVFGQdvsLBb+Time/kN1QeGRYkhmhL7r6xCr?= =?us-ascii?Q?kcF1L0QDqbz0vaspho25xGhU9XG1tKsZKk3vz2ItB4T1mLE6aK2evvUyL8Vh?= =?us-ascii?Q?eJicgv/d8ZhTgZY2kW+kv9ciu3keYtWAZD8iRKpwgZOJYu7f1qcRkz4wyjnk?= =?us-ascii?Q?qi2x8IOz0GHocJH6d3Vl6W4irECHrH73hbsY7/eaedzgdf1B0m+QexLYeacu?= =?us-ascii?Q?k7wQXyCjDbT12rSEDFvsYEZJgqmhTffYetDuCRb3x+HfnToNK89Pjxzahnk+?= =?us-ascii?Q?Yrec1+tYvgJcP0gYE=3D?= X-Forefront-PRVS: 03137AC81E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(979002)(6009001)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(39400400002)(377454003)(24454002)(53754006)(6246003)(305945005)(110136004)(966005)(478600001)(6306002)(33656002)(229853002)(50466002)(86362001)(38730400002)(230783001)(23726003)(6512007)(82746002)(42186005)(25786009)(53416004)(6116002)(83716003)(3846002)(50986999)(189998001)(66066001)(53936002)(50226002)(4326008)(47776003)(81166006)(450100002)(57306001)(5660300001)(2361001)(8746002)(2950100002)(76176999)(2351001)(6506006)(6486002)(7736002)(2906002)(6666003)(6916009)(8676002)(36756003)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:pboucek-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 23:PaJs2Bcrfjt1glWLplsNramC8L4t9t7fpAnIVQ3Pz?= =?us-ascii?Q?wMXdDA4MWsykGM2veuitutAPKEXEhOxekQQ3OdoyEU5jdTUn/F2CMclgN5MJ?= =?us-ascii?Q?kqMboMKAqYqi4DpWU9pcbmx2gxjJ2zKzVYymBGOL6FC7+QcJPCHwAlhfjfaQ?= =?us-ascii?Q?zv1CYpAOkya18atq7DT4lnb6+LPuKA/xjVFahKt0nyCrsDlxEO8Oic/F91FH?= =?us-ascii?Q?z+la5JVHKS0g1PTnNEX90YlA3LIgdH0fBJ8bT5kRYPewfxR6UsQNNM4Zrt/9?= =?us-ascii?Q?jbghQKDsWjhhkHhBSXRUQlvSp8hRt4uzboSKVIOZVNBri/djh6JBk8DsX3HP?= =?us-ascii?Q?9p7uyO8VUw+oy59f4YGdMJwQzDqd6TPk5/XCdUSVWbRDLgvK+Ilr6BS1sCi3?= =?us-ascii?Q?NO02p38ecyvK/VXm6Hnwm1YFVpx09l6cdNBcUHXjoC+er/Rai+xN2HGBIk5k?= =?us-ascii?Q?JsgXi7sMbnr3DVDOQvV3URjTQ7RO26BkeOjKoxS7odcosfyRqTSYZl/runZ4?= =?us-ascii?Q?TA90ISYnWJvIUoqA0nycTwJquOugjgLHZTWKRpswrSqBFArsSg9t8ZdxvI4j?= =?us-ascii?Q?+7yVbQDjuJmW1/IP7LsRt4ZtoLqyjZ1alNcsXaY6QJid1w26rsumCH0tBfzH?= =?us-ascii?Q?CTV2xlyCvLlGahQ56mlvmLS+gnJT9bwfmTwR0lEVXsphnHOfMP8w9yF8tRZm?= =?us-ascii?Q?FgoRX3zl2OY3YyJV/0hIzo2g9OHB27lEIVzfX6wt+iKWN1aR9rHDWsQCgE+4?= =?us-ascii?Q?WOBCuYXsXQY8+og5kkK9tVKyAuj/ouNL/bKNncsg2UaQbSiaFFhfYb20owif?= =?us-ascii?Q?BrvnS8twl6Ms5rzpYoVmgfm4iwa8RIdzBEyr3rbKPwK1Men3yWnJs/GRr/3m?= =?us-ascii?Q?NxfUzv/7aB88mVxBFkQl4GX3ZQLwz0U9lMnVJWDmaLNE6PYdtDz7AIVCF4nA?= =?us-ascii?Q?SGcCEFSIODcfZycf1LGonTvDOJDOrI6pvB7SllOSsP1I273Ura7O8EnkThw2?= =?us-ascii?Q?GfZVpWbFOCQl9dhm1lSRadXUtpKgt6d6F90fCzcVXZVNYqCDPOYeYm8C3Fwd?= =?us-ascii?Q?yBMYNgXZwvgmfCFHW8nZ1mLRvn3cWY1DxK67Hf4tr4/fG6WFGlSeUFiJpPaN?= =?us-ascii?Q?xZDwnV58lrITmSJR5cwUCmwljcZ4efEnT7gcp2opdkzY03+t9FrvKm/OdmG6?= =?us-ascii?Q?rSbP4vSVhYcA9TS5tIDB6MNwESRmQBW8WYAncit+LjeJ0d5QCF99shaWNouB?= =?us-ascii?Q?0pqQLr8ysMX8zNBlZ4V05jUYOdq4+k1GKVSXJIcsZ1o7aeHdKnbhDyCHUIf9?= =?us-ascii?Q?uUPddTXXtNOSTqPcqiTPr61jjrBYXY038at0vBYKzpf6EgMzL2UZIxGWXGgY?= =?us-ascii?Q?KuYNSK9SExM6sBeYPNuPE64Os3ylsPRDRZtYHpCHtJs8zUTODVK4kAAjewDE?= =?us-ascii?Q?2Ttzf6XZCr06whnH7gkq6Nw7rJJPISvAc1I6i25qcbH42T2lK05?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 6:KDUqryk/6mYKzahrTvoRS5yISA1kaYAFZ7avuBRjkJ9XPOLYMYFVYoaHeJBK4KjrzlWQjk+RUth2e6KCCSlvulDc1iFBojmx65z/HPZS8HNYVechFoIirFgoukzlL/9L3EWEfzQrOsROvMU6TGsL3NVKQb/YUuN9UgLjC6M+Q1ATOBKZffT5Gm4dXiNBjrz3VM3DRz+IX5pW20sOn9tG5MaKLXYfuBoSYCcoR76bn5oMCX+t2TpSYS/qyZ5h/EBuzAsf1TuNxSaazmFUlbn7Y8SRdMcPDX2w3CenKT8kwkBoJ0IWmQunyDKV1XnDjPWRDwyN4CYayFQPFRbJo2rvZPLytsPgDK3kIi4tOSytCfM2P1qH/5dtUvu7FTOMSFDJklbN+p2MrYKXcJdSjPwZmAwy+bB9uatkpsnsqvQQRFcC03tdJimxzcHT9Ey0Dcv/DqDF6wLhkR5Txn9k77/DcXBFzZIsy1RlMN/tT4wBL+RFnDK0nPWjU1TZI8hhLrzjWswkMH/yqob2nf1+qxOwX8Yqg4KTVVfW6ciyuiHecwU= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 5:3WOHAuUHrOmIFq/teguklN7WjFvrC2Uqjpd6fB86YgSj9WjXOGu70zg7rcw6qM7BhFRg5zLVip9W2SA64MpGS+GvlsB1AGThQFDtmZvmf3iCoebcAyN4akDG+RW1tN+AnLeMJClGG/lzMfGGN64KZRlTru6/guZ0vKch8HIZ1v92MWaawQuvZYZ49a8x7lavuXCfhos8dm5CRbC8a35SsHHnfKLZJlgS9DbWrBtedOmU6vHnjqMJaEQVX6gnufYWAycHGP3xfzNZhFYPVzaPsyQVomlnyJZsxWLsiu/02gus9m0IuJ4tCkJsp8B9B0VfY4a4UmLV9aFkkdOh9I9oTWJ0b0+nFxPKeqA6HFL8ZjmDIGXBZOSQwSjcSScqC2tSmb3wH+1fPDU6ND3r361Yv6F4N480yTazanPKK0tap2M7OSFXAGzz8x8cwdeE1eVgTBCl0mE9nEbGzF09Xl8J6jijW17KOgmjAnJS2PA4mS1l8ZXinP5sj6KBCKNS3jwl; 24:BG0AjnCEmQZ2vWHNbGeiClP12og1eJpzpbkH/ldGGuUNpR4IgZeJFYfq0z9cKVZVFLKs43x1fLPQcLwXN1PTnHf6W4/F9N8M/S+lzVywMdo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 7:jrDIna6/1SpQJjzOHcIoOxhMb+d/pEhi0KsNasUo+YpYE0++/f1Ac64N2e9q7oeqwIje0MzDWuMni+BWJNfEtZ2h9PMl38gMZ7ob54pUM57C+uQIp+m2oDVt67v57sepr0HPTEGUHE1invxQQLC5GcaHbHTq4TQQ+6aaRp3kLRdxzjqxDpbpftgANFJD9sz7GEWpZe8jipz9zErgdVTLUSztNjxMlFYfDYyTTUSp5gk7Wtk+b34IpqrTReMWurr1TCihXcSE+a5JxhIYYYV2NVPczFa4pz7Dydy19UQxdm/s/ulr4yaefXLTIpU2kGxOGIrz5TzFbEg9SmlzYYg4Hw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 May 2017 19:40:09.8189 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Subject: Re: [Idr] [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 19:40:13 -0000 BTW I forgot to mention, authors, please say if you're aware of any IPR = that applies. Regards, --John > On May 18, 2017, at 12:32 PM, John G. Scudder wrote: >=20 > Hi All, >=20 > IDR working group adoption has been requested for = draft-decraene-idr-next-hop-capability-03. Please send your comments to = the IDR mailing list before June 2, 2017. Please remember that we need = affirmative support in order to adopt the draft, so don't be shy. >=20 > draft datatracker page: = https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/ > slides from IETF-98: = https://www.ietf.org/proceedings/98/slides/slides-98-idr-08-bgp-next-hop-d= ependent-capabilities-00.pdf >=20 > Since in part this draft specifies a replacement for the Entropy Label = Capability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 = and deprecated by RFC 7447, I have cc'd the MPLS WG mailing list. Since = the proposed new attribute is a generic container with the ELCA = replacement just the first application, the current draft is targeted to = IDR and not MPLS (this was discussed during IETF-93).=20 >=20 > Thanks, >=20 > --John From nobody Sat May 20 12:47:28 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E84129456; Sat, 20 May 2017 12:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uym6u2WKQ1Ax; Sat, 20 May 2017 12:47:26 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0091.outbound.protection.outlook.com [104.47.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5ECA129454; Sat, 20 May 2017 12:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VIOi48otpctSr4uDnXEoSVRzGDARlfHd0wNWnlriMSY=; b=TgkUVGFnBBS5ZGEPA+ORZqadmPJRM9y0+sVf4KsIUfsZWc7bZclYkKm8Os5riTkDr4LKc76VyRSYInfXlwpTvAkwHnwIxwSyxxmWwmW0xuT7/M2xiSx0WKRkarTkYgio4SUEenyF3EY/OIUNObNTswAOmiqC9FkGv9xTliwJutk= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from pboucek-sslvpn-nc.jnpr.net (66.129.241.11) by SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Sat, 20 May 2017 19:47:20 +0000 From: "John G. Scudder" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 20 May 2017 15:47:17 -0400 Message-Id: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> Cc: draft-ietf-idr-tunnel-encaps@ietf.org To: idr@ietf.org 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: BN6PR05CA0025.namprd05.prod.outlook.com (10.174.92.166) To SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN2PR05MB2511: X-MS-Office365-Filtering-Correlation-Id: 69de408f-ae2a-4937-4614-08d49fb907b7 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:SN2PR05MB2511; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 3:V+T8dkcV/72xfLI4Xnx1CgDl2wXmAz0fMy6WCD7DJbl+VT3J4ignMK5JDgJ/HAvDzKeS570eAich++ddz/aXiuqkJLTNFINMuScnFJWmF7Uwc7Q4halyoI0pQefgePnFyXJm4dEz8+GND6os2FUJz/OJZ/yiQP5aft+MC+g02SoABoZX121Laksh0rLb4wr1bjovfOIoQk1AyH43d9yJrIS5hIshFgqCdDTWkzwtj7rR5d+ryc48qx0Hazdsg7EmvJG7rjn89xbY6rG1OY2Ks4Wnf55FMFxawUTeTo8ZcHlGxIT+4cFe0KjS8fURB/NecjbnHP/eEb8w64CpPZ4+7dm4eHqtbql8p/EC+ATzYcM=; 25:q6Wr57ng7Qa7h+Yy4uIOazXzSQlFxEkpkQj4TSisJWS+fNoMkDlA/++YlMRSzLl3/akFkzfyqxmrLNuoGCRxN3shTfOpjw00PRUUr8wvo2YZ7LQ+5/9FcdjsrXhKDUAbipqnjYx4ILffczEktSSvFs/RGlvFYfFCqNYNLN5ZekvAgT/qtmcmsR51RiGWWiRKsItIzGJHTpW2GoNXu+553eiC9kClf5qlh+srY1oqt/XtdvEfnMMSMjOQQIArqCSP02X3sn53oyibDQAeyNhWbsyoTiXpmoD5wMeUxefVJc/jBrq1aQ58fPzaK6b/F3L4QVA4yVOcRaiqay8e50bCN+bKT/7G86nRs8X26jXdk+MbJiSAXWnMOeqP5R9M5KNs0BF2c0f5zVYXq1zGaxdegz40UKfKUOVwvFKvzZ17poreFyHrmrrxwmaXCa2wwxDhMRlUQaSv6PfmzKr0z5UwUAAdEv9G55uRfEJy5mxsWJA= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 31:YZltDAmsVxwlWqJTy0vy7p2Kmlz16JIxkADVGpvuzBsclewNJUxU21Ju3nV130QjEP31WJpxS5q7E4CYvBo8LUWhDiOfv9MiGQKqzwocjiU1/pPawk1S+9lQ1hQCCelmLgrDr/FH+yHVDtlteMZv0VeL+zbHAEm1+cwIlVN20gqYFYC0ufJlZXAasb5OcdtkjPlG5kR44OUaSiYdYrB+lNLPb0IRiYMWw60WBhgMTRIirPmft7+SEow7zNMApB2I; 20:yrhDdAGjKJR3pF+sA19Wd2hTE2V7WDHz0nih6k+MKUYx94RD6uHfhBJ+R3akHRacDdcHezMucJD5Oek/JryLL6mkB4VWmAGfoMh+KseSuJuR1yj4eVD4OKWteDiJ8s7/IFVoxg0hdDQwbtY7x7a/rECHW14w0ezR5Wzlod4FyqgIcFkQTSSdgP3DoMiIdm8go8BubbWkt/5ge3LA5BNbMa4lk0cLzly3grfL+fh6VDZ8akRbHOTGa7P0AzClPuqrh6X5+zmBUjqNuqLYqXPYJPrAqHYMw4I+hc82EmVxvGhGD3pIKpuiJTfFlg6w2D09VWTvpavysC3qENKAIF10EHly8QXQRqALycRmylVCPyXj0ByBE+VaRF+ISi4dEQp4IQICE0w5UVO4mYm0opaS1X6FmVMdViqSVXoxXm5U9L7sRTuRPoHMaQ0tlbZvYU0w/KF2SicYrJ794rX+pdwJgggESABtWPg2yKjfPNRimGfh5ZFoS1AafImic1Q9RhHXKOfqIJKG8FI00LTZskNA4GktQBfXGUCffxiSjA2375+lnHY0/niNr6JxNs6ZMc2vV/MSv2xH2OxNNZpZvo9uHf64xbg1os1t9GXqRTd/CDU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:SN2PR05MB2511; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2511; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 4:5kB3M5qyB1HeiAVUNGreXod5IVpk6haprckWnc/R6tEmU5pLCKkrShsU8vYeNGwSY7GyS1FTavMLq/pAYKPCK9YqSkH1K3eJDFDV0AVRO/fkS98A2v3npWCH5Ha6pyyF3eVV2jhZLAEeoI7Mkaxj5JMqpALzwFu/JuGCUr6PJTxSqGV6P7a3/J7l5woX4pzrYuXdfS1b7PF2vMG3b7k2qRkIIc+VC85APcMmeP/g8zja8alN5obQ4QsPRXKw/xfXQiBxXvx5D0ve+Cji83tSx/jTOX2gOV0KKKmNBDM5+I8zc/L8oR384PvigAWxwNw6zty44QtBtNRnvzpiCmglzelJlKwmTyFw+jvxtHEb/ybdPzYWwNq6SfPEqAJ2o78paHkJ9Fe9Bg+y1lCel55u1IQ3JMcRrPKdKYIeQ8OEGAi+JMl14sqwjPQ2wxWpqed7ITy4nescC8r9R4N3EGCXw7Mh2sBLdmOWTpV25EezLi3jNcSdvEH/70d8vW6+Y8gWCDrGVUNJxh1NqWyvqnA9c/AFM36L91kGl4281yh9IWAvR5sDccJOOCTf5VdisoYj+0QBo1A3+xDyodzd3jUe2UcL5bMXsxLls5yN/eIGNblB0GwalJpCpNBBQueH85hmZiA4t+o6ffbkvdLT0v+wRPx7ppPIJl7WARVKyEQykxTvfAv+cE1v4/b+0EnBmas0W0ho+50GqSr13XXppw3ZtVTktQCnjnzHqEdRwGs1WSYhQil//0HLo9CoO0yMwexDM6PgsPsS3Ac6C0WoUXRe54plczdXpHDUAMsB9nspnU4= X-Forefront-PRVS: 03137AC81E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39860400002)(39840400002)(39450400003)(39410400002)(39400400002)(39850400002)(53754006)(50466002)(6666003)(6916009)(2361001)(3846002)(23726003)(2351001)(7736002)(6116002)(86362001)(42186005)(53416004)(110136004)(53936002)(2906002)(38730400002)(8676002)(450100002)(478600001)(4326008)(81166006)(5660300001)(57306001)(82746002)(966005)(50226002)(25786009)(8746002)(33656002)(36756003)(230783001)(6512007)(189998001)(6306002)(50986999)(6506006)(47776003)(83716003)(6486002)(305945005)(66066001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2511; H:pboucek-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2511; 23:DHO4yaSTQG4mtDXBM8WOS7ybPPhMl4tCK6wQfaWvX?= =?us-ascii?Q?wZGfeizT30878aNvIU5+nF7YoPRBVo+zlUmdNrkec7XEa0zwbkElTWB2bBMr?= =?us-ascii?Q?jyLHfuuAAS0Eck86+JBuu/E/sum7nSskaQIWcfpvVlv0C80U5wu3JB8C5sB2?= =?us-ascii?Q?0DaFeET2VrIAQkPgeA8Fv2FRQctqg2qS+p2/Kp6n4/6/0UCOkaZXNnCLgbNL?= =?us-ascii?Q?cRXpCyjEe+Uj/DxHPfd34MuwtRVYRrunqXcarA1SHJEVc9FMOl3im2dkRgwP?= =?us-ascii?Q?5Og9MFaB0RKT0N4cTxJ2w1scSUMX1GOKYiN5AkG5kB7ZJ7A9DHc0EZcbJoMG?= =?us-ascii?Q?IHh4IHzJygi24siCOpZKU6YYMeazzjBLeNQflo4MDQSf4vk9eL1iDeezKXeL?= =?us-ascii?Q?r0Tmk7MmdKdVmnT61khIn8TGdBnIwbMb2N1g84nRZQ4ELiFCedSennEAVM+c?= =?us-ascii?Q?NpxsmJq856zCHGbfqI6X5YkOM3UbxXLumzVY/CS64Sqir1eYiJ2pUw+BajlQ?= =?us-ascii?Q?sDUp2KQ30gPlm/AZvLuXj2Sn7AboFIEaawQRXgiYR4MMeVqBfEFE3CkunOER?= =?us-ascii?Q?mzzlUpPbwLBT6HSSVKyrOu2GmXm79CsE+a730a84NirnCZwF8H5KH87XRiZU?= =?us-ascii?Q?UFCWiIRjKAiJeKg4RIA+aFKaitPQCSiCUHUGLam8UpUg9CZ2JEMkSR81h25Y?= =?us-ascii?Q?Ww6DuDoyUGT8pVbNyAp07XcDgyjUt5/6dv2v9ejMiCBKG3phZzxLLRW96eHS?= =?us-ascii?Q?iW0jjtePoalRUbjon2CPYdT3tlQ/z5lnewM2T+hJKj9Q2retTMYnvwNI3E4u?= =?us-ascii?Q?oUMUK97Le72O3/XXJv/OriwNqLYQRH6/cdnFpwD1QQJp5iMMShrlFbHx7JHT?= =?us-ascii?Q?xc5JnAC2kL8m0ekK4byKzRwqMSeqUPYOOdu9fZ7dEBo+X0TRShM5LOT803l7?= =?us-ascii?Q?dLlj23DP7xWoVRo5Za1crl6cYTq+XUjATolSJDJ7GQ/D4fLcOuSZ7Q5bRZ4D?= =?us-ascii?Q?lJi/SKuk21iIwNgSyJzaBQiWdOWOeLi8jkByDrigB8V22dLpIX6QpvtNkaY0?= =?us-ascii?Q?2ei4t8h3CTFvNHKyTkRSTdVibgnnKRwM/l/Pbk0s/EPqJKVM15c7PNpbjm+f?= =?us-ascii?Q?GxOUvSRyuRZjfHVSyeRTgeQ3qJGdETGgAsyNO3ExX2tt44Vv2gkMjGROJ1Cy?= =?us-ascii?Q?RMOOjVKl4y4QKcsYYrhUBkEsVFWBO8snO/UTPSNlsoyhWj4lphKt8PrQHRHI?= =?us-ascii?Q?aJYaXrPQKoEJVpZMLc=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 6:dQTGuVjl1SPyFZrVqvlOEpTp5TXsySCOjGyglSyyAh/Ckfg/ryda2Ne830gG/qJbZcxjlDsBdi3IssTbJs1CrOk7c+7MgfUOCuFyAVQO4LnbHBG6LjxQ6AljoJQz4as7ddUbxlRpRUDNsxHcpoR5194KOFgcy5wcOv896LNCY7JS+wFMSnMo2r5MA1tQjacwKp8BpVKPow9E0hJftAyIiDefm3e1qlgAgRqLEr81bD9F1D4z4H07a+5PL04+iKk1x1ssN3dQ/b7U/DqVCxB2FycJcvnbhXYHFpjY7O9Yg+jpgbri2HhG8U7Cc8DcxepLHX8tsea9bEnLxUseHouGUSLh1KooD68u8OI4+mZY90BmhmPMMM0ACBPplKkVYq2duwG4LZPO/5YbFL81blzUKckyB9jQLLKls5nJmtrEg9d6qWDoXNEoW7M+DLsnTEXKDkE5SZiCP3VRJxTR59xUxDohoE9ZkpPXTyBgR2Of1eEKrAvc3jI59wCL4alyhNd+7gbVF1rullI2yKVy9OOHVCdtdtsHkVSj/zgBKpgF9tc=; 5:o9IzpRjm85MbxQMeMKhL4pStqq4Pk8d+zhBXDkLT0OUQqV16T5ULqwh5CqsORgeAFERV1V/l2kRXLfoMN1o2AB0EHybIcZ7f8ZmWHF4RO5RhtjYTHmJgWE7uOhbuBTlAa6VQHzTFRzGo+eFETNPVww==; 24:zLItQfDj3Tn5DXbDC3FIEg6S3pli2K8Cp3rPgQ9sN5/EWDEDtFRoVvHkP7jUocxG4ed1yrWzdkqWDZhKa1VyXVppHwEjSCiM5Dwus7f4wh0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 7:+n4b+TULZ1xAVZmj34EJMBm7DeGAnJijUB99+JjVj3BPQMvA7ZwHKm84CEj/kFA2rNFUq001og0LuQ30xL25XjIaXf8jyV90NWFkpbxUg5yVkbdPRDk03zdFjSzdt2LvgF9cYTeph9/KhKFm42yzJ0hXAkVEaLnTmhFfr1WizhBtKbcViiV09WdvIWmmxn1SAIZFnxLxt5jOlXj+LcATTLaXd54v4KeY8rfIgylo7U+rstU/jIqooRM/eYHxDfggSh1eRQ/2IozjvMDpJHSFYZRqrX+A7QGs+G1d4ZbNvsdeLDCpplaKejpm3H3FKjMEvgSid0vn1Oxeo+hoZt9e7Q== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 May 2017 19:47:20.9637 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2511 Archived-At: Subject: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 19:47:28 -0000 Hi All, A working group last call has been requested for = draft-ietf-idr-tunnel-encaps-04. Please reply to the list with your = comments. As usual note we cannot advance the draft without = participation from the group. Please get your comments in before June 5, = 2017. Authors, please confirm that any relevant IPR has been disclosed. https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-04 Thanks, --John= From nobody Sat May 20 12:54:52 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678F212932A for ; Sat, 20 May 2017 12:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 Swl7zDALKvIU for ; Sat, 20 May 2017 12:54:49 -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 3F5FC12420B for ; Sat, 20 May 2017 12:54:48 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id p134so11594078wmg.1 for ; Sat, 20 May 2017 12:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SROf+w1sb/qX7HnxpbqSSgVeFE7d/uYF/G2hSGZsTIQ=; b=jenH0XjXKj95go8L0KTZ4rQITL8GRl7y+yyH0Nu4ceYqv9gS1DpxjOrj1czCCfLiJA LZBPdU66h/q6Fy9bb12kLBc8ZA9/wL5J4MvYRuX/JZ01tbu5bdzgxg1UvR4NZ+MsIklp LzD57j6CcXSL7Uujq5Fs9tXu+eh15boq7IacCQoIDNgl37ZQZe0c26gcrb+QmJRF8gXW kUzR8HArXLtpVtNhvk9+DKxjlFdT2DpS1AocoMUODP3YB2rNPoYudc5voeAQPgGH9ZFi /3xjQpD+eC7CLaY2FeJUQanjCtFnPeEyPzk7nEySsOwKoj3z1mlN+zPUmZSsqIMZclbz r6WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SROf+w1sb/qX7HnxpbqSSgVeFE7d/uYF/G2hSGZsTIQ=; b=YC+S7i/8hZVT5jtq+nFnZ9YHyP39LsIcb0CUm/zKMobaOUVe/0aKnE+JXqVOphfhIF A5xNJDkl0BPpBStMqcETSxTcRW3WIqq4Df2w0Axg1CEghCFoZ3DWWfFozZlEa8G+XnjZ MjOJ6V0UUAZCY5SGeY2oECZUdq2F6VxE8NUyFYLUlIl4MJ6Sqer3EJYnG8cQg96pXKsa rD7pAwHRgUM8lKiabTezObvs1ydAkwilBJWu7fdsMqE09NVlZ9DcRx9iql7EbFFkqf0K Fwtp/sPv1+uFxAhc18UMrPZbCeQn8gHbmP28RbsgWt0L6G/W9xIx0aJV6uxso6DMJyYz 4FZw== X-Gm-Message-State: AODbwcDOBpVW4NH6smjVkeHZtGAaYjYMLZSreumhvYOQjoa6HMCaxfJ1 smktwzaB8rg7nz21qmuITBYgriE/25cN X-Received: by 10.28.68.195 with SMTP id r186mr9500588wma.22.1495310087480; Sat, 20 May 2017 12:54:47 -0700 (PDT) MIME-Version: 1.0 References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> In-Reply-To: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> From: Job Snijders Date: Sat, 20 May 2017 19:54:36 +0000 Message-ID: To: "John G. Scudder" , idr@ietf.org Cc: draft-ietf-idr-tunnel-encaps@ietf.org Content-Type: multipart/alternative; boundary="001a1148f4fc9820e7054ffa02e2" Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 19:54:51 -0000 --001a1148f4fc9820e7054ffa02e2 Content-Type: text/plain; charset="UTF-8" Hi, What implementations of draft-ietf-idr-tunnel-encaps exist as of now? Kind regards, Job On Sat, 20 May 2017 at 21:47, John G. Scudder wrote: > Hi All, > > A working group last call has been requested for > draft-ietf-idr-tunnel-encaps-04. Please reply to the list with your > comments. As usual note we cannot advance the draft without participation > from the group. Please get your comments in before June 5, 2017. > > Authors, please confirm that any relevant IPR has been disclosed. > > https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-04 > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a1148f4fc9820e7054ffa02e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

What implementations of draft-ietf-idr-tu= nnel-encaps exist as of now?=C2=A0

Kind regards,

Job

O= n Sat, 20 May 2017 at 21:47, John G. Scudder <jgs@juniper.net> wrote:
Hi All,

A working group last call has been requested for draft-ietf-idr-tunnel-enca= ps-04. Please reply to the list with your comments. As usual note we cannot= advance the draft without participation from the group. Please get your co= mments in before June 5, 2017.

Authors, please confirm that any relevant IPR has been disclosed.

https://tools.ietf.org/html/draft-ietf-id= r-tunnel-encaps-04

Thanks,

--John
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--001a1148f4fc9820e7054ffa02e2-- From nobody Sat May 20 13:06:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7A912948A; Sat, 20 May 2017 13:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYYKvooqKVky; Sat, 20 May 2017 13:06:30 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0124.outbound.protection.outlook.com [104.47.32.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 C517A1286CA; Sat, 20 May 2017 13:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Tnt5vRvjaMJrl02quHEgoPs/KPttpH2nMqo/c8H+xic=; b=GRlZahyilW/BcTaL8KXry8AlLjjyqUvcOkUstfldC+vVAyW4k+Hh5vtl0CfMtGYUEcXT6B8i9LCaqzcAmHmoCEJQ7T0jXI0ssDBOE+mmoGeNLOL/gwmwkdsEGtLGTC2FnVFzvFkHNiL8n6P0ngdM+CQraXvEjV/bY2JPeAUbnng= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from pboucek-sslvpn-nc.jnpr.net (66.129.241.11) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Sat, 20 May 2017 20:06:28 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_2E48AE0C-73D2-4739-83A0-D17C538E36FE" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Sat, 20 May 2017 16:06:23 -0400 Cc: draft-ietf-idr-tunnel-encaps@ietf.org Message-Id: References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> To: idr wg X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN6PR20CA0059.namprd20.prod.outlook.com (10.171.181.149) To CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY1PR05MB2506: X-MS-Office365-Filtering-Correlation-Id: aa7fe7d8-59d5-4f27-a6bb-08d49fbbb39e X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR05MB2506; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 3:WCYqbmLrHXRPNvPtoljsR4bUpv6wlpbh8sB6ryLNu3Wf8kADVMKDEyay8raejHOoU8rTOq8nBD5vPqbsg8psjRGCWlpC5J8ZreTvzmNsu+Gd5XgWjbBFudbQzj3Q+Tc3NTR1lrQtgq+9Mdd8myIPZ+olVKRx++SLdT1h/JmFa4IfmLFbpmqV9yu+c2MDavwVHCdFkXcfORQpuRnsdacro6hZnDhYLWms+jotBW3Nrl2H+ZCIFqmtYlTty7CHR7VbtGGVyzPpbNPD9OZPwcSXxj6t5HbYVjC+4a50LdUvEhU+7pRF3L0YCD5GMCAFnxBox3z+3aKnlj6B7zAsGdVFjUJfJeQGPwE0e9nMRBuG4dU=; 25:+k0smAyd87NEmCj6d7b3ctSqBQu/PZgGvYQl4h/8EFI+bIr85ow3htHvUtynk2D37nQ6nOlpf9I5vxwQZ3ciFEEWP3JBL90lC+TgW9jT+cylRLbFkbdQ1ZQctJ3C9YJ2ZDraD8++cnG2C1fCj/4tOdPAKlz7qcffNbg8uIukiohICXrR925psUgq3GNSjqjHEzodMzeqzIk1NyYNLW52UpDNk2qNdEIA8QfPG259ibHMfwHUlYNCTKvbydOhT2hIAvPydrpW5y5+sILnyvYEi/YqXiMci8h9CFOCyhmDLe3JUHmVQLTFltDtZWWVg4CjQsrI4UPGguSpkuUoURVJNRBftiXQCUkl7rEdtnQVh2mDkYMCGY7nBYXueKdG4wlZi9Ejo1j2v7/1Uqa0yzaZrtmFMkZoPAceTvN/imsRLU/UwjA7wdO1uHm3F0o0bEO4lqQwCLaB415w+G+MbwASKEs+0ns+cT8kppTR6e48TDQ= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 31:eMunf5B4cch5l3FBmniSx2ggsfCHagCeHzZnnXRNo248wQcKmeANMgSpYn+xFkjqsaq0tJgULAY+ULmflsJmIem6JRyY0BcnGiuwmzBFGAJuGJ3ZO5s7Ros+cPosuekZCdVds93oudjxrXM0ywKlQwPUFrHLBmhVzQg7TsgAS9DegXv0KEkIKG/EwQ5NHdj8oOCAPtzv9z4g5NvI1u2bt+Lhj7osrRh4mQmAi6/uYaA7n4NxUqGTMw6Ptp3SRVb/; 20:hxbJEsNoL6sg5IeUmj1NZhlFHW9OgTtwN3Mn23Rn2HXRNGZxrrxivxacwfU9bTIDQ8NPHpFnaL3m0N0St2e7pIwyRwfVXHZXlNIM+X00gz7OdA9kbFWrUNsBbDokryCe1lHjnZtwTMqasXNKesm/p2lkdBRH1QuZ6McUsq/Re9afyD16w2zMy4Kg/ca3CWQm2rRrV5ybOTDbp0RT+GgGKnRVrYYa3H++ywKvUWm66O2hDiIG2J1UaQQiOwzKXlZWPDp7dxl1g21hbb96JycuUvTGQlV+3/17qTMmIhKt2ihVOfH0jixNRVGHiydnLHvcYUrAl12ayV5a+wJwZNxVwTvFiEcjYXEe9Kksc7f0XirhCoMMFTxOFcocsKR2o35BiHt32uOmm/tJn/yVgOG19jUpVdXLDguiqRXusQvsfF9K3KkDWdCzDYPwYi2UxNKUXdjGHsiVm6leIXYLgj/ZYOUqFAevyD0+goLycyUcYiiDeqCcYlyIFbv9dWxieQ/+EcuaXg4+aBb8TuEg7JBt8WE1934rHFM6+xzYdfV31+zTfTWWXO2iGyd/ZzRWWQ8HciMVbGEyZTzUwe9BzkH1rYrBWtPYcq2MGAwXu2eZ5kU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(211171220733660); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703036)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:CY1PR05MB2506; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2506; 4:kKc0WBT7RG03xsbYlQe44mXJhLZzHajS9re8HsYFfV?= =?us-ascii?Q?OLa+WnSwGWk/egf6DnZh0QG4WcfPoI6eI0ktRPTQSGoOznvQ2ZsR7JpeUhRB?= =?us-ascii?Q?or+9fEPi6FHHktOrumqiuduZEH0+YHXJVx74xN1MTf6jN2oRstSrS6BET9p4?= =?us-ascii?Q?rZ4P80q2R5RtXdyJYpXNPhZgOyaTepZKmpLzzUpqG8rAiHWsS7lKft1v9ibN?= =?us-ascii?Q?vOwXyOcl/MSDAISWFcZE/lEhxuVtydUzcTFVdL7NhGMWO8UGkbia+EMgPa3m?= =?us-ascii?Q?k60Mj5pRtqTVnJwxNPsgyNoUPnxIOdm4GMnscX0pFD7O5tQuwqglVS3hlucQ?= =?us-ascii?Q?BEl1ZEnLng9a79Y/IIwGBV/m5OuBwksDbAnbbZwGhWvfzTDONOYBPZyVn3fo?= =?us-ascii?Q?dyJvO6MPPmhAH7CLbyH/Oievgb74xkp1KY9gNlazeqNF47lJnzKrVniQEfL8?= =?us-ascii?Q?oo1xUgO1HuB7Oo1RoSvVs1jamofktggIw/v3ukVNV+wOBSNaAPMLxOM2aJRx?= =?us-ascii?Q?MdU+NRPZ12FgXdouZ94Pr8CfxwoFvbbbiSac1e5PVJfJFmGPVctNIqygaWBr?= =?us-ascii?Q?0TiWP9iHMU2rUtIuQH/5IyVZsIoU5+I/xff165cPU9oi2CrIwIV+XYanHFcv?= =?us-ascii?Q?LG9ypX2XMRkaRCMrR08H4DJCYlooohdgZE3/wxC8lA+kJ4tlPJbz8F5XemJK?= =?us-ascii?Q?qW7HvJzYmFRx2MxfXF2b3WyDkShqPLdfSZMssEy4O9SKFIQbwPOb7o7hhhGG?= =?us-ascii?Q?VIZ8qA2H6+Dn/GJDoxb4B2Ug+E7KEMUZuLtmr3pJYcWaOW7yLSX4ZKn/gFB9?= =?us-ascii?Q?LFKR+v2/RYwMWOdmRYiFe7ralcVsA5yjTUh0mCU2wNWp+prIuu0aFQfVXCyo?= =?us-ascii?Q?xMS17Ms/BmrNBD9vzqabJa1Oi/qBosUhHiqGAyO+rBJR6mLh/aXXVZmVrPgA?= =?us-ascii?Q?FpkkwjteOFxFCQERn4IoC0ljekyz/jVnoW+6r1oQxNBGxwV3FWQBFacJql5x?= =?us-ascii?Q?jwaKbniwUnzguJzVNIPHhKd374sFjKBAN/EcM1txRF0BuOJZ5aCSUSFwiWHM?= =?us-ascii?Q?R+vEa+SZlYTTo4BSJ7OpPKxyWtShgyDVZDA8+f+LexGKo17DqAOg89LxXeb1?= =?us-ascii?Q?cMu8r/MlLAxKCbBfYAEDOvR6HYGyTEYMBU9kGAtzVG8+IbtzHO5KGFTdfWqP?= =?us-ascii?Q?IAP7QfEg6R5INUKrIGWh53vEzDU9KBCFo1Ca7Q+qXgwxT0Tqh4FiYkJIcGP4?= =?us-ascii?Q?nIXs0/2BBoBZQILC0=3D?= X-Forefront-PRVS: 03137AC81E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(39860400002)(39450400003)(39840400002)(39400400002)(39410400002)(39850400002)(377454003)(53754006)(24454002)(83716003)(3846002)(6116002)(478600001)(966005)(84326002)(110136004)(42186005)(86362001)(2950100002)(230783001)(6916009)(33656002)(53416004)(6666003)(229853002)(69556001)(82746002)(38730400002)(66066001)(6486002)(57306001)(50986999)(76176999)(7906003)(36756003)(189998001)(8676002)(50226002)(81166006)(606005)(2906002)(53936002)(6506006)(450100002)(7736002)(6512007)(236005)(6306002)(4326008)(25786009)(5660300001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:pboucek-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2506; 23:x3OwrwUh0Ou31qiHp97rAqwE/NOYL3maedM+VUCnO?= =?us-ascii?Q?X73B6qsqz6WzByP0+T9FQkJaPDJh51O8elI0NCyWnbAAqlY/iTjmUZjMrdAI?= =?us-ascii?Q?FcsyV7wf/M1tD5qBm0/uP0mV81e2gCR3fP/TywKMIxNziBhoBjvhzy3gt4jT?= =?us-ascii?Q?TLIQvdggs2spZTsNVytqBWbWAM4fDZ3pSMVpY7bnLNxXGmQb1XUAjww6KhoI?= =?us-ascii?Q?YOUvhD0Dn13tbdKsys3YRYD4Qo+GXhTo7e+py50eCcY+utsoOXjclMwzq3t8?= =?us-ascii?Q?EnoPoPRt7tfySQNH1oFH+AvWSdQ+LDZyrneXrTM4pFjBK5mUoCXEJ1clQ53g?= =?us-ascii?Q?U8Y19r84mWq/WHgpWV32Yp3SCjrHFlHnzCHrHlPkZY8JRqT9mGmwDH3eg4vf?= =?us-ascii?Q?fVvEZUbt/9Ju0+KtYRGbtfp9eLKJUHZWr9mrZfs9WmPOsbCcQgdFXMz0BX52?= =?us-ascii?Q?PEgbDAdN7ah20DFFT+EAl+HQFqyF3DEaL57y9jiYpFJ0DlNBRSxG+noOD7nm?= =?us-ascii?Q?s1ZlftMQDxsAGRZReY38veb754CWIJuMms/v8r/izbKtqru42tEJ+O47vcQw?= =?us-ascii?Q?RRFvtUm1kRaG0WGkz14e8WJhEnW840RK8pDJcpktZ91yjWtDuPHb9runCDrf?= =?us-ascii?Q?r5OIukCLjQVwsaLRl2GS1fnnhYJz37OEuKjkWIaeK85aX3ZNI6L6qAf+pFmL?= =?us-ascii?Q?Yy6VUwCnjRvDPXv4OtNq0qomyD0jduJrttmE3+Zp8ev1vdaoXEoaxgcggM3r?= =?us-ascii?Q?WLaRmtoGyT4keoIT99FLokb+ggV5QBoTA+gfbh63CLBUws6SC6tywkCaNYc8?= =?us-ascii?Q?J4jB49/D8+QaAolz0j0Iphv82cUJ8rMav0XZRtALUt95NvxF+QRbjYkn01+Q?= =?us-ascii?Q?VCBwAy1CGk6S1ZAD5oVZ9+TNjuuUyPhx3I65qQxz2MbnUce1P2rqdbdohILR?= =?us-ascii?Q?PqyM46drCsNUfHeoxgwQ7f2tuCPrHrxr16/bNcHXPJiNrAvka9c9oF1HxxPA?= =?us-ascii?Q?tuRB4ivKvyZZBT4xqeJfOc40Z9Xmf6u7o04S4zo+VlhaK8/MgeFQv6Rs/9vF?= =?us-ascii?Q?amJaN3DfXKltFh9RZMz8SQao2SopPdNCgD37+STzEM7EFTyVrvOHxGpids1D?= =?us-ascii?Q?ZZwsHfGj3iqfMjl36fc+rkJETuBM6Z1sfntvQWxNzabWPt82Ryj+dKGMsbdO?= =?us-ascii?Q?7/Q0Fwt43WQvaZ7E8hzG7yel7vbO3xJPIWtlFnDaD86//3P/tMm3KlHpJIyM?= =?us-ascii?Q?EAmQsDovLnF52GIn8dXzG4l2Cq4aRD+oEC8ZY2GnDeJ4NHE7MlT8jOAVO9g7?= =?us-ascii?B?QT09?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 6:dNlf642N5Ll9LCbXa/Mr91Vj/92NNwmydxjVyNo5LCXaiNEwpjTAm8IrVPW/Olzrl6mXEjsFH/XYR8z7T4Gb54RJKFz3kcK2UD3qRAZnYSLebyizLi5zdViMIRTyt+ITqbSYWR9Svduh3jcDRKzaZcyWR2EOUQbpQDHtqn1BUSBEawfLLIJc7243iALEfzYFXkGUPGXClZH4ypwAlm6euPBXDMsidZsswHY057MHpOLw4S01xKfmJyAQHp6xnjRvEb+1/H2sea20IX6iC0hv6PIaa7xKDzZr4De7HoZ4N9wI+HudCOMi5wizl6Ix4YAirO+zSfJRBofx6cOHlYTpb9NH1XP10XfeLguz0fGsBDrGvLffQJn0+074DhCQQZHtdED4dDlwtl8d1vOWG4BV9z55vqBl7GKwh5x9Ho4WUBX91RLC9q+9FKf0WntIvbtdDvJXEdQQayrREyforyA9iZLnNT8GCPYfZpU2MwgMU7gel+AWzFV19MWhi7Bk90iqnrV+rY6V6B/hBIeIGdfOKkFaCcnWAceiBWiEfkNyX+c= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 5:73hA6mcBSc3dWRmPram+vlHSd+trtzkSFY7TmezkmL5EDakmyihOd24QO97kSzT42DJaqipmK7PGq89nVI/GOuOebJ7X/84cWG2I3zHKKq0M04hgr0wFD3X8gBRuGXVgFUJPdcdYv92SBAHJD8IHpkl9ODWRE6LtVSGljJ7hkO3VBafzcNgBynuqenCD/qvStvBDKoI9VCBsF5pjSxmY/f13Aito80NaAS0RFm8vMrOf3FfA6+wBoatNFUjngvKKkCHJy0YdacOX1sjLFUZX84AnWPUf6VH+29IVNnHrsZqmHyfuVAujkxbU/OuIVjn90BL+c0CrrzO3Z9z85qvsaLdU24mpu6RwyP1AwXEBGIUK7DLsuy181XwjRgIWH3L1bBEV53aNFLtAWD8t6xbamUwVjEmcdBCtfR2b2RlQ1HaYsfmBz7fbbep21YBKHW6jukvRY3vGhlIn5R5uFacsWH4brdsJJQV5fSlQKKzbIbRHo0MgvQrwwPg7b5N7lUow; 24:u983aq6JWl2ae0HwKzAc8d57a6hWYrYM8RUzIoZnjIxq5tCNxqShnV/pW8njSWviHS2CpLZ8Ku+A0tKsmCWwtZLWM5+IijcgDZyeEuTx3uo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2506; 7:LHG4oVhvrRdGULwDw/WjkIiEQ8oiobfBBs+TozL9kEUl9PiLmExzmPfqno9s3CEAi/EeVBuOC40cPc+H1oPHNfMBm5V53JDZxuIE//CEkOIE7mFzomGYQs2bXTdrXa8oTJHvDnjUDmhYQpO57XWyvmt3tdrML3rerupEZ7wnNWLC4g+K6FxPuhYLZRYoRvSQozOGC3lEle0peE4+nzvnksrpoZEWQO4adOvfsVQnUxxEf0dNmFjU4tzk9SpWh1poKcVGOtXGJ/gZJVcNFyqFiwit78Lmj1uUTnr/pyR05Rrl8vUsgGnDQXPuytZLvuhy9rJv4UTF+opM4OQor+R9bA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 May 2017 20:06:28.2614 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506 Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 20:06:32 -0000 --Apple-Mail=_2E48AE0C-73D2-4739-83A0-D17C538E36FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Further to this, it would be helpful if in addition to replying, those = reporting implementations created a new document under = https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports = and listed them there. If you need help with the wiki, let one of the = chairs know. As a reminder, although we don't require implementation in order to = WGLC, we do require it in order to progress the document (the = implementations MAY be reported after the WGLC that is). Whether WG = members choose to consider implementation status in reaching their = opinion as to whether the draft is ready to progress is up to them. --John > On May 20, 2017, at 3:54 PM, Job Snijders wrote: >=20 > Hi, >=20 > What implementations of draft-ietf-idr-tunnel-encaps exist as of now?=20= >=20 > Kind regards, >=20 > Job >=20 > On Sat, 20 May 2017 at 21:47, John G. Scudder > wrote: > Hi All, >=20 > A working group last call has been requested for = draft-ietf-idr-tunnel-encaps-04. Please reply to the list with your = comments. As usual note we cannot advance the draft without = participation from the group. Please get your comments in before June 5, = 2017. >=20 > Authors, please confirm that any relevant IPR has been disclosed. >=20 > https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-04 = >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr = --Apple-Mail=_2E48AE0C-73D2-4739-83A0-D17C538E36FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Further to this, it would be helpful if in addition to = replying, those reporting implementations created a new document = under https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%= 20Reports and listed them there. If you need help with the wiki, let = one of the chairs know.

As a reminder, although we don't require implementation in = order to WGLC, we do require it in order to progress the document (the = implementations MAY be reported after the WGLC that is). Whether WG = members choose to consider implementation status in reaching their = opinion as to whether the draft is ready to progress is up to them.

--John

On May 20, 2017, at 3:54 PM, = Job Snijders <job@instituut.net> wrote:

Hi,

What implementations of = draft-ietf-idr-tunnel-encaps exist as of now? 

Kind regards,

Job

On = Sat, 20 May 2017 at 21:47, John G. Scudder <jgs@juniper.net> = wrote:
Hi All,

A working group last call has been requested for = draft-ietf-idr-tunnel-encaps-04. Please reply to the list with your = comments. As usual note we cannot advance the draft without = participation from the group. Please get your comments in before June 5, = 2017.

Authors, please confirm that any relevant IPR has been disclosed.

https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-04=

Thanks,

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

= --Apple-Mail=_2E48AE0C-73D2-4739-83A0-D17C538E36FE-- From nobody Sat May 20 22:19:02 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAAA126C7A for ; Sat, 20 May 2017 22:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 ufGeX0XhvQqb for ; Sat, 20 May 2017 22:18:59 -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 9F872124D68 for ; Sat, 20 May 2017 22:18:59 -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 1dCJGa-0000PC-Vk; Sun, 21 May 2017 05:18:57 +0000 Date: Sun, 21 May 2017 14:18:55 +0900 Message-ID: From: Randy Bush To: "Susan Hares" Cc: "'idr wg'" In-Reply-To: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com> References: <001e01d2d14c$32ed2e10$98c78a30$@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: Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017). X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 05:19:00 -0000 > This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy > (5/20 to 6/3/2017) > The authors should indicate if they know of any IPR related to this > document. You can find the document at: hi sue, i know of no ipr on this document randy, who so old and stuck in the mud that he does not believe authors should declare support From nobody Sun May 21 12:58:41 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D268112946F for ; Sun, 21 May 2017 12:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmzUXhn-2JKS for ; Sun, 21 May 2017 12:58:38 -0700 (PDT) Received: from gproxy3.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 307B212702E for ; Sun, 21 May 2017 12:58:38 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id D0C38401B4 for ; Sun, 21 May 2017 13:58:34 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id P7yW1v00N2SSUrH017yZWV; Sun, 21 May 2017 13:58:34 -0600 X-Authority-Analysis: v=2.2 cv=VKStp5HX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=tJ8p9aeEuA8A:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=C2NkijaDB96XFB6hWy4A:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=w2l21ksHr2TAUA4w2xbqDZu1HOb6cjJQ+QGt+UIIhy0=; b=LZMjyV4dwkfsuJ8YoaVpoguXMD +weaAfdXOMCzogd0UNjJwGZzdoptwXH5PC9Zn0IOa938PQW9OQktlMQAi5engjjRy79scUuFrfHH3 STSXWwE1p++6+n3HZnjOaDAGX; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:53262 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dCWzm-0004oV-Ok; Sun, 21 May 2017 13:58:30 -0600 To: "John G. Scudder" Cc: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> From: Lou Berger Message-ID: <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> Date: Sun, 21 May 2017 15:58:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dCWzm-0004oV-Ok X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.84.20]:53262 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 19:58:40 -0000 On 05/20/2017 03:47 PM, John G. Scudder wrote: > Hi All, > > A working group last call has been requested for draft-ietf-idr-tunnel-encaps-04. Please reply to the list with your comments. As usual note we cannot advance the draft without participation from the group. Please get your comments in before June 5, 2017. > > Authors, please confirm that any relevant IPR has been disclosed. > > https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-04 > > Thanks, > > --John > Overall I support this document being published, but after addressing some comments, most importantly the first one: 1. I think this document needs to cover its impact on RF5566. My personal preference is for this document to subsume/obsolete 5566, but the types defined in 5566 shouldn't be lost. (BTW I previously provided authors with text to allow this draft to obsolete 5566 as well, and can do so to the list if it would be helpful.) 2. WRT the Encapsulation Extended Community. I find the following rule very hard to parse: A Tunnel Encapsulation attribute MUST NOT include a barebones Tunnel TLV. Instead of placing such a TLV in the Tunnel Encapsulation attribute attached to a particular route, the corresponding Encapsulation Extended Community MUST be attached to the route. Are you saying the extended community MUST be "barebones". If so, I agree as this matches 5512 formatting. If you want this extended community to carry sub-tlv information, then I see no backwards compatibility basis for this and don't support this. Either way, I think this rule needs to be clarified. 3. I'm not sure why the color sub-tlv is still needed. why not just use the Color Extended Community alone? (Is there really a case where the recursive lookup in section 7 would have a different color?) 4. In section 12.4, values should be defined by this document fo the newly established Tunnel Encapsulation Attribute Sub-TLVs registry. 5. Nit: the document says "This document deprecates the Encapsulation SAFI (which has never been used)". The use part of this statement isn't strictly true as it can be found implemented in FRRouting (a fork of quagga). This said, I fully support its depreciation and look forward to submitting the patch that will remove it! Just drop the two never used comments. - Since the question was raised on list: a partial implementation of this draft can be found in FRRouting, notably bgp_encap_tlv.{h,c} in https://github.com/FRRouting/frr/tree/master/bgpd . It supports: o encap attribute sent with other safis. The code uses it with the VPN safi to provide underlay tunnel information for VPN routes for NVO3 type applications. o "Remote Endpoint Address sub-TLV" for v4 and v6 o encode/decode of type specific and sub-TLV formats per draft -00 or -01 rev (this means it is a subset implementation. This is open source code so anyone is free to review and submit changes. Lou From nobody Sun May 21 23:49:58 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8521A1286B1; Sun, 21 May 2017 23:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.586 X-Spam-Level: * X-Spam-Status: No, score=1.586 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 IaFe-jw6KY3D; Sun, 21 May 2017 23:49:56 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255086.outbound.protection.outlook.com [40.92.255.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C11612706D; Sun, 21 May 2017 23:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tUrPdiCPMbbY1xMaklXLDntPCcMtM7mG63WZpOg9gA0=; b=KLE+34ho3+YpXlpaEqJUwzIog0XWU6C3BduMFwxUL0Jwsk2X2awqCvFxED4IHnY52WdJBh43RCVFpJnZlzTQn3S4BaDknZhunf0YllYUsY7xCtGQWK/44OG8aNvhx1znzrg3LRLkbLgEksDZRjZOOwo8ByPrlWSpdXP0OWyXWhOGmnjG2Ddy80ozmy73Lgh6KUwPJuzLXii6Nuh1spxqzXjpQR8SJ243IAYiz+dh/G+Zbm9SwPylBbn4UrMbuPoHGjZOZGSJ+GtGw6ewBXeBBeb1zLMzoo1ovvklKU5OWg7Z9E6fZAwYpd9jqDjSBwfnass4/uGzhsbhuS/Q385jVA== Received: from PU1APC01FT018.eop-APC01.prod.protection.outlook.com (10.152.252.55) by PU1APC01HT135.eop-APC01.prod.protection.outlook.com (10.152.252.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1075.5; Mon, 22 May 2017 06:49:52 +0000 Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com (10.152.252.59) by PU1APC01FT018.mail.protection.outlook.com (10.152.253.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.5 via Frontend Transport; Mon, 22 May 2017 06:49:51 +0000 Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com ([fe80::2115:a445:9d1f:b88b]) by HK2PR0601MB1361.apcprd06.prod.outlook.com ([fe80::2115:a445:9d1f:b88b%14]) with mapi id 15.01.1101.019; Mon, 22 May 2017 06:49:51 +0000 From: li zhenqiang To: opsawg , idr , "ipfix@ietf.org" Thread-Topic: discussion about exporting BGP community information in IPFIX Thread-Index: AQHS0sec79+PG+QhZkiBAviflUwRGQ== Date: Mon, 22 May 2017 06:49:51 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:8047A2B209D0B41D3929C5AD5A78B02155A16A3143AA106D15A6D33A1732F3CE; UpperCasedChecksum:ACEA18884C07D3750BC5AF0C97E0D7AA38D04CEA0A983E399109AA3D7DDCE0D1; SizeAsReceived:8022; Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PU1APC01HT135; 5:Paud577amoEGtc0kWIic3JwYoaPvA/AUVsMUO6QuKAC9GD7EnblYSVpdWFRzOroHsKuhriPhq2kuDDKWh8DDKTF2VmLPqs0IlWz8WpZRxRcc/NvAi4K7/yxj77orKPKDAVv3eEkzWk0fFP9+7FNMrg==; 24:AqyULVUqDjRl+AX5hfCW+Lo0+3c6CD2Q9oQ/PFiE+CEylMyBxWQmfT5u5SBsPuyfLJ3E7qASFcuYQBclVL+gtU/aWydUbC1CBEwAi5M6tyo=; 7:3/J3P5RMKJlI8TbXwHNTlf7Nsw0dLA6YAQ6Joh4RYqS5vIKwfFIkR8Jdj6T+zLTdlJrRQU4phScTNMLX1TQc1syTXL1lEWVO3TnI6yL/JCyq92ulu1p3+06x8eL9LK1iC+AUfyNmm89I6m/CFgoBFjsglNZ0pymu7ZzhEAIGagJatx5uJVjuH+8bz97EMnF34v5BAI7hMXra9+hUl3kj2HuFO1l38OeJxMgBfqCvkYjNLFvjku/O8aJ2mNQBDX95QZOIVjfUsTSykQsIk4j/HYM2xN9ecqGQr72nPVryqE2s3bD7QfLN8LVzWuGJZis9 x-incomingheadercount: 40 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT135; H:HK2PR0601MB1361.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: db830bac-71df-40c2-3d58-08d4a0debcc3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:PU1APC01HT135; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:PU1APC01HT135; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT135; x-forefront-prvs: 03152A99FF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HK2PR0601MB13617E5EA5828A10E5B3D1A6FCF80HK2PR0601MB1361_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2017 06:49:51.8992 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT135 Archived-At: Subject: [Idr] discussion about exporting BGP community information in IPFIX X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 06:49:57 -0000 --_000_HK2PR0601MB13617E5EA5828A10E5B3D1A6FCF80HK2PR0601MB1361_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello experts from OPSAWG, IDR and IPFIX, This mail is to follow up the discussion in the mail lists and face to face= meetings. Since traffic aggregation in BGP community granularity is useful for severa= l applications such as backbone network traffic engineering, https://datatr= acker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/ introduces new in= formation elements(IEs) in IPFIX to export the BGP community information of= a specific traffic flow. At present, this draft only defines the IEs for s= tandard community specified in RFC1997. To solve the following two signific= ant questions raised in the previous meetings and mails, I solicit more com= ments and solution alternatives. Question 1: Does one IPFIX message have enough space to fit all the commun= ities related to a specific flow? BGP community, including standard, extended, large and community container,= is a path attribute of BGP distributed in an update message. Since the ma= ximum length of one BGP message is 4096 bytes as per RFC4271 and 64K bytes= for one IPFIX message as per RFC7011, the answer for this question SHOULD = be yes. Howerer, some experts say the specification for BGP message lenth i= n RFC4271 is out of date. Its length is not limited to 4096 bytes. But I d= o not know the new specification. Solution alternatives for this question a= re also welcomed. Question 2: Do we need to cover other kinds of BGP communities, such as ext= ended, large and community container? Based on previous discussion, large community defined in RFC8092 will be co= vered in the next version, since it has the same application purpose as sta= ndard community. Till now, we do not reach consensus about extended communi= ty defined in RFC4360 and community container defined in https://datatracke= r.ietf.org/doc/draft-ietf-idr-wide-bgp-communities/. We usually do not use = the statistical information based on extended community or community contai= ner to do traffic engineering tasks. If you think it is useful to export th= ese two kinds of BGP community informaiton in IPFIX, please show your opini= ons and application use cases. Thank you all very much and best regards, ________________________________ li_zhenqiang@hotmail.com --_000_HK2PR0601MB13617E5EA5828A10E5B3D1A6FCF80HK2PR0601MB1361_ Content-Type: text/html; charset="us-ascii" Content-ID: <402CE4E4BB0F8647ACB5BF2E574ABEDD@apcprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hello experts from OPSAWG, IDR and IPFIX,

This mail is to follow up the discussion in the mail lists and face to= face meetings.

Since traffic aggregation in BGP community = ;granularity is useful for several applications&nb= sp;such as backbone network traffic engineering,&n= bsp;https://datatracker.ietf.org/doc/draft-ietf-op= sawg-ipfix-bgp-community/ introduces = ;new information elements(IEs) in IPFIX to export the&= nbsp;BGP community information of a specific = traffic flow. At present, this draft only defines the IEs for standard= community specified in RFC1997. To solve the following two significant que= stions raised in the previous meetings and mails, I solicit more comments and solution alternatives.

Question 1: Does one IPFIX message&n= bsp; have enough space to fit all the&nb= sp;communities related to a specific flow? 
BGP community, including standard, extended, la= rge and community container, is a path  = attribute of BGP distributed in an update&nbs= p;message. Since the maximum length of one BGP message is 40= 96  bytes as per RFC4271 and 64K bytes for=  one IPFIX message as per RFC7011, the answer= for this question SHOULD be yes. Howerer, some experts say the specificati= on for BGP message lenth in RFC4271  is out of date. Its len= gth is not limited to 4096 bytes. But I do not know the new specification. Solution alternatives for this question are al= so welcomed.

Question 2: Do we ne= ed to cover other kinds of BGP communiti= es, such as extended, large and community container?
Based on previous discussion, large community defined in= RFC8092 will be covered in the next version, since it has the same applica= tion purpose as standard community. Till now, we do not reach consensus about extended community defined in RF= C4360 and community container defined in <= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-idr-wide-bgp-communit= ies/" style=3D"font-size: 10.5pt; line-height: 1.5; background-color: windo= w;">https://datatracker.ietf.org/doc/draft-ietf-idr-wide-bgp-communities/. We usually do not use the statistical information based on extended commun= ity or community container to do traffic engineering tasks. If you think it= is useful to export these two kinds of BGP community informaiton in IPFIX,= please show your opinions and application use cases. 

Thank you all very much and best regards,

li_zhenqiang@hotmail.com
--_000_HK2PR0601MB13617E5EA5828A10E5B3D1A6FCF80HK2PR0601MB1361_-- From nobody Mon May 22 00:13:10 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3D7129B7A; Mon, 22 May 2017 00:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 lzIT0TehTNO1; Mon, 22 May 2017 00:13:05 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54002129B79; Mon, 22 May 2017 00:13:05 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 85D54A03D1; Mon, 22 May 2017 09:13:03 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 55ED340075; Mon, 22 May 2017 09:13:03 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0339.000; Mon, 22 May 2017 09:13:03 +0200 From: To: "John G. Scudder" CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" , "idr@ietf.org" Thread-Topic: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHS0aDeX67d8sloskeDYSDEq7Y1FqH/8SBA Date: Mon, 22 May 2017 07:13:02 +0000 Message-ID: <26881_1495437183_59228F7F_26881_13214_1_53C29892C857584299CBF5D05346208A31D21DCD@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 07:13:07 -0000 I'm not aware of IPR. Note that this draft borrows a very small subset from RFC 6790 (Entropy Lab= el) which has IPR https://datatracker.ietf.org/ipr/search/?rfc=3D6790&submi= t=3Drfc Regards, --Bruno > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: Saturday, May 20, 2017 9:40 PM > To: idr@ietf.org > Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@ietf.org > Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-n= ext-hop-capability- > 03 >=20 > BTW I forgot to mention, authors, please say if you're aware of any IPR = that applies. >=20 > Regards, >=20 > --John >=20 > > On May 18, 2017, at 12:32 PM, John G. Scudder wrote: > > > > Hi All, > > > > IDR working group adoption has been requested for draft-decraene-idr-n= ext-hop- > capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please > remember that we need affirmative support in order to adopt the draft, s= o don't be shy. > > > > draft datatracker page: https://datatracker.ietf.org/doc/draft-decraen= e-idr-next-hop- > capability/ > > slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides= -98-idr-08-bgp- > next-hop-dependent-capabilities-00.pdf > > > > Since in part this draft specifies a replacement for the Entropy Label= Capability Attribute > (ELCA) that was defined by the MPLS WG in RFC 6790 and deprecated by RFC= 7447, I have > cc'd the MPLS WG mailing list. Since the proposed new attribute is a gen= eric container with > the ELCA replacement just the first application, the current draft is ta= rgeted to IDR and not > MPLS (this was discussed during IETF-93). > > > > Thanks, > > > > --John ___________________________________________________________________________= ______________________________________________ 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 Mon May 22 06:20:09 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8D0127873; Mon, 22 May 2017 06:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xC31hEO596mg; Mon, 22 May 2017 06:20:05 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0126.outbound.protection.outlook.com [104.47.38.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D398812E04F; Mon, 22 May 2017 06:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KVW7C+tykIXEecRlpfAHTUToztxf2yuDcN34MZ5DF0Q=; b=MVTUcAaOnH8Cf9K8hbVaEQALMiDsqTDu8AgWTOb3EUyEIpKXNkkDeOwFSsojpRfLAOmZKWtCTNGvmrsigj5NcKSoYD45SiEiDbwTZouTDAIBKCJQjY1ZkTVmI1y8nFbEfX4M7nVWtuA1PsCSImw6H7aNfyiXiA9WSOjxLQ6Qkr4= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.195] (66.129.241.11) by SN1PR05MB2189.namprd05.prod.outlook.com (10.169.124.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Mon, 22 May 2017 13:20:02 +0000 To: "John G. Scudder" , idr@ietf.org References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> Cc: draft-ietf-idr-tunnel-encaps@ietf.org From: Eric C Rosen Message-ID: <1ecc0225-adbc-5f91-10eb-b28cfce35cd6@juniper.net> Date: Mon, 22 May 2017 09:19:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: CY4PR20CA0002.namprd20.prod.outlook.com (10.173.116.140) To SN1PR05MB2189.namprd05.prod.outlook.com (10.169.124.137) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PR05MB2189: X-MS-Office365-Filtering-Correlation-Id: fadfc16e-bdf1-4455-5043-08d4a115416f X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:SN1PR05MB2189; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 3:sRsgYsVzMAX9wK7xZXzgTtjyISL4oQsDnPic/UTSr6SRauiBkfcIQOjxB8L1R9gE+mk/IBiHkrsxCUkDW1yLfwID4tZ86kn8zSwjYAcbMzT6MTl/9uoVwrCRH7hR5l+uiL7ed9C/FHkonDNhuWvHaexLN193EbTXBU3l4df2ZcSB+r1UINcUrxF0ppgpeJhJP93BCW84LO3J3bH3PYZsq+CHXUGApjKORgBj+Oasm/mY2pJexswSgf75pZGxc0mNDikBKsiwfId+UJvHQ7oA1suBy6Vd9hPHWL7FbqE6vDH4hBqGu7a0m0cjBZpGOUxvQYrsn57Uv80KoV5TuNzHm1U31Ex/bhxyUIHBPCPzbaE=; 25:zLbVcuBJj7ts08I5bAOvMgTGaYjtt9xl0bU2FW+KGPXSodaqjQnS7aQxyW2pn5O20ra1j3VRPxK/K9SX925msFUXS/96KzuCWvJs4I2INRWrhMeMcZtBvNDnvdZK0kAyHODOey7p6H1Y7L/HCOLHC1BLBN6nrIMiorZQ8UD7EVoenwtkdQ33cOTnmSuUwo2rQLKMr9C9veQekNnYr9pNlhx1gSKD30niNJF3XLcXTyWOss3f/BxUtRJ8NmFcFQVcabuCW1DbTxrA0Qlh3GnE3FWNmYG3o12hE1lkUa2sX4xkig/jYRUnqnKvGviaqdAL+DCYR3kU8X116BVegXNL1jyCSUNIAHoIAnVx0BXwmg1XUYhHaYXkOIZvJa+H5EchNbA9OCyLj+JEslip0gQ2F/2ZfHKrCvJRJ6qH28UjwhM6Epuzv+wqZsI8KqppBKtEzE5aixSbwsLqKGxlnuIj7gy2TMJVATKNXvYecqIBsVQ= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 31:6xWlEgLHHFbPyE5cnQc2jtb0yDdgDLJ8bEn3dc4yXi6D5bwHJjmLgF5TBa8p0NjvFOjkr0P1z4ELJXiH5cI1eL9kdpIOURunuVbyUXz5FgmXS3M/3gmqzYdKrQITciQMjBpaHCcdlbjQBhwEZertR5JrNNap4N0TrR0QEGrdhf60TGwSybhwX4KA1FjIITe1lpk2MgqSmcx4zcv+WWXHs2YiWraRMFuFICUPvXHu3n+A221tMy0i1j8fTJuTWrTNmBECUsvtEtD9n4zQpEruJA==; 20:YebR43AbfhbJ1uQxaaKhQrqncnEasYmr817CfL2wdi3omLky8l29XkIlUshyq3fU8ne2DyzbOzypG9eNHTkR0Gv13y8VqOTYu8FcxNc8YwR5me2mwlBV4xj8bdQDIDCDsuDl5N78Lq8wIIlox6ZhsznpYX8JJzlhChXZ6J+deybQoSqRqi8o9ReKB49LRI+1vVLcKiiG3VHfOCDOgl//01Bdtxxc0MuhE5I/OEVneK5nqugCglVT4gF1vDjW/Poh7+/yalwXfdqTIN9oGdXBHQp0g+u4Cie05uGBQnj/lmiNmqEsUmw8ZQJwdbMqVEBKiWJbOmNUGAZMorUr7byf6Ok97WafjjAGUtw3RLzj1fcLLiDzDwTO/XEsFt4ZKAvthoNCIGdcFo1WPfoAiZR9mwJNE1srtRzeswsn/dicds8fQIJ+1Ttw4fht/wFRnngjQ6NReV09w/En9ViVVu0LgYA6rV2k5Jqp7EUe7oJrXv4dkyJaD2kCIAjmJQHriz96K4WA5x0+Pk7YrbITP+RWY1f51EFVE4KwVu3dYN933KarRghFRDhoLHcJctjGVhklw8RK+wfsuNZdSgG5Vg180EcmRhHKu/2qHHbRf+ElNag= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703036)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:SN1PR05MB2189; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:SN1PR05MB2189; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; SN1PR05MB2189; 4:0Qk+TI5o7cVgkpiaRxhTZDOrntoQRoh5abUuA/?= =?Windows-1252?Q?acn3EYePtR4B10/rBM0xkEl3tyKSes0FprlbEihYymnLiCcFqQrbzkQ9?= =?Windows-1252?Q?go3q3n4y5DOPpAEqbWH7Rhaw/EHVWiNXBULH/9iCDKbeNXwBSJ1h/Asb?= =?Windows-1252?Q?h7eduti5/Gx5TcMUcXrMaUM744lPLtL7W3XnC8dM47VE2g5ui9bI79rm?= =?Windows-1252?Q?g4Hc9ikZOoyGPJnWp1sgBNEFIla3zvojNpKps4qJoT5pVcgbci1T3t9u?= =?Windows-1252?Q?3g0ftWXFgf5AYdyq2NhMFsjIcX2kxl3en/zKpvzW+9oG2CynyM7pPOwL?= =?Windows-1252?Q?4fbaJc6lHyAYZ/ZZ7C2Yw6Fx5whjKIHQR3UvxtlFnq+AozBT7W2QSp+x?= =?Windows-1252?Q?qBSNvSztWKMfrLDYVggCB7WMfWOQotEydhWsNB/WyFm4CQ6HiRjCnm+T?= =?Windows-1252?Q?Ne0rM+1chOTRt/aiJEgAPy6a1Y6h9QXW2+sB5bAN0DX8XypFPg1m8X/1?= =?Windows-1252?Q?rZELfPI2A59o4PotUuqPLEwbkbAXfS1xCIWs3okeI30EkcBkjPR/4jk6?= =?Windows-1252?Q?Q1wCFKbeIQ/JLKUoUESxR09J6eiUO1/X9J9nx6UPkg9gTucz95vsBTWl?= =?Windows-1252?Q?Vc7TFWx1AqMHAyCEzvcYlNcEGlzz6p9U6T47U7SwgPfA6zu7TsBj1/oK?= =?Windows-1252?Q?w2VZTt9ku+lqLHW7APohs/UF8qDGsbu1nLVmNx159w/44qcW16q/KsqO?= =?Windows-1252?Q?03mtZkK7HZPayWt7boGV0LZ5B/yzd6tAzv6YV+TSNp391/mfGut+0Spr?= =?Windows-1252?Q?dlcFATmo+OZ/+UpeOMJ/Hj3gCEqVHoAozc1TohNXnox+3dmV9Qw9OiCm?= =?Windows-1252?Q?Ib/pxCw66QVVzw4QqpvVy6XjKq4lEDYqIXQ1nbPWXF51ua4/+AmjBrPq?= =?Windows-1252?Q?asgL397piRreyTl26RlKjJjqAMROHlvY1d7u2DJ7WGYY/fRlFfcIdy0y?= =?Windows-1252?Q?1sSQwyvbYXs33arTln7alww451N3jX8fyfJHM+cGolWt7g5tlQ7m/8/n?= =?Windows-1252?Q?Dm0zmGEHhYUgSM3BIV3rkop0Yr+FeYB4qs79OETqqIJRoqB9Oznx1mna?= =?Windows-1252?Q?M2i6INxG1kBtAvtFQ16OqqHlF4w/22yaZ7PR3w/BBnU2EvdaVtS/+LSj?= =?Windows-1252?Q?kQ4gwjY6G4fo2nyJ678dIfVCmzbDHaxT/2vEAhPh06jKLpmhYq+1K7Hg?= =?Windows-1252?Q?dS/7qr0LRuQtonCQ=3D=3D?= X-Forefront-PRVS: 03152A99FF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39450400003)(39860400002)(39840400002)(39400400002)(39410400002)(39850400002)(377454003)(24454002)(2906002)(65826007)(42186005)(47776003)(6246003)(7736002)(305945005)(558084003)(36756003)(5660300001)(230783001)(33646002)(31686004)(3846002)(64126003)(50466002)(6116002)(53936002)(38730400002)(110136004)(25786009)(54356999)(3260700006)(6486002)(53546009)(230700001)(450100002)(77096006)(4001350100001)(189998001)(23746002)(66066001)(229853002)(50986999)(81166006)(478600001)(83506001)(4326008)(86362001)(31696002)(8676002)(76176999)(6666003)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2189; H:[172.29.35.195]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; SN1PR05MB2189; 23:9A9nYuW0eOotQ8flLzaWDN/blAV2ydfhCz7w8?= =?Windows-1252?Q?DZZcAeDQkkeHIjCpEXkOqHvo7AuTwTywVgOrMBbIqUx0uJFPDH3yR3KJ?= =?Windows-1252?Q?clyx4zUr1aCrMPJRnFHoHcQv30b4ev2p+moj3YgAr5feYFoGI4ZizA3p?= =?Windows-1252?Q?oqhYrmPENEo2+we3hGwNtd84OxoBQSaaaVzmY1HJNFKdqulGpl/qdqAZ?= =?Windows-1252?Q?eDDjzWYGbIjM3g0pjBtSkboHbNnMfmyKlcnMWqgRbaR5awkywkDj8s5X?= =?Windows-1252?Q?Fw3nNGWcFm8d3iyED6IllaS3kK1oPZd9OK0hA4vg+femf6Ks8PiiMSl4?= =?Windows-1252?Q?ppAJytece9tXnAzcnaFaqFQdHpjp5Q4xv5A9wr4fPssLFFB/CsM3xA+G?= =?Windows-1252?Q?bOCECrhMoq2AxeX61PwAhGeVnhRDNQZv6nODoDDaLWGFMP/Sk+dGxIcT?= =?Windows-1252?Q?cW1aXziWrWNV7AJkZzX4g7W3EVflPBzcGaWs4qVI73hOOUqY7g9/0U3R?= =?Windows-1252?Q?4I0LuQ5LFP7knsXmyEn+G6ZWhdDRbVVW2Wq7fK1FwF9LxWPJ494mpkD1?= =?Windows-1252?Q?hZRp2iWcITRvo7Egk85iyq4QA+aU63MjTTrxzUAwnO/F0wg1IY0v5FXp?= =?Windows-1252?Q?3IbUY5igwXn8LgDVwN27ZJXkDr3IKIicFO3YSjroh3HfutbpIyrufc1+?= =?Windows-1252?Q?SFG15Y9jExUysNG2QPsgIBqNBLzvHYx2m+d3CwCsX8KUMO3dLhIuDT9R?= =?Windows-1252?Q?8SWDfrzf3sawIOmWxMs747sC5nwdeGsN+HF0u7kLe2XOSdGTkktuYgIk?= =?Windows-1252?Q?5RXi/f8paxIYY5+CNmV87x5EpWvRTtttBciooK6/EFNXqcpZlzBtz/71?= =?Windows-1252?Q?KWdj8VRO8RATkAWARzheyZzVArLlXqhSXnrG7I69mLP1KGIjidMCC3Ja?= =?Windows-1252?Q?EXeH73Vbj+7urvVK8y5A5YUcp50fQwze/myg1hDSbe16FrQn8ok4mCUH?= =?Windows-1252?Q?kOrvJ4qds5oVEIIdjXFiCO1MqXfdjDEJnVBe7ema+XGphXar/sqkYBgF?= =?Windows-1252?Q?PyoWHnCLH4vBunYKBxvoinYsghgDHeBkboCZJiGkUmMg23SbbjjpfL4m?= =?Windows-1252?Q?1Hs5Qgk3X2U/kr8iDIbyDmAHrrb6RjnU+o/B0Ksmb+kKjF+/z16FdYKr?= =?Windows-1252?Q?xwQS4CNSDiA2a/IOXE5YU5eL38Jdp48b2nxqt9Zdq47Y2pmQNq57He/I?= =?Windows-1252?Q?/nyr9HSnzsv8NnV970RU8UWrRoGnC9E/M9bJA4WCFZlCOw7YR15MXL3C?= =?Windows-1252?Q?aPQDCOrvGgxcCddzg5shLItEE/52DzMZkDASWiosGVfvinfuyBawKbyY?= =?Windows-1252?Q?MslxLoZJRVp7EcFnvbHsx1NdffKABtEN4WtQNMH5/8bLe/E9+sToRoCH?= =?Windows-1252?Q?3zlM8kRyD+8goTcL/VcP0QEr0Hp3DD9z4PZ/QvXO3ZROizFT+qKYCAio?= =?Windows-1252?Q?PNNpTA=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 6:PnIr4vSI8lggAWlHutlzXjuZszKsKDFhwhKGaLarCcE5DQ99De4pyivQuHKv8L+JXigT+9XhaohdThWNPL/YVPTEaY08HI9JJx/RQotXyK/JhDgMf38mZ62L2YdcYv36QWLg6ny7IPt7HftI96bxQKMgRY4CgsOgGYRcp/LdNlvdEconN1+5SgeRraLeOv3kG3xLsVBHnFRNdHdwMts/jdwiGHWL4etC7E8iYychoiX7dKrebl0u0tkB1+DpB+2mNCtgu5hWr9JDazyBKHUnEVfaaqgxUXwRZKFR6Kqe4JxYbqlMDpHmvgZWgkOjHp1hm6U3TuZewfYA4ynh9NpmtaHKS5euszswqqNUybmaN3cpGtdAemlkwIjn4mm4O6mC+0peZ8aRLXEUlyMjUdnQtT1CtcXDpgjhapWkhIBZJwgw/LAk7FBCVY/wm0kxLheFDlAcixtBTfe2IohjXRujaUDe8TWLwKRvjip34VinJnbepyvZk/p/Ro29muIkL0YcfwhNDyEIkUpedBBc+32CrJGj4ompxUWCzzgdm6+TbXs= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 5:fMgY3rOAuVBup+5FC24ukGejdJ7g+XGR0fM5IlJs4N1dEc2LB9USl2TBDhScG/A89EdxXehKCeFtdC+L3P1l0+h1ycUR1BXEXf2c3NE1E6frMU+VRcOrs/vXZ+C8WwKOOhiucUOZRCtIm2mVXWjDCxOMFYqu3rjHOtosOwrAg9vU2x1/4pxnOX5OtWsGfIs4AfYwHoCOPnDr8pIRUElxuwItlRKbQBhOGEZ8DBZg1kE05eoovySv+BSRZUnwQwZBurjqv03YNRcfFQm2e/waio1SYV4iJcWUm1ET4J6hEG6k8aaJ/hlDc5aTleu2vU1PqWKZFbd9aRClMQZl4kbGDW+GAvXJdYJeah67Un3q7Eabn8cmX4jgAR6CocZCGcS3ql3K8W71sMlQzEk4MeBOOJM/L3m10GVuCRlK4J9Uc0fALW6+ZEPBxUcfd9uVF5Eum0Jzf2Hy0exq8gMZNrUNapmXL0UwZtS3wKU6JG16CIAWIC2mysY6AR/npFqgLBPC; 24:FzuvaPHef853fZRGbgXGSRE50oSbe5BTnduo4cXqxHTnuIUDzqtJlBk4pbaPgLAoJPHOwTl2JADs7UIeerYiH58WstSufCMquBpoXS9KGnc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 7:7h7NtuVFOgUea5DJpN/lU1KKAgdP9uGGMxbQ56u5A6Hhix12CKeiwJ0zK7YGPiJ3iEPoALR416mKt8mMss017pOOQY9v1tk8Q9CQFw40vvFxoQ9xtqYvXNq4B3JEPpMDXRvtbvcu8GDK73/f2/Lb8wT5Qs9th9ASE6/+VkospmFOEipoV/ALKFuM9lawjrKQuNmce3hiAu56wR3le6SsfODwtQg3bsafJT3uAoP6X+AjnRmWk8Ix/9mwTA6n+NiYY+6Bx64wnZco8Ha+wTsE+AlvdCgXn3wYqO2cO09t9/nn4NIHvfFyPL8I1D7Rt5jpVU5V5To60jIkWbX1OfLGvg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2017 13:20:02.1687 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2189 Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 13:20:08 -0000 I am not aware of any undisclosed relevant IPR. On 5/20/2017 3:47 PM, John G. Scudder wrote: > Authors, please confirm that any relevant IPR has been disclosed. From nobody Mon May 22 06:22:12 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C83D12E052 for ; Mon, 22 May 2017 06:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=highloadlab-com.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 JH-_0fz3v14I for ; Mon, 22 May 2017 06:22:06 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 43D9312E04F for ; Mon, 22 May 2017 06:22:06 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id e193so82453804pfh.0 for ; Mon, 22 May 2017 06:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highloadlab-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=HHOCo1gSgIKrRc96QQCadSA/fVwyFyuz92J44d4c4mU=; b=RkI1hXGn4zAAa7nTUGZgFXqgVCobbmfF8FtpPSpysBO8bM6qHCgdnQdr1Kyapbvrjq CcqDcsRUhnhMVo8AcYM4XZ97j0hwlpttWlQH71oAKkzFrPnlXJtzuvM0aRDWdQDZ6+qW Sb+gKbRejj1+MmL+kPvX9kdAcRHCD+3ZARUbfuZJtJYLSW3A/JiQMNoxgbd8gmq3NKWz RaQcT8U9m4Uk1mAlcDDO7dMMBkUfqrNPBCJFBlm1MaJeitcX4R1HalmVfOZijutncP+q NVu6ua9A9lz8P+M1ITCtRxlC404H51DUFNpVdrbt0EA3mwiE6580Zw/SgUPRl5sUCu8d 3e9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=HHOCo1gSgIKrRc96QQCadSA/fVwyFyuz92J44d4c4mU=; b=NZ+3sdGI81V7XVP1st9NB03WH7VlHS6FqhfVhmKx+KdQFhu/UA75NYKobPIeUA+/D5 51su1lx9m8R+rJf+Ft0dFpSvon0F2ItlI6/hBbrkMnfBZfAL1LY/9A0yPflI+E5+dEku 8qbmLBd6ZHyo2+FgAC8goXrRLZaEEt7bScUGK1tcJ0vh3gvuDJkSXltiVmLW8ErZwxRX HyZ56IqhVnaOLN72QhVoa+Zh0kI8poxU0pP/k69ns31uSFfDZIQuDFc0Awm9pTdlvsIz eGjiNX8MHLMZwKaIJ/PuDGiUyHzMFmtCyneKdzPFG8WmdK/q5u40AYBr0WHqSw6cz7Ej oaDA== X-Gm-Message-State: AODbwcBjFB//CKbFnoDZkcDNYto9SSZ64XGfXWUZKvTTqJt/sXq3R4mJ HpjPVfHU1PH/NZKKyIVhRRGGhqO+QTxm X-Received: by 10.99.1.207 with SMTP id 198mr14232619pgb.37.1495459325799; Mon, 22 May 2017 06:22:05 -0700 (PDT) MIME-Version: 1.0 Sender: aa@highloadlab.com Received: by 10.100.166.74 with HTTP; Mon, 22 May 2017 06:22:05 -0700 (PDT) X-Originating-IP: [95.143.124.62] In-Reply-To: References: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com> From: Alexander Azimov Date: Mon, 22 May 2017 16:22:05 +0300 X-Google-Sender-Auth: YBKepkOEcdTJNTY6g5PUFxFgB3c Message-ID: To: Randy Bush Cc: Susan Hares , idr wg Content-Type: multipart/alternative; boundary="001a11468e40e4041805501cc1ee" Archived-At: Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017). X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 13:22:10 -0000 --001a11468e40e4041805501cc1ee Content-Type: text/plain; charset="UTF-8" Hi Susan, I am not aware of any IPR. 2017-05-21 8:18 GMT+03:00 Randy Bush : > > This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy > > (5/20 to 6/3/2017) > > The authors should indicate if they know of any IPR related to this > > document. You can find the document at: > > hi sue, > > i know of no ipr on this document > > randy, who so old and stuck in the mud that he does not believe authors > should declare support > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa@qrator.net | visit: www.qrator.net --001a11468e40e4041805501cc1ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Susan,

I am not aware of any IPR.

2017-05-21 8:18 GMT+03:00 Randy Bush <rand= y@psg.com>:
> This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-po= licy
> (5/20 to 6/3/2017)
> The authors should indicate if they know of any IPR related to this > document.=C2=A0 You can find the document at:

hi sue,

i know of no ipr on this document

randy, who so old and stuck in the mud that he does not believe authors sho= uld declare support

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



--
= | Alexander Azimov =C2=A0| HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto:=C2=A0= aa@qrator.net=
| visit:=C2=A0www.qrator.net
--001a11468e40e4041805501cc1ee-- From nobody Mon May 22 07:28:03 2017 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 A2DED12EACA; Mon, 22 May 2017 07:28:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-idr-shutdown@ietf.org, Susan Hares , aretana@cisco.com, idr-chairs@ietf.org, skh@ndzh.com, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149546328165.14094.11053425207224059343.idtracker@ietfa.amsl.com> Date: Mon, 22 May 2017 07:28:01 -0700 Archived-At: Subject: [Idr] Alexey Melnikov's No Objection on draft-ietf-idr-shutdown-08: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 14:28:02 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-idr-shutdown-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 2: Shutdown Communication: to support international characters, the Shutdown Communication field MUST be encoded using UTF-8. A receiving BGP speaker MUST NOT interpret invalid UTF-8 sequences. Note that when the Shutdown Communication contains multibyte characters, the number of characters will be less than the length value. This field is not NUL terminated. I think you should stick a reference to RFC 5198, which talks about subset of UTF-8 intended for human consumption. I was also thinking about language tagging (RFC 5646) for human readable text, but I suspect that nobody will implement it in your extension. From nobody Mon May 22 07:51:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC6812EAED; Mon, 22 May 2017 07:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xvsDDRUYR8K; Mon, 22 May 2017 07:51:11 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0090.outbound.protection.outlook.com [104.47.36.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2C6127078; Mon, 22 May 2017 07:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZWOf6WRLzMO1kNnhPD1V6AFdCIf0rWqapQvIeCpnjb4=; b=EX8S9f0Hg+uBVwba/4gDDqvMQkZ78haHvEiS5JiM1nPB9EjnxvlLGL6grkWMZYstPkIMkTqtJiMES9y9GrklDWRls1LVxAqzNXOXYJkB3yJAoYYcqYtxwcmXN3LdeTYb8nJ3x25H4kdZ5lmXkdHZDyNbtP15ehaiQVKYyEbf4Hs= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.195] (66.129.241.11) by SN1PR05MB2189.namprd05.prod.outlook.com (10.169.124.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Mon, 22 May 2017 14:51:09 +0000 To: Lou Berger , "John G. Scudder" References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> Cc: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org From: Eric C Rosen Message-ID: Date: Mon, 22 May 2017 10:51:05 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN6PR1701CA0021.namprd17.prod.outlook.com (10.172.26.159) To SN1PR05MB2189.namprd05.prod.outlook.com (10.169.124.137) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PR05MB2189: X-MS-Office365-Filtering-Correlation-Id: caae1b59-2e10-404b-c1fa-08d4a121fbdb X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:SN1PR05MB2189; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 3:ygIyKMqegJIx1SCgTX/Wgn1bVX45N7wBknUOt9DwHaOKugNJnarJtTJv5uBoCPtEPJsfDrewLDl0mfdODF17ZWJsq4HU1obhi8vuLBTngSFhFGU6bkUgo7vJeItAxaGArkBs42vdCfkMugAxKGtP65yvB9FkyllC/H0UPrfxiClCX/FuuAitwC+z/GmJk/OztNYgqP23mL8bIZzOlGgY98Tf/d/1UYhW0BcOtzUgjuGwRWVn1i+BZhR9V26KRjxBhJZiEU8S0msGXK8BiAvsHm2wCMdkeJ5K/+LSUf4wdmWIKPZEfDvL322yvZOPVKKoV+O3uViWijJPZyjnbktfPfqS4sC1zThBScMxmnyIHng=; 25:IIMfw2KWmteYHH9eElqY6rIlEo582AKNf75eAhxagL/2K0Igkplw1hX/Djtdww8/Gbhz+EBoKXGcnw13rQYqfc0STaVxU65h0d2IErgpQF2A4OYCN/IU1KEZboLykfV4Jsa9X3NywcWKrq4Q7sk8E0gvpCsMQk/dIolLuGlDzVG6I/X/Uy1b3ptsCW6KgNkcE19W3bPMLUzwgTBxUYbsdVvfepEd7XYQhVbooscdFz35EX9qrY/OG4a+E9SpNp060RSZYvPZly5mlRlgzWXi3JVS09+BsMuGCR+KvNaxWQR9QZREpX1j/U+28vkPvKMbH8MNCbzmfBHPCxACXnBl1KsuX2MeKAoZOjemzeODOxjnKwcDQe7YgF+6cKvErPhYvBdAmC4ILD+J8g9T0QlHdwBnTydrkx8d5AvVTAIat/6e46Hrir0qYTnPp0+g2NTMGjm/QMEUcZU0Xm0OMpVf7s5p3S9S6BOxpMy7baOHPp8= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 31:HME2xC5tkcRjZcrEUuGr6rmjYjmqeyRmHVIQsmhAm3adBIM2IUvmhAcBSw6pPQEBget8sIXRk2mMCQjzN2KpEuRF9+1hpfqQWmLagcv3AdrezmFI/QgJHVHjVPhxCC8/WoH28HNXAK4wz4yzkWTyQlk5cX1CYIIZWmPTgkgHtTeGHwShY0KRCEXbnvK957JTz2dq/CCO//7lyJfLI/jB+C3Y8aQ2WbrXiMssOt13zNo=; 20:FawG+weElDuMQQU0XuClUFASKC5vIOLkJYPoBa7+3N2HT9/AtSuxp7XfzTjxWViw0RZK9vlVx3Tp/YDQuWr0Ukz3UOHM05uDCRWAGYT3O1FBs3wphGRF5j8hmtokvr3TExpGrnlf9JjwKZLDx5jK+zrjFrY+v3UUFnuG8CIgqWXlBmktb463hGq1al4oiE7ZKTjI88IkdSBVNlstzg9uVSdj2CGPnjJ5PkQq5un9gqt2yYjkuyP3baVcjMHbOlgi4jb4RzPPW7mpHweBjV+Dr/UYQU9+jj+o3DymU1LyCufEtwE2PRPAU/MHwRqM/Xnc1XCNXGm+Bvay5vYZcvGdJMI3xSZNAa5DmAbmrX3PCYDKrlfTY/q94uGHd8IOGR9dh1PxpYXCE2MDlimPWleGIMMgU7eMTWbVHuYRETOHGUGSPvJTKcSPTESP589NVWDDpDIxRLgeTHw4mHMZ52/YW/LNgxi23pyTm9Jt1C2hYN81mHfpgpYmaqjWFl5M/Z/QxjN0Qu36oqjXw5QLAdEDaXmZxh/JiyXiXwh9O+uPpwM/hLnjC6QimSGdoa3Z9tFGIYSysdTxM4AsRV7Rvv5+pQM6dIqwGF2XaiBDdVqkG5w= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703036)(100105400095)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:SN1PR05MB2189; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:SN1PR05MB2189; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; SN1PR05MB2189; 4:Sx11gp+n2fl/kgSohqXDGy8OAzkd7NA0lizUWh?= =?Windows-1252?Q?scVfEu/q6xHGkSMLL9sD5qDHQNKougC8Q71uNdTyBknudQngTpCVEugq?= =?Windows-1252?Q?QVzNzJcarwkh5k77nxrJz3zgFR57WQuSm9KB6KOx1e4wHlfy7szhnRtM?= =?Windows-1252?Q?My4xJSk8Co1jOFjgoRWFKhOuUkQBlpLOkDRndYW8B6TSoCD4belGKOVP?= =?Windows-1252?Q?9lnOrhZDLZl1OlVxZf9NoXOzLVscpZXLnVdIS/lfGKuYkI449ThmIbl9?= =?Windows-1252?Q?6ED/YP2U7FJfXSKF/ti2GlXvfl11NemtGP/OGCgcScELGbX6mnx0rlWX?= =?Windows-1252?Q?X7jfphiWNODRCRyTT/XYLAW28hUYA9M0r0Hu81PmdONmes0r58D3Wb9D?= =?Windows-1252?Q?c0Z8FKtTxIB66qPvZXDmBpN+2gMLnBrlANnSb5sZQxi1vvJj58Ehxqs/?= =?Windows-1252?Q?F8MrsIug9lHgo84T77mjtlr6byZclSSni5pxJYT/Cek7JpCINlWOvFwG?= =?Windows-1252?Q?FlACC7f/TrQuk1Jab5vhyHeuX0b/6FfTKBG7GRONjoak4XMc+4HtEqkf?= =?Windows-1252?Q?zHQRBManVZ4C/o16KFQCLpTDTrou2tcm0KMQhJ8trmp/mPYQmmcxT/jx?= =?Windows-1252?Q?6eNOFfwCgaO4FLYPmHEf7HxqVwdiLRBWetgKTE7r+xm++vX41E3gYIGe?= =?Windows-1252?Q?kk4VBGh3eJoN21CQ92r6mZ2oQ8WIZ0kzDkw1/M/JNDgqmk4+wVoXY4eP?= =?Windows-1252?Q?K5vgdiQYWbdCHxNje4S7xuNmHziOFUE3uMOfGib0HtiEtC9Gw6d+Gpbn?= =?Windows-1252?Q?lThuI7XgDR6OPylr+hNq1ZfjEAWOXrSb3GFLioe80jEQlpsgehYyawBl?= =?Windows-1252?Q?NMuaxJneQETqju13+U8KQLqZU3PJycFunIKKtttpwaw+nsMDB8bXUxJG?= =?Windows-1252?Q?dD84GuK69394u9twfyinnubSVZabKrXsjxUXSS7PiQjOKCdFemu3dRR3?= =?Windows-1252?Q?DRm5XNVQ8CaNMl+tDDzHrHNqCkdbtlrTR6SF2naFZuMqECdq/ut6Njka?= =?Windows-1252?Q?r9dAvSuGOIUUf4bmeqfWOSFtXYTNHCeqjt29PEMpesMUUcoUu8T9YGUs?= =?Windows-1252?Q?z3VNc6ubkMK7PHNtG2Zc+JffPqYecsWczMyGHDWhep+pywyos1pZh98A?= =?Windows-1252?Q?QwldpFY7ggO2167qj6Htz+3Yl65xY9eJjsegLrp+b9QK9c/wdH7KuNQh?= =?Windows-1252?Q?f90fGQclaq4kqkgtOh/7sC2Tewnj9myxFbUAozSZPeT8MOlISo/SHzgj?= =?Windows-1252?Q?RM?= X-Forefront-PRVS: 03152A99FF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39400400002)(39840400002)(39860400002)(39450400003)(39850400002)(39410400002)(377454003)(24454002)(2906002)(65826007)(42186005)(6246003)(47776003)(7736002)(305945005)(36756003)(5660300001)(230783001)(31686004)(33646002)(3846002)(6116002)(50466002)(64126003)(53936002)(38730400002)(5890100001)(54356999)(25786009)(3260700006)(6486002)(66066001)(53546009)(230700001)(77096006)(4001350100001)(189998001)(23746002)(229853002)(6636002)(50986999)(478600001)(83506001)(81166006)(4326008)(8676002)(31696002)(76176999)(86362001)(6666003)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2189; H:[172.29.35.195]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; SN1PR05MB2189; 23:Wg0hBFYvT5jJhRdp/b4iiEMlP6BDSXhRWcVGP?= =?Windows-1252?Q?aAflFSdgYTfc95hVSeGygBbGMgVoKUR7nPVhE8n/utR09JuDebcpgeIg?= =?Windows-1252?Q?TiBEWjtrKwPAlMkaZTIf+XPg02p+f3j/QS2yyDigHWwrlDZlFW7NMVhL?= =?Windows-1252?Q?JrloTknAY/GnlVo9ZgClTPxA2+w9OTUgpnyQBvrZbkqqmnM8YzxLObPK?= =?Windows-1252?Q?lcGUqUNshiIhNu6c4zTSsWlGKsOR7S+FgT5FzFMBVEe+9prSHjHpnCbt?= =?Windows-1252?Q?EfeSdbXvY2ilKc2GNsVrJ+dyPis3HwNr+H08KIyCtLeghk9HPpG20Bl4?= =?Windows-1252?Q?4W/gZrmNyinFuLCBBVr4ky4KwWOvckNoaoyQ9DGJ3CuZM307ju5eBDJt?= =?Windows-1252?Q?V1WhFrgIgqeDZh5oRFoZGh1b1pM2Wwoz63c7v1fsJpAI4PrvMiXZVeu4?= =?Windows-1252?Q?RRvqn2Gy0kzb8fW1W9aBtkUNg6Ab3TOdCs/1kxay5wHGVfLfRD15YA1W?= =?Windows-1252?Q?Xa5YGMyB/o9kECgYBcI4MYXv9wsmUp52W3kdfwk5mxbR1PceNyJNbs4/?= =?Windows-1252?Q?l2NuFZv6xNTz4tUd381gOrWDvSMrqY3Nv1OixPXIhgzgdKTMuwWIMXwL?= =?Windows-1252?Q?52Qh0uQiCgDEzVmCEr2c5Hr1lmKQjwnPiJy0ppugv9ZmGKYTuM8GkIBm?= =?Windows-1252?Q?qmWLzE+RAz3lxqFJCR1Y5CbMcuUzlS9ZwmklS+2riYpNFxqxej6w0yrc?= =?Windows-1252?Q?UeQ7OIbPgnnzhpZn/PKFuc7a/DbdXeje7CWf2yaOXzqDewF/dILzs2dS?= =?Windows-1252?Q?GF3QwoXL6jX37FjXVZaOxi8XPLBO+cMOVsGDxd/RBXc9Ajytpvv1QnPv?= =?Windows-1252?Q?tf8TxB7Obyx7ioMgot3KfIxtolTg5SDsFr1l5hl2nf2a5hXpzIVl+9ua?= =?Windows-1252?Q?XbaeN/gU+xjbbGqLn3GaD0P5ID1TJG+3cA7XYRcpj3DCu5dcR84iKN5I?= =?Windows-1252?Q?VvM9cSw4DXpU6lxBxDER9L9TiMLOQWUE+me0MsAvZEu/xC6zKnoUuFwA?= =?Windows-1252?Q?FRLyr+2LtLiJWFyBdHQHPlnAXqe0WtMPLyc5R9MoqGmZdkvGtMU6JP9z?= =?Windows-1252?Q?5Cv7ypSHLPEZxcnIzF7SnjLZQ5gQwQZE35DzvzpXTrV/FIiz6PkMecsM?= =?Windows-1252?Q?XTYGjeyNsx54cBAj9I2yWx/E0oG6o9n9rQbu3CdI/MQ3HM8bd1zbxjk6?= =?Windows-1252?Q?yLKDJymencg6ZlZ9vOibcl0YEZ3aPZwz5iknBUJsmQWT78xOXYDAiIqq?= =?Windows-1252?Q?SpPsiwBM+mCtsH+YVHyoVxivy8lp+7aCiNIoAcvKewAGV36GjIgMlrV5?= =?Windows-1252?Q?PqTog3MFQBeEBkZ6MSfR9sCJmCjI16hwvpwomF4DLNpMYri7eQx+baCP?= =?Windows-1252?Q?JOsBqk0AxgMseW8vV8l?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 6:JcH6ne6dGjeRNksBTanKSkQnH+ErEGD0XMeEHN6YemNWXBXf5q0d6SefEN08w4BvBBB7b7iDMQzbUd3LiDIKgufLZveEEs7r0pIvtEOfdg/urjUyaeaQ7jiNr+cuzOfF0rDVPmucOE+ZfVRPjEhhS9iqEH7vkEZCQ4DqIjAPaZQN65gw+IuOSBzxpNbjq5hX3a+MNFOJVrbUH0LNy7U0F9OpAI5KHDESPJYiA89rxTFHZHSKDO1rpeoMkfp3erMJctBMNCQu02dASUTh8Z/5zjFtL65/2gqwCa0ihkBKwAJWwOgFYnJRjzHOscZqq8VRKFx3jJCVS9dyMqnw8EiRNYau19DqXnltxSdfHLBlU8Np//8Auo46O5dTT5HMDSj7LNXpr2c2DSxIDpiGMYwLeeMibKCfm6hoo5IvRu9F6wDSJP522264z4OeDBvq276Obe3R797tGzvRsmbj/q1u/2Aj9afjkJbCH1iyVC1d4AE7ei+H6On+dLmuxI6IZN0cLBt2yzhGxi82u2z7HMN1eRtItNge/W5xMSimZN4pmw4= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 5:mxhg64hfQB4TZgkN1SqCrZx9qn8CocmPpNpTacAInaorXb1141DEyWxHcBO3j1W+TFf+KQqgAxn54wArsgrRqxjgzvMjbWmsoIlS9U+JvXoDWJ2LoIXlkCEY/JXJFJnSwAlTfIUYgWCnwsihMq5NkBsn8l1+JnwmCmN/UOsmlDdBNHuRS/cmcPSZJrQjdaFRUG3lOkJdJT1EVZ0Cp9XNTHmxGGZWuD1g84cZ1cfTo6r1FouYP0T1ejkcBSGlsCSY+aU4ws6/Vay9MQvQ5laHzx0BNz3Ng1KkBwNlpxUx5ODCykmmzrs6L1Vd7gIBWMSOZfgH7BPmElZ/CPCIH6KCfptyjkR56PfuVA633p6gxo3Jtjhj4j7zuvF3Ia3WLDSpJva/OYoFac2ot8bi+ia41UOeJ8RQ9iN/N5xSYrxV/BayuetAnS+Cw67T4+3WrcPq1HjU8xsvx8018pAbfZZR+qzoK5xBSp/bSfPtvNYKYxmrMmSrvIhdWhHneU3acZHn; 24:po0IfFpo1R8ARH3iXAdGZp9c3X2ApxyMAIuQNs4f1OHEIISez2fDAs8cEpCEkxmdWueob9G9eHNZHfUsTLRJrCiRIxoeOKDcbHlTg4Or5SI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 7:k2WhPfibxW4VZ62KtNBa5FfGwEquKkStRXp+tpDMc4tPNpjA/gejInkZ035Fs8ktKtR+xD9mn8JHVeYeF957jbKoN5+MNyRKMnC4KgiErdsDK9YfemSazEuKBGUWzhEZgzmLSVpqRVOeF2r88f09GcDPGo3qTagXHCJ1Gxd5JHcVGQog3bgALSiiw8aArti2QcOI7AV2n2wErDxTD5bbVKNUsWZqi2QbRYi+Hr4QWUZ4mIGRY5iJdI5ymDEzpbujIRklEXhEDrsQWNnNWohy1KK9YBW0N6D21fJQXEPuiZ4bE0G9D9sINQJkL7mq2QV2e+DkL70xyg3j68whs7D4AA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2017 14:51:09.0683 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2189 Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 14:51:13 -0000 On 5/21/2017 3:58 PM, Lou Berger wrote: > > Overall I support this document being published, but after addressing > some comments, most importantly the first one: > > 1. I think this document needs to cover its impact on RF5566. My > personal preference is for this document to subsume/obsolete 5566, but > the types defined in 5566 shouldn't be lost. (BTW I previously provided > authors with text to allow this draft to obsolete 5566 as well, and can > do so to the list if it would be helpful.) It is true that this document orphans RFC 5566 by obsoleting a document on which 5566 has a normative dependency. However, incorporating the security-related material from 5566 in a way that makes it useful is going to be a fair amount of work, and the rest of the document shouldn;'t be held up waiting for that. If you have some simple and non-controversial text to suggest, let's consider it. (I checked my old emails on this topic but couldn't find it.) > > 2. WRT the Encapsulation Extended Community. I find the following rule > very hard to parse: > > A Tunnel Encapsulation attribute MUST NOT include a barebones > Tunnel TLV. Instead of placing such a TLV in the Tunnel > Encapsulation attribute attached to a particular route, the > corresponding Encapsulation Extended Community MUST be attached to > the route. > > Are you saying the extended community MUST be "barebones". If so, I > agree as this matches 5512 formatting. If you want this extended > community to carry sub-tlv information, then I see no backwards > compatibility basis for this and don't support this. Either way, I > think this rule needs to be clarified. I'm not sure I understand what you are objecting to. An extended community cannot carry sub-TLVs. A number of existing applications exist that use the Encapsulation EC to specify a tunnel type, with no parameters. The above-quoted paragraph attempts to encourage backwards compatibility with those applications by saying that if you want to specify a single tunnel type with no parameters, use the Encapsulation EC. The Tunnel Encaps attribute would be used whenever the Encapsulation EC is not sufficient. > > 3. I'm not sure why the color sub-tlv is still needed. why not just use > the Color Extended Community alone? (Is there really a case where the > recursive lookup in section 7 would have a different color?) The color sub-TLV is per-tunnel, the color EC is per route. You could have multiple tunnels to a given endpoint, each with a different color. > > 4. In section 12.4, values should be defined by this document fo the > newly established Tunnel Encapsulation Attribute Sub-TLVs registry. I am under the impression that the preferred procedure is for the values to be assigned by IANA, not by the drafts. > > 5. Nit: the document says "This document deprecates the Encapsulation > SAFI (which has never been used)". The use part of this statement isn't > strictly true as it can be found implemented in FRRouting (a fork of > quagga). This said, I fully support its depreciation and look forward to > submitting the patch that will remove it! Just drop the two never used > comments. Since you are looking forward to removing the Encapsulation SAFI, I guess it is safe to say that there is no production deployment of it. If that's the case, I think "never used" is accurate. From nobody Mon May 22 08:04:47 2017 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 8FF6D12EAFA; Mon, 22 May 2017 08:04:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-idr-shutdown@ietf.org, Susan Hares , aretana@cisco.com, idr-chairs@ietf.org, skh@ndzh.com, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149546547958.14094.10590846251303101931.idtracker@ietfa.amsl.com> Date: Mon, 22 May 2017 08:04:39 -0700 Archived-At: Subject: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-shutdown-08=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:04:40 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-idr-shutdown-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I wondering why there is this addition cited below to the copyright notice needed given there is no IPR declared. Can you please explain?! „This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.“ From nobody Mon May 22 08:05:43 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E62312EAF8 for ; Mon, 22 May 2017 08:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VKZTJ6TYancC for ; Mon, 22 May 2017 08:05:41 -0700 (PDT) Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) (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 A6D7D12EAF7 for ; Mon, 22 May 2017 08:05:40 -0700 (PDT) Received: by mail-wm0-f48.google.com with SMTP id e127so41307177wmg.1 for ; Mon, 22 May 2017 08:05:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=bR0f5QVpTHlgOJXsTqpMu4Gnu96ygaWYv2Cx4ZMzuzw=; b=cxVmsWLMSyaa1Rd982xyxbH77NSh1lpjS50sKwzY1ym6PhVq6FGJRbKKrum0M9nSPa OahWBzSLnojVSekbVh4hjWQ+6i7ksd6JtsLUnAQkMtcmizvvVPQRopRH+ZeKVlZYpAJ8 Qe7l+b4+aJGavaVFm8jJajvzdueZ6gSkHHcD5zqQcRK40AcZvfNyWSllvXWHpkS29p40 vbSdAivMHSPKM8bvX8eJnldvSgYmnSLweoF/Xc4STYmxMt2szMQl78o4TSu/djrhhh7t WKvaev9PrMaJvbcxRbm9TGeGADmSFGHTeXQLhN7W/WKKlnUJd7rzcKtS6No184kkPeDe 9r0w== X-Gm-Message-State: AODbwcDZgQCbqtGBo5zxGyBhffn6JIRp1vQ+zzOu11MrhV3qH88IsxeR p/mN3hrWjrN5be4V X-Received: by 10.80.171.230 with SMTP id u93mr17949548edc.130.1495465539153; Mon, 22 May 2017 08:05:39 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:8d65:8a05:9b0c:6c7e]) by smtp.gmail.com with ESMTPSA id y55sm8132625edb.12.2017.05.22.08.05.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 May 2017 08:05:38 -0700 (PDT) Date: Mon, 22 May 2017 17:05:37 +0200 From: Job Snijders To: Alexey Melnikov Cc: The IESG , idr@ietf.org, draft-ietf-idr-shutdown@ietf.org, idr-chairs@ietf.org Message-ID: <20170522150537.5hb3lw3jsutu2jse@hanna.meerval.net> References: <149546328165.14094.11053425207224059343.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149546328165.14094.11053425207224059343.idtracker@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] Alexey Melnikov's No Objection on draft-ietf-idr-shutdown-08: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:05:42 -0000 On Mon, May 22, 2017 at 07:28:01AM -0700, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-idr-shutdown-08: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In Section 2: > > Shutdown Communication: to support international characters, the > Shutdown Communication field MUST be encoded using UTF-8. A > receiving BGP speaker MUST NOT interpret invalid UTF-8 sequences. > Note that when the Shutdown Communication contains multibyte > characters, the number of characters will be less than the length > value. This field is not NUL terminated. > > I think you should stick a reference to RFC 5198, which talks about > subset of UTF-8 intended for human consumption. Oh, that is a great reference! Thanks. How about adding: """For interoperability and consistent text display, the Shutdown Communication field SHOULD be normalized as recommended in "Unicode Format for Network Interchange" [RFC5198].""" Resulting in the following: NEW: Shutdown Communication: to support international characters, the Shutdown Communication field MUST be encoded using UTF-8. A receiving BGP speaker MUST NOT interpret invalid UTF-8 sequences. For interoperability and consistent text display, the Shutdown Communication field SHOULD be normalized as recommended in "Unicode Format for Network Interchange" [RFC5198]. Note that when the Shutdown Communication contains multibyte characters, the number of characters will be less than the length value. This field is not NUL terminated. > I was also thinking about language tagging (RFC 5646) for human > readable text, but I suspect that nobody will implement it in your > extension. That would be extremely unlikely indeed. Kind regards, Job From nobody Mon May 22 08:11:38 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7054F1200CF for ; Mon, 22 May 2017 08:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.418 X-Spam-Level: X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=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 kW2DbRiyXTzj for ; Mon, 22 May 2017 08:11:30 -0700 (PDT) Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) (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 48D2D12EB00 for ; Mon, 22 May 2017 08:11:28 -0700 (PDT) Received: by mail-wm0-f52.google.com with SMTP id e127so41481782wmg.1 for ; Mon, 22 May 2017 08:11:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=3bba3tJOH3GTh5xGHaYUUFRQE6j1cHP0xRbT9pssvB0=; b=Yf2wBtoWgQZ/G/4CFK3Jg4ZsxLtD7E7eupTW3RhFrBCMfEHabqLOD/eLT0YGticnSx /S0JPq6oXpsLw8ZIs3i27b49LKpxcUKFuzp6VWoakyu0bUI3MXl+0+0vp4kTuuVhsqQS kxlXnt6FkKaQwaHxjeDfsf9TdBE0NPUA+qYVHQkxPAv07Z/i+njgzKPXve6KKu/RmZ8M vMGrpvVJUYBbVg6wJ9ntcvsvMkibctyZ75kWynkaRH8Yiauchel0n61yx6M3p16fnvXt dWrTKSSU+MS5kyd1jxMSuFdF4Em4I5pLr9czMooaQm6H74F+xkoq/z3xo332uSe+xVDJ YnGw== X-Gm-Message-State: AODbwcDcG0sMI46UBetHutTdVf3y61cVnhUHX6yO9+Pnexh1ILJjOKGa 5UV9MJ36wUMjQwzo X-Received: by 10.80.163.131 with SMTP id s3mr17416592edb.156.1495465886605; Mon, 22 May 2017 08:11:26 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:8d65:8a05:9b0c:6c7e]) by smtp.gmail.com with ESMTPSA id d2sm8143692ede.31.2017.05.22.08.11.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 May 2017 08:11:25 -0700 (PDT) Date: Mon, 22 May 2017 17:11:24 +0200 From: Job Snijders To: Mirja =?iso-8859-1?Q?K=FChlewind?= Cc: The IESG , idr@ietf.org, draft-ietf-idr-shutdown@ietf.org, idr-chairs@ietf.org Message-ID: <20170522151124.dvc3ljpatp4cg5vs@hanna.meerval.net> References: <149546547958.14094.10590846251303101931.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <149546547958.14094.10590846251303101931.idtracker@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-idr-shutdown-08=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:11:31 -0000 On Mon, May 22, 2017 at 08:04:39AM -0700, Mirja Kühlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-idr-shutdown-08: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I wondering why there is this addition cited below to the copyright > notice needed given there is no IPR declared. Can you please explain?! > „This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before November > 10, 2008. The person(s) controlling the copyright in some of this > material may not have granted the IETF Trust the right to allow > modifications of such material outside the IETF Standards Process. > Without obtaining an adequate license from the person(s) controlling > the copyright in such materials, this document may not be modified > outside the IETF Standards Process, and derivative works of it may > not be created outside the IETF Standards Process, except to format > it for publication as an RFC or to translate it into languages other > than English.“ The document updates the technology defined in rfc4486, and the idnits thingy gave this feedback: Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC4486, updated by this document, for RFC5378 checks: 2006-01-25) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) source: https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-idr-shutdown-08.txt ---------------------------------------------------------------------- Without the disclaimer for pre-5378 the idnits tool gives this feedback: https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-idr-shutdown-01.txt I am open to any suggestions if change is needed, I do not consider myself a copyright expert. Kind regards, Job From nobody Mon May 22 08:16:04 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23BC129C48 for ; Mon, 22 May 2017 08:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh_a495RZQas for ; Mon, 22 May 2017 08:16:01 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BB212EAFB for ; Mon, 22 May 2017 08:15:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=MvBoGKUI5jCLjpz8w+LZOMWGw4kvmMn/x3ECzIglL/PfkfCP2ITE1vpbAtut6ELX2obAXXD3lI3MSGolCtwNnMq68htqSDvD8Cl4QwdRVExs6ejxGvh6qvi1j8fnoMiLtsLeFc7SgdfS8IBJjqbDyQeCRmKuacYV2ZTtj43JzQo=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 10053 invoked from network); 22 May 2017 17:15:55 +0200 Received: from pd9e110d0.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.16.208) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 May 2017 17:15:54 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <20170522151124.dvc3ljpatp4cg5vs@hanna.meerval.net> Date: Mon, 22 May 2017 17:15:53 +0200 Cc: idr@ietf.org, draft-ietf-idr-shutdown@ietf.org, The IESG , idr-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149546547958.14094.10590846251303101931.idtracker@ietfa.amsl.com> <20170522151124.dvc3ljpatp4cg5vs@hanna.meerval.net> To: Job Snijders X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170522151555.10045.41360@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-idr-shutdown-08=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:16:03 -0000 Ah, thanks. Wasn=E2=80=99t aware of this. I=E2=80=99m neither a = copyright expert. Did you try to contact the authors of RFC4486 rather = than adding this note? Mirja > Am 22.05.2017 um 17:11 schrieb Job Snijders : >=20 > On Mon, May 22, 2017 at 08:04:39AM -0700, Mirja K=C3=BChlewind wrote: >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-idr-shutdown-08: No Objection >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I wondering why there is this addition cited below to the copyright >> notice needed given there is no IPR declared. Can you please = explain?! >> =E2=80=9EThis document may contain material from IETF Documents or = IETF >> Contributions published or made publicly available before November >> 10, 2008. The person(s) controlling the copyright in some of this >> material may not have granted the IETF Trust the right to allow >> modifications of such material outside the IETF Standards Process. >> Without obtaining an adequate license from the person(s) = controlling >> the copyright in such materials, this document may not be modified >> outside the IETF Standards Process, and derivative works of it may >> not be created outside the IETF Standards Process, except to format >> it for publication as an RFC or to translate it into languages = other >> than English.=E2=80=9C >=20 > The document updates the technology defined in rfc4486, and the > idnits thingy gave this feedback: >=20 > Miscellaneous warnings: > = --------------------------------------------------------------------------= -- >=20 > (Using the creation date from RFC4486, updated by this document, = for > RFC5378 checks: 2006-01-25) >=20 > -- The document seems to contain a disclaimer for pre-RFC5378 work, = and may > have content which was first submitted before 10 November 2008. = The > disclaimer is necessary when there are original authors that you = have > been unable to contact, or if some do not wish to grant the BCP78 = rights > to the IETF Trust. If you are able to get all authors (current = and > original) to grant those rights, you can and should remove the > disclaimer; otherwise, the disclaimer is needed and you can ignore = this > comment. (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.) >=20 > source: = https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-i= dr-shutdown-08.txt > ---------------------------------------------------------------------- >=20 > Without the disclaimer for pre-5378 the idnits tool gives this = feedback: > = https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-i= dr-shutdown-01.txt >=20 > I am open to any suggestions if change is needed, I do not consider > myself a copyright expert. >=20 > Kind regards, >=20 > Job >=20 From nobody Mon May 22 08:39:54 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FE612EB0A; Mon, 22 May 2017 08:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=mUJAPkxU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BtVe5rut Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLGq2jsFoMO3; Mon, 22 May 2017 08:39:44 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671CF12944F; Mon, 22 May 2017 08:39:44 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 14481209B0; Mon, 22 May 2017 11:39:42 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Mon, 22 May 2017 11:39:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=BnqAnRWAUkPJo+M9Z82LJdQf83NJj fLDWqDlPT0zxS0=; b=mUJAPkxU7O7teXWJ2iD1xa1Y5Ng4IuIjkirOMSa2GNTOC SeWAQbzNiH3aZ5dZhoXTXGgMZQ/mrWrC3xxhtOQjIbgSqbY4NXWsiA6ErHcgPuqE xEXGsXH9LQpOqJpKjKcq++EQWKCSyGsQ268yiANlO4iJppBm32SfMHr3ajzUSjyB b/73usauj2kxIHg4qVGA6FbcL3fcHsnTDYkXzQIApzX1u2ce5tvtkTTidK5TluTU y5XzOLNHEAK9boqwoIAAnFn82D/NTCNaiHZZbMz/b9zrmKkyTK5OeD8P1au/Jo18 NUjDcOLRhuMD4ySGGtadW936NCAS/YXFN2WlBLUQw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=BnqAnR WAUkPJo+M9Z82LJdQf83NJjfLDWqDlPT0zxS0=; b=BtVe5rutA1GTaPakd71jyv Endo/y9P6/jaB2STFUh1FoHI6aSYH9UTdIeWfFFp6juVcgrUykQvCHOATHX+9CJV f51w4BRcN7ZyewLjbd0f3C+GNnJ8WtXFh8/UBz4yXpL2VQtB3DlIq3tSP4PJpn0n I52CKwryedBv0aBY58UwwqgMfP8/HKLvH1fjyKZX4JZS/8MRlSp/CNrzrU9XdCCZ i/3PZjM2jt8z38CLWjllF6pFWfSRepQt3Kq5bsjKkwliHEeQbiWkxjBjBWrtYdU/ aZcQIVhK2SEkUVVZd+eXY8stF1etgJrhu7OVW0yCFpnwznSiiW99+TuP8Kb+OGsg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E8A7B9E231; Mon, 22 May 2017 11:39:41 -0400 (EDT) Message-Id: <1495467581.3724298.984730624.543042B1@webmail.messagingengine.com> From: Alexey Melnikov To: Job Snijders Cc: The IESG , idr@ietf.org, draft-ietf-idr-shutdown@ietf.org, idr-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-a5162694 Date: Mon, 22 May 2017 16:39:41 +0100 In-Reply-To: <20170522150537.5hb3lw3jsutu2jse@hanna.meerval.net> References: <149546328165.14094.11053425207224059343.idtracker@ietfa.amsl.com> <20170522150537.5hb3lw3jsutu2jse@hanna.meerval.net> Archived-At: Subject: Re: [Idr] Alexey Melnikov's No Objection on draft-ietf-idr-shutdown-08: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:39:46 -0000 On Mon, May 22, 2017, at 04:05 PM, Job Snijders wrote: > On Mon, May 22, 2017 at 07:28:01AM -0700, Alexey Melnikov wrote: > > Alexey Melnikov has entered the following ballot position for > > draft-ietf-idr-shutdown-08: No Objection > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > In Section 2: > > > > Shutdown Communication: to support international characters, the > > Shutdown Communication field MUST be encoded using UTF-8. A > > receiving BGP speaker MUST NOT interpret invalid UTF-8 sequences. > > Note that when the Shutdown Communication contains multibyte > > characters, the number of characters will be less than the length > > value. This field is not NUL terminated. > > > > I think you should stick a reference to RFC 5198, which talks about > > subset of UTF-8 intended for human consumption. > > Oh, that is a great reference! Thanks. > > How about adding: """For interoperability and consistent text display, > the Shutdown Communication field SHOULD be normalized as recommended in > "Unicode Format for Network Interchange" [RFC5198].""" > > Resulting in the following: > > NEW: > > Shutdown Communication: to support international characters, the > Shutdown Communication field MUST be encoded using UTF-8. A > receiving BGP speaker MUST NOT interpret invalid UTF-8 > sequences. For interoperability and consistent text display, the > Shutdown Communication field SHOULD be normalized as recommended > in "Unicode Format for Network Interchange" [RFC5198]. Note that > when the Shutdown Communication contains multibyte characters, > the number of characters will be less than the length value. > This field is not NUL terminated. Works for me! > > I was also thinking about language tagging (RFC 5646) for human > > readable text, but I suspect that nobody will implement it in your > > extension. > > That would be extremely unlikely indeed. From nobody Mon May 22 08:49:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0B212EAFF for ; Mon, 22 May 2017 08:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rgbxsG3kRGPF for ; Mon, 22 May 2017 08:49:43 -0700 (PDT) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (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 6BC721242F7 for ; Mon, 22 May 2017 08:49:43 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id d127so156254936wmf.0 for ; Mon, 22 May 2017 08:49:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=JXCHYHz9vAhYLgxXr/Ht8H9ohn5kXSTzHaaHSrIToi0=; b=TKLcAspV2XaHbnsNbDH6bCDjK+oYq6YXlDb/6Yxb+VES6Y3Cri7sGIaXFVtK0HCfFW 6+fElWZGH/xYxERBFTbRcNYjNdHORUZUAjMduIQy8FwsSyzP7TKuWHue+RkarR2LVKrc 4drDVsxqwNX1+nf+Trl3dpkGTBUjLbx5EdGEp2ocO4C16o6Ht3iGqTx6pcNF0c13XHuc yBmQiGOXNlVOmz85Tmwt1fNBwzkxd2S915Us+Bpk7K73HXA9jHp7Qu0bv5w0400jOV5P NKjiCmmGLLP544Pa2p/9w0xv84mYdWi9XkXncgjHmoiv8ELuImcoFMBQd/6poI2lNFed SrXQ== X-Gm-Message-State: AODbwcCRgQE8KNUjuKELRMNgIqSrDrNE1OLrGE/iwtRm+J2GemTlS1tf xA8YTxG/HlyXg/JC X-Received: by 10.80.212.211 with SMTP id e19mr17810861edj.164.1495468181783; Mon, 22 May 2017 08:49:41 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:8d65:8a05:9b0c:6c7e]) by smtp.gmail.com with ESMTPSA id m9sm6680251edd.41.2017.05.22.08.49.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 May 2017 08:49:40 -0700 (PDT) Date: Mon, 22 May 2017 17:49:40 +0200 From: Job Snijders To: "Mirja Kuehlewind (IETF)" Cc: idr@ietf.org, draft-ietf-idr-shutdown@ietf.org, The IESG , idr-chairs@ietf.org Message-ID: <20170522154940.xmswso4hneaq6c25@hanna.meerval.net> References: <149546547958.14094.10590846251303101931.idtracker@ietfa.amsl.com> <20170522151124.dvc3ljpatp4cg5vs@hanna.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-idr-shutdown-08=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:49:45 -0000 On Mon, May 22, 2017 at 05:15:53PM +0200, Mirja Kuehlewind (IETF) wrote: > Ah, thanks. Wasn’t aware of this. I’m neither a copyright expert. > Did you try to contact the authors of RFC4486 rather than adding this > note? No. Copy+pasting the note as suggested by the idnits tool seemed less work :-) Kind regards, Job From nobody Mon May 22 09:32:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44ED12EB2C; Mon, 22 May 2017 09:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.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 n2xVtmKEFEVQ; Mon, 22 May 2017 09:32:45 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0088.outbound.protection.outlook.com [104.47.38.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29E812EB22; Mon, 22 May 2017 09:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=c/H24VkqPVU8hgt+X989CaDbQCm/xX/FWvrUAq4phBs=; b=JzS4IKIw92B2LJ9FBY4wvHAhS5ls9DhCmlQG7K7qWaDvqdlxFe2Bx3RF89H7hQyEIULAkhJXO/5nRTGl5NrIC5FH/zE9Ktji9g+AN3UlGlyErUcEVDoVzUDLFc+PrWn2LseBNZU+Lc/tBE3+tNDBsOrAKFOp5JgijSXWGmp2LXk= Received: from CY4PR18MB1127.namprd18.prod.outlook.com (10.173.184.14) by CY4PR18MB1128.namprd18.prod.outlook.com (10.173.184.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Mon, 22 May 2017 16:32:36 +0000 Received: from CY4PR18MB1127.namprd18.prod.outlook.com ([10.173.184.14]) by CY4PR18MB1127.namprd18.prod.outlook.com ([10.173.184.14]) with mapi id 15.01.1101.019; Mon, 22 May 2017 16:32:37 +0000 From: Keyur Patel To: Eric C Rosen , "John G. Scudder" , "idr@ietf.org" CC: "draft-ietf-idr-tunnel-encaps@ietf.org" Thread-Topic: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 Thread-Index: AQHS0aHuyGGOavUG6UOAW5CyruRtEaIAWPEA///AfYA= Date: Mon, 22 May 2017 16:32:37 +0000 Message-ID: <64EBF5ED-F0BE-47D8-A2E7-D69134D702FF@arrcus.com> References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <1ecc0225-adbc-5f91-10eb-b28cfce35cd6@juniper.net> In-Reply-To: <1ecc0225-adbc-5f91-10eb-b28cfce35cd6@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [96.68.143.133] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR18MB1128; 7:6ITVLXHqZBJvXb37QUdVgh7gda7QybiWn7EABz2CedEdwtlMgvN1vdEs/6FPMU6+1FOKvcMVeEIPmyIPGu7uK5M0UiJD88NHt8ak8K/F8Ld6iEJbGYMey99emTxHpMLMPC/WTQqRIt753RpHCpFFh/gZ9qwMQW7d1CceuLeRvhxno6yqhUlPbpZP7CKaPbAIhD5M/1UJh8qGC7LvBwxYL8G2Ohe6ACZZ1+2DdH3ogGNKRHZcuXmHtgDLqHEOunodv9z9Y/tk0NykExd0nHR56JB14ZbpDMS/qm3/YkApU8SAbhw+KwAk3z0i4OnjQITQDz1IAs+3bzHNzIoDoZY0HQ== x-ms-traffictypediagnostic: CY4PR18MB1128: x-ms-office365-filtering-correlation-id: 38a97bc7-81af-4677-b0ec-08d4a130285a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075); SRVR:CY4PR18MB1128; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(2016111802025)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(6043046)(6072148); SRVR:CY4PR18MB1128; BCL:0; PCL:0; RULEID:; SRVR:CY4PR18MB1128; x-forefront-prvs: 03152A99FF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39830400002)(39410400002)(377454003)(24454002)(8666007)(2906002)(6512007)(4326008)(305945005)(53936002)(7736002)(6436002)(99286003)(6246003)(38730400002)(6306002)(189998001)(83716003)(25786009)(3280700002)(53546009)(3660700001)(5660300001)(6506006)(82746002)(6486002)(122556002)(77096006)(8676002)(76176999)(8936002)(478600001)(6116002)(230783001)(54356999)(50986999)(81166006)(102836003)(2501003)(2950100002)(66066001)(229853002)(86362001)(36756003)(3846002)(966005)(2900100001)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR18MB1128; H:CY4PR18MB1127.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2017 16:32:37.1184 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR18MB1128 Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 16:32:47 -0000 SSBhbSBub3QgYXdhcmUgb2YgYW55IHVuZGlzY2xvc2VkIHJlbGV2YW50IElQUi4NCg0KUmVnYXJk cywNCktleXVyDQoNCk9uIDUvMjIvMTcsIDY6MTkgQU0sICJJZHIgb24gYmVoYWxmIG9mIEVyaWMg QyBSb3NlbiIgPGlkci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBlcm9zZW5AanVuaXBl ci5uZXQ+IHdyb3RlOg0KDQogICAgSSBhbSBub3QgYXdhcmUgb2YgYW55IHVuZGlzY2xvc2VkIHJl bGV2YW50IElQUi4NCiAgICANCiAgICANCiAgICBPbiA1LzIwLzIwMTcgMzo0NyBQTSwgSm9obiBH LiBTY3VkZGVyIHdyb3RlOg0KICAgID4gQXV0aG9ycywgcGxlYXNlIGNvbmZpcm0gdGhhdCBhbnkg cmVsZXZhbnQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZC4NCiAgICANCiAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIElkciBtYWlsaW5nIGxpc3QN CiAgICBJZHJAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkcg0KICAgIA0KDQo= From nobody Mon May 22 09:34:35 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6E512EB2B; Mon, 22 May 2017 09:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 cJA18YV5p3hk; Mon, 22 May 2017 09:34:32 -0700 (PDT) Received: from mr11p00im-asmtp001.me.com (mr11p00im-asmtp001.me.com [17.110.69.252]) (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 158FD12EB2C; Mon, 22 May 2017 09:34:32 -0700 (PDT) Received: from process-dkim-sign-daemon.mr11p00im-asmtp001.me.com by mr11p00im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OQD00G002GIAU00@mr11p00im-asmtp001.me.com>; Mon, 22 May 2017 16:34:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1495470858; bh=hBGTp1xj+b9uo/pXdvXKnWBuC461dnHDFqKdKqdjQPE=; h=Date:From:To:Message-id:Subject:MIME-version:Content-type; b=WyJ31U0jyeWgAlSjx2Wo3fOnn4Suo6WKWnUSrqP7+zpbMSCuk0+OdWrTRWj4Bi0J+ i+BLmowr2wimHn8yGMi5yXDMBi/3GETU8YlQ/0GDGbkiKxJXy5L9ps72mAyP84G0Du rehkPf0dusyzmN5SlzSHt8nlQKukPSgxvECZMsXnqxc/OoGTuz8QzA6QyyRpOYi0Vh 4GO27HC3comtS1Tam5gS5WZ+csSYvcfZjlqwZYe6udAHRRl7wMqKmn9hroFXsfec4M Cc/Y9i4gr6eJtMFPHb2chxqE2ZFWPVgirFM4cv5NPFpM+rTOmn+FceZJo28KO2zqmk ScJvvwvqAuRmA== Received: from icloud.com ([127.0.0.1]) by mr11p00im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OQD0035J4OZEC00@mr11p00im-asmtp001.me.com>; Mon, 22 May 2017 16:34:15 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-22_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705220087 Date: Mon, 22 May 2017 16:34:11 +0000 (UTC) From: guntervandeveldecc@icloud.com To: Eric C Rosen , "John G. Scudder" , idr@ietf.org, Keyur Patel Cc: draft-ietf-idr-tunnel-encaps@ietf.org Message-id: <246E99BEEE5D0AE6.cefb4945-0c93-4d6c-a472-8c40755a9fd8@mail.outlook.com> In-reply-to: <64EBF5ED-F0BE-47D8-A2E7-D69134D702FF@arrcus.com> References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <1ecc0225-adbc-5f91-10eb-b28cfce35cd6@juniper.net> <64EBF5ED-F0BE-47D8-A2E7-D69134D702FF@arrcus.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_Part_12167_1707494327.1495470851619" X-Mailer: Outlook for iOS and Android Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 16:34:33 -0000 ------=_Part_12167_1707494327.1495470851619 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am not aware of any IPR G/ Get Outlook for Android On Mon, May 22, 2017 at 6:32 PM +0200, "Keyur Patel" wrote: I am not aware of any undisclosed relevant IPR. Regards, Keyur On 5/22/17, 6:19 AM, "Idr on behalf of Eric C Rosen" wrote: I am not aware of any undisclosed relevant IPR. On 5/20/2017 3:47 PM, John G. Scudder wrote: > Authors, please confirm that any relevant IPR has been disclosed. _______________________________________________ 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 ------=_Part_12167_1707494327.1495470851619 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I am not aware of any IPR

G/




On Mon, May 22, 2017 at 6:32 PM +0200, "Keyur Patel" <keyur@arrcus.com> wrote:

I am not aware of any undisclosed relevant IPR.

Regards,
Keyur

On 5/22/17, 6:19 AM, "Idr on behalf of Eric C Rosen"  wrote:

    I am not aware of any undisclosed relevant IPR.
    
    
    On 5/20/2017 3:47 PM, John G. Scudder wrote:
    > Authors, please confirm that any relevant IPR has been disclosed.
    
    _______________________________________________
    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
------=_Part_12167_1707494327.1495470851619-- From nobody Mon May 22 09:45:03 2017 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 5DA76126CF6; Mon, 22 May 2017 09:45:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-idr-shutdown@ietf.org, Susan Hares , aretana@cisco.com, idr-chairs@ietf.org, skh@ndzh.com, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149547150337.5542.9055637503089744791.idtracker@ietfa.amsl.com> Date: Mon, 22 May 2017 09:45:03 -0700 Archived-At: Subject: [Idr] Warren Kumari's Yes on draft-ietf-idr-shutdown-08: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 16:45:03 -0000 Warren Kumari has entered the following ballot position for draft-ietf-idr-shutdown-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Having had to deal with many instances of "Hey, my BGP session with you just went down, whatsup?!", "Yes, it's a maintenance. I sent you mail about it last month, then last week, then this morning, then 5 minutes before pulling the session. You even generated a ticket for me, it's # [1432323] 'kthnxbye..." I think that this is the best thing since sliced bread (of course, I also thought jabber over BGP was cool). Some nits: 2. Shutdown Communication Shutdown Communication: to support international characters, the Shutdown Communication field MUST be encoded using UTF-8. perhaps: "MUST be encoded using UTF-8 "Shortest Form" encoding"? (from Security Considerations) - or Alexey Melnikov's suggestion... Also, *perhaps* it is worth noting that it might be possible for someone to send: 'BGP going down\nMay 22 11:19:12 rtr1 mib2d[42]: SNMP_TRAP_LINK_TYPE: ifIndex 501, ifOperStatus "Interface is a small turnip", ifName ge-1/2/3' and that logging of these should strip control characters. This may already be covered in syslog... From nobody Mon May 22 09:57:34 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD8A126CF6 for ; Mon, 22 May 2017 09:57:33 -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=unavailable 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 ay-4gpuvqkEW for ; Mon, 22 May 2017 09:57:31 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c: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 E9ADE12EB29 for ; Mon, 22 May 2017 09:57:30 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id 7so1440240wmo.1 for ; Mon, 22 May 2017 09:57:30 -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=et4jao9L9GwCkhmWny2/h3CJ3qF4h3I4CczNe3anQFM=; b=vpi9bFZBZFoE4ipZwyPAbttvRUPd7Cdoqvw66DLpDmoLH34BMFA4veOYQFnyJTLYLh nQsb97dCSvV+iZLBKx97DQbB2CoMEX08SsPaRZCqXrFrXQeJMXwEc6uQugtPp4aGRKEp A7iV2X6OATyuNQlTQbLf9mc4OqR0vgbselYlogM818EE6RP68FHxVHkWdh2rzorR/OR8 pbMhfEg/c2IKVk3vtut0fr8XLps6UbAlcwZcn2Elk4THiCdaWYOcoxb5k4+FRsYoUWye YVw1OJDH4U8bLIi8ffzXfOuShZbym381TAk/H2iwu+wXtyZsZ6HxII4+JdQZnV4aosXx buiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=et4jao9L9GwCkhmWny2/h3CJ3qF4h3I4CczNe3anQFM=; b=UZDdIRuEayAWIcdNhzUyrhfPvKY97IkYAiNFhi472VA1iTsl2MjuD1mVmM1W7cXqzM AZPgAPIR0KpOSZKnum6V/81qj7QJF/MKdWyhB1uJsHH4DBLcrlwYUiIV+E5CqhgD6NA1 BnS3b5+Ha6BfWH9zIZSmR3zk2f+ZhYirNvENlEul8eTajRcV/dVNm+KLaXnmMFEdgUpB w0tFSuySa4W7knuGNszaruqckoJOxCGv/d0DezthtYcL7FB5uVyPYbnVHzn6gyILUcPm PzBFovG2T/WNIUk6zoY3iNRA6ZBQDKgPVqfV6hMIvPIqgV2p9CAZWe6pZWppvrWpXuhh oDIQ== X-Gm-Message-State: AODbwcBUb/ryMdJKOfqxCIQkCG7d32fLi/hpw6k8jkVeuHR5gpWm+LCg Vv+Ka8ic/4vioXqj X-Received: by 10.80.195.17 with SMTP id a17mr18239207edb.9.1495472249299; Mon, 22 May 2017 09:57:29 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:8d65:8a05:9b0c:6c7e]) by smtp.gmail.com with ESMTPSA id e35sm2767726edb.40.2017.05.22.09.57.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 May 2017 09:57:28 -0700 (PDT) Date: Mon, 22 May 2017 18:57:27 +0200 From: Job Snijders To: Warren Kumari Cc: The IESG , idr@ietf.org, draft-ietf-idr-shutdown@ietf.org, idr-chairs@ietf.org Message-ID: <20170522165727.j3b66kuiozdzcsnr@hanna.meerval.net> References: <149547150337.5542.9055637503089744791.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149547150337.5542.9055637503089744791.idtracker@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] Warren Kumari's Yes on draft-ietf-idr-shutdown-08: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 16:57:33 -0000 Dear Warren, On Mon, May 22, 2017 at 09:45:03AM -0700, Warren Kumari wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Having had to deal with many instances of "Hey, my BGP session > with you just went down, whatsup?!", "Yes, it's a maintenance. I sent you > mail about it last month, then last week, then this morning, then 5 > minutes before pulling the session. You even generated a ticket for me, > it's # [1432323] 'kthnxbye..." I think that this is the best thing > since sliced bread (of course, I also thought jabber over BGP was > cool). > > Some nits: > 2. Shutdown Communication > Shutdown Communication: to support international characters, the > Shutdown Communication field MUST be encoded using UTF-8. > perhaps: > "MUST be encoded using UTF-8 "Shortest Form" encoding"? (from > Security Considerations) - or Alexey Melnikov's suggestion... The Security section already contains normative text to that effect, so wouldn't that be somewhat redundant? I can add it, but then would be two references in this document to the concept of "Shortest Form" encoding, on top of it also being the recommendation through [UTR36]. > Also, *perhaps* it is worth noting that it might be possible for someone > to send: > 'BGP going down\nMay 22 11:19:12 rtr1 mib2d[42]: SNMP_TRAP_LINK_TYPE: > ifIndex 501, ifOperStatus "Interface is a small turnip", ifName > ge-1/2/3' > and that logging of these should strip control characters. This may > already be covered in syslog... Stripping / sanitizing is also covered by referencing RFC5198 as per Alexey Melnikov's suggestion. As to your direct example, the security section contains: "This specification minimizes the effects of visual spoofing attacks by limiting the length of the Shutdown Communication." If you can suggest different (more accurate) wording that would be appreciated. Note: your attempted visual spoofing attack example is 140 bytes, the specification only allows up to and including 128 bytes. Kind regards, Job From nobody Mon May 22 13:28:56 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73683128792; Mon, 22 May 2017 13:28:54 -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, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 KuerhtnXwrjk; Mon, 22 May 2017 13:28:52 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0125.outbound.protection.outlook.com [104.47.1.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA74126CF9; Mon, 22 May 2017 13:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=154qFWHKdgiLmqY1IIqzt+Pe2nO/ucX7TB2MXI0/cCM=; b=bmrxp7AlTEUtLO+KqueTEc28zjwIdJQ+61fkap20GNmKWGJxDOr1dd5b8jbsW+XkaSN0BnO8qePybeEOdGlWJQpqmyfcLcr5mK9PmZyZKjppW/IyEf2gG7D//gCiZ//5kM0mzV/sP5QXCK+0SukZXzxdN5cp2ipnGFJQ6BegL/Y= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0963.eurprd07.prod.outlook.com (10.162.37.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Mon, 22 May 2017 20:28:48 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::8ca8:abc5:c3c7:9d6d]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::8ca8:abc5:c3c7:9d6d%15]) with mapi id 15.01.1124.007; Mon, 22 May 2017 20:28:48 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: "bruno.decraene@orange.com" , "John G. Scudder" CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" , "idr@ietf.org" Thread-Topic: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/VTfsG4m8/9b0SvgXKKVya+jKH9odKAgAJT9gCAAMWPAA== Date: Mon, 22 May 2017 20:28:47 +0000 Message-ID: References: <26881_1495437183_59228F7F_26881_13214_1_53C29892C857584299CBF5D05346208A31D21DCD@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <26881_1495437183_59228F7F_26881_13214_1_53C29892C857584299CBF5D05346208A31D21DCD@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170403 authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [89.225.206.56] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0963; 7:6FtqS5dQo3avWibi8C1F38rteaaF0wKiqXQ/oRlC1fv6Llxsr/VxLyiBlhr+JkSByF7E1tAzohP4PklRl7aUWxp4/s/90SpOilCTWEV4hnksCFC5dsa+QyOgXk3IE/Rhw1K7IECqJ72T7O+So4iTBOUErLD9f7uws5VjnCQGKyfYqCL+xQ2GDPPDXmAuQHEtPg5VozmNklccxJEgjdm/wd/zqpGQ02trHX7C7G+Lq261h8CAAMdx0WqL3EciH1R9+zJ6YDxgM+bAa1mLq3snY+QzNph+JPQwj5IibINS43G1sM0XIQr7LxC5EjG6EsUiFDnU69aa+3oNaU+4Yzb89A== x-ms-traffictypediagnostic: AM2PR07MB0963: x-ms-office365-filtering-correlation-id: 0411bc1d-ee5c-4907-c825-08d4a1512728 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM2PR07MB0963; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(6072148); SRVR:AM2PR07MB0963; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0963; x-forefront-prvs: 03152A99FF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39840400002)(39400400002)(39850400002)(39410400002)(13464003)(24454002)(53754006)(377454003)(82746002)(4001350100001)(25786009)(83506001)(83716003)(38730400002)(53546009)(86362001)(54356999)(54906002)(76176999)(36756003)(229853002)(2950100002)(6512007)(6506006)(305945005)(6436002)(7736002)(478600001)(81166006)(5660300001)(5890100001)(8676002)(4326008)(50986999)(8666007)(102836003)(189998001)(2501003)(6116002)(99286003)(6246003)(66066001)(6306002)(2900100001)(8936002)(53936002)(3846002)(3660700001)(230783001)(33656002)(2906002)(3280700002)(6486002)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0963; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <08B8BEB4EDC0FC44868DFB740D15B09D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2017 20:28:47.2458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0963 Archived-At: Subject: Re: [Idr] [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 20:28:54 -0000 Tm90IGF3YXJlIG9mIElQUiBlaXRoZXIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0DQoNCk9uIDIyLzA1 LzIwMTcsIDA4OjEzLCAiYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSIgPGJydW5vLmRlY3JhZW5l QG9yYW5nZS5jb20+IHdyb3RlOg0KDQogICAgSSdtIG5vdCBhd2FyZSBvZiBJUFIuDQogICAgDQog ICAgTm90ZSB0aGF0IHRoaXMgZHJhZnQgYm9ycm93cyBhIHZlcnkgc21hbGwgc3Vic2V0IGZyb20g UkZDIDY3OTAgKEVudHJvcHkgTGFiZWwpIHdoaWNoIGhhcyBJUFIgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9pcHIvc2VhcmNoLz9yZmM9Njc5MCZzdWJtaXQ9cmZjDQogICAgDQogICAgUmVn YXJkcywNCiAgICAtLUJydW5vDQogICAgDQogICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCiAgICAgPiBGcm9tOiBKb2huIEcuIFNjdWRkZXIgW21haWx0bzpqZ3NAanVuaXBlci5uZXRd DQogICAgID4gU2VudDogU2F0dXJkYXksIE1heSAyMCwgMjAxNyA5OjQwIFBNDQogICAgID4gVG86 IGlkckBpZXRmLm9yZw0KICAgICA+IENjOiBtcGxzQGlldGYub3JnOyBkcmFmdC1kZWNyYWVuZS1p ZHItbmV4dC1ob3AtY2FwYWJpbGl0eUBpZXRmLm9yZw0KICAgICA+IFN1YmplY3Q6IFJlOiBbbXBs c10gV29ya2luZyBHcm91cCBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1kZWNyYWVuZS1pZHItbmV4 dC1ob3AtY2FwYWJpbGl0eS0NCiAgICAgPiAwMw0KICAgICA+IA0KICAgICA+IEJUVyBJIGZvcmdv dCB0byBtZW50aW9uLCBhdXRob3JzLCBwbGVhc2Ugc2F5IGlmIHlvdSdyZSBhd2FyZSBvZiBhbnkg SVBSIHRoYXQgYXBwbGllcy4NCiAgICAgPiANCiAgICAgPiBSZWdhcmRzLA0KICAgICA+IA0KICAg ICA+IC0tSm9obg0KICAgICA+IA0KICAgICA+ID4gT24gTWF5IDE4LCAyMDE3LCBhdCAxMjozMiBQ TSwgSm9obiBHLiBTY3VkZGVyIDxqZ3NAanVuaXBlci5uZXQ+IHdyb3RlOg0KICAgICA+ID4NCiAg ICAgPiA+IEhpIEFsbCwNCiAgICAgPiA+DQogICAgID4gPiBJRFIgd29ya2luZyBncm91cCBhZG9w dGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWRlY3JhZW5lLWlkci1uZXh0LWhvcC0N CiAgICAgPiBjYXBhYmlsaXR5LTAzLiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBJ RFIgbWFpbGluZyBsaXN0IGJlZm9yZSBKdW5lIDIsIDIwMTcuIFBsZWFzZQ0KICAgICA+IHJlbWVt YmVyIHRoYXQgd2UgbmVlZCBhZmZpcm1hdGl2ZSBzdXBwb3J0IGluIG9yZGVyIHRvIGFkb3B0IHRo ZSBkcmFmdCwgc28gZG9uJ3QgYmUgc2h5Lg0KICAgICA+ID4NCiAgICAgPiA+IGRyYWZ0IGRhdGF0 cmFja2VyIHBhZ2U6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRlY3Jh ZW5lLWlkci1uZXh0LWhvcC0NCiAgICAgPiBjYXBhYmlsaXR5Lw0KICAgICA+ID4gc2xpZGVzIGZy b20gSUVURi05ODogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3Ns aWRlcy05OC1pZHItMDgtYmdwLQ0KICAgICA+IG5leHQtaG9wLWRlcGVuZGVudC1jYXBhYmlsaXRp ZXMtMDAucGRmDQogICAgID4gPg0KICAgICA+ID4gU2luY2UgaW4gcGFydCB0aGlzIGRyYWZ0IHNw ZWNpZmllcyBhIHJlcGxhY2VtZW50IGZvciB0aGUgRW50cm9weSBMYWJlbCBDYXBhYmlsaXR5IEF0 dHJpYnV0ZQ0KICAgICA+IChFTENBKSB0aGF0IHdhcyBkZWZpbmVkIGJ5IHRoZSBNUExTIFdHIGlu IFJGQyA2NzkwIGFuZCBkZXByZWNhdGVkIGJ5IFJGQyA3NDQ3LCBJIGhhdmUNCiAgICAgPiBjYydk IHRoZSBNUExTIFdHIG1haWxpbmcgbGlzdC4gU2luY2UgdGhlIHByb3Bvc2VkIG5ldyBhdHRyaWJ1 dGUgaXMgYSBnZW5lcmljIGNvbnRhaW5lciB3aXRoDQogICAgID4gdGhlIEVMQ0EgcmVwbGFjZW1l bnQganVzdCB0aGUgZmlyc3QgYXBwbGljYXRpb24sIHRoZSBjdXJyZW50IGRyYWZ0IGlzIHRhcmdl dGVkIHRvIElEUiBhbmQgbm90DQogICAgID4gTVBMUyAodGhpcyB3YXMgZGlzY3Vzc2VkIGR1cmlu ZyBJRVRGLTkzKS4NCiAgICAgPiA+DQogICAgID4gPiBUaGFua3MsDQogICAgID4gPg0KICAgICA+ ID4gLS1Kb2huDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIA0KICAgIENlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KICAgIHBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQog ICAgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwNCiAgICBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQogICAgDQog ICAgVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsNCiAgICB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4NCiAgICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCiAgICBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuDQogICAgVGhhbmsgeW91Lg0KICAgIA0KICAgIA0KDQo= From nobody Tue May 23 05:45:41 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41A0129B3A for ; Tue, 23 May 2017 05:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVW715gLnnaK for ; Tue, 23 May 2017 05:45:38 -0700 (PDT) Received: from gproxy6.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 07CA2129B45 for ; Tue, 23 May 2017 05:45:25 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id C06CF1E0884 for ; Tue, 23 May 2017 06:45:21 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id PolJ1v0062SSUrH01olMbA; Tue, 23 May 2017 06:45:21 -0600 X-Authority-Analysis: v=2.2 cv=K+5SJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=tJ8p9aeEuA8A:10 a=B6KMzFptAAAA:20 a=KrvhCIQHVrTc-dspBagA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+M8OENAtmhPGYpXsLVjM5zbLmYRvJCP3IIS/M6TVnuc=; b=F33rAM2/qqx5IXuMsK9fb31l3A sJ7E9iDf5C7IWoMWkYaKoBIlygD7ujGaECryN1+i5CM5Ae2A5JnFv6nX1ltRLADrhGqWhQRYxuXL8 TWqocUe9aQ5CTe0QA0fVcj3Nz; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:36984 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dD9Be-0005tz-02; Tue, 23 May 2017 06:45:18 -0600 To: Eric C Rosen , "John G. Scudder" Cc: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> From: Lou Berger Message-ID: <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> Date: Tue, 23 May 2017 08:45:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dD9Be-0005tz-02 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:36984 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 12:45:40 -0000 On 5/22/2017 10:51 AM, Eric C Rosen wrote: > On 5/21/2017 3:58 PM, Lou Berger wrote: >> Overall I support this document being published, but after addressing >> some comments, most importantly the first one: >> >> 1. I think this document needs to cover its impact on RF5566. My >> personal preference is for this document to subsume/obsolete 5566, but >> the types defined in 5566 shouldn't be lost. (BTW I previously provided >> authors with text to allow this draft to obsolete 5566 as well, and can >> do so to the list if it would be helpful.) > It is true that this document orphans RFC 5566 by obsoleting a document > on which 5566 has a normative dependency. However, incorporating the > security-related material from 5566 in a way that makes it useful is > going to be a fair amount of work, and the rest of the document > shouldn;'t be held up waiting for that. Well I did make this comment ~ 2 years ago, so you shouldn't be surprised that I'm raising it now. I'm not saying the WG has to follow my preferred path (of having this doc replace 5566 as well), but I think something has to be done to not leave 5566 "orphaned". > If you have some simple and > non-controversial text to suggest, let's consider it. (I checked my old > emails on this topic but couldn't find it.) my memory is that I put together a rough google doc at the time we discussed whether your doc would deprecate 5512 or not. (See https://docs.google.com/document/d/1PSVTwf_QaRVWqhmkfaoRuP2JoGq_Nq9mlICUv6Z2BOQ/edit) To have tunnel-encaps deprecate 5566 as well, I think the following is needed: - Include the 5566 defined tunnel types (particularly 4, 5 and 6) - include section 3.4.1 and 3.6 from the google doc (which is just edit text from 5566 sections 3 and 4) - perhaps include the 2nd paragraph of the Security Considerations section Given that the text is mostly lifted from 5566, I'd hope this qualifies as "simple and non-controversial". (new issue 6) In looking at the google doc, I was reminded of a deficiency of in 5512 that still exists in the wg draft. Neither ever define the format of the Tunnel TLV. Don't you think it should? Obviously, I do. Feel free to lift Section 3 of the google doc. > >> 2. WRT the Encapsulation Extended Community. I find the following rule >> very hard to parse: >> >> A Tunnel Encapsulation attribute MUST NOT include a barebones >> Tunnel TLV. Instead of placing such a TLV in the Tunnel >> Encapsulation attribute attached to a particular route, the >> corresponding Encapsulation Extended Community MUST be attached to >> the route. >> >> Are you saying the extended community MUST be "barebones". If so, I >> agree as this matches 5512 formatting. If you want this extended >> community to carry sub-tlv information, then I see no backwards >> compatibility basis for this and don't support this. Either way, I >> think this rule needs to be clarified. > I'm not sure I understand what you are objecting to. An extended > community cannot carry sub-TLVs. Perfect. That's what I was hoping for/expecting, but I couldn't parse your text in a way that made sense (at least to me). I also think the current phasing goes beyond what some implementations do, e.g., send a barebones EC all the time. > A number of existing applications exist that use the Encapsulation EC to > specify a tunnel type, with no parameters. The above-quoted paragraph > attempts to encourage backwards compatibility with those applications by > saying that if you want to specify a single tunnel type with no > parameters, use the Encapsulation EC. The Tunnel Encaps attribute would > be used whenever the Encapsulation EC is not sufficient. How about replacing the quoted paragraph with: An Encapsulation Extended Community MUST be included when a barebones Tunnel TLV is used to identify a tunnel endpoint. The corresponding barebones Tunnel Encapsulation attribute MAY be omitted in this case. BTW our implementation always includes a "barebones" Encapsulation Extended Community ;-) > >> 3. I'm not sure why the color sub-tlv is still needed. why not just use >> the Color Extended Community alone? (Is there really a case where the >> recursive lookup in section 7 would have a different color?) > The color sub-TLV is per-tunnel, the color EC is per route. You could > have multiple tunnels to a given endpoint, each with a different color. okay, this works -- we solved this using multiple updates. That said, do you think the complexity of multiple tunnel tlvs in the same update is needed or really used today (vs just using multiple/per tunnel tlv updates)? The encap safi certainly resulted in some pretty complex code in order to "optimize" update sizes. It seems that this too is a similar trade off, and would be a good additional area of complexity that can be simplified. If it's not used today, I think we should restrict the Tunnel Encapsulation Attribute to one Tunnel-TLV. If this is kept, it seems like there's some special aggregation rules that could apply. > >> 4. In section 12.4, values should be defined by this document fo the >> newly established Tunnel Encapsulation Attribute Sub-TLVs registry. > I am under the impression that the preferred procedure is for the values > to be assigned by IANA, not by the drafts. I don't think this is the case for *new* registries. We can defer to the Doc shepherd on this and not discuss further. >> 5. Nit: the document says "This document deprecates the Encapsulation >> SAFI (which has never been used)". The use part of this statement isn't >> strictly true as it can be found implemented in FRRouting (a fork of >> quagga). This said, I fully support its depreciation and look forward to >> submitting the patch that will remove it! Just drop the two never used >> comments. > Since you are looking forward to removing the Encapsulation SAFI, I > guess it is safe to say that there is no production deployment of it. > If that's the case, I think "never used" is accurate. > "never used" is not the same as "not currently used". The latter is accurate, the former is not. I can live with this (pedantic) inaccuracy. Lou From nobody Tue May 23 06:58:41 2017 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 57BE9128DF6; Tue, 23 May 2017 06:58:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149554792031.21441.17538641677279207956@ietfa.amsl.com> Date: Tue, 23 May 2017 06:58:40 -0700 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 13:58: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 : The BGP Tunnel Encapsulation Attribute Authors : Eric C. Rosen Keyur Patel Gunter Van de Velde Filename : draft-ietf-idr-tunnel-encaps-05.txt Pages : 40 Date : 2017-05-23 Abstract: RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional tunnel types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel. This document obsoletes RFC 5512. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-05 https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-tunnel-encaps-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 Tue May 23 07:01:58 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B93129B51 for ; Tue, 23 May 2017 07:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSTurWupkmqM for ; Tue, 23 May 2017 07:01:54 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0098.outbound.protection.outlook.com [104.47.36.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 D97BD129B66 for ; Tue, 23 May 2017 07:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zqCrA7LXh0oTa7QLLR2yJNnlfOiz3D2qARh+yndMTJA=; b=FnA8uFLISUUTZmwGdad/a6nyFjbP5ndD19Rco3pR+sGD8kMMOU5TSkq9F3GzkptJIvKEry3RAgjR++8nAQQ76CoWJ3nvIZRHC3MOe+ur/h1fvDPjbGNOWg4f+jmP8WZOENAlRMEjijO/20ftfeUGcy/x7smBGtUnUen9blbTUm8= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.195] (66.129.241.11) by BY2PR05MB2184.namprd05.prod.outlook.com (10.166.112.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Tue, 23 May 2017 14:01:49 +0000 To: idr@ietf.org References: <149554792031.21441.17538641677279207956@ietfa.amsl.com> From: Eric C Rosen Message-ID: <062af475-3c38-8413-dc64-bfbcfabba62d@juniper.net> Date: Tue, 23 May 2017 10:01:46 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149554792031.21441.17538641677279207956@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN6PR11CA0030.namprd11.prod.outlook.com (10.173.25.16) To BY2PR05MB2184.namprd05.prod.outlook.com (10.166.112.12) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY2PR05MB2184: X-MS-Office365-Filtering-Correlation-Id: db6cb990-3bff-4afd-ca26-08d4a1e44269 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BY2PR05MB2184; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 3:an/Cs1FdcR16U3N4Nc0xU+L/HwJ6agEo2ygfcZsnj4j3/xd2x56RPyrFDhAfcwki21gNg0YqAP10cPGEDNHNQdDGteP6Kq1eZlbFCyif/Ajpyb1XP+//YGdnGd40SQwunv2aQ2GCejQqfdpOVJRrzHgLFXHK57HStaoYBt5w1uHVeGKCc2r5BQ1yVuX+ocvERbddGxaMn8mmCWSJIX1LClnyLzom/DKL7agid7255B23HSjtq0NhzxBHXfutsKwe6uet+cgZHgwA0O/PomJTT9RgkLbExCRSEXsBqg9cnj9WoAgW9zyNaq+IcW57K/ss8FWyzs+xgYvQ/Tw6Gttm9hoBFbj0Ifpc+O73lo47LJo=; 25:kJqyixMR4ITjdLnEC+3n9YX5JbUelmMqPU85Zk4Q5t7z8VplrdTquGx51kLfrsZtPxCU+zc9A/4dFTgYyccF6qOx9S4fDD+NoQ9wdkQqIu8jkoSTZAs/jknQeIDk5d83DA4wbetZfD2FoZ8EaIbIsG2cZYAEagXa9RyCf5qxLVHMU2utOX5HDnM1KnEXTkgryxANjsxPAA1mXs1IitmAaY1YOXzM976xP0iHuhGcxKT5cjjx6icGlsJ2ElLZMz971WKh+BV4AlFeWe6VLUwR0j4d02I9nKI0wrn0CrAc9POVYllJQ2ibXxk/qVfAmWVNOpisW56ZO5AjQnnRinfW7Vo6b5IM4tC/U95JnX0FCkKI5glKNfA2hj7FO718WKoiBAbi4cBXy2itNDxWcOwVIvUmvEXlxJS4THxDYMBm5dBDlP2I5M4ylO1fETze8kX3RK+cYIjM/9pyuWSbs5k8TXzm1n+xTFevxKu35oAJ+qU= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 31:9CwMCsvgkTrnbsbM4j5W/XFglHBbk1k2q8V77tN6OCml4NqeOpHuIY32hC0IZI06eTHyH41BUAvSMFHaJvv+O8NYvIIPWsgCEVJc1QiVWYsRpfuNyMa4vaZxFgw7OsfNAw1Ojn19W+NBduV7kxjN7o9NP0wy+FGIi/LgFSUSzkaX1kz+7M1/IlFwZblrUTL1X5lXB+JqClinYlpFg2B0XpvfIjo9fGx49JrZ2l+WiD4=; 20:QMyDBzTNKbVl2XeK875JdjlKt2d2ZXOXXPYQrKhDJouT1yWjhIJQYn5mCIlCRPRyuC/Gv3tRIAPBDgex0ensqbdLBDu0ea05aSWOYK5CBqusEYF5Pk/vDcMezla+F21P16zP8tWME1GWGicP55nKJifOv1IDdydLeL+aokv2Zpm0/L41mdytd8aTKNeOkQ+ZIfPYnRkV2JNdFAT9q5kofQGV5HH77bL//09Tmv9MewBEeBFdlt0uy8ZhneteJmiZDGracmCbV5sWidrmpvs3ZDRK1ESZIwudfQxTtTDJrtKiBbcTz2MhjmqUrwk2z9+RRWr4v3w0hF4KeFbcEqZ37fB8HYHXE/Wi+V9t0/YCy9B4vMve60o7w0klOPj52SUeWHQMjXADuncb2BTg4z9iwzOMG4ilv7qU1Xe1pQKrYWhsCL9VUpd5pS16MDE3tIvFSXMtdIQ29YX/PZTrqluU9nGtRaqM9+szQz8FHlJ9wOPWXhTq8A3yTuyEBrtLst1EYDJ5NeCfzAj30k81zRZhOPVt1qSg5V+EnQgTCGK9xs2x9raFkxwE/EnSsHVNxMX1PdDbguiJfihV8R9zdJKq4LfgMfdBbsoVNw3QY6dBkRg= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:BY2PR05MB2184; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2184; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 4:QTPLPAA+SdKoTnzS5jkuvW6xFDKCQsOXV2HqxX4PbgwRlRIKWLh5sxYnvda36ZtlUKUct/vO1klnuUxm/Hl0nXbaVETA0hTRmWm0zJbYbU89OAbTlmBFa2ILHTKDOpuLsW9Tye3oFrYejA4Vb8iRxp7yqe9z+Sr1aNhb0TvIHFjH0iaQjBT+nj93POmp6c1chpz23eQel4jrU4E4CXgmKIKHTPNzZaPcCu4JzgM1LZ1/DTUKvEvNAuaY1KLi718ddlNb29sUDBAKUiDym1dkzAJPE9sRoirvmDyyvpWhkDcQpFDqxBfMlo/jnsV1Ni8a+YdGgeQh8kSDulBuIfkZGW1SzI9OtWnzkgsNdcDrSIDCuvfE6QfWfHgqWy6KCQtv3T0JexAUEkaOYvGBN2pvCceWWOdUVp32jR4MF8yDWmVZp5CNU24kVqdTxDdRsaTcOCMC0AXL6C0+oI1ik0XWhgGji/AaxiWRVRKhOjb9/DhlG6CdnKwOkQwFLUTrP0BpQyZvpbXdDoYP3iQmYSOvjdHFixguM2fWs2ljUsfOyWRHM3oZFMBwjUF6hHHiU3Xh1vEk4KOkdMdp9SU/FKcXSPDmR6yGdUg+tYSR7nfgu7OUsW0XEwafszApFANAttBsr+tA+O/TWUfWafDcF5HX9bnWeI9QguEQ3nSTGS+dL6V2FWh6gGQBAgtC1FyaiIesQmQMsNCJs0Fg87MJG1LJQa2aZz8SVziBU8DU75dwkpSTLeMd15+NAOUEEeYJZ+cbmdqeeJPAdIpVxc6dQDOiQB+9i3cUrnPugmEMmTHLMZ3i5WfPpY8qEfq4UWbBOe3avSClfL0BQLLWO7VcKGCHaOsb8906Ghy+n7/X8DbQdP4= X-Forefront-PRVS: 0316567485 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39860400002)(39850400002)(39400400002)(39840400002)(39450400003)(39410400002)(377454003)(24454002)(377424004)(50986999)(3846002)(6116002)(230700001)(966005)(2361001)(230783001)(83506001)(2906002)(110136004)(31686004)(53936002)(23676002)(38730400002)(53546009)(2351001)(81166006)(25786009)(54356999)(76176999)(33646002)(8676002)(42186005)(50466002)(4001350100001)(6666003)(2950100002)(6916009)(36756003)(65826007)(5660300001)(90366009)(64126003)(47776003)(6306002)(478600001)(31696002)(305945005)(86362001)(7736002)(77096006)(6486002)(189998001)(65956001)(66066001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2184; H:[172.29.35.195]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjA1TUIyMTg0OzIzOkpSUG8zVlhsbmVaTm81dmdMU3JOUTllWU54?= =?utf-8?B?Y2daRWhSazF4d3NTMFZuSk1HMTdTcGlrTi93azRmSzRBeG9WaE01UXdXalBY?= =?utf-8?B?K1MzM3FPMU9TWi9YUHcxcmNhcTNTMVdHdGhVV3ZMQk90bTBka0RacVI4VDdi?= =?utf-8?B?WTlxb0xlKzZzOGc5VHJDK2JJZ3NTdHpBczlwWG5JWnBHblprR2lTam9RYlU1?= =?utf-8?B?REQwQ1BsVVdXUHBxOFVoRzBWRUwyOTNhS2hmSmFrUjhPK2ZFMGczL0ZLZnYy?= =?utf-8?B?QW5MMDVrM0hBYWZDTGp0dUp3ZnhqaHlBcWVHOGp6MGZUNjlIaUw5eHhubHpX?= =?utf-8?B?d2krbjJmSzVlMzE4RGxQQnRaWTBwM2FoZjlKN0dHdzZTTGtSSjhWcVNTU3NY?= =?utf-8?B?ZXY4b0ZHOERVYVA5RUovMGFvcGJlcnY2UHN0L2xRWStWd2RiM0pBeDlFUVRE?= =?utf-8?B?Y3JMczFsbEpmM3o5ODJEYXJ6cnFjbHJBNUdsZlZBQUd2WVRrUk9pTkpaR0VM?= =?utf-8?B?ODJERE1aQ1A0R3FHSVcwWkVtWktiMDhvUGkzMXcxRG5CMDl1WGpPYlJIWHJq?= =?utf-8?B?bUhJWmsySm5LZWtnMjhCZG1lekExZGRuWjR3R1laOFc1a2wxVzY5dUpQZU96?= =?utf-8?B?blhuYldPV1dkcFFQVFI4aXBPd3hZWWc5dUlWVkowYjluWlhEeDJWa0o4V1ZY?= =?utf-8?B?S0hmZXVueHMxd2ZkVnV0ZkxPcmkwU1FUQTZ2UmhPSVlqNFhmN3ZqbElBOTVP?= =?utf-8?B?YUZBSzFydjVKcDZHSGwvbE5IbnFZa1VCMXpUUjgwbEpia2lkbGwzY0c3K1Ja?= =?utf-8?B?UHRyaWRFeWFtUGdJekNyU2NaRkNUYndpaGV6WXFnTXZhYllYUVBaUzJpdFlW?= =?utf-8?B?aXB3Sk5IbHJVcTdNcmthZFNTU3FHZlV3Q3lGNGdBeTNvVVFHK1BmdC95bFFm?= =?utf-8?B?SHdOSzFzeS9ZRytxVk1ySGQyWjYvdmdiS3A0RlJ0UDQwRUZiQ01KV09hUDU2?= =?utf-8?B?ZW1UYkJhc0Y5cGZ4VXZZemxjcUorbEpCMlN1cmoxTUxHS1F2QTNVR3FIWU8w?= =?utf-8?B?eFpaMHJiaFFUTkdObjhvdHZ1UjdZMytUZXluMVdETFBJbXFJUDdGbWZGSDBE?= =?utf-8?B?Z1A0YmdRaVY5dGU0NzJ0WG5hVzBQYk5sTjNiWEI4Rm5zZ291MnRwMmNXYlJN?= =?utf-8?B?NGhkYlZ0ZXYwRWxsK1ZSVUE1TXozaVorN3RkNDZQOGVzOUVNMHVYK0V1MTFq?= =?utf-8?B?YVN5aTBjQjNVanBVbDdtUWNoQkVNdnU1M3NuZkJQRUsvd3dzWGY2anF4eFZS?= =?utf-8?B?bS9sRlBtWWtTUEwzZnJuRVVITU5DTHZjY3dQc0xZVUxGcUtoZkRDcHhBeFJR?= =?utf-8?B?VkxVN0pZc1pTZXhFUUprWllSa1FpMkU4ajduakpWSmo1Z3Z5eStpR1E5anFh?= =?utf-8?B?RG1BWkhiSENoQkZUV045aXRwMzF3bDZ3YlI5S3ZkUzMveEhPeGJYNGVPdERG?= =?utf-8?B?Z2dJZzBpMXBlRlphSE11Y0xselorQUo3MXE5aUsyenBiQUF4NUI3NnBrbFhh?= =?utf-8?B?bEVOcFV0OXJlQlFYK2Myb2htb3pCbzcrU3lxaFRsM0Rhc1RVQnJGenZVSXpF?= =?utf-8?B?cFdMcVdJemE0L0ZTSGxRTUI2dVBNRE5ncUVvUTllMm85QW9QczZhVFlwT0w5?= =?utf-8?B?QXF4VGVRaGVUd3dZQW8wUWpJUkt6OHRISTdudE1wcDk1NUlBNDB3VWRVTVhu?= =?utf-8?B?MHd6NmlIM0tERi9BR0Fvell6ZXJNTTVDZ2Q2MVd5SXNCT0J3b1pwRVpwVlVW?= =?utf-8?B?c01WVjJzUytFbXZuRDF5NmYyNVZBMEh5aUNabDNSMksybDlCdGN4YW1FOFpm?= =?utf-8?B?V1p5VWZSQ0VZL01EYXkyR1BMQnkxWEdpUWF4NW4zK1l6K3F0SUgwTFVmSFJp?= =?utf-8?B?OXpXY1VCODR3PT0=?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 6:0y9acy8CfovINUmfAjVk3i9I4KVtVUs1Sb7L9H1P+YkEKd5toFQEkSXTtKybTp0e4dqAXc/3wE9l9coEw7d9Dl5JVbf4ipOa6cC+0J3hbja767+Q4kMBuhNLfjft3VZi5qHJIvmzf8RHx7nmWDU6C2IN0OJ06Lcidg/YZp4jJTcgDfvjjwwgQZf9ytcIGZFjD61htBlZOfsTjqR0HRFOIDtEi+eyf8aN2i4pqpjkQDTiXK0UYhCvZGSr3hkqTOyLFqxge2f38mCDtQSle2j2MQw8k6eTlezeFj2t8EHm8OCazEBJ9wmh0PaAXSl61BgIwTMt46scMiiByoMp0+w5KGeZt+QWHqSpJOX5/LtIEb9R5MkWiM6caJPEUKuuYCUrmeqvLRyTS5DVMlas8mHDEdTUa4vZW6MLjaAfY/MaEotYIYxBl1LvvMmIvPd52P3sM2FW5xZq3/boC/g7YwGopW1NoUo+gLrmpFtxGfBgicSzoDCMMjfjR0f1Y8MxaKbkjg6GZt3mMRXw27eTQpBQ7KW/pbTSmm4+L5VAKR2h1xGpLu7x9ILcIm0dvZ5+FkZD0klSyViCrPHOfPWv1zo6Sg==; 5:cEt4jRglnJ5H48WFCF/cWYSlo/Sdr/9mEWrK/OM1Ep2C6kzLCKSTHNGOEXyYRZ6YEWa475BniQKxv0aFrtcHKWjnt88zvNxFcv4cXHahfwRQdHyv4KobWbAjI9yg11wVtEKiuXx4IiDX1SfFkhbseQ==; 24:aTY2L4vNRhM1aqs1G34xCNmvySoB/pB+dUAAeN5rUmYJne/6/53S2gXKUMdimKQ1IJ/noq5tEreloOp0FLfG62Bbq67DLqujaiiebPG3qyA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 7:Cr9RdEsm0BX+c+Hl4U7NM4JMvhW7xiLtSVGzA8g/gkS/8ZbooqICTmH8esJXgTBDLB69mf8/26+o92G0NSxZCGI88zn/pR6fXBoY0pwgQIS16G3WaepY1P4/wg5TcN+f9VmhBGfVtAuG1gSokzyA4HCj2oWpUAT8ey3y6B/obaqeMFC8NAJ7FxgHgFYjG+ldATHR5RZZOZ55/3ZndW2qO7ZdLBMSRU+S6SYRZ6z8hKPfez4ARFVBLYQhNlYORVyHlmoj6aGYda22KWa1geNTXnMhVSvHSkoIvO41Iyagf5ldtise+lR/e4idyTqK/2V2C/PKoQYWi9bRUkppcapwdw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2017 14:01:49.9927 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2184 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 14:01:56 -0000 This update is not substantive, it just corrects a co-author's email address. Sorry for the noise. On 5/23/2017 9:58 AM, 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 : The BGP Tunnel Encapsulation Attribute > Authors : Eric C. Rosen > Keyur Patel > Gunter Van de Velde > Filename : draft-ietf-idr-tunnel-encaps-05.txt > Pages : 40 > Date : 2017-05-23 > > Abstract: > RFC 5512 defines a BGP Path Attribute known as the "Tunnel > Encapsulation Attribute". This attribute allows one to specify a set > of tunnels. For each such tunnel, the attribute can provide the > information needed to create the tunnel and the corresponding > encapsulation header. The attribute can also provide information > that aids in choosing whether a particular packet is to be sent > through a particular tunnel. RFC 5512 states that the attribute is > only carried in BGP UPDATEs that have the "Encapsulation Subsequent > Address Family (Encapsulation SAFI)". This document deprecates the > Encapsulation SAFI (which has never been used), and specifies > semantics for the attribute when it is carried in UPDATEs of certain > other SAFIs. This document adds support for additional tunnel types, > and allows a remote tunnel endpoint address to be specified for each > tunnel. This document also provides support for specifying fields of > any inner or outer encapsulations that may be used by a particular > tunnel. > > This document obsoletes RFC 5512. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-05 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-tunnel-encaps-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 Tue May 23 08:04:46 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33953129B8C; Tue, 23 May 2017 08:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frWSjk3110yT; Tue, 23 May 2017 08:04:42 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0091.outbound.protection.outlook.com [104.47.42.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307C2129B81; Tue, 23 May 2017 08:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y0axRnoC2g2ZyYKm6JFCiaImdJl2lp/FcCg/o8/qk6w=; b=Vk/05bvPk7XvALQlm0LRT/RCQGut9s1wlVqGWUvpQwBGG5eZAFZjnQwO1pg+g/MGJL7E/0oIhgdWEO+xpfYCDL5xiEvVEnXnuQB0KNa4oVKr0+tQq35hi+VhI2WjrEO6CS3ilzbW3RPRi43IFgfwnoXi5qRAXo7AhRlBOMu5T0g= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.195] (66.129.241.11) by BY2PR05MB2181.namprd05.prod.outlook.com (10.166.112.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.5; Tue, 23 May 2017 15:04:39 +0000 To: Lou Berger , "John G. Scudder" Cc: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> From: Eric C Rosen Message-ID: <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net> Date: Tue, 23 May 2017 11:04:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN6PR03CA0008.namprd03.prod.outlook.com (10.168.230.146) To BY2PR05MB2181.namprd05.prod.outlook.com (10.166.112.9) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY2PR05MB2181: X-MS-Office365-Filtering-Correlation-Id: cf0c1ecc-6a7e-45c1-209f-08d4a1ed0954 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BY2PR05MB2181; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 3:U726arMot5dlH/IKg2DRVwtCguUPiK0/28NrstrNRv/mOc0O3arw2YWaWh422kgxZuYscViRBKr4kpA8LnHhomJ7IByJUTw6NKZn6zT4TFEm+Mf2FvFQWj24SrKr1rydhMk74wXjlB9TPC2/3dT/ZaGn2a2bN+4zJCNYH5309EiEE9HsGE5Nj3UvMU+mkvM3O3TYUVvnomcPcL9bfzsz1ymPqPkf3bqaFNSU2HhCtawz8CEPV+VzhYQICjEDpAuAbL7P25/lrRJrIxb3aTZdBNYR1F9ffOQFlSHhRaMHb3xAEE/L7lqi/QM1MDSJ/DB5ilSQuZofUdgzYFBRK6lhLDuomeiK5bgy3r8698KXQDI=; 25:VXrqWXX1fdEQ49/AetqC7HRF6kKkwFlHsiflGG2Xp46Kc48vR19ulZDPaJJ85dzVq3fhFoPGEPH+nz7H0HRNp3i6CZM6+50Gt4oLnDbV+mhTanYrUhGdRPVxPPolh1gh5aOeaw5R7Lc/u61cmu915cIMfuYcbagT+9r1xA0KZvecnNAElazdKvPpHm/r4t+FPMG/YnG8GtmEgXEe1PgHkWAuGvtPu2UIYfw4OgBN+K919KUK2MoTZDon+uTr5n9cPol6nJKCKA/mZWtt02+fW9+4cfzZq0ldXT7mdbqBo+dwbnW4SN9cR14XhnT9G5nKnBwbIfjkjDIi+2zDiKCoqu6iJD7UnKa3m4vDcmCgFOeTNuInM1CGWY6VkFW+nxb6cl1Fhisl+95MsfvIcR4c0kHNZZQ9cPaSQKNFtEaUDXuhHupY0Eb7H8cSsG4gw2iL+yY3sDvpDgrdT4IK4t0d/NpESLVQzAuFLuH/10LPTSI= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 31:n3KpM6bL+2+M4/jeAVGxW8EW0DCYdk25lKtgWpZ7bp8uL9KOQnt7x6Aa0O2cf5C7tS+ByYq7ZpmnG6vIRuK1OnOg/LBTTjphq9NBqbh4bI4jT5E4nWGs+cq4nPicJP+vXf7Td8p01m0z88T42J3kT3Uv1jE6fnxkcGpLyGw51ye8ZcPbbrQFUTAQe088l0bhm3LQUVKM3EoMnvyUgu3FoUEo9olZHudYf3aAcJpVp9s=; 20:6L9JwtbH1Q085IGPsvbeMsBiJZqdtsTEU3ebZ7HV2dfDrZB3tJ8GQULIU/TCtVcQG5ZR/kskJP1BamOcC+61rckavTQsbQ2aDe/5qszx5g1KhzwbaNlnSBdPSzZuK5U5NJqviGJtUFantol7b1kQjoMe8fwpj6tNIlE926+/qMY8t/jMeGP6Ur7LY9MbPhUlVquWH+cazQNUdyS1DK1NEcpb1fKzbjxwwrSep/fBska8TgNuW4I9pbDAU6cZcps2Ml5fLT0TTExrJMnQXd4DQyT8I4CCr6dykLZawB8DfygziSDd/XJLWumZM95L/AI8f82L8ZdiOGnTZcaKKaewPfpOibOcf8Qny3EbMbK+w3dOwRgDR4mK+ILUbWV9KC8SrfIruyTqI0f+zG732vvP2rqXEkg/ZaLNOz56dHUt9FkGQ2yBuiU3AWmjzg1P7qGEAhPEAR1L1gUfWSzvb0ALWTPISjWskjENU2C7GxBm0s31nJX3Vn1Ce8KGihmCjnMtbA0StXqoHc417HdOvzKV4sXebpoNUfKNku+OnPrSdzanhjNhMHcj1Rf0w6SmHIY61wjEdzXEHiNG9TmZ1wUk4UTlfddDsXsT2+h4CDNGQXo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(192374486261705)(788757137089)(211936372134217)(119230021023882); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BY2PR05MB2181; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2181; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY2PR05MB2181; 4:tUqLcs3v6TD0xPxfdQdHip8vgvkd5UksunLPvr?= =?Windows-1252?Q?wtJzlDCUnnNu4ghTTZ+FoRDH8Al1eDbzeY3yUx9TRJoLvVB0LHyUunNs?= =?Windows-1252?Q?J3sIiuevr5cyCa603qo1U3Z84FmoKAzVn7SEjWx8/6CGOvYH2kT1jEUE?= =?Windows-1252?Q?tBGDo3bT859PkY8C3PgB9n7wyGfcGjaRHMojvXlbq6mo3GrW0w5sygRW?= =?Windows-1252?Q?Xxk/sEgoaIfTfV4bQTgHk5H1KVFsLaSPTsyaLAbrAdNUt3x8PKFfgGD2?= =?Windows-1252?Q?i+Xzw93eMncmy79cxItWLrgC58MuWPgNwnsYLPI/iBVH8EXhhhWy+Qtv?= =?Windows-1252?Q?HeB50HZU464/MwrbzWnHkwStBu8ZpW6k9HYkcV9OYuuBtmxMBCnHKHk+?= =?Windows-1252?Q?PR2w2/p2yKZdITqjQ2flnMjBGxrtjtmuaH2pVjz9cFefusVIS2aC9ydV?= =?Windows-1252?Q?v7Azx05InkBvXSHjJfPC81tE0PDdxqg/zjen+3jaaiXT4WScfMb+gM8b?= =?Windows-1252?Q?S3P6YH4+P6qk/zR+1gH6Mu6vaVfavggFMqMv4Fu5jYs7Ei8rsyimUPec?= =?Windows-1252?Q?pkWqS+6OmtnpHQGiylTjsfK6bLSlvoFDmHtAXuFxxShgytnP2/M7Ax8S?= =?Windows-1252?Q?CRTdpcSsLRFJAupVcBfYORJXQbZRZJsMGGdFFP6UgotLJuEOiFavFLhM?= =?Windows-1252?Q?SDh5dcJKgSehFmQUUlDRYitIVSA6Z82Q5BlJEyOuEsPD3o8+IjLxFEcJ?= =?Windows-1252?Q?BfXxCauCvpU/hwjagBxIO5B1aqYGwiNYQyrdnI5+1bZN+ZRdwcFdKYaY?= =?Windows-1252?Q?Rj3zcX+lHUzGa9fpz7gw+JCMX4MSpqML7yGCa3ELkTccQ3Wh9pmMlN1o?= =?Windows-1252?Q?0U1ed4Ipq3ZNL5e5vmV2d9HK5xvmb16cDpYc/phTpPNSsKHlh4Wu+Xek?= =?Windows-1252?Q?LujtgjeKGJfimX5SRENrUNJ4OHSqFtJoGztUgBWO9MAPvsjbeOVRDbMX?= =?Windows-1252?Q?/ocYfHunyzUiD192mxY5iRXyrMAYlqRYiVdslhb/lJ81/UAVN1APTtHb?= =?Windows-1252?Q?PzHujrA0qLTng=3D?= X-Forefront-PRVS: 0316567485 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39450400003)(39850400002)(39860400002)(39840400002)(39410400002)(39400400002)(24454002)(377454003)(31014005)(5002510100001)(36756003)(230700001)(4001350100001)(42186005)(31686004)(23746002)(2906002)(6666003)(33646002)(65956001)(66066001)(5890100001)(230783001)(3846002)(5660300001)(31696002)(65826007)(86362001)(6116002)(83506001)(6486002)(76176999)(54356999)(38730400002)(50986999)(77096006)(47776003)(478600001)(93886004)(7736002)(4326008)(305945005)(53936002)(189998001)(8676002)(966005)(81166006)(6306002)(64126003)(25786009)(2950100002)(6636002)(50466002)(53546009)(90366009)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2181; H:[172.29.35.195]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY2PR05MB2181; 23:SLbYJ0GYUPxf9JL712lI8pzvJK5pexnxegDJZ?= =?Windows-1252?Q?DTBsE7JizVvCXpRiNnp5mOYi9GiSOYAjYW3I3yl7HfS9PX1L7LWCK8mR?= =?Windows-1252?Q?VOzTNvTNpb4LCPdfxb1LjubNBbZEKVo/c+30QdivfLa2SS0wKy+6mmZ5?= =?Windows-1252?Q?XtN9+NFYj/YL6BQrHzUikAn+yrpbu1qo4sZe9umplo0hZXV7hvyg9nri?= =?Windows-1252?Q?gBkgks5Izo/4XUUgTERgmOlp+CHwoPLSrSewbXmTw89mlyeykZaABeMj?= =?Windows-1252?Q?Kybt/KLSLOclSXBHwxGko/KxKDqGD4mr+3c62qe09UQk240lbRpz51+S?= =?Windows-1252?Q?8QATy9UrSV1Aw1qFjMVV2XJbwP4xnyz5tgTEMv1ck0Qdi69kMyXoBLwd?= =?Windows-1252?Q?TDBTOzppbf0deZdGJp2D7IePmtFxUATduCN9lt+ujUod6gddMK6n5x8D?= =?Windows-1252?Q?pKiDdYkVSvSq0HDbG0Ik6vEkN5La3nPoBijJsI5ELHBhjoZI+4Pf5Agy?= =?Windows-1252?Q?8KP2YhDjqwcsxiRTXiZ09sAC9/vQOijUymFHOM1SiBYN9CSb/sAe7pUo?= =?Windows-1252?Q?1byYofC0aYbgSLkvV8uBl/OXVwT6BFeaqBomySTk74Lx0gW7cg4AG9pp?= =?Windows-1252?Q?Sk/gunr5KV8ka/QMnTKYtyGxrIlOt/366OOTPOM7QbHJA8UNPJpvhMJK?= =?Windows-1252?Q?xyNutlP+8520IjFuiv3IivdnoUieUyHCHDz5i/rtftcMfPHwEH7jgcAa?= =?Windows-1252?Q?+imulUtSuvKFiRacvjVsRKEDVhj7HWwVTTdJDDwuopiNEnKbr6e9Aat/?= =?Windows-1252?Q?7YSptCl28ka8QP9Jw++aEcvcwlK7Bd2ZgFMWa1Q/voziOPA4nhfPpbGX?= =?Windows-1252?Q?qbnmEfGNTi1KlzAHfCvCpna0A8C1pYoMmHZn6c9pl3/ZpQe2zwM4S6so?= =?Windows-1252?Q?XX39FJ6uh30w84T14ZGYqwBA3nnP3Jk3Q89DFciirpXzN95HGdVckycE?= =?Windows-1252?Q?zuJ9FWtOU143PKO/iL0V7S1u0bBdsu5AtVcCO1S+b5jyD6qu+MamyLFZ?= =?Windows-1252?Q?iZJ6iqzmpsRnGpMH1d0TbSfheJ57A0k0cA3Y427d8NVFVnb4fJqnkdZA?= =?Windows-1252?Q?RrwuLhKPIXPkFR3PVpzIVTGMUP/xEPVPPpAEZau1uelJtvfA7kr7y57r?= =?Windows-1252?Q?5vzx4sS272gnLoV2a7sr4V2x1OJmmY52SFTCYPJKQZE23CjKtidX/px5?= =?Windows-1252?Q?f4afv8SxZCPCXBmTZTmf5yQbqXuvIKQzQZHO6FtihQToTxgE9DnLQ2Dg?= =?Windows-1252?Q?2tyOIhWEAv7CLiCvzrM3LMS7IExWvBSqMlCdROdspcSSJPrC1na+X6C4?= =?Windows-1252?Q?uPE0cDMcVS+4Owy7VZmClJ2QZAVTYCzL6Q5S4RD3bbKycastZsJ6ZBxn?= =?Windows-1252?Q?ClESQ15PM8jQTtvf4QSVy98GzUblh00YYLTM7BfwlxQcfvZm7TARck6f?= =?Windows-1252?Q?xQeblvvINbmEr2p/d8joxGm76gp1jDZFPuZAX7zNA7zqPn5CTPkx9CUt?= =?Windows-1252?Q?+JtkpYvsDKqRzGeKW8/h6Fqixo46uia52TA?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 6:YlTcgQZnbH+/d2lngtJWASBUMDucJPAWO4gi12KtrlWow18ZyaYrQCYd3H6lT19pMz6f7XyFmNfCam2qOagjv2fWpNIf0ydYpWHcfxYaw6IBgXhVuiAV4y34XeF5VNgSxnZTBdC8xoxmsp6O6xHjs06p8+jg56BfCNnqxMlAp0Mp1orfDcyc3na17Rb24RLfm7GWG7f5Qzf0MReVkHsBUHTBpOseRqKpjL9IxW4wJXxCK0wPZv9j/vEB6sryrfotRLFEQ4zJS2cPKmhWKxMLpNy5Kn6H8qFNf+lV7IQCEf2Lny9PTf2HEfTSy9ntiQDrFRBv3XBgzhh76oylIKYaiXTvrORvFhwTHEDKdldGgICvg58QzPMtY13boMp0EDy1idY9IpccmBRVSXsQlg+nBC83Z3eSfP7MMkzGQPgTmDx8YnJ3mPJ/XNcR4bPoYR4KLaRZAJ0ugfFC2ZomYnTVvu2CZwZwWXy6CBAFahmnAeFbhuVuqpzUEq25psFwG2oA0x5uvyXsQpyT2sZFZa1kHYRANn6212ERJflYz3tU9y0=; 5:HK6KLwHIPce8zDK17q6jbdEC6N00eiLenWSKlBRnIu3dme23e4r8tfvXCSRnToL/cOnxgu6Q8HAaR1dPRkk2bJa11xr84Pq8ZGW3bmdXbYXLiJycUMFNyFQFXFcorAyAh9irh7OpNvNjntuheljEow==; 24:HVSrPWpKlO5n9NE7zp2N18jONS6nI3G7GyWw7SLJMTgTagJyuhlwA3aBKSwCRGlz7xBmTO1eCLMQhzcAlfmg9APDEGxio14dg1Tcp7FW26A= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 7:GaLJ0gQKDIQ3HYxCIpIz38gzsrdPgze0uzGjanKMt+h4W/0OqPvHLIwakUt/hThBBigPwP9tHpv8KwkUnqYn3Hw+YV/ZsKhLBbLL44h3qsn67NfrpCZTd791YRjeaWqV/YsFdsglnpsOGB/LQi38lNWL9k/ba1CVwHa0E0NO79cWLYlj4NDm5+Fd9D/6dgu0g1RGh6WH7uGBwh6DUsvHcM6RrP3I5c3k9w26Pw2C5EwIe7iL16qKL5P4qCcb2v3xpGMSPJaDCOha9A1SbKjDbqY54CiUrIc+LFoxCLZC5xXJvM0N58MSpUP+6g7kTvio3pjD50TTpG1lP9zkL9gbCg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2017 15:04:39.2154 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2181 Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 15:04:45 -0000 On 5/23/2017 8:45 AM, Lou Berger wrote: > > On 5/22/2017 10:51 AM, Eric C Rosen wrote: >> On 5/21/2017 3:58 PM, Lou Berger wrote: >>> Overall I support this document being published, but after addressing >>> some comments, most importantly the first one: >>> >>> 1. I think this document needs to cover its impact on RF5566. My >>> personal preference is for this document to subsume/obsolete 5566, but >>> the types defined in 5566 shouldn't be lost. (BTW I previously provided >>> authors with text to allow this draft to obsolete 5566 as well, and can >>> do so to the list if it would be helpful.) >> It is true that this document orphans RFC 5566 by obsoleting a document >> on which 5566 has a normative dependency. However, incorporating the >> security-related material from 5566 in a way that makes it useful is >> going to be a fair amount of work, and the rest of the document >> shouldn;'t be held up waiting for that. > Well I did make this comment ~ 2 years ago, so you shouldn't be > surprised that I'm raising it now. I'm not saying the WG has to follow > my preferred path (of having this doc replace 5566 as well), but I think > something has to be done to not leave 5566 "orphaned". > >> If you have some simple and >> non-controversial text to suggest, let's consider it. (I checked my old >> emails on this topic but couldn't find it.) > my memory is that I put together a rough google doc at the time we > discussed whether your doc would deprecate 5512 or not. (See > https://docs.google.com/document/d/1PSVTwf_QaRVWqhmkfaoRuP2JoGq_Nq9mlICUv6Z2BOQ/edit) > > > To have tunnel-encaps deprecate 5566 as well, I think the following is > needed: > - Include the 5566 defined tunnel types (particularly 4, 5 and 6) > - include section 3.4.1 and 3.6 from the google doc (which is just edit > text from 5566 sections 3 and 4) > - perhaps include the 2nd paragraph of the Security Considerations section > > Given that the text is mostly lifted from 5566, I'd hope this qualifies > as "simple and non-controversial". RFC 5566 assumes that the IPsec tunnel info and the authenticator sub-TLV is conveyed on an update of the encapsulation SAFI. I'm not convinced that there are no addtional security issues to be considered if this information is carried on updates of other address families. Also, note that in RFC 5512, the tunnels only extend to the BGP next hop, while in the tunnel-encaps draft the tunnel endpoints are not necessarily the BGP next hop. This might also change some of the security properties. I think this would have to be thought out fairly thoroughly, and I don't think that work's been done yet. Given that no one's been motivated to do the necessary work over the past two years, I don't think the draft should be held up waiting for it. > (new issue 6) In looking at the google doc, I was reminded of a > deficiency of in 5512 that still exists in the wg draft. Neither ever > define the format of the Tunnel TLV. Don't you think it should? > Obviously, I do. Feel free to lift Section 3 of the google doc. Figure 1 is not satisfactory? > >>> 2. WRT the Encapsulation Extended Community. I find the following rule >>> very hard to parse: >>> >>> A Tunnel Encapsulation attribute MUST NOT include a barebones >>> Tunnel TLV. Instead of placing such a TLV in the Tunnel >>> Encapsulation attribute attached to a particular route, the >>> corresponding Encapsulation Extended Community MUST be attached to >>> the route. >>> >>> Are you saying the extended community MUST be "barebones". If so, I >>> agree as this matches 5512 formatting. If you want this extended >>> community to carry sub-tlv information, then I see no backwards >>> compatibility basis for this and don't support this. Either way, I >>> think this rule needs to be clarified. >> I'm not sure I understand what you are objecting to. An extended >> community cannot carry sub-TLVs. > Perfect. That's what I was hoping for/expecting, but I couldn't parse > your text in a way that made sense (at least to me). I also think the > current phasing goes beyond what some implementations do, e.g., send a > barebones EC all the time. > >> A number of existing applications exist that use the Encapsulation EC to >> specify a tunnel type, with no parameters. The above-quoted paragraph >> attempts to encourage backwards compatibility with those applications by >> saying that if you want to specify a single tunnel type with no >> parameters, use the Encapsulation EC. The Tunnel Encaps attribute would >> be used whenever the Encapsulation EC is not sufficient. > How about replacing the quoted paragraph with: > > An Encapsulation Extended Community MUST be included when a barebones > Tunnel TLV is used to identify a tunnel endpoint. The corresponding > barebones > Tunnel Encapsulation attribute MAY be omitted in this case. > > BTW our implementation always includes a "barebones" Encapsulation > Extended Community ;-) For anyone trying to follow this thread, the Encapsulation EC was defined in RFC5512 as a simple way to specify a tunnel whose endpoint is the BGP next hop, and for which no encapsulation information needs to be provided. That is, only the tunnel type is identified, and nothing is said about how to form the encapsulation for that tunnel, how to choose which packets go through that tunnel, etc. In the draft, a "barebones Tunnel TLV" is defined to be a Tunnel TLV that that only specifies the tunnel type, and hence could just as well be encoded in the Encapsulation EC. I don't see how it could be correct for an implementation to always include an Encapsulation EC. Sometimes you need to specify more than the tunnel type in order to construct the encapsulation properly. I don't think your suggested text is accurate, because a barebones Tunnel TLV does not identify a tunnel endpoint. > >>> 3. I'm not sure why the color sub-tlv is still needed. why not just use >>> the Color Extended Community alone? (Is there really a case where the >>> recursive lookup in section 7 would have a different color?) >> The color sub-TLV is per-tunnel, the color EC is per route. You could >> have multiple tunnels to a given endpoint, each with a different color. > okay, this works -- we solved this using multiple updates. That said, > do you think the complexity of multiple tunnel tlvs in the same update > is needed or really used today (vs just using multiple/per tunnel tlv > updates)? The encap safi certainly resulted in some pretty complex code > in order to "optimize" update sizes. It seems that this too is a > similar trade off, and would be a good additional area of complexity > that can be simplified. If it's not used today, I think we should > restrict the Tunnel Encapsulation Attribute to one Tunnel-TLV. The use of multiple tunnels between a pair of endpoints seems to make sense, especially if the tunnels have different characteristics, and if color can be used to map particular traffic flows to particular tunnels. This is something that has not changed from RFC 5512. Note also that even the Encapsulation EC allows multiple tunnels to be specifiied (if they are of different types), since an EC attribute can contain multiple instances of the same extended community. > If this is kept, it seems like there's some special aggregation rules > that could apply. I'm not sure I understand this point. If you receive two routes, and want to aggregate them so that you onluy need to propagate one upstream, and the two routes have different tunnel-encaps attributes, you need some policy to decide what to do. But that's true even if the tunnel-encaps attribute only specifies one tunnel. >>> 4. In section 12.4, values should be defined by this document fo the >>> newly established Tunnel Encapsulation Attribute Sub-TLVs registry. >> I am under the impression that the preferred procedure is for the values >> to be assigned by IANA, not by the drafts. > I don't think this is the case for *new* registries. We can defer to > the Doc shepherd on this and not discuss further. I'm sure that whichever way I do it, the document shepherd will tell me it's the wrong way ;-) > >>> 5. Nit: the document says "This document deprecates the Encapsulation >>> SAFI (which has never been used)". The use part of this statement isn't >>> strictly true as it can be found implemented in FRRouting (a fork of >>> quagga). This said, I fully support its depreciation and look forward to >>> submitting the patch that will remove it! Just drop the two never used >>> comments. >> Since you are looking forward to removing the Encapsulation SAFI, I >> guess it is safe to say that there is no production deployment of it. >> If that's the case, I think "never used" is accurate. >> > "never used" is not the same as "not currently used". The latter is > accurate, the former is not. I can live with this (pedantic) inaccuracy. Was there ever a production deployment? I'm sure the IESG will ultimately grill me on this, so I would like to get the facts right. > > Lou > From nobody Tue May 23 09:11:48 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735B5129BB6 for ; Tue, 23 May 2017 09:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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=-2.8, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2GH09nJoWJp for ; Tue, 23 May 2017 09:11:45 -0700 (PDT) Received: from gproxy4.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 E5701129418 for ; Tue, 23 May 2017 09:11:42 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id E70621766C9 for ; Tue, 23 May 2017 10:10:51 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id PsAo1v0092SSUrH01sArhK; Tue, 23 May 2017 10:10:51 -0600 X-Authority-Analysis: v=2.2 cv=K+5SJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=N659UExz7-8A:10 a=tJ8p9aeEuA8A:10 a=B6KMzFptAAAA:20 a=p7YFGuTEWXz_nwAk95EA:9 a=f21VQvZyLqnkhLdK:21 a=OGiMHABoWSAq-RmE:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=1d943nT1k8g9WKvw2vnTzcR+P7qeeT09r4wbhWAxyCE=; b=Ryzjocn4J9YAb5/mMXA4lmNdid FE/IUelO3t7vgT7npqAHCLfyMcZrIT7HOHGOcAZtOrV0Hgdu9g2GpxECbfBnJaxHA4QRRZu41bIQ2 GWLaov7C9y4JJsU18Zuxm4gHz; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:41512 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dDCOV-0000sA-TC; Tue, 23 May 2017 10:10:47 -0600 To: Eric C Rosen , "John G. Scudder" Cc: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net> From: Lou Berger Message-ID: <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net> Date: Tue, 23 May 2017 12:10:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dDCOV-0000sA-TC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.84.20]:41512 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 16:11:46 -0000 On 05/23/2017 11:04 AM, Eric C Rosen wrote: > On 5/23/2017 8:45 AM, Lou Berger wrote: >> >> On 5/22/2017 10:51 AM, Eric C Rosen wrote: >>> On 5/21/2017 3:58 PM, Lou Berger wrote: >>>> Overall I support this document being published, but after addressing >>>> some comments, most importantly the first one: >>>> >>>> 1. I think this document needs to cover its impact on RF5566. My >>>> personal preference is for this document to subsume/obsolete 5566, but >>>> the types defined in 5566 shouldn't be lost. (BTW I previously provided >>>> authors with text to allow this draft to obsolete 5566 as well, and can >>>> do so to the list if it would be helpful.) >>> It is true that this document orphans RFC 5566 by obsoleting a document >>> on which 5566 has a normative dependency. However, incorporating the >>> security-related material from 5566 in a way that makes it useful is >>> going to be a fair amount of work, and the rest of the document >>> shouldn;'t be held up waiting for that. >> Well I did make this comment ~ 2 years ago, so you shouldn't be >> surprised that I'm raising it now. I'm not saying the WG has to follow >> my preferred path (of having this doc replace 5566 as well), but I think >> something has to be done to not leave 5566 "orphaned". >> >>> If you have some simple and >>> non-controversial text to suggest, let's consider it. (I checked my old >>> emails on this topic but couldn't find it.) >> my memory is that I put together a rough google doc at the time we >> discussed whether your doc would deprecate 5512 or not. (See >> https://docs.google.com/document/d/1PSVTwf_QaRVWqhmkfaoRuP2JoGq_Nq9mlICUv6Z2BOQ/edit) >> >> >> >> To have tunnel-encaps deprecate 5566 as well, I think the following is >> needed: >> - Include the 5566 defined tunnel types (particularly 4, 5 and 6) >> - include section 3.4.1 and 3.6 from the google doc (which is just edit >> text from 5566 sections 3 and 4) >> - perhaps include the 2nd paragraph of the Security Considerations >> section >> >> Given that the text is mostly lifted from 5566, I'd hope this qualifies >> as "simple and non-controversial". > > RFC 5566 assumes that the IPsec tunnel info and the authenticator > sub-TLV is conveyed on an update of the encapsulation SAFI. I'm not > convinced that there are no addtional security issues to be considered > if this information is carried on updates of other address families. I think the assumption is that the sub-TLVs are conveyed with the attribute. I don't see how changing the SAFI impacts this. > Also, note that in RFC 5512, the tunnels only extend to the BGP next > hop, while in the tunnel-encaps draft the tunnel endpoints are not > necessarily the BGP next hop. This might also change some of the > security properties. I think this would have to be thought out fairly > thoroughly, and I don't think that work's been done yet. So leaving 5566 as is introduces this issue already (due to the introduction of the remote endpoint sub-tlv). If the we deprecate 5566 with this document, this can be trivially addressed by saying that the endpoint Authenticator sub-tlv applies to the endpoint identified in the Remote Endpoint Sub-TLV. > Given that no one's been motivated to do the necessary work over the > past two years, I don't think the draft should be held up waiting for it. > Well the document was dormant for a time and had I realized it was coming up for LC I would have offered to do the work yet again. I guess that's part of the reason to do a LC. >> (new issue 6) In looking at the google doc, I was reminded of a >> deficiency of in 5512 that still exists in the wg draft. Neither ever >> define the format of the Tunnel TLV. Don't you think it should? >> Obviously, I do. Feel free to lift Section 3 of the google doc. > > Figure 1 is not satisfactory? Yes it is - I should have had another cup of coffee before sending the message! > >> >>>> 2. WRT the Encapsulation Extended Community. I find the following rule >>>> very hard to parse: >>>> >>>> A Tunnel Encapsulation attribute MUST NOT include a barebones >>>> Tunnel TLV. Instead of placing such a TLV in the Tunnel >>>> Encapsulation attribute attached to a particular route, the >>>> corresponding Encapsulation Extended Community MUST be >>>> attached to >>>> the route. >>>> >>>> Are you saying the extended community MUST be "barebones". If so, I >>>> agree as this matches 5512 formatting. If you want this extended >>>> community to carry sub-tlv information, then I see no backwards >>>> compatibility basis for this and don't support this. Either way, I >>>> think this rule needs to be clarified. >>> I'm not sure I understand what you are objecting to. An extended >>> community cannot carry sub-TLVs. >> Perfect. That's what I was hoping for/expecting, but I couldn't parse >> your text in a way that made sense (at least to me). I also think the >> current phasing goes beyond what some implementations do, e.g., send a >> barebones EC all the time. >> >>> A number of existing applications exist that use the Encapsulation EC to >>> specify a tunnel type, with no parameters. The above-quoted paragraph >>> attempts to encourage backwards compatibility with those applications by >>> saying that if you want to specify a single tunnel type with no >>> parameters, use the Encapsulation EC. The Tunnel Encaps attribute would >>> be used whenever the Encapsulation EC is not sufficient. >> How about replacing the quoted paragraph with: >> An Encapsulation Extended Community MUST be included when a >> barebones >> Tunnel TLV is used to identify a tunnel endpoint. The corresponding >> barebones >> Tunnel Encapsulation attribute MAY be omitted in this case. >> >> BTW our implementation always includes a "barebones" Encapsulation >> Extended Community ;-) > > For anyone trying to follow this thread, the Encapsulation EC was > defined in RFC5512 as a simple way to specify a tunnel whose endpoint is > the BGP next hop, and for which no encapsulation information needs to be > provided. That is, only the tunnel type is identified, and nothing is > said about how to form the encapsulation for that tunnel, how to choose > which packets go through that tunnel, etc. In the draft, a "barebones > Tunnel TLV" is defined to be a Tunnel TLV that that only specifies the > tunnel type, and hence could just as well be encoded in the > Encapsulation EC. > > I don't see how it could be correct for an implementation to always > include an Encapsulation EC. Sometimes you need to specify more than > the tunnel type in order to construct the encapsulation properly. It doesn't "hurt" to include it always and there is an implementation that does this, so why not allow it? > > I don't think your suggested text is accurate, because a barebones > Tunnel TLV does not identify a tunnel endpoint. then just s/endpoint/type > >> >>>> 3. I'm not sure why the color sub-tlv is still needed. why not just use >>>> the Color Extended Community alone? (Is there really a case where the >>>> recursive lookup in section 7 would have a different color?) >>> The color sub-TLV is per-tunnel, the color EC is per route. You could >>> have multiple tunnels to a given endpoint, each with a different color. >> okay, this works -- we solved this using multiple updates. That said, >> do you think the complexity of multiple tunnel tlvs in the same update >> is needed or really used today (vs just using multiple/per tunnel tlv >> updates)? The encap safi certainly resulted in some pretty complex code >> in order to "optimize" update sizes. It seems that this too is a >> similar trade off, and would be a good additional area of complexity >> that can be simplified. If it's not used today, I think we should >> restrict the Tunnel Encapsulation Attribute to one Tunnel-TLV. > > The use of multiple tunnels between a pair of endpoints seems to make > sense, especially if the tunnels have different characteristics, and if > color can be used to map particular traffic flows to particular > tunnels. This is something that has not changed from RFC 5512. Note > also that even the Encapsulation EC allows multiple tunnels to be > specifiied (if they are of different types), since an EC attribute can > contain multiple instances of the same extended community. I'm not arguing it that it's not a real use case, but rather that it can be solved using other existing, albeit more verbose, mechanisms. Just like encap safi itself, if no one is using this, I think it would be better to simplify the solution and associated code. If you are already making use of this in deployed code, then I withdraw the proposed simplification. > >> If this is kept, it seems like there's some special aggregation rules >> that could apply. > > I'm not sure I understand this point. If you receive two routes, and > want to aggregate them so that you onluy need to propagate one upstream, > and the two routes have different tunnel-encaps attributes, you need > some policy to decide what to do. But that's true even if the > tunnel-encaps attribute only specifies one tunnel. > Sure, and the policy may be to merge the tlv lists. This is the kind of information I'm suggesting should be added. >... Lou From nobody Tue May 23 15:01:31 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1535D128B93 for ; Tue, 23 May 2017 15:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 myunOsSfkGya for ; Tue, 23 May 2017 15:01:29 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 8F2A8128D16 for ; Tue, 23 May 2017 15:01:26 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1dDHro-002MDo-5F>; Wed, 24 May 2017 00:01:24 +0200 Received: from x55b23e34.dyn.telefonica.de ([85.178.62.52] helo=mw-PC.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:AES256-SHA:256) (envelope-from ) id <1dDHrn-003LGU-Re>; Wed, 24 May 2017 00:01:24 +0200 Date: Wed, 24 May 2017 00:00:52 +0200 From: Matthias Waehlisch To: Susan Hares cc: 'idr wg' In-Reply-To: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com> Message-ID: References: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="150386338-28355-1495529323=:15180" Content-ID: X-Originating-IP: 85.178.62.52 Archived-At: Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017). X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 22:01:30 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --150386338-28355-1495529323=:15180 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: Hi, +1 for adoption. I read the document and like the slim "algorithmic" approach, which gives an additional perspective compared to draft-ietf-idr-route-leak-detection-mitigation. Cheers matthias On Sat, 20 May 2017, Susan Hares wrote: > > This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017) > >   > > The authors should indicate if they know of any IPR related to this document.  You can find the > document at: > >   > > https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/ > >   > > Sue Hares > >   > > > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl --150386338-28355-1495529323=:15180-- From nobody Tue May 23 19:39:58 2017 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 6F873126B7F; Tue, 23 May 2017 19:39:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-idr-shutdown@ietf.org, Susan Hares , aretana@cisco.com, idr-chairs@ietf.org, skh@ndzh.com, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149559358944.28506.18362121959782542849.idtracker@ietfa.amsl.com> Date: Tue, 23 May 2017 19:39:49 -0700 Archived-At: Subject: [Idr] Adam Roach's No Objection on draft-ietf-idr-shutdown-08: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 02:39:50 -0000 Adam Roach has entered the following ballot position for draft-ietf-idr-shutdown-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The portion of Section 6 (Security Considerations) that discusses confusable characters is describing a problem that isn't obvious on first reading. As these strings are human-produced and human-consumed, it's not clear what harm would arise through the use of spoofing. If there is a real risk here that the authors are aware of, it should be described in more detail to allow implemetors to more adeptly steer around it. If not, the statement around spoofing should probably be removed so as to avoid implementors scratching their heads regarding what mitigating actions they might take. From nobody Tue May 23 22:32:22 2017 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 D54C0124B0A; Tue, 23 May 2017 22:32:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-idr-shutdown@ietf.org, Susan Hares , aretana@cisco.com, idr-chairs@ietf.org, skh@ndzh.com, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149560393986.28455.14877358573594421068.idtracker@ietfa.amsl.com> Date: Tue, 23 May 2017 22:32:19 -0700 Archived-At: Subject: [Idr] Suresh Krishnan's No Objection on draft-ietf-idr-shutdown-08: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 05:32:20 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-idr-shutdown-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Since this notification message is only defined for two of the subcodes, shouldn't the error handling in Section 4 also check for invalid subcodes? Why is the length limited to 128 (instead of the possible 255)? Could be useful to clarify. From dginsburg@gmail.com Tue May 23 22:49:00 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B775126D45 for ; Tue, 23 May 2017 22:49:00 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 Hh0r8Hq3ZOrO for ; Tue, 23 May 2017 22:48:58 -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 6DC5C124BFA for ; Tue, 23 May 2017 22:48:58 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id m18so61100817lfj.0 for ; Tue, 23 May 2017 22:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wL/aFvGcjHEvwaBRxz1toDq2kDX+x0BQJB07qsmSBRc=; b=YeoMQKkmyo4TcCvSJRgYDDpq01hm+hX0NpMxRTWkLByOjmCJVcl9SIlNESI17iwc0r xlU6LNnWTZO3rHpMTVxRYFrBioifyUpLKa5O4qgO6wGkWCpNZAstM3rwPRxeXO0xDtDL j3otUfwaC1n2G1zQbsRSlRTiX9OnNDzI8BsmwzScPPt+T9QYxwuAnIQvKkWIWadKKYzE yCmoAQgnUjGNdN3HuFuHQPAB4zHRKgxgZflnAUFm+oT5ro2/EsPJ2uOUYyG6jx0PAQYm jc8OplWYjn6TbTFKOyml+HpEeP2WwRQM5bUcfkGRt0iTEP8H+poYkiN0laIwMSaKPIkZ PrRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wL/aFvGcjHEvwaBRxz1toDq2kDX+x0BQJB07qsmSBRc=; b=AOeabEoWth6dvoFoXwzf7ZtS4telimJsVOoewHS2fOrzEtCNIb+OmgEOSwv0h/txFB yidr+t3WDokzB2vuiuBYyyL1utUHbRhLNnnymhiTZRMYkUs1nlrK0JFdb1VBAfCTfZxG NPHqafO4PgCm3qokSa2k0lY/oMKGcU3+5Pxm6rb9FjDb8SGst1kkGmYONn12D45LzIcP fxh891EpF70D99GdlnRXAGQ+BJnEG6T/CbWf9m2Mvf3+m6JLFY772TmqfaVXQX2d9FXn ynxJ05KG/uVcXEazT1CGrCqoVqkWGT/lbIzk5qwtPUEc9GVcI4XJNx6IWIR7xqGiy99d 6yfA== X-Gm-Message-State: AODbwcDAzhR2goCCV7sy88Qftrqn0yyfK1/dN9GKUStMjUMhKWeNubWk SB2pdYKzztkah6D63kL0za7nrr3F7Q== X-Received: by 10.25.148.20 with SMTP id w20mr8685103lfd.169.1495604936809; Tue, 23 May 2017 22:48:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.41 with HTTP; Tue, 23 May 2017 22:48:55 -0700 (PDT) Received: by 10.25.21.41 with HTTP; Tue, 23 May 2017 22:48:55 -0700 (PDT) In-Reply-To: References: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com> From: Daniel Ginsburg Date: Wed, 24 May 2017 08:48:55 +0300 Message-ID: To: Matthias Waehlisch Cc: Susan Hares , idr wg Content-Type: multipart/alternative; boundary="001a113d7e60fba2c905503ea8a2" Archived-At: Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017). X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 05:50:41 -0000 --001a113d7e60fba2c905503ea8a2 Content-Type: text/plain; charset="UTF-8" +1 Yes/Support On May 24, 2017 01:01, "Matthias Waehlisch" wrote: Hi, +1 for adoption. I read the document and like the slim "algorithmic" approach, which gives an additional perspective compared to draft-ietf-idr-route-leak-detection-mitigation. Cheers matthias On Sat, 20 May 2017, Susan Hares wrote: > > This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017) > > > > The authors should indicate if they know of any IPR related to this document. You can find the > document at: > > > > https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/ > > > > Sue Hares > > > > > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --001a113d7e60fba2c905503ea8a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 Yes/Support

On May 24, 2017 01:01, "Matthias Waehlisch&quo= t; <m.waehlisch@fu-berlin.de= > wrote:
Hi,

=C2=A0 +1 for adoption. I read the document and like the slim "algorit= hmic"
approach, which gives an additional perspective compared to
draft-ietf-idr-route-leak-detection-mitigation.




Cheers
=C2=A0 matthias

On Sat, 20 May 2017, Susan Hares wrote:

>
> This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-poli= cy (5/20 to 6/3/2017)
>
> =C2=A0
>
> The authors should indicate if they know of any IPR related to this do= cument.=C2=A0 You can find the
> document at:
>
> =C2=A0
>
> https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/
>
> =C2=A0
>
> Sue Hares
>
> =C2=A0
>
>
>


--
Matthias Waehlisch
.=C2=A0 Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl
__________= _____________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--001a113d7e60fba2c905503ea8a2-- From nobody Wed May 24 05:32:25 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EEB129B97; Wed, 24 May 2017 05:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zxSpGlaFbtXU; Wed, 24 May 2017 05:32:18 -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 EE428129C09; Wed, 24 May 2017 05:32:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNR84009; Wed, 24 May 2017 12:32:14 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 24 May 2017 13:32:13 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 24 May 2017 20:32:08 +0800 From: Xuxiaohu To: "John G. Scudder" , "idr@ietf.org" CC: "draft-ietf-idr-tunnel-encaps@ietf.org" Thread-Topic: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 Thread-Index: AQHS0aH2i683CbXoLkmUFZJznidGv6IDb1XQ Date: Wed, 24 May 2017 12:32:07 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBAA236@NKGEML515-MBX.china.huawei.com> References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> In-Reply-To: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@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.184.181] 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.0A020206.59257D50.015C, 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: 80d61d4bb161416a1f1124634f00190b Archived-At: Subject: [Idr] =?gb2312?b?tPC4tDogIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciBk?= =?gb2312?b?cmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzLTA0?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 12:32:20 -0000 SGkgYWxsLA0KDQpTaW5jZSB0aGUgTlZHUkUgaGVhZGVyIGhhcyBhIHByb3RvY29sIGZpZWxkLCBp dCBzZWVtcyB1bm5lY2Vzc2FyeSB0byBhZGQgdGhlIGZha2UgTUFDIGhlYWRlciB3aGVuIGVuY2Fw c3VsYXRpbmcgSVAgcGFja2V0cyBvdmVyIE5WR1JFIGluIHRoZSBpbnRlci1zdWJuZXQgc2NlbmFy aW8sIGFzIGRlc2NyaWJlZCBpbiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlv bmctbDN2cG4tbnZncmUtdnhsYW4tZW5jYXAtMDAjcGFnZS0zKS4NCg0KQmVzdCByZWdhcmRzLA0K WGlhb2h1DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogSWRyIFttYWlsdG86aWRy LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSm9obiBHLiBTY3VkZGVyDQo+ILeiy83KsbzkOiAyMDE3 xOo11MIyMcjVIDM6NDcNCj4gytW8/sjLOiBpZHJAaWV0Zi5vcmcNCj4gs63LzTogZHJhZnQtaWV0 Zi1pZHItdHVubmVsLWVuY2Fwc0BpZXRmLm9yZw0KPiDW98ziOiBbSWRyXSBXb3JraW5nIGdyb3Vw IGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2Fwcy0wNA0KPiANCj4gSGkg QWxsLA0KPiANCj4gQSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMgYmVlbiByZXF1ZXN0ZWQg Zm9yIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMtMDQuDQo+IFBsZWFzZSByZXBseSB0byB0 aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMuIEFzIHVzdWFsIG5vdGUgd2UgY2Fubm90IGFkdmFu Y2UNCj4gdGhlIGRyYWZ0IHdpdGhvdXQgcGFydGljaXBhdGlvbiBmcm9tIHRoZSBncm91cC4gUGxl YXNlIGdldCB5b3VyIGNvbW1lbnRzIGluDQo+IGJlZm9yZSBKdW5lIDUsIDIwMTcuDQo+IA0KPiBB dXRob3JzLCBwbGVhc2UgY29uZmlybSB0aGF0IGFueSByZWxldmFudCBJUFIgaGFzIGJlZW4gZGlz Y2xvc2VkLg0KPiANCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRy LXR1bm5lbC1lbmNhcHMtMDQNCj4gDQo+IFRoYW5rcywNCj4gDQo+IC0tSm9obg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBs aXN0DQo+IElkckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkcg0K From nobody Wed May 24 10:53:55 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6AD1204DA; Wed, 24 May 2017 10:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 CTI5-HqcVC76; Wed, 24 May 2017 10:53:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5BA821200E5; Wed, 24 May 2017 10:53:43 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4OHre7I074905 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 May 2017 12:53:41 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Robert Raszuk , Job Snijders , The IESG , idr@ietf.org, draft-ietf-idr-shutdown@ietf.org, idr-chairs@ietf.org, aretana@cisco.com, skh@ndzh.com References: <149559358944.28506.18362121959782542849.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <53c58824-e5fa-88e1-b092-b2e285906514@nostrum.com> Date: Wed, 24 May 2017 12:53:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------922CEE46F90A819CBB5AE461" Content-Language: en-US Archived-At: Subject: Re: [Idr] Adam Roach's No Objection on draft-ietf-idr-shutdown-08: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 17:53:46 -0000 This is a multi-part message in MIME format. --------------922CEE46F90A819CBB5AE461 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I'm putting this back on the relevant lists, as I believe we need to have this conversation in the open. The problem that this text is apparently referring to is preventing the spoofing of syslog messages or the output of other CLI tools (which I read as similar to the concern Warren raises). If this is the attack the text in the security section is attempting to describe, I think it misses the mark: I can't get from the words there to the concept of spoofing syslog messages. This is exacerbated by the presence of the clause "due to character confusion" as part of the description, as this raises the specter of UTF-8 confusables, which doesn't seem to be the related to the concern here. Concretely, what I'm asking: please be clear in the security section -- with an example, if necessary -- so that implementors understand what is being prevented. It's perfectly fine to say "don't send more than 128 bytes," but if implementors don't understand *why*, then they'll do it anyway (cf. the prohibition on DNS names starting with numbers, or chaining CNAM records in DNS: both are -- or were at a time -- prohibited by spec, but widely implemented nonetheless, because the explanation about *why* not to do them was completely unclear). /a On 5/24/17 1:57 AM, Robert Raszuk wrote: > Just FYI ... > > I raised the exact same point during WG review and we agreed with Job > that it is not about spoofing, but "visual attack". Other then limited > size of the msg no other means of mitigation are needed by developer. > > Cheers > R. > > On May 24, 2017 04:39, "Adam Roach" > wrote: > > Adam Roach has entered the following ballot position for > draft-ietf-idr-shutdown-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The portion of Section 6 (Security Considerations) that discusses > confusable characters is describing a problem that isn't obvious > on first > reading. As these strings are human-produced and human-consumed, > it's not > clear what harm would arise through the use of spoofing. If there is a > real risk here that the authors are aware of, it should be > described in > more detail to allow implemetors to more adeptly steer around it. > If not, > the statement around spoofing should probably be removed so as to > avoid > implementors scratching their heads regarding what mitigating actions > they might take. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > --------------922CEE46F90A819CBB5AE461 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I'm putting this back on the relevant lists, as I believe we need to have this conversation in the open.

The problem that this text is apparently referring to is preventing the spoofing of syslog messages or the output of other CLI tools (which I read as similar to the concern Warren raises).

If this is the attack the text in the security section is attempting to describe, I think it misses the mark: I can't get from the words there to the concept of spoofing syslog messages. This is exacerbated by the presence of the clause "due to character confusion" as part of the description, as this raises the specter of UTF-8 confusables, which doesn't seem to be the related to the concern here.

Concretely, what I'm asking: please be clear in the security section -- with an example, if necessary -- so that implementors understand what is being prevented. It's perfectly fine to say "don't send more than 128 bytes," but if implementors don't understand *why*, then they'll do it anyway (cf. the prohibition on DNS names starting with numbers, or chaining CNAM records in DNS: both are -- or were at a time -- prohibited by spec, but widely implemented nonetheless, because the explanation about *why* not to do them was completely unclear).

/a

On 5/24/17 1:57 AM, Robert Raszuk wrote:
Just FYI ... 

I raised the exact same point during WG review and we agreed with Job that it is not about spoofing, but "visual attack". Other then limited size of the msg no other means of mitigation are needed by developer.

Cheers
R.

On May 24, 2017 04:39, "Adam Roach" <adam@nostrum.com> wrote:
Adam Roach has entered the following ballot position for
draft-ietf-idr-shutdown-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The portion of Section 6 (Security Considerations) that discusses
confusable characters is describing a problem that isn't obvious on first
reading. As these strings are human-produced and human-consumed, it's not
clear what harm would arise through the use of spoofing. If there is a
real risk here that the authors are aware of, it should be described in
more detail to allow implemetors to more adeptly steer around it. If not,
the statement around spoofing should probably be removed so as to avoid
implementors scratching their heads regarding what mitigating actions
they might take.


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


--------------922CEE46F90A819CBB5AE461-- From nobody Wed May 24 11:15:49 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348B0128D3E for ; Wed, 24 May 2017 11:15:42 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 hWHCD7xiN1nJ for ; Wed, 24 May 2017 11:15: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 DBF8412940D for ; Wed, 24 May 2017 11:15:38 -0700 (PDT) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dDaos-0006J6-NZ (job@us.ntt.net) for idr@ietf.org; Wed, 24 May 2017 18:15:38 +0000 Received: by mail-wr0-f176.google.com with SMTP id w50so59788971wrc.0 for ; Wed, 24 May 2017 11:15:38 -0700 (PDT) X-Gm-Message-State: AODbwcD2mPbej/eREqk0FRIWLE1dtjti6/MtWhaDZlN4QI/XT/ofporP SlwZ2nhgAbkQnFHAYek2VVC+sHAbr1gK X-Received: by 10.223.174.209 with SMTP id y75mr20633125wrc.82.1495649736983; Wed, 24 May 2017 11:15:36 -0700 (PDT) MIME-Version: 1.0 References: <149559358944.28506.18362121959782542849.idtracker@ietfa.amsl.com> <53c58824-e5fa-88e1-b092-b2e285906514@nostrum.com> In-Reply-To: <53c58824-e5fa-88e1-b092-b2e285906514@nostrum.com> From: Job Snijders Date: Wed, 24 May 2017 18:15:26 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach , Job Snijders , Robert Raszuk , The IESG , aretana@cisco.com, draft-ietf-idr-shutdown@ietf.org, idr@ietf.org, idr-chairs@ietf.org, skh@ndzh.com Content-Type: multipart/alternative; boundary="001a114767fc482a840550491748" Archived-At: Subject: Re: [Idr] Adam Roach's No Objection on draft-ietf-idr-shutdown-08: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 18:15:42 -0000 --001a114767fc482a840550491748 Content-Type: text/plain; charset="UTF-8" Do you have a text suggestion, or does what is proposed here work? I'd also like to point out that it is strange to anticipate vendors entirely ignoring normative text like "MUST". Spec violations should be dealt with by robust error handling, and guidance from the market. I consider it somewhat out of scope for the document to define, specify and teach people what "visual spoofing attacks" are. We'll remove the sentence about "confusion character", you are right that it doesn't add much. NEW 6. Security Considerations This document uses UTF-8 encoding for the Shutdown Communication. There are a number of security issues with UNICODE. Implementers and operator are advised to review UNICODE TR36 [UTR36] to learn about these issues. UTF-8 "Shortest Form" encoding is REQUIRED to guard against the technical issues outlined in UTR36. This specification minimizes the effects of visual syslog spoofing attacks by limiting the length of the Shutdown Communication. Users of this mechanism should be aware that unless a transport that provides integrity is used for the BGP session in question, a Shutdown Communication message could be forged. Unless a transport that provides confidentiality is used, a Shutdown Communication message could be snooped by an attacker. These issues are common to any BGP message but may be of greater interest in the context of this proposal since the information carried in the message is generally expected to be used for human-to-human communication. Refer to the related considerations in [RFC4271] and [RFC4272]. Users of this mechanism should consider applying data minimization practises as outlined in Section 6.1 [RFC6973] as a received Shutdown Communication may be used at the receiver's discretion. Kind regards, Job On Wed, 24 May 2017 at 19:53, Adam Roach wrote: > I'm putting this back on the relevant lists, as I believe we need to have > this conversation in the open. > > The problem that this text is apparently referring to is preventing the > spoofing of syslog messages or the output of other CLI tools (which I read > as similar to the concern Warren raises). > > If this is the attack the text in the security section is attempting to > describe, I think it misses the mark: I can't get from the words there to > the concept of spoofing syslog messages. This is exacerbated by the > presence of the clause "due to character confusion" as part of the > description, as this raises the specter of UTF-8 confusables, which doesn't > seem to be the related to the concern here. > > Concretely, what I'm asking: please be clear in the security section -- > with an example, if necessary -- so that implementors understand what is > being prevented. It's perfectly fine to say "don't send more than 128 > bytes," but if implementors don't understand *why*, then they'll do it > anyway (cf. the prohibition on DNS names starting with numbers, or chaining > CNAM records in DNS: both are -- or were at a time -- prohibited by spec, > but widely implemented nonetheless, because the explanation about *why* not > to do them was completely unclear). > > > /a > > > On 5/24/17 1:57 AM, Robert Raszuk wrote: > > Just FYI ... > > I raised the exact same point during WG review and we agreed with Job that > it is not about spoofing, but "visual attack". Other then limited size of > the msg no other means of mitigation are needed by developer. > > Cheers > R. > > On May 24, 2017 04:39, "Adam Roach" wrote: > > Adam Roach has entered the following ballot position for > draft-ietf-idr-shutdown-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The portion of Section 6 (Security Considerations) that discusses > confusable characters is describing a problem that isn't obvious on first > reading. As these strings are human-produced and human-consumed, it's not > clear what harm would arise through the use of spoofing. If there is a > real risk here that the authors are aware of, it should be described in > more detail to allow implemetors to more adeptly steer around it. If not, > the statement around spoofing should probably be removed so as to avoid > implementors scratching their heads regarding what mitigating actions > they might take. > > > _______________________________________________ > 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 > --001a114767fc482a840550491748 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do you have a text suggestion, or does what is proposed here work?

I'd also like to point out that it is strange to = anticipate vendors entirely ignoring normative text like "MUST". = Spec violations should be dealt with by robust error handling, and guidance= from the market.

I consider it somewhat out of sc= ope for the document to define, specify and teach people what "visual = spoofing attacks" are.=C2=A0

We'll remove= the sentence about "confusion character", you are right that it = doesn't add much.=C2=A0

NEW

6.  Security Considerations
=
=C2=A0=C2=A0= =C2=A0This document uses UTF-8 encoding for the Shutdown Communication.
=C2=A0=C2=A0=C2=A0There are a number of security issu= es with UNICODE. Implementers and
=C2=A0=C2=A0=C2= =A0operator are advised to review UNICODE TR36 [UTR36] to learn about
=
=C2=A0=C2=A0=C2=A0these issues. UTF-8 "Shortest F= orm" encoding is REQUIRED to guard
=C2=A0=C2= =A0=C2=A0against the technical issues outlined in UTR36. This
=C2=A0=C2=A0=C2=A0specification minimizes the effects of visua= l syslog spoofing attacks by limiting
=C2=A0=C2=A0= =C2=A0the length of the Shutdown Communication.
=C2=A0=C2=A0=C2= =A0Users of this mechanism should be aware that unless a transport that
=C2=A0=C2=A0=C2=A0provides integrity is used for the = BGP session in question, a
=C2=A0=C2=A0=C2=A0Shutd= own Communication message could be forged. Unless a transport
=C2=A0=C2=A0=C2=A0that provides confidentiality is used, a Shu= tdown Communication
=C2=A0=C2=A0=C2=A0message coul= d be snooped by an attacker. These issues are common to
=C2=A0=C2=A0=C2=A0any BGP message but may be of greater interest in = the context of this
=C2=A0=C2=A0=C2=A0proposal sin= ce the information carried in the message is generally
=C2=A0=C2=A0=C2=A0expected to be used for human-to-human communication= . Refer to the
=C2=A0=C2=A0=C2=A0related consider= ations in [RFC4271] and [RFC4272].
=C2=A0
<= div class=3D"line js-file-line" id=3D"LC221" style=3D"box-sizing:border-box= ;padding:0px 15px"> Users of this mechanism should consider applying data= minimization
=C2=A0=C2=A0=C2=A0practises as = outlined in Section 6.1 [RFC6973] as a received Shutdown
=C2=A0=C2=A0=C2=A0Communication may be used at the receiver's di= scretion.

Kind regards,

=
Job

On Wed, 24 May= 2017 at 19:53, Adam Roach <adam@nos= trum.com> wrote:
=20 =20 =20
I'm putting thi= s back on the relevant lists, as I believe we need to have this conversation in the open.
The problem that this text is apparently referring to is preventing the spoofing of syslog messages or the output of other CLI tools (which I read as similar to the concern Warren raises).

If this is the attack the text in the security section is attempting to describe, I think it misses the mark: I can't get from the words there to the concept of spoofing syslog messages. This is exacerbated by the presence of the clause "due to character confusion" as part of the description, as this raises the specter of UTF-8 confusables, which doesn't seem to be the related to the concern here.

Concretely, what I'm asking: please be clear in the security section -- with an example, if necessary -- so that implementors understand what is being prevented. It's perfectly fine to say "don't send more than 128 bytes," but if implementors d= on't understand *why*, then they'll do it anyway (cf. the prohibition on DNS names starting with numbers, or chaining CNAM records in DNS: both are -- or were at a time -- prohibited by spec, but widely implemented nonetheless, because the explanation about *why* not to do them was completely unclear).


/a


On 5/24/17 1:57 AM, Robert Raszuk wrote:
Just FYI ...=C2=A0

I raised the exact same point during WG review and we agreed with Job that it is not about spoofing, but "visual attack". Other then limited size of the msg no = other means of mitigation are needed by developer.

Cheers
R.

On May 24, 2017 04:39, "Adam Roach&= quot; <adam@no= strum.com> wrote:
Adam Roach has entered the following ballot position for
draft-ietf-idr-shutdown-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.iet= f.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-idr-shutdown/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

The portion of Section 6 (Security Considerations) that discusses
confusable characters is describing a problem that isn't obvious on first
reading. As these strings are human-produced and human-consumed, it's not
clear what harm would arise through the use of spoofing. If there is a
real risk here that the authors are aware of, it should be described in
more detail to allow implemetors to more adeptly steer around it. If not,
the statement around spoofing should probably be removed so as to avoid
implementors scratching their heads regarding what mitigating actions
they might take.


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


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--001a114767fc482a840550491748-- From nobody Wed May 24 11:19:13 2017 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 2F7E31200CF; Wed, 24 May 2017 11:19:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: idr-chairs@ietf.org, aretana@cisco.com, jgs@bgp.nu, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149564995110.8673.5790679880334422737.idtracker@ietfa.amsl.com> Date: Wed, 24 May 2017 11:19:11 -0700 Archived-At: Subject: [Idr] idr - New Meeting Session Request for IETF 99 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 18:19:11 -0000 A new meeting session request has just been submitted by John Scudder, a Chair of the idr working group. --------------------------------------------------------- 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: 100 Conflicts to Avoid: First Priority: netconf netmod trill i2nsf i2rs grow Second Priority: bess sidrops mpls rtgwg spring bfd ospf Third Priority: detnet dots nfvrg ccamp People who must be present: Susan Hares John Scudder Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed May 24 11:44:19 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A611294E7; Wed, 24 May 2017 11:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 qsDjOuQWt_QJ; Wed, 24 May 2017 11:44:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6333B129422; Wed, 24 May 2017 11:44:15 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4OIiC8x083240 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 May 2017 13:44:13 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Job Snijders , Robert Raszuk , The IESG , aretana@cisco.com, draft-ietf-idr-shutdown@ietf.org, idr@ietf.org, idr-chairs@ietf.org, skh@ndzh.com References: <149559358944.28506.18362121959782542849.idtracker@ietfa.amsl.com> <53c58824-e5fa-88e1-b092-b2e285906514@nostrum.com> From: Adam Roach Message-ID: <0b729dc2-03cb-1ee0-18c2-aa40c454617f@nostrum.com> Date: Wed, 24 May 2017 13:44:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Idr] Adam Roach's No Objection on draft-ietf-idr-shutdown-08: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 18:44:18 -0000 On 5/24/17 1:15 PM, Job Snijders wrote: > > I consider it somewhat out of scope for the document to define, > specify and teach people what "visual spoofing attacks" are. > So, the problem here is that "visual spoofing attack" actually does have a meaning that some implementors are likely to be familiar with (see, e.g., google results for searching for that phrase: ), and -- as a term of art, at least -- it refers to homoglyphs and confusables. As I initially mentioned, the impact of homographs and confusables on human-to-human communication is not immediately obvious, and -- especially based on this... > We'll remove the sentence about "confusion character", you are right > that it doesn't add much. > ...not what you actually mean. So if you're using the phrase "visual spoofing attacks" in a way that runs counter to the well-established meaning used by that phrase as a term of art, then I *do* think it is incumbent on you to clarify what you mean, since it is likely to diverge from what readers interpret those words to mean. I understand your request for me to send text, but I'm still slightly perplexed about the exact issue you are trying to highlight, so I'll probably get it somewhat wrong. Here's an attempt: 1) Completely remove this text: However, the visual spoofing due to character confusion still persists. This specification minimizes the effects of visual spoofing by limiting the length of the Shutdown Communication. 2) Between the first and second paragraph, add the following: "As BGP Shutdown messages are likely to appear in syslog output, there is a risk that carefully formed Shutdown Communication fields might be formatted by receiving systems in a way to make them appear as additional syslog messages. To limit the ability to mount such an attack, the mechanism described in this document limits the length of BGP Shutdown Communication fields to 128 octets in length." To be clear, I don't believe the mitigation proposed is a particularly good solution to the problem. I'm just proposing this text as my interpretation of what you seem to be claiming the existing text is supposed to say. If you can verify that the text I propose above is an accurate representation of the concern, then we can open a discussion around whether the mitigation is appropriate. /a From nobody Wed May 24 13:22:32 2017 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 29F9D127419; Wed, 24 May 2017 13:22:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-idr-shutdown@ietf.org, Susan Hares , aretana@cisco.com, idr-chairs@ietf.org, skh@ndzh.com, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149565734516.8705.9368971325877995104.idtracker@ietfa.amsl.com> Date: Wed, 24 May 2017 13:22:25 -0700 Archived-At: Subject: [Idr] Spencer Dawkins' Yes on draft-ietf-idr-shutdown-08: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 20:22:25 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-idr-shutdown-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (So obviously the right thing to do that even TSV ADs ballot Yes - thanks!) From nobody Wed May 24 13:46:14 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D65129B7E for ; Wed, 24 May 2017 13:46:12 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 yQg413a2VvvV for ; Wed, 24 May 2017 13:46:10 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 B7B881287A3 for ; Wed, 24 May 2017 13:46:10 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id g126so46750874ith.0 for ; Wed, 24 May 2017 13:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PwV7ZdcRt46ijYqktyF5+HiTLj56Bgj07e/rkcmgIU4=; b=jYlHj9zMtPVlogrfoBtXt9+jCVn84o6Fs8UFBFw8Zq/YPoLM+NKZuLI8sHL8yTZMu6 huqkHguwLpPOXZiZNYsoAiOE37sL2IzWPF4LHHfUuBe60xYKedFscJzAcSFnfUtWD4Kc TzBhZ5D9yIEInWIv1pYEwa+DqVTBU6RWXIrmtygK5II/Jl3AwOuocN1PRV7QyeRQp331 1uzQ8Q5Lf7z9gkj2b26cvQDl5CMNMkPxh7MKElVaTggO6zvkLVx9f+jMJGnv/ZOXwJHf ctRTYNyhBLZfCPKyV9T0XXE9ZfxF50Mo9oxoYnJNn4tefv5yjNRwxOETQ5BaGHMIkHon soRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PwV7ZdcRt46ijYqktyF5+HiTLj56Bgj07e/rkcmgIU4=; b=Rax4IOqdwT3dzGfoifomFOJi4pQ+j/d5Sy1AOVmU0P2LCPi5dJesxHVeMgruMcfs/p /2e9AiIxY2ydmlnWrtM8RryZY0ZWhzTMrlpM8iZ3A4+KYJtbFZZyQCpDFYoZ/pK74BsN YDUjXtyOd58E2+NpZDGoCjpgIEs0LE5aSs6u3k31FBC0s/TBPwOQsXSpHMby3YTU3Rfg OVhTEoA/hdIJL7lUiB5bl4xKVgTX8gjqPr9v1WvD74zj3I7Pu6UHLwCN+2Omfzz+PKlx 1W+I0ghewfKmSKP3qYUs7w5S1+Q+1dsLYz86nkNcz/GMDu+hDQyEJeHxrzUcXN9dujw/ zZhg== X-Gm-Message-State: AODbwcD47AiOm7w6vhLVuwZOEe8tVVQiIR8M3ay67tHbu2epJWb22ALT v4gfA7Dyc7DoZrsvi79D4nBkIDYzyA== X-Received: by 10.36.210.10 with SMTP id z10mr9941004itf.76.1495658770074; Wed, 24 May 2017 13:46:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.79.149 with HTTP; Wed, 24 May 2017 13:46:09 -0700 (PDT) In-Reply-To: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com> References: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com> From: Brian Dickson Date: Wed, 24 May 2017 13:46:09 -0700 Message-ID: To: Susan Hares Cc: idr wg Content-Type: multipart/alternative; boundary="94eb2c0574deb2243b05504b31da" Archived-At: Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017). X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 20:46:12 -0000 --94eb2c0574deb2243b05504b31da Content-Type: text/plain; charset="UTF-8" Support. Brian On Sat, May 20, 2017 at 2:33 AM, Susan Hares wrote: > This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy > (5/20 to 6/3/2017) > > > > The authors should indicate if they know of any IPR related to this > document. You can find the document at: > > > > https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/ > > > > Sue Hares > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --94eb2c0574deb2243b05504b31da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Support.

Brian

On Sat, May 20, 2017 at 2:33 A= M, Susan Hares <shares@ndzh.com> wrote:

This begins = a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2= 017)

=C2=A0

The authors should indicate if they know of any IPR relat= ed to this document.=C2=A0 You can find the document at:

=

=C2=A0

https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-ope= n-policy/

=C2=A0=

Sue Hares

=C2=A0


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


--94eb2c0574deb2243b05504b31da-- From nobody Wed May 24 14:49:34 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9262128CFF; Wed, 24 May 2017 14:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 x3E2oZySYwpi; Wed, 24 May 2017 14:49:24 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 489931289B0; Wed, 24 May 2017 14:49:24 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id p73so84652863ywp.0; Wed, 24 May 2017 14:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4BiNQ7mv5NOGDEdIVuAeXUNNbN+hZSzT7vvJdXeDCgc=; b=bo5PmMrbzZr3ZKIpTEVV7iGKC+rvpNR9yKaB/dF8ibvthEWVuNu1xl3bYz5EZB8hdN 40z0/166xzej1vvSOebLeT+rvfsRTSS5/JLsRVYc1fbK3sGUG4O5bryBjv2+N31IbyuZ /v2V1JtNcqc53KwrIX3rQzbqB8qZR/6AIQkeZjDRsupV0gHi1BKUTmcry5BbESZ2vmc6 xkDVNi45eLCFHLCzKvjmAa4vcJ1LgVC4c9jzFdYxjmCVOhptYqy2JbBESZn9A0yZN9JW WATriUcGIhCUgyifZDE1HIF6YwMnsOw8Ap06TLQO0rAlYwlcd4W00tZX48Ops37A4Ri/ MAzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4BiNQ7mv5NOGDEdIVuAeXUNNbN+hZSzT7vvJdXeDCgc=; b=aLFSZCzialerWfZ+vgKTYHZIQj5Tu+LQkPPeBg1zGNuilDyy65DxzuqQuvfFVRvRl6 lF3ecNIO2VAjPU8HFm9A3RAVm5MawAr0vkWT9uuiziS1WQRAX6wYxCTtPorkEk133uaV M8zV3/W3DcZE1+DiA5LMXtYGL4VRytKVKqDLdOWqpzR5kLtgDSa6FAwJ/SOYDi7BV/cv haF1A30LbCeJ4NOZpfc3+zNf5rRks9zdWFfwgy0XP+jaYmJbibojzleP+JUMentqsIsl gUn8+Fq7/mnAM2JbWOEWvHDDoe3ITBp5QdYo82AG3kQzZc5AH+upplnB/tkqxTbnu/D6 cVJQ== X-Gm-Message-State: AODbwcBAR4A49K32B+DHfWrIA/M6tLaX3AMDEqC4gIMo9zjEf0dhaFoN FxMUQVzdZfWvbAb1jULFqemQbDF1Qw== X-Received: by 10.13.254.68 with SMTP id o65mr32793435ywf.263.1495662563623; Wed, 24 May 2017 14:49:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.198 with HTTP; Wed, 24 May 2017 14:49:23 -0700 (PDT) In-Reply-To: <20170522154940.xmswso4hneaq6c25@hanna.meerval.net> References: <149546547958.14094.10590846251303101931.idtracker@ietfa.amsl.com> <20170522151124.dvc3ljpatp4cg5vs@hanna.meerval.net> <20170522154940.xmswso4hneaq6c25@hanna.meerval.net> From: Spencer Dawkins at IETF Date: Wed, 24 May 2017 17:49:23 -0400 Message-ID: To: Job Snijders Cc: "Mirja Kuehlewind (IETF)" , idr@ietf.org, draft-ietf-idr-shutdown@ietf.org, The IESG , idr-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c081dcacf0f8a05504c138b" Archived-At: Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-idr-shutdown-08=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 21:49:26 -0000 --94eb2c081dcacf0f8a05504c138b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Job, On Mon, May 22, 2017 at 11:49 AM, Job Snijders wrote: > On Mon, May 22, 2017 at 05:15:53PM +0200, Mirja Kuehlewind (IETF) wrote: > > Ah, thanks. Wasn=E2=80=99t aware of this. I=E2=80=99m neither a copyrig= ht expert. > > > Did you try to contact the authors of RFC4486 rather than adding this > > note? > > No. Copy+pasting the note as suggested by the idnits tool seemed less > work :-) Having done the same thing, it's less work, THIS time. The problem is that authors of older RFCs get closer to not being able to respond to questions every year (many changed e-mail addresses, some retired, and some, sadly, died), and if you don't check this now, every time this draft gets a bis, you'll have to decide whether to go chase the authors or keep cutting and pasting boilerplate that says, essentially, "we're not actually sure we're allowed to use this text, because the original authors were never asked the question". As I understand things, of course. Spencer, who has a draft in AD Evaluation with an author who has passed on - his e-mail address still works, but that only irritates his family when we ask questions like this one ... --94eb2c081dcacf0f8a05504c138b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Job,

On Mon, May 22, 2017 at 11:49 AM, Job Snijders &l= t;job@ntt.net> wrote:
On Mon, May 22= , 2017 at 05:15:53PM +0200, Mirja Kuehlewind (IETF) wrote:
> Ah, thanks. Wasn=E2=80=99t aware of this. I=E2=80=99m neither a copyri= ght expert.

> Did you try to contact the authors of RFC4486 rather than adding this<= br> > note?

No. Copy+pasting the note as suggested by the idnits tool seemed les= s
work :-)

Having done the same thing, it'= ;s less work, THIS time.=C2=A0

The problem is that= authors of older RFCs get closer to not being able to respond to questions= every year (many changed e-mail addresses, some retired, and some, sadly, = died), and if you don't check this now, every time this draft gets a bi= s, you'll have to decide whether to go chase the authors or keep cuttin= g and pasting boilerplate that says, essentially, "we're not actua= lly sure we're allowed to use this text, because the original authors w= ere never asked the question".

As I understan= d things, of course.

Spencer, who has a draft in A= D Evaluation with an author who has passed on - his e-mail address still wo= rks, but that only irritates his family when we ask questions like this one= ...
--94eb2c081dcacf0f8a05504c138b-- From nobody Thu May 25 02:08:37 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A961412714F for ; Thu, 25 May 2017 02:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.408 X-Spam-Level: X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, T_HTML_ATTACH=0.01] 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 LNQOrcIMUMXP for ; Thu, 25 May 2017 02:08:29 -0700 (PDT) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) (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 19756129C49 for ; Thu, 25 May 2017 02:08:26 -0700 (PDT) Received: by mail-wm0-f44.google.com with SMTP id 7so83953997wmo.1 for ; Thu, 25 May 2017 02:08:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3vU+ya/2A2hl/qsa60dsFyBT6gOzjK/fD4y9vRNfRqQ=; b=NK/6DOZpIjvupCm+a62W8ISihVkOMtDKth/UqkDommjEAT6Gb4vqb5S+A5rO3g9NFM nb9LMJbwxLTwQ09sQnmLIJnVWAHiZuLuckH5NF+McdZqEZZ+lVoqojbKc1kYdmrnKO60 GpE/Y+un3HpZwiSzsEBb8vf790BEb1CXXdw/3MnG79Puurlihvv++ocAL0y826sQ2nYD LRcpFC6/QR7d1Seq0q2spSXlj11HzGGAtYV+Timg364e/baD+MgYenL2rbUzRxyrvppU cRzjMnxuTzbhF/TyWbF6r2zCmOIVCuMqwcxCs2JGOzmDd7ZSAuwHHbN4iGKuu9RuZVf4 WaAw== X-Gm-Message-State: AODbwcDk4cujFgPUxjQBhC8Wnn1zaR083+v0VRqqzBuR3eI/xsbLc+IO XAKWsZu5NjTMopI9 X-Received: by 10.28.178.207 with SMTP id b198mr9406544wmf.0.1495703305282; Thu, 25 May 2017 02:08:25 -0700 (PDT) Received: from localhost (union-hotels-13.gh-union.si. [91.208.88.13]) by smtp.gmail.com with ESMTPSA id g25sm10177856wra.1.2017.05.25.02.08.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 02:08:23 -0700 (PDT) Date: Thu, 25 May 2017 11:08:20 +0200 From: Job Snijders To: Adam Roach Cc: The IESG , aretana@cisco.com, draft-ietf-idr-shutdown@ietf.org, idr@ietf.org, idr-chairs@ietf.org, skh@ndzh.com Message-ID: <20170525090820.ottlalmsdyorqrst@Vurt.local> References: <149559358944.28506.18362121959782542849.idtracker@ietfa.amsl.com> <53c58824-e5fa-88e1-b092-b2e285906514@nostrum.com> <0b729dc2-03cb-1ee0-18c2-aa40c454617f@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="aqet6io5pz2xnazc" Content-Disposition: inline In-Reply-To: <0b729dc2-03cb-1ee0-18c2-aa40c454617f@nostrum.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] Adam Roach's No Objection on draft-ietf-idr-shutdown-08: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 09:08:32 -0000 --aqet6io5pz2xnazc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear adam, On Wed, May 24, 2017 at 01:44:12PM -0500, Adam Roach wrote: > I understand your request for me to send text, but I'm still slightly > perplexed about the exact issue you are trying to highlight, so I'll > probably get it somewhat wrong. Here's an attempt: > > 1) Completely remove this text: > > However, the visual spoofing due to character confusion still > persists. This specification minimizes the effects of visual > spoofing by limiting the length of the Shutdown Communication. > > 2) Between the first and second paragraph, add the following: > > "As BGP Shutdown messages are likely to appear in syslog output, there is a > risk that carefully formed Shutdown Communication fields might be formatted > by receiving systems in a way to make them appear as additional syslog > messages. To limit the ability to mount such an attack, the mechanism > described in this document limits the length of BGP Shutdown Communication > fields to 128 octets in length." > > To be clear, I don't believe the mitigation proposed is a particularly > good solution to the problem. I'm just proposing this text as my > interpretation of what you seem to be claiming the existing text is > supposed to say. If you can verify that the text I propose above is an > accurate representation of the concern, then we can open a discussion > around whether the mitigation is appropriate. I accepted your suggestion & slightly rewrote the sentences for readability flow within the context of this document. Thanks! As to your belief on whether the mitigation proposed helps, the shutdown communication concept could've been defined in such a way to allow the communication to fill up to the maximum BGP message size (4000 octets, so with marker, type, etc a bgp shutdown communication perhaps could've been ~ 3979 octets). I believe that putting a limit in is useful: with 3979 octets someone can fill up a terminal screen, with 128 you can't. 128 could've been 127, or 129 - it is an arbitrary small value. The 128 number comes from earlier implementations where there was no Length field, in later versions of the document on the length field was added, but the effective shutdown communication message size was not changed. To keep things byte-aligned a 8 bit length field was used. "hysterical raisins" :) BTW, if you want to open an discussion, I don't understand why you cast your ballot as "no objection". And what outcome are you targetting? It seems unlikely at this point for the on-the-wire format to change. Attached is a rfcdiff HTML file to show the differences. NEW: -------- 6. Security Considerations This document uses UTF-8 encoding for the Shutdown Communication. There are a number of security issues with UNICODE. Implementers and operator are advised to review UNICODE TR36 [UTR36] to learn about these issues. UTF-8 "Shortest Form" encoding is REQUIRED to guard against the technical issues outlined in UTR36. As BGP Shutdown Communications are likely to appear in syslog output, there is a risk that carefully constructed Shutdown Communication might be formatted by receiving systems in a way to make them appear as additional syslog messages. To limit the ability to mount such an attack, the BGP Shutdown Communication is limited to 128 octets in length. Users of this mechanism should be aware that unless a transport that provides integrity is used for the BGP session in question, a Shutdown Communication message could be forged. Unless a transport that provides confidentiality is used, a Shutdown Communication message could be snooped by an attacker. These issues are common to any BGP message but may be of greater interest in the context of this proposal since the information carried in the message is generally expected to be used for human-to-human communication. Refer to the related considerations in [RFC4271] and [RFC4272]. Users of this mechanism should consider applying data minimization practises as outlined in Section 6.1 [RFC6973] as a received Shutdown Communication may be used at the receiver's discretion. ------- Kind regards, Job --aqet6io5pz2xnazc Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-idr-shutdown-09-from-8.diff.html" Diff: draft-ietf-idr-shutdown-08.txt - draft-ietf-idr-shutdown-09.txt
 draft-ietf-idr-shutdown-08.txt   draft-ietf-idr-shutdown-09.txt 
IDR J. Snijders IDR J. Snijders
Internet-Draft NTT Internet-Draft NTT
Updates: 4486 (if approved) J. Heitz Updates: 4486 (if approved) J. Heitz
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: November 6, 2017 J. Scudder Expires: November 26, 2017 J. Scudder
Juniper Juniper
May 5, 2017 May 25, 2017
BGP Administrative Shutdown Communication BGP Administrative Shutdown Communication
draft-ietf-idr-shutdown-08 draft-ietf-idr-shutdown-09
Abstract Abstract
This document enhances the BGP Cease NOTIFICATION message This document enhances the BGP Cease NOTIFICATION message
"Administrative Shutdown" and "Administrative Reset" subcodes for "Administrative Shutdown" and "Administrative Reset" subcodes for
operators to transmit a short freeform message to describe why a BGP operators to transmit a short freeform message to describe why a BGP
session was shutdown or reset. This document updates RFC 4486. session was shutdown or reset. This document updates RFC 4486.
Requirements Language Requirements Language
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 6, 2017. This Internet-Draft will expire on November 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 38 skipping to change at page 4, line 38
Reset" in the "Cease NOTIFICATION message subcodes" registry under Reset" in the "Cease NOTIFICATION message subcodes" registry under
the "Border Gateway Protocol (BGP) Parameters" group in addition to the "Border Gateway Protocol (BGP) Parameters" group in addition to
[RFC4486]. [RFC4486].
6. Security Considerations 6. Security Considerations
This document uses UTF-8 encoding for the Shutdown Communication. This document uses UTF-8 encoding for the Shutdown Communication.
There are a number of security issues with UNICODE. Implementers and There are a number of security issues with UNICODE. Implementers and
operator are advised to review UNICODE TR36 [UTR36] to learn about operator are advised to review UNICODE TR36 [UTR36] to learn about
these issues. UTF-8 "Shortest Form" encoding is REQUIRED to guard these issues. UTF-8 "Shortest Form" encoding is REQUIRED to guard
against the technical issues outlined in UTR36. However, the visual against the technical issues outlined in UTR36.
spoofing due to character confusion still persists. This
specification minimizes the effects of visual spoofing by limiting As BGP Shutdown Communications are likely to appear in syslog output,
the length of the Shutdown Communication. there is a risk that carefully constructed Shutdown Communication
might be formatted by receiving systems in a way to make them appear
as additional syslog messages. To limit the ability to mount such an
attack, the BGP Shutdown Communication is limited to 128 octets in
length.
Users of this mechanism should be aware that unless a transport that Users of this mechanism should be aware that unless a transport that
provides integrity is used for the BGP session in question, a provides integrity is used for the BGP session in question, a
Shutdown Communication message could be forged. Unless a transport Shutdown Communication message could be forged. Unless a transport
that provides confidentiality is used, a Shutdown Communication that provides confidentiality is used, a Shutdown Communication
message could be snooped by an attacker. These issues are common to message could be snooped by an attacker. These issues are common to
any BGP message but may be of greater interest in the context of this any BGP message but may be of greater interest in the context of this
proposal since the information carried in the message is generally proposal since the information carried in the message is generally
expected to be used for human-to-human communication. Refer to the expected to be used for human-to-human communication. Refer to the
related considerations in [RFC4271] and [RFC4272]. related considerations in [RFC4271] and [RFC4272].
skipping to change at page 6, line 34 skipping to change at page 6, line 39
[UTR36] Davis, M. and M. Suignard, "Unicode Security [UTR36] Davis, M. and M. Suignard, "Unicode Security
Considerations", Unicode Technical Report #36, August Considerations", Unicode Technical Report #36, August
2010, <http://unicode.org/reports/tr36/>. 2010, <http://unicode.org/reports/tr36/>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to gratefully acknowledge Tom Scholl, David The authors would like to gratefully acknowledge Tom Scholl, David
Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John
Heasley, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares, Heasley, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares,
Saku Ytti, Lou Berger, and Alvaro Retana. Saku Ytti, Lou Berger, Alvaro Retana, and Adam Roach.
Authors' Addresses Authors' Addresses
Job Snijders Job Snijders
NTT Communications NTT Communications
Theodorus Majofskistraat 100 Theodorus Majofskistraat 100
Amsterdam 1065 SZ Amsterdam 1065 SZ
The Netherlands The Netherlands
Email: job@ntt.net Email: job@ntt.net
Jakob Heitz Jakob Heitz
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95054 San Jose, CA 95134
USA USA
Email: jheitz@cisco.com Email: jheitz@cisco.com
John Scudder John Scudder
Juniper Networks Juniper Networks
1194 N. Mathilda Ave 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
 End of changes. 7 change blocks. 
10 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--aqet6io5pz2xnazc-- From nobody Thu May 25 02:14:16 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB0F12E04A for ; Thu, 25 May 2017 02:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] 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 HzBH6WFwKyQ9 for ; Thu, 25 May 2017 02:14:09 -0700 (PDT) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) (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 44843129400 for ; Thu, 25 May 2017 02:14:08 -0700 (PDT) Received: by mail-wm0-f44.google.com with SMTP id 7so84066528wmo.1 for ; Thu, 25 May 2017 02:14:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=1FnJpd3O3m9hSHRj0P6ajZAUfTKnSF/EWVGQM2H1pZI=; b=dcY53ldtL5+s+g3Z8YCAI49jxIjo7bImOF+q1azDYmTiAOxqf7A7gkGnoqV0xB2/Rk 3iWlLQQlMVc2ciBwNh6AANmv4byWdUPzMFVLxJKpjpgAiYVUmmxdO3VH9zc0AR7UwU5b Yn516iXvME1eJJQ59M7G7jH0Dyh0kS77k2ve6rU6jphzIvLMGh3mAK4xiWLNyONO+jGv BMLLSq+7vkKEpZz8j/s5Tdjj/ReJcLIfN5ANOzG+RFKtD6SRqqrbkZvMN00afgEqYvS8 SW/h9xZhdOvdXFAgLvj+M563rAF+59hEO7rjZxUN4wrKjDPQNIZ4r6783oYPKhgdN6GT 1czw== X-Gm-Message-State: AODbwcBgUTfOIkrmtFHyhrwEhJcUjJi7Y+hK2Y6fpibml38Yj/t1NDv2 cArfhT3Cr5JRO42P X-Received: by 10.28.107.7 with SMTP id g7mr8844942wmc.74.1495703646633; Thu, 25 May 2017 02:14:06 -0700 (PDT) Received: from localhost (union-hotels-13.gh-union.si. [91.208.88.13]) by smtp.gmail.com with ESMTPSA id l81sm8638236wmi.22.2017.05.25.02.14.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 02:14:05 -0700 (PDT) Date: Thu, 25 May 2017 11:14:02 +0200 From: Job Snijders To: Suresh Krishnan Cc: The IESG , idr@ietf.org, draft-ietf-idr-shutdown@ietf.org, idr-chairs@ietf.org Message-ID: <20170525091402.m4bnnt3ujrrfpiy6@Vurt.local> References: <149560393986.28455.14877358573594421068.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149560393986.28455.14877358573594421068.idtracker@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] Suresh Krishnan's No Objection on draft-ietf-idr-shutdown-08: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 09:14:10 -0000 On Tue, May 23, 2017 at 10:32:19PM -0700, Suresh Krishnan wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Since this notification message is only defined for two of the > subcodes, shouldn't the error handling in Section 4 also check for > invalid subcodes? The shutdown communication specification only applies for two of the subcodes, if another (invalid or valid) subcode is used, the shutdown communication specification simply does not apply at all, and today's procedures are used. Some implementations will syslog of a hexdump of the data received, others silently ignore it, or log an error that an unknown subcode was used. > Why is the length limited to 128 (instead of the possible 255)? Could be > useful to clarify. The shutdown communication proposal started as a maximum of 128 octet construct, without a length field: https://tools.ietf.org/html/draft-snijders-idr-shutdown-00#section-2 the length field was added later on as suggested by Bruno Decraene to allow for a form of extendability should we want to define a 'shutdown communication version 2'. While the length field was added, the shutdown communication size itself was not increased, hence the length field is not fully used. 128 is an arbitrary small value. Kind regards, Job From nobody Thu May 25 06:54:33 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BAF124234 for ; Thu, 25 May 2017 06:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] 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 kbVLXuIN8XiE for ; Thu, 25 May 2017 06:54:31 -0700 (PDT) Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) (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 C5FDE12942F for ; Thu, 25 May 2017 06:54:30 -0700 (PDT) Received: by mail-wm0-f66.google.com with SMTP id b84so37452845wmh.0 for ; Thu, 25 May 2017 06:54:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=x4khhjHjvVdCb1sLzsTlLVp8izpLtj4KVlL/nQ33pJs=; b=MpQIvIQotZ0jUCSgc1t8LPBdFdL+unigh+4jpsjB4KQ0uqs44qhn1+p+sCOXMHxQQR UtkhcFXZesf3qiCjzPN4OEdlgh5gzUWBBSpMOi50sU9HTiaXckqEPFEJOE39VPrXpdbx 12RYchkElkVAuicl+DY9JFIbmT4A0lmQS/MgSo3VvxcBIKi58Sbe9IbaAUPi6zddUYJU ZeasyUrp2ZOOW9sU96dsFtWvoIZbMZ0bJ362pXGU+zFtxqN0TyukLYIjXDcXP7KYt9JC gM9CRXghwLpG6S9wrkdSxKCja0/qI7q9Z2EX3TOq4zcdhFeCkD363lfJQPdur2n7ffWg fpsQ== X-Gm-Message-State: AODbwcDYoXD64SxTjXsJ2vB1ILwDmhkov/PX0iX7QcEGzKNygwEaMhT7 xsDEEmk2nZjhQVBO41l+/Q== X-Received: by 10.28.66.2 with SMTP id p2mr10570943wma.20.1495720468939; Thu, 25 May 2017 06:54:28 -0700 (PDT) Received: from localhost ([195.138.201.60]) by smtp.gmail.com with ESMTPSA id y6sm10153971wrc.51.2017.05.25.06.54.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 06:54:27 -0700 (PDT) Date: Thu, 25 May 2017 15:54:24 +0200 From: Job Snijders To: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org Message-ID: <20170525135424.3v3ea3rfdsquwizu@Vurt.local> References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 13:54:33 -0000 Dear all, TL;DR: I do not support advancing this document at this time. Lack of full-spec implementation experience, and little feedback from actual implementers, lead me to not support progression of this document. I understand that this position has little to do with the actual contents of the document. On Sun, May 21, 2017 at 03:58:29PM -0400, Lou Berger wrote: > On 05/20/2017 03:47 PM, John G. Scudder wrote: > > A working group last call has been requested for > > draft-ietf-idr-tunnel-encaps-04. Please reply to the list with your > > comments. As usual note we cannot advance the draft without > > participation from the group. Please get your comments in before > > June 5, 2017. > > - Since the question was raised on list: a partial implementation of > this draft can be found in FRRouting, notably bgp_encap_tlv.{h,c} in > https://github.com/FRRouting/frr/tree/master/bgpd . It supports: > > o encap attribute sent with other safis. The code uses it with the > VPN safi to provide underlay tunnel information for VPN routes for > NVO3 type applications. > > o "Remote Endpoint Address sub-TLV" for v4 and v6 > > o encode/decode of type specific and sub-TLV formats > per draft -00 or -01 rev (this means it is a subset implementation. Cool stuff, thanks for sharing that! While John Scudder pointed out that there is no blocking requirement for a document to have implementations before passing through WG LC. I (and probably participants too) am of the opinion that actual feedback from implementers is extremely valuable. Should an implementer find an actual technology issue, or lack of clarity in the wording of the document, as long as the document in the WG it'll be trivial to resolve any issues. I understand that there are ways to modify a document after WG LC, but I think its simpler to be able to say to the working group itself "this technology works, i have an implementation". Should someone write a partial implementation, that might be a hint that the document needs to be split up (or perhaps it is of no significance). To properly assess a document, I hope for feedback from full implementations (perhaps two technology components within a doc conflict with each other). If parts of an Internet-Draft are not implemented by anyone, I'd advocate the document should not (yet) progress further. With "implementation" i don't mean that you are shipping code to customers, I'm fine with stuff hanging in private beta branches - all I'm looking for is an attestation that the implementer found the full specification implementable. RFC7942 is good guidance. I'd like to request the chairs to consider a slight adjustment of the procedure: encourage the working group to create implementations _before_ WGLC, so the working group can take implementer feedback into account when assessing the proposed document. Kind regards, Job ps. if two full implementations show up during this WGLC, I will ofcourse withdraw my non-support. From nobody Thu May 25 10:54:13 2017 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA71C129BBE; Thu, 25 May 2017 10:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=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, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqSI982qM7Lx; Thu, 25 May 2017 10:54:09 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0097.outbound.protection.outlook.com [104.47.36.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 EE45A129ACD; Thu, 25 May 2017 10:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=28RLfZm8M/KVJzq4T19HXAqhtaqogNUcS9JRDJZiN40=; b=FQzu80hVPxA5q7TTJERxjRfw9+nzD1I+tDKI72Feo/kPwKDHrxEpsV/xrvIX4BpVpyLMGi9mutkE1pPQeRji69UtJoGkO4JPpxSf81MlZpCBqUGukeiOcPYgFcRI6LSB72PbKAztrvWOgaUEcZDyrR1Njke3uVQWdMaZ8Sax8Kw= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.34.170] (66.129.241.10) by BL2PR05MB2180.namprd05.prod.outlook.com (2a01:111:e400:c74e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Thu, 25 May 2017 17:54:06 +0000 To: Lou Berger , "John G. Scudder" Cc: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net> <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net> From: Eric C Rosen Message-ID: <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net> Date: Thu, 25 May 2017 13:54:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net> Content-Type: multipart/alternative; boundary="------------C06DC5C02F5BC30B87297DEA" Content-Language: en-US X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BN6PR11CA0029.namprd11.prod.outlook.com (2603:10b6:404:4b::15) To BL2PR05MB2180.namprd05.prod.outlook.com (2a01:111:e400:c74e::12) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL2PR05MB2180: X-MS-Office365-Filtering-Correlation-Id: cb9a4ee3-80db-4353-3bab-08d4a3970a3d X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 3:0aiSNhDSlL0Qo3yAj1wI3NPCVSZBLoiXaeNeW3XG0d5yQSRK4TQ1ZkEjDJ+9jvf836AlLHUu3Y5Vr64vJBNHs3jIzBwJZa9khyaWJ4+FEEZyrVx5h0NyPXTY0CVVhCphJ/XP0W6ygcnogXJCFJsviTGmVSrsuEQcgyv6TbB1evJM2c7FZ8D7x5qEVHJVtacvGcXHkJ/go6RvAhqVS9gyK9jLKgq8fMOrE5qgiamy3P5Ac+speCW7ZEnRq8AwcNceErdWAF8+bNom8hW2bVKmiWTNevXRFLcLOeOqX0SEz9QsnF1ZlLarHfKyBAGF8I1io8AarvlqZpd+zHHQkT6QA4/wDoFfAlj6Xk8A3SmYgTw=; 25:zy8Fzuy8laAZrM0059Y7p8UOe49pXQ3gA7QFDB2kgiY7bXRzfaXB9cyC/SGtUwBR2aFV7/EGm4s2dR+9+IidOG2BiBpaX71VSIMj02evURP8TSzXJCRpafqcu0eIOGHravPL41zUiOJkPNJ2TijtDTXDrvtzsDMtoqRKqp+9vajzrrQqzutbdeqyNbNDwcaWo9oigZhGPoUwm1DFfN5NVR7SgKRrawQ6mj0j61lX9kH0NF3Ytc0J8pJeQdOT50jGYyX/rnrKRfjVQ4K60kr1I7Yn8qOwiOdTbNnAuRB1DFZJ/ey1J4lX1FqGcIrVYr102ouWYbGr2lFDrmNgP+hCUBlyH1Qf0OBCVoKdUdibIq9bV/kHSN4QVVD4j/RdMykWthnGQuSV0rDosfknfz6d9n0hSP/byXF+ZmaV1/lym7AHzYLvxH5BjlJBOWCubJaUqCu+jpYgJIVmgQLaRHW1ZToMxqbtSXLAW/UdYZo7VjM= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 31:1dda1KK/wKtlUsIqk3rgX2Z7oyGeLC0+Jgb4Zgq5bda9Sc/vUyajiWM4uDGG93fL/Z/mJr67/HgkXkGUzd2OPs1THcjRDFuB8LlpcuZO3BajzxXcl+9Q1coH46troSf3QwGYY9ir7GUz2SAIF99Ccl0APbdWfEW3LXbdnbyG0I/CtWnN1IGYqyZAlU3PRY/NrNRdUeXq3H9E8ys6aJp7gqKO+H9s2ctOLMV9IWT2JME=; 20:+uHNFGznt88nRpY/iZNZuXSMIBWFoMd4ZGGV6PjVSZnuqABpj/HGicDbqQ17qZrryZlntrNxU6OigwIktVHljCtBjI9N3kaXhwri28TKCViQj8NduWwPik0/CQDNeDRtgh7QJWrewYFHRuS89RxL0ezsAWd+SMFSv65DhhqJlgZyyP8NyzvqtBYwfHttVIRA6/PHeUx7IxW8rbXuSsjdkmLWC1sx1AhT6Vr74GKSCS+X+kLYwnCWyTI1mj6iDf8nCygDBQ5gnNutm2A0/MWTjhe/Q2PEJV/4/8XaM2ED7xQ7cL5v+/HEZJpRBqcQ5eHeKVyTJQ6cvB9ibVw1Q+vHCFMQnAQ2vaz8kbxdlRMMJ2f5ylLC8OR1q7R3oL6byG3pPtKeEtX5PowNINzARNA2XQcVleOl3M2KbToNvZ2soqtNuwRH4w5gB2cTFBGq8+xzMQY/hOo0IRZocF7KKd4nuc0n+eTPqbazKrgA6YyIeijbXBXGLasWCzEjz0OkK4HsJ+xeUeF28hc413186ysZUSTKi+SJX2ory32rBbClsEq7vj2EQYkLHVOx02CI9vsv1jb9hDL0CGdqKvip1qw5CghgGcal9xgX2dzD6/sGvSo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(6072148); SRVR:BL2PR05MB2180; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 4:9v8ZIzoEij28TuDk2c2PwhcMxWVJow1ZtbXjfpVo1q/lqXAADmgrEvkBcvuRX+lgcYQUcT60Z1pR7XAegjHlwOo0aCtD/xDe78pyztBou2t3Pa/gUMc1VvCgi6wpZq4l0XTXQWf76XUiTQJAXxBDOWSfU9OYTN+9I9rKq2uMNFvqL3nVdZftpLRGTaa4uXUCTgVUZjxe9xGgarUMtNuww99n1HhJAU4+ANk/oWRFZ0CIsIcKlIsK+gVodo2f+IdRExX9ipUwZlUu3IcD9KRgwjcI+w7GIGMwxKyRwGX9ZRs1zkMXmLqJMvCZiVuncCkvKiVhLP4LrpkvwayHLUu9F5zffF8h1AUVY65QR0G0HLBgvIvUAQ/0QIQyEgmM8lML527WrmbQgd91EHKNha5uZ5DbXbystWoziDqMZ14rBDmP6LIqShEbTBoKdOvbY0B5/j4oTwGA3RZIiFM/lyDIc05QuQOCJIavBCQPbqk80AC3bfLvB6koPxiRfOAwZplgjlcprclmE1JK6z9PyoKPB+mk5n7vir0sMhX2edcBSySa99bWbkGeubtcu9TX95mk/WzLnR4cWwoD8Awh+88HbIEOm6uqNGuZnDKPCi6AdKVCCsAWv7wOkkoIRyVrtBU6NxROsNh0dWTOMYPuPCIU/1cHENNDYtylGx9dH4FGP+Ez1uJhF+LgGVbCiB8qZK+DFdpDsMtUQAQP9oRRUy1yO7vVcx/OvtuwJW3o2jAAeoBBBWH9u5BIEwoyGFuZ7OUkO59mXFP7QdKaQujQ7Hmbwv49apoHUbeFucvgJndOzfiHuD1YfA17OONuqdXmaNN6IeBItgFBQiNHO4urpZ+g0hXTql0RSWqtihR726bIBXs= X-Forefront-PRVS: 0318501FAE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39840400002)(39450400003)(39860400002)(39400400002)(39850400002)(39410400002)(24454002)(377454003)(65826007)(38730400002)(2950100002)(478600001)(270700001)(5660300001)(81166006)(77096006)(189998001)(8676002)(7736002)(33646002)(3846002)(6636002)(6486002)(4326008)(3260700006)(2906002)(25786009)(54896002)(6666003)(53546009)(50986999)(54356999)(76176999)(66066001)(83506001)(93886004)(65956001)(65806001)(84326002)(6246003)(31696002)(36756003)(86362001)(31686004)(230783001)(42186005)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2180; H:[172.29.34.170]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR05MB2180; 23:2DzXQyuXaBLV8BAb+Ov5YDhj7jL/8kEw5gyRZIP9r?= =?us-ascii?Q?OTftwoSlLZqGcE+pWN/WldIOP0fWnHMz3hgnjuTcnesLVhte5aRJSC2ct2hx?= =?us-ascii?Q?gF2/T1kFm9clsNzSlzXWUjJ1/+db+aq+DWXjIi7RdZEe8N+1mh+F+/brgrIb?= =?us-ascii?Q?9t6RMdJ6APeypp7jZZo9mX5Tv24CwMK6YV7+xX31Jiv+FFjpteDCSBWqJNdp?= =?us-ascii?Q?egE4sWUKOniw4emHyubzohMsh20mSPnyOkhbxb12L/ZrqzQhS9O2SAp01a9a?= =?us-ascii?Q?AGwwAxy5qUEEcLi32tIye5OnWW6C08iW9aVit5sdsMh22oFDIZk6+ynudBk0?= =?us-ascii?Q?c8pJbXLo3ngFkjnEdcNh8f7uHDUN9s9DRmuCsmU2FcemDyGmSrtIbr+mF+wt?= =?us-ascii?Q?XFULcN6vVuw0adld086RsCC8rpUshdUZqyN/kKkzOCTR69s3kKGKR3LTJ+hf?= =?us-ascii?Q?imJ9WF0y8FqVBKFbu8oIFiMcwQDm2IGPZomfV+LWvVU3Fu1nFPRfx7LgrPIR?= =?us-ascii?Q?FFBOdQeVrF9zmMfjNGENenNSlT3Dfvl55Mg2F0ROBZMuQQdUA3MXfmgkw/Kx?= =?us-ascii?Q?RjyaWJbQyKHgOqvqYttLdcAxTju0qbotPvf8zZkIREkVESkZqQkzV+Dm6o8x?= =?us-ascii?Q?2XIOuJ1yOxIrs+eJlImumaNvQE+t72sVb3CvPJ/xI27wg6TNH+5iihchWvde?= =?us-ascii?Q?Lb5pT57V0zd7Sjs/m5tRXO0ZvdQsOX0JjKDK8px3FF2cOhKpIMtkh5JAwwp2?= =?us-ascii?Q?nKIGiNrk9KEid0vx6dRGEkyADmmfxF1yYg8uY9OJZhQ/9J9lPXMzf+6uscN9?= =?us-ascii?Q?TLpj4PsOMelcgfbehz0a0ClfRVt4Ww22a9sHLamSMjTuXNVBgull48wkS3wU?= =?us-ascii?Q?sI/mpJJmX0rQdk4qP2LrsZaXhl6b2Nq731++bxKldzgs5dnPgoHLe5cBnXYf?= =?us-ascii?Q?FV4Uc8zZguPiC3m+6cz8Z6qwU+5+amtu+LFYPTiyHPCfLpWrmUNaigZpTXMb?= =?us-ascii?Q?faOBv+BVjpH3XWd6UUmA/5oENn9IuyTl1L32grLg+yBkhICzSr/xU782DCJm?= =?us-ascii?Q?hd7hJ75wxVn3RVnxswwKmXau2iSmI3oQWRHR1N87Zx/00uDXtk+0Z/slYCDf?= =?us-ascii?Q?SbMAl6PF+do/jIdmPGsTC+VXsPWbZclrTfTM051fM5zib16ZUkChC3mxrAIT?= =?us-ascii?Q?2KeA2+JWZgZJgTmI5bAIY7Cg6MarWQuqhW311cj4XN53XqYpKSoSKTZ/zPPI?= =?us-ascii?Q?bum9ZyNKNo1V6S8m14=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 6:EmsH5+B78Ie6P4aStyTTVkBpVyesstAZyU2hWWW/gg9WbKMIVBWS0Bojgt+K+rulCu8v6o8fGXFl71/VUVaGscGXii3TylZn/LoznXu6cQk31T7j27E1RebRWAJZu6BuZJ7J/PglWzYRhDI8nQhS7alPgpKk67V/fjaHkrM9TFm5jG5eTmPuATn7uCzLmUaLsUjt11QgRGs1fr2RetbxIYkANEZIZNrjsk69hkClpwVxJ2bInh7D2smS4HGv8dyuNaKlIrgSA2E5ro7cInhH0jx2NiYaNeDNT7x+FfA6vnoZBSPybjiS8Nf5Ai09wYSztOG6QOwhlOKPCmUiA890lk+tM00FElYbODZVcwdkssNpOU8miuRWAN1QjvkoqTBonCucRvjMCTjzEdOcfbN7B1IyDh5KkJPFIi9D+P8JeDjcm6WKMQ5hk7F0oYqDQM5+s4L5T4OVsCtll+XOP2gsaPMQaeKyuyIH561Zbck+He4Jj0mkmLYdVuZouvfvZ395+ZeXt7mY+NKDD6MNvLRKKv9g6Z7ejvFFFRTKaDalLqo=; 5:wWMLG0jdfaHzZXZMHikwEn0xqQoAMr1wZrXE1+3GUKGO8MASi+y9vx0ebzSkdIy8uNSSZYOZ5u/r9VPRlvnp39Es/3hv3duMbuGVmvAARnMzRWqU8agSx3OKd3esetf5LE+AunHutazhiy/widLMx909O+m0c208bMTnFNpr5tA=; 24:MmBulMTmcWbOrk/z1QPd4gE/dFwyY6bMjrgR/c22ckaPv1smvANg36x15BPOtHltXR5y3c/f2ZHU59VNTyFIkJIhFmnyKI7ofS2n+sSH504= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 7:Ljh8vdIU499drSNdU7FKRJ1n2024rwFwUwgjQ/ZkE2N2gVG18MSQRdgjI7eLlXkQdyBcCKcbjk6V5kXP+RDf4NBKSR4vwii8nDoNTGVz3f/4xpuqIUf79JNYoepd2VPb/AlWZ8DHXqBliTi41f1KlCboXuLayGibTwXBT/Pzf9ukNxjh06j87ED4NsBa0mp/ixz9Lpv6sF7TRxVQwzTxMUbJq09qQtPbpI79qTAmHt7iDAMhGs7QNEjKO6ZlvH2gNeAk+vle/C9qYjbHQffJu5XEOtRGdGr/9zydzNT8r7GGfnwi6t6LXkeEzZ2Dzm5SbhE5PK3kZUa5BUZnpaGFgQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 May 2017 17:54:06.7944 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2180 Archived-At: Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 17:54:12 -0000 This is a multi-part message in MIME format. --------------C06DC5C02F5BC30B87297DEA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 5/23/2017 12:10 PM, Lou Berger wrote: >> RFC 5566 assumes that the IPsec tunnel info and the authenticator >> sub-TLV is conveyed on an update of the encapsulation SAFI. I'm not >> convinced that there are no addtional security issues to be considered >> if this information is carried on updates of other address families. > I think the assumption is that the sub-TLVs are conveyed with the > attribute. I don't see how changing the SAFI impacts this. I'm not saying that it does or does not, just that I'm not sure, and I'm not prepared now to defend a claim that the security aspects are not altered by this change. So I'd rather see that addressed in a different document. > >> Also, note that in RFC 5512, the tunnels only extend to the BGP next >> hop, while in the tunnel-encaps draft the tunnel endpoints are not >> necessarily the BGP next hop. This might also change some of the >> security properties. I think this would have to be thought out fairly >> thoroughly, and I don't think that work's been done yet. > So leaving 5566 as is introduces this issue already (due to the > introduction of the remote endpoint sub-tlv). If the we deprecate 5566 > with this document, this can be trivially addressed by saying that the > endpoint Authenticator sub-tlv applies to the endpoint identified in the > Remote Endpoint Sub-TLV. I'm also not prepared to defend a claim that this is has no signficant impact to the security characteristics. Since the existing contents of the document do not depend upon anything in RFC 5566, I think obsoleting and replacing RFC 5566 is better done in a separate document . >> I don't see how it could be correct for an implementation to always >> include an Encapsulation EC. Sometimes you need to specify more than >> the tunnel type in order to construct the encapsulation properly. > It doesn't "hurt" to include it always and there is an implementation > that does this, so why not allow it? > It seems to me that it does hurt to include it. If the intended tunnel endpoint is not the BGP next hop, or if the tunnel will not work unless the encapulation is prepared as specified within the attribute, then including an encapsulation EC for the same tunnel type provides false information. > The use of multiple tunnels between a pair of endpoints seems to make > sense, especially if the tunnels have different characteristics, and if > color can be used to map particular traffic flows to particular > tunnels. This is something that has not changed from RFC 5512. Note > also that even the Encapsulation EC allows multiple tunnels to be > specifiied (if they are of different types), since an EC attribute can > contain multiple instances of the same extended community. > >> I'm not arguing it that it's not a real use case, but rather that it can >> be solved using other existing, albeit more verbose, mechanisms. Allowing a choice of tunnels between a pair of endpoints should not require the origination of multiple routes with different NLRIs, or (even worse) the use of add-paths. I don't really see the merit of this suggestion. >> If you receive two routes, and >> want to aggregate them so that you only need to propagate one upstream, >> and the two routes have different tunnel-encaps attributes, you need >> some policy to decide what to do. But that's true even if the >> tunnel-encaps attribute only specifies one tunnel. > > Sure, and the policy may be to merge the tlv lists. This is the kind of > information I'm suggesting should be added. I think such policies will be very application-specific, and thus are out of scope of this document. A draft proposing the use of the tunnel encaps attribute for a particular purpose might well have to deal with these policy issues. --------------C06DC5C02F5BC30B87297DEA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 5/23/2017 12:10 PM, Lou Berger wrote:
RFC 5566 assumes that the IPsec tunnel info and the authenticator
sub-TLV is conveyed on an update of the encapsulation SAFI.   I'm not
convinced that there are no addtional security issues to be considered
if this information is carried on updates of other address families. 

I think the assumption is that the sub-TLVs are conveyed with the
attribute.  I don't see how changing the SAFI impacts this.

I'm not saying that it does or does not, just that I'm not sure, and I'm not prepared now to defend a claim that the security aspects are not altered by this change.  So I'd rather see that addressed in a different document.



Also, note that in RFC 5512, the tunnels only extend to the BGP next
hop, while in the tunnel-encaps draft the tunnel endpoints are not
necessarily the BGP next hop.  This might also change some of the
security properties.  I think this would have to be thought out fairly
thoroughly, and I don't think that work's been done yet.

So leaving 5566 as is introduces this issue already (due to the
introduction of the remote endpoint sub-tlv).  If the we deprecate 5566
with this document, this can be trivially addressed by saying that the
endpoint Authenticator sub-tlv applies to the endpoint identified in the
Remote Endpoint Sub-TLV.

I'm also not prepared to defend a claim that this is has no signficant impact to the security characteristics.

Since the existing contents of the document do not depend upon anything in RFC 5566, I think obsoleting and replacing RFC 5566 is better done in a separate document .

I don't see how it could be correct for an implementation to always
include an Encapsulation EC.  Sometimes you need to specify more than
the tunnel type in order to construct the encapsulation properly.


It doesn't "hurt" to include it always and there is an implementation
that does this, so why not allow it?

It seems to me that it does hurt to include it.  If the intended tunnel endpoint is not the BGP next hop, or if the tunnel will not work unless the encapulation is prepared as specified within the attribute, then including an encapsulation EC for the same tunnel type provides false information.

The use of multiple tunnels between a pair of endpoints seems to make
sense, especially if the tunnels have different characteristics, and if
color can be used to map particular traffic flows to particular
tunnels.  This is something that has not changed from RFC 5512.  Note
also that even the Encapsulation EC allows multiple tunnels to be
specifiied (if they are of different types), since an EC attribute can
contain multiple instances of the same extended community.


I'm not arguing it that it's not a real use case, but rather that it can
be solved using other existing, albeit more verbose, mechanisms.

Allowing a choice of tunnels between a pair of endpoints should not require the origination of multiple routes with different NLRIs, or (even worse) the use of add-paths.  I don't really see the merit of this suggestion.

If you receive two routes, and
want to aggregate them so that you only need to propagate one upstream,
and the two routes have different tunnel-encaps attributes, you need
some policy to decide what to do.  But that's true even if the
tunnel-encaps attribute only specifies one tunnel.



Sure, and the policy may be to merge the tlv lists.  This is the kind of
information I'm suggesting should be added.

I think such policies will be very application-specific, and thus are out of scope of this document.  A draft proposing the use of the tunnel encaps attribute for a particular purpose might well have to deal with these policy issues.


    

    

  


--------------C06DC5C02F5BC30B87297DEA--


From nobody Thu May 25 11:10:18 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5251B1294A3; Thu, 25 May 2017 11:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScnspsyphnoA; Thu, 25 May 2017 11:10:13 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0121.outbound.protection.outlook.com [104.47.34.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7D8127B73; Thu, 25 May 2017 11:10:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=64a+0SyKWK6ggMuXeZSSV0pbkaN3aMxOaKVbUL4xtxU=; b=QsIhErRCk+EEeQMo1EmP3nQRBDiLOs2/fY1vUHG+eyeVpolic9aegcb0I7boVU7+B5qKjlQmxKIU+Ltu7IWOXqDC6xRopqdw8Bp0Dyy5auwVvvyYCV72FjtRXJIotS/HnFj5TRpn7JlIjcYUFPnGwRK0u2tblELMdTpzwncnX9g=
Received: from CO2PR05MB618.namprd05.prod.outlook.com (10.141.198.146) by CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Thu, 25 May 2017 18:10:12 +0000
Received: from CO2PR05MB618.namprd05.prod.outlook.com ([10.141.198.146]) by CO2PR05MB618.namprd05.prod.outlook.com ([10.141.198.146]) with mapi id 15.01.1124.007; Thu, 25 May 2017 18:10:11 +0000
From: John E Drake 
To: Eric Rosen , Lou Berger , "John Scudder" 
CC: "idr@ietf.org" , "draft-ietf-idr-tunnel-encaps@ietf.org" 
Thread-Topic: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
Thread-Index: AQHS0aHtgmiwFo/ZwE+Npslhnc8W56H/NfeAgAE8coCAAW8jgIAAJvWAgAASgACAA0GEAIAAAiaA
Date: Thu, 25 May 2017 18:10:11 +0000
Message-ID: 
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net>  <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net> <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net> <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net>
In-Reply-To: <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO2PR05MB2503; 7:gMtJ0Fk7q+76R8RgP6BOP/TfHxVFlphBu8drspqzSwDfcn7CV5yAJ2+ZI/3BXIE7VfZvPABnaOsjc4/ZEqp+bYuB7bVAOz0fAyF9+HIxgcxK8YtW2rb3uuJQ05Pl1PMMFDy/szPzVYFu8py5z/mHnj8KL6bjNvtOfULQ26u2Ys7guRDTZWneX8mWVY03+nc4Y/sEZj0bcYZkF+t9zaLRprUsG1hOasNLZGZZQXr+EyQaAfx+JTty5s2sASa4SwGDEzOeJmNX7UcwOcb6W3sm92KIhhCl8Q+XJaNBxfjFpXWqT5kF5jH6seRqf2NHKsI7zEvpRSNPpYZlRobI7T2lDg==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39860400002)(39850400002)(39400400002)(39450400003)(39840400002)(377454003)(24454002)(93886004)(7736002)(38730400002)(54906002)(55016002)(50986999)(99286003)(54356999)(790700001)(76176999)(54896002)(102836003)(6306002)(3846002)(86362001)(2950100002)(74316002)(6246003)(77096006)(6636002)(6506006)(9686003)(53936002)(230783001)(5660300001)(66066001)(3660700001)(81166006)(8676002)(7696004)(3280700002)(33656002)(53546009)(25786009)(2906002)(189998001)(8936002)(4326008)(9326002)(2900100001)(478600001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2503; H:CO2PR05MB618.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-ms-traffictypediagnostic: CO2PR05MB2503:
x-ms-office365-filtering-correlation-id: a5d47467-c1c6-4e48-39f3-08d4a39948e6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:CO2PR05MB2503; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705)(138986009662008)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(6072148); SRVR:CO2PR05MB2503; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2503; 
x-forefront-prvs: 0318501FAE
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CO2PR05MB618B4D4BC607325D25D29C0C7FF0CO2PR05MB618namprd_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2017 18:10:11.2891 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2503
Archived-At: 
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 18:10:16 -0000

--_000_CO2PR05MB618B4D4BC607325D25D29C0C7FF0CO2PR05MB618namprd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Is it really the responsibility of  a RFC which obsoletes a another RFC to =
explain how every RFC referencing the obsoleted RFC is to be updated?  I th=
ink it's a much better idea to  update each of these RFCs individually.  So=
, as Eric suggests, I think an update to RFC 5566 is in order.

Yours Irrespectively,

John

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Eric C Rosen
Sent: Thursday, May 25, 2017 1:54 PM
To: Lou Berger ; John Scudder 
Cc: idr@ietf.org; draft-ietf-idr-tunnel-encaps@ietf.org
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps=
-04

On 5/23/2017 12:10 PM, Lou Berger wrote:


RFC 5566 assumes that the IPsec tunnel info and the authenticator

sub-TLV is conveyed on an update of the encapsulation SAFI.   I'm not

convinced that there are no addtional security issues to be considered

if this information is carried on updates of other address families.

I think the assumption is that the sub-TLVs are conveyed with the

attribute.  I don't see how changing the SAFI impacts this.

I'm not saying that it does or does not, just that I'm not sure, and I'm no=
t prepared now to defend a claim that the security aspects are not altered =
by this change.  So I'd rather see that addressed in a different document.







Also, note that in RFC 5512, the tunnels only extend to the BGP next

hop, while in the tunnel-encaps draft the tunnel endpoints are not

necessarily the BGP next hop.  This might also change some of the

security properties.  I think this would have to be thought out fairly

thoroughly, and I don't think that work's been done yet.

So leaving 5566 as is introduces this issue already (due to the

introduction of the remote endpoint sub-tlv).  If the we deprecate 5566

with this document, this can be trivially addressed by saying that the

endpoint Authenticator sub-tlv applies to the endpoint identified in the

Remote Endpoint Sub-TLV.

I'm also not prepared to defend a claim that this is has no signficant impa=
ct to the security characteristics.

Since the existing contents of the document do not depend upon anything in =
RFC 5566, I think obsoleting and replacing RFC 5566 is better done in a sep=
arate document .



I don't see how it could be correct for an implementation to always

include an Encapsulation EC.  Sometimes you need to specify more than

the tunnel type in order to construct the encapsulation properly.



It doesn't "hurt" to include it always and there is an implementation

that does this, so why not allow it?



It seems to me that it does hurt to include it.  If the intended tunnel end=
point is not the BGP next hop, or if the tunnel will not work unless the en=
capulation is prepared as specified within the attribute, then including an=
 encapsulation EC for the same tunnel type provides false information.



The use of multiple tunnels between a pair of endpoints seems to make

sense, especially if the tunnels have different characteristics, and if

color can be used to map particular traffic flows to particular

tunnels.  This is something that has not changed from RFC 5512.  Note

also that even the Encapsulation EC allows multiple tunnels to be

specifiied (if they are of different types), since an EC attribute can

contain multiple instances of the same extended community.



I'm not arguing it that it's not a real use case, but rather that it can

be solved using other existing, albeit more verbose, mechanisms.



Allowing a choice of tunnels between a pair of endpoints should not require=
 the origination of multiple routes with different NLRIs, or (even worse) t=
he use of add-paths.  I don't really see the merit of this suggestion.



If you receive two routes, and

want to aggregate them so that you only need to propagate one upstream,

and the two routes have different tunnel-encaps attributes, you need

some policy to decide what to do.  But that's true even if the

tunnel-encaps attribute only specifies one tunnel.



Sure, and the policy may be to merge the tlv lists.  This is the kind of

information I'm suggesting should be added.

I think such policies will be very application-specific, and thus are out o=
f scope of this document.  A draft proposing the use of the tunnel encaps a=
ttribute for a particular purpose might well have to deal with these policy=
 issues.






--_000_CO2PR05MB618B4D4BC607325D25D29C0C7FF0CO2PR05MB618namprd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


Is it really the responsibility of&nb=
sp; a RFC which obsoletes a another RFC to explain how every RFC referencin=
g the obsoleted RFC is to be updated?  I think it’s
 a much better idea to  update each of these RFCs individually.  =
So, as Eric suggests, I think an update to RFC 5566 is in order.=



 




Yours Irrespectively,


 


John




 








From: Idr [mailto:idr-bounces@ietf.org]
On Behalf Of Eric C Rosen

Sent: Thursday, May 25, 2017 1:54 PM

To: Lou Berger <lberger@labn.net>; John Scudder <jgs@junipe=
r.net>

Cc: idr@ietf.org; draft-ietf-idr-tunnel-encaps@ietf.org

Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel=
-encaps-04






 


On 5/23/2017 12:10 PM, Lou Berger wrote:










RFC 5566 assumes that the IPsec tunnel info and the authenticator=



sub-TLV is conveyed on an update of the encapsulation SAFI.  =
; I'm not


convinced that there are no addtional security issues to be considered=



if this information is carried on updates of other address families. <=
o:p>




I think the assumption is that the sub-TLVs are conveyed with the=



attribute.  I don't see how changing the SAFI impacts this.<=
/o:p>






I'm not saying that it does or does not, just that I'm not sure, and I'm no=
t prepared now to defend a claim that the security aspects are not altered =
by this change.  So I'd rather see that addressed in a different docum=
ent.










 


 




Also, note that in RFC 5512, the tunnels only extend to the BGP next


hop, while in the tunnel-encaps draft the tunnel endpoints are not


necessarily the BGP next hop.  This might also change some of the=



security properties.  I think this would have to be thought out f=
airly


thoroughly, and I don't think that work's been done yet.



So leaving 5566 as is introduces this issue already (due to the


introduction of the remote endpoint sub-tlv).  If the we deprecat=
e 5566


with this document, this can be trivially addressed by saying that the=



endpoint Authenticator sub-tlv applies to the endpoint identified in t=
he


Remote Endpoint Sub-TLV.






I'm also not prepared to defend a claim that this is has no signficant impa=
ct to the security characteristics.



Since the existing contents of the document do not depend upon anything in =
RFC 5566, I think obsoleting and replacing RFC 5566 is better done in a sep=
arate document .












I don't see how it could be correct for an implementation to always


include an Encapsulation EC.  Sometimes you need to specify more =
than


the tunnel type in order to construct the encapsulation properly.=



 




It doesn't "hurt" to include it always and there is an imple=
mentation


that does this, so why not allow it?


 






It seems to me that it does hurt to include it.  If the intended tunne=
l endpoint is not the BGP next hop, or if the tunnel will not work unless t=
he encapulation is prepared as specified within the attribute, then includi=
ng an encapsulation EC for the same tunnel
 type provides false information.










The use of multiple tunnels between a pair of endpoints seems to make<=
o:p>


sense, especially if the tunnels have different characteristics, and i=
f


color can be used to map particular traffic flows to particular


tunnels.  This is something that has not changed from RFC 5512.&n=
bsp; Note


also that even the Encapsulation EC allows multiple tunnels to be=



specifiied (if they are of different types), since an EC attribute can=



contain multiple instances of the same extended community.<=
/pre>

 




I'm not arguing it that it's not a real use case, but rather that it c=
an


be solved using other existing, albeit more verbose, mechanisms.<=
/o:p>


 








Allowing a choice of tunnels between a pair of endpoints should not require=
 the origination of multiple routes with different NLRIs, or (even worse) t=
he use of add-paths.  I don't really see the merit of this suggestion.=













If you receive two routes, and


want to aggregate them so that you only need to propagate one upstream=
,


and the two routes have different tunnel-encaps attributes, you need


some policy to decide what to do.  But that's true even if the


tunnel-encaps attribute only specifies one tunnel.




 


Sure, and the policy may be to merge the tlv lists.  This is the =
kind of


information I'm suggesting should be added.






I think such policies will be very application-specific, and thus are out o=
f scope of this document.  A draft proposing the use of the tunnel enc=
aps attribute for a particular purpose might well have to deal with these p=
olicy issues.








 


 








--_000_CO2PR05MB618B4D4BC607325D25D29C0C7FF0CO2PR05MB618namprd_--


From nobody Thu May 25 13:33:31 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE5D127871 for ; Thu, 25 May 2017 13:33:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4xO_mK-hVsL for ; Thu, 25 May 2017 13:33:27 -0700 (PDT)
Received: from gproxy8.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 68F66126C23 for ; Thu, 25 May 2017 13:33:27 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id D883E1AB0D2 for ; Thu, 25 May 2017 14:33:23 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id QkZL1v0022SSUrH01kZPqJ; Thu, 25 May 2017 14:33:23 -0600
X-Authority-Analysis: v=2.2 cv=VKStp5HX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=tJ8p9aeEuA8A:10 a=FfdZnV884f6bpAXlRDsA:9 a=s7XHToudHlygNAlb:21 a=Y1NeEWoyNrhDY_b5:21 a=pILNOxqGKmIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jewcdEyLeOG2fAKxzdR2f2PFyshCTJvcnrkn9gfdHIM=; b=VKhwYCJv7Wu8YKiVMYYIcsIGz1 ulqDjaIz4J+f3JG0Y3XGXn6ohA7C5rLoXgUQj2/toKq0TI3VhKje62nTwpt0pLQkHFp+99gN7Mpy2 NNAMyqpEAUg6DgBAqhCYvPvYp;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:50048 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dDzRf-0005rR-Oy; Thu, 25 May 2017 14:33:19 -0600
To: Eric C Rosen , "John G. Scudder" 
Cc: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net>  <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net> <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net> <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net>
From: Lou Berger 
Message-ID: <017c08ac-55f6-ab12-9b9c-54f03b570f03@labn.net>
Date: Thu, 25 May 2017 16:33:07 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dDzRf-0005rR-Oy
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:50048
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: 
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 20:33:29 -0000

On 5/25/2017 1:54 PM, Eric C Rosen wrote:
> On 5/23/2017 12:10 PM, Lou Berger wrote:
>>> RFC 5566 assumes that the IPsec tunnel info and the authenticator
>>> sub-TLV is conveyed on an update of the encapsulation SAFI.   I'm not
>>> convinced that there are no addtional security issues to be considered
>>> if this information is carried on updates of other address families. 
>> I think the assumption is that the sub-TLVs are conveyed with the
>> attribute.  I don't see how changing the SAFI impacts this.
>
> I'm not saying that it does or does not, just that I'm not sure, and
> I'm not prepared now to defend a claim that the security aspects are
> not altered by this change.  So I'd rather see that addressed in a
> different document.
Well both of these are different statements than you made before.

So the way you'd prefer to resolve the 5566 issue is to leave it for the
future.  I can live with that, but think this should be made explicit
since 5512 is being deprecated.  How about something adding something
like the following to section  1

  RFC5566 uses the mechanisms defined in RFC5512, while this document
replaces RFC5512
  it does not address how the tunnel types defined in RFC5566 can be
used with SAFIs other
  than the Encapsulation SAFI. 

>
>>
>>> Also, note that in RFC 5512, the tunnels only extend to the BGP next
>>> hop, while in the tunnel-encaps draft the tunnel endpoints are not
>>> necessarily the BGP next hop.  This might also change some of the
>>> security properties.  I think this would have to be thought out fairly
>>> thoroughly, and I don't think that work's been done yet.
>> So leaving 5566 as is introduces this issue already (due to the
>> introduction of the remote endpoint sub-tlv).  If the we deprecate 5566
>> with this document, this can be trivially addressed by saying that the
>> endpoint Authenticator sub-tlv applies to the endpoint identified in the
>> Remote Endpoint Sub-TLV.
>
> I'm also not prepared to defend a claim that this is has no signficant
> impact to the security characteristics.
>
> Since the existing contents of the document do not depend upon
> anything in RFC 5566, I think obsoleting and replacing RFC 5566 is
> better done in a separate document .
>

That's fine assuming something like the above.

>>> I don't see how it could be correct for an implementation to always
>>> include an Encapsulation EC.  Sometimes you need to specify more than
>>> the tunnel type in order to construct the encapsulation properly.
>> It doesn't "hurt" to include it always and there is an implementation
>> that does this, so why not allow it?
>>
>
> It seems to me that it does hurt to include it.  If the intended
> tunnel endpoint is not the BGP next hop, or if the tunnel will not
> work unless the encapulation is prepared as specified within the
> attribute, then including an encapsulation EC for the same tunnel type
> provides false information.

Well we disagree.

Going back to your original text, if I read it right, sole use of the EC
was required in the case of a barebones "attribute".  Is this correct? 

If so, I certainly don't think it's reasonable to require use of EC in
some cases and attribute in others.  Allowing for both certainly has
maximal interop, but I think the required baseline should be the common
one, ie., tunnel attribute, not the special case; and EC can be added in
the barebones case.

>
>> The use of multiple tunnels between a pair of endpoints seems to make
>> sense, especially if the tunnels have different characteristics, and if
>> color can be used to map particular traffic flows to particular
>> tunnels.  This is something that has not changed from RFC 5512.  Note
>> also that even the Encapsulation EC allows multiple tunnels to be
>> specifiied (if they are of different types), since an EC attribute can
>> contain multiple instances of the same extended community.
>>
>>> I'm not arguing it that it's not a real use case, but rather that it can
>>> be solved using other existing, albeit more verbose, mechanisms.
>
> Allowing a choice of tunnels between a pair of endpoints should not
> require the origination of multiple routes with different NLRIs, or
> (even worse) the use of add-paths.  I don't really see the merit of
> this suggestion.
The point is simplification for an unused use case.  Is your position
based on theory or actual use?  As I mentioned before, if the latter I
withdraw this proposed simplification.  If the former, I think we should
simplify this case, just like we're eliminating Encap SAFI even though
it provides good theoretical benefits in advertisements.

>
>>> If you receive two routes, and
>>> want to aggregate them so that you only need to propagate one upstream,
>>> and the two routes have different tunnel-encaps attributes, you need
>>> some policy to decide what to do.  But that's true even if the
>>> tunnel-encaps attribute only specifies one tunnel.
>>
>> Sure, and the policy may be to merge the tlv lists.  This is the kind of
>> information I'm suggesting should be added.
>
> I think such policies will be very application-specific, and thus are
> out of scope of this document.  A draft proposing the use of the
> tunnel encaps attribute for a particular purpose might well have to
> deal with these policy issues.
>

Sounds like a future interop issue to me.  

Lou


From nobody Thu May 25 14:04:43 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1AB1292C5 for ; Thu, 25 May 2017 14:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: 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-6DCLrxj_mq for ; Thu, 25 May 2017 14:04:40 -0700 (PDT)
Received: from gproxy5.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 97AF9127B5A for ; Thu, 25 May 2017 14:04:40 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id D19CE14043F for ; Thu, 25 May 2017 15:04:39 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id Ql4c1v0022SSUrH01l4f6c; Thu, 25 May 2017 15:04:39 -0600
X-Authority-Analysis: v=2.2 cv=Ibz3YSia c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=tJ8p9aeEuA8A:10 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=OUXY8nFuAAAA:8 a=5X7pQ0OWmlG20kRLF3IA:9 a=pbxFD4ynq3rNf2me:21 a=z6U91yd1pYKWs-Yv:21 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=cAcMbU7R10T-QSRYIcO_:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=z1Na3Ynn9fsIHXau7xO4DSpCNmqHLMNYc+3MFAS9tAI=; b=NGH68CYev/6J8ErvhTg3UyepU5 lc0iKP0fj4Mdh0OOU0XnmHnuskJBol3uErt7pssXymXXeYIaXoF5XjcG2RdkaJfn/jhqU+r7ji1ky tjgnsAf3cj1JLAMdqGEkM0po0;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:50112 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dDzvv-0002nr-Re; Thu, 25 May 2017 15:04:35 -0600
To: John E Drake , Eric Rosen , John Scudder 
Cc: "idr@ietf.org" , "draft-ietf-idr-tunnel-encaps@ietf.org" 
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net>  <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net> <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net> <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net> 
From: Lou Berger 
Message-ID: <6c89a60e-e205-223e-1823-c4b8499f1b2e@labn.net>
Date: Thu, 25 May 2017 17:04:23 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dDzvv-0002nr-Re
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:50112
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: 
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 21:04:42 -0000

considering the impact of deprecating an RFC on other RFCs seems to me
to be a reasonable thing to cover in the rfc doing the deprecating...


On 5/25/2017 2:10 PM, John E Drake wrote:
>
> Hi,
>
>  
>
> Is it really the responsibility of  a RFC which obsoletes a another
> RFC to explain how every RFC referencing the obsoleted RFC is to be
> updated?  I think it’s a much better idea to  update each of these
> RFCs individually.  So, as Eric suggests, I think an update to RFC
> 5566 is in order.
>
>  
>
> Yours Irrespectively,
>
>  
>
> John
>
>  
>
> *From:*Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Eric C Rosen
> *Sent:* Thursday, May 25, 2017 1:54 PM
> *To:* Lou Berger ; John Scudder 
> *Cc:* idr@ietf.org; draft-ietf-idr-tunnel-encaps@ietf.org
> *Subject:* Re: [Idr] Working group last call for
> draft-ietf-idr-tunnel-encaps-04
>
>  
>
> On 5/23/2017 12:10 PM, Lou Berger wrote:
>
>         RFC 5566 assumes that the IPsec tunnel info and the authenticator
>
>         sub-TLV is conveyed on an update of the encapsulation SAFI.   I'm not
>
>         convinced that there are no addtional security issues to be considered
>
>         if this information is carried on updates of other address families. 
>
>     I think the assumption is that the sub-TLVs are conveyed with the
>
>     attribute.  I don't see how changing the SAFI impacts this.
>
>
> I'm not saying that it does or does not, just that I'm not sure, and
> I'm not prepared now to defend a claim that the security aspects are
> not altered by this change.  So I'd rather see that addressed in a
> different document.
>
>
>      
>
>      
>
>         Also, note that in RFC 5512, the tunnels only extend to the BGP next
>
>         hop, while in the tunnel-encaps draft the tunnel endpoints are not
>
>         necessarily the BGP next hop.  This might also change some of the
>
>         security properties.  I think this would have to be thought out fairly
>
>         thoroughly, and I don't think that work's been done yet.
>
>     So leaving 5566 as is introduces this issue already (due to the
>
>     introduction of the remote endpoint sub-tlv).  If the we deprecate 5566
>
>     with this document, this can be trivially addressed by saying that the
>
>     endpoint Authenticator sub-tlv applies to the endpoint identified in the
>
>     Remote Endpoint Sub-TLV.
>
>
> I'm also not prepared to defend a claim that this is has no signficant
> impact to the security characteristics.
>
> Since the existing contents of the document do not depend upon
> anything in RFC 5566, I think obsoleting and replacing RFC 5566 is
> better done in a separate document .
>
>
>         I don't see how it could be correct for an implementation to always
>
>         include an Encapsulation EC.  Sometimes you need to specify more than
>
>         the tunnel type in order to construct the encapsulation properly.
>
>          
>
>     It doesn't "hurt" to include it always and there is an implementation
>
>     that does this, so why not allow it?
>
>      
>
>
> It seems to me that it does hurt to include it.  If the intended
> tunnel endpoint is not the BGP next hop, or if the tunnel will not
> work unless the encapulation is prepared as specified within the
> attribute, then including an encapsulation EC for the same tunnel type
> provides false information.
>
>
>     The use of multiple tunnels between a pair of endpoints seems to make
>
>     sense, especially if the tunnels have different characteristics, and if
>
>     color can be used to map particular traffic flows to particular
>
>     tunnels.  This is something that has not changed from RFC 5512.  Note
>
>     also that even the Encapsulation EC allows multiple tunnels to be
>
>     specifiied (if they are of different types), since an EC attribute can
>
>     contain multiple instances of the same extended community.
>
>      
>
>         I'm not arguing it that it's not a real use case, but rather that it can
>
>         be solved using other existing, albeit more verbose, mechanisms.
>
>          
>
>
> Allowing a choice of tunnels between a pair of endpoints should not
> require the origination of multiple routes with different NLRIs, or
> (even worse) the use of add-paths.  I don't really see the merit of
> this suggestion.
>
>
>         If you receive two routes, and
>
>         want to aggregate them so that you only need to propagate one upstream,
>
>         and the two routes have different tunnel-encaps attributes, you need
>
>         some policy to decide what to do.  But that's true even if the
>
>         tunnel-encaps attribute only specifies one tunnel.
>
>      
>
>     Sure, and the policy may be to merge the tlv lists.  This is the kind of
>
>     information I'm suggesting should be added.
>
>
> I think such policies will be very application-specific, and thus are
> out of scope of this document.  A draft proposing the use of the
> tunnel encaps attribute for a particular purpose might well have to
> deal with these policy issues.
>
>
>  
>
>  
>


From nobody Thu May 25 19:39:59 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E8A1293F2; Thu, 25 May 2017 19:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.502
X-Spam-Level: 
X-Spam-Status: No, score=-5.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 uUg23mg0gvTx; Thu, 25 May 2017 19:39:55 -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 ACBFB128796; Thu, 25 May 2017 19:39:55 -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 1dE5AN-0003u4-9Q; Fri, 26 May 2017 02:39:51 +0000
Date: Fri, 26 May 2017 11:39:48 +0900
Message-ID: 
From: Randy Bush 
To: Lou Berger 
Cc: John E Drake , Eric Rosen , John Scudder , "idr@ietf.org" , "draft-ietf-idr-tunnel-encaps@ietf.org" 
In-Reply-To: <6c89a60e-e205-223e-1823-c4b8499f1b2e@labn.net>
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net>  <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net> <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net> <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net>  <6c89a60e-e205-223e-1823-c4b8499f1b2e@labn.net>
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=ISO-8859-7
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 02:39:57 -0000

> considering the impact of deprecating an RFC on other RFCs seems to me
> to be a reasonable thing to cover in the rfc doing the deprecating...

the transitive closure, while bounded, could be quite large

>> Is it really the responsibility of  a RFC which obsoletes a another
>> RFC to explain how every RFC referencing the obsoleted RFC is to be
>> updated?  I think it=A2s a much better idea to  update each of these
>> RFCs individually.  So, as Eric suggests, I think an update to RFC
>> 5566 is in order.

this makes more sense

randy


From nobody Thu May 25 20:49:04 2017
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 DB4CC127B57; Thu, 25 May 2017 20:49:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: idr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149577054185.8744.17430341236599211606@ietfa.amsl.com>
Date: Thu, 25 May 2017 20:49:01 -0700
Archived-At: 
Subject: [Idr] I-D Action: draft-ietf-idr-shutdown-09.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 03:49:02 -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 Administrative Shutdown Communication
        Authors         : Job Snijders
                          Jakob Heitz
                          John Scudder
	Filename        : draft-ietf-idr-shutdown-09.txt
	Pages           : 7
	Date            : 2017-05-25

Abstract:
   This document enhances the BGP Cease NOTIFICATION message
   "Administrative Shutdown" and "Administrative Reset" subcodes for
   operators to transmit a short freeform message to describe why a BGP
   session was shutdown or reset.  This document updates RFC 4486.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-shutdown-09
https://datatracker.ietf.org/doc/html/draft-ietf-idr-shutdown-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-shutdown-09


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 Fri May 26 08:26:36 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D857129AAA; Fri, 26 May 2017 08:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 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.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WBz6o2bSpmZd; Fri, 26 May 2017 08:26:20 -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 E506C129AD5; Fri, 26 May 2017 08:26:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4968; q=dns/txt; s=iport; t=1495812379; x=1497021979; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=a/UpPJmKAjaATUyBuaVHDH31xylF0LGelh7zl66+6ws=; b=eXbo8n+jU8/PMSz5DzvzEkc6XlpOTTqcarxxZfDlEXs1NdeoRZXEJ8EE qsQd7GxeVHoPqys7bfWu3vc6kYZwmBj12uO2dUDYnrdTPd/8UZxvr6ntb dzJVv2fcX/r0xGn+Sf+CdoxjgwOf8N//FUf5enNsN30mJRVaGyj2VRjsB Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAQAdSChZ/5pdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQ0Hg2iKGJFllXmCDyENhXYCGoJwPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?ZAQEBAwEBGwYROhsCAQgYAgIRFQICAiULFRACBAESiioQqzuCJotWAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEZBYELhzEBgxyEfSiCU4JgBZ4jAYcfjAiCBoU8ijWUTQE?= =?us-ascii?q?fOIEKdBVGhQgXgWN2AYd7gQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.38,397,1491264000"; d="scan'208";a="429024302"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 May 2017 15:26:19 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v4QFQIEX005191 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 May 2017 15:26:18 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; Fri, 26 May 2017 11:26:18 -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, 26 May 2017 11:26:17 -0400
From: "Acee Lindem (acee)" 
To: Job Snijders , "idr@ietf.org" , "draft-ietf-idr-tunnel-encaps@ietf.org" 
Thread-Topic: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
Thread-Index: AQHS0aHyfjzql++v8E6rbs0uznlaOqH/eQWAgAXjmgCAAWjtAA==
Date: Fri, 26 May 2017 15:26:17 +0000
Message-ID: 
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> <20170525135424.3v3ea3rfdsquwizu@Vurt.local>
In-Reply-To: <20170525135424.3v3ea3rfdsquwizu@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.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <4B19B15FFF0C5E4BB1603DCB9688A657@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 15:26:33 -0000

SGkgSm9iLCANCkNpc2NvIGlzIHN1cHBvcnRpbmcgVHVubmVsIEF0dHJpYnV0ZSBwYXJzaW5nIGFu
ZCBwcm9wYWdhdGlvbiBhcyB3ZWxsIGFzDQp0aGUgVEUtUG9saWN5IHR1bm5lbCB0eXBlIGluIGFu
IHVucmVsZWFzZWQgdmVyc2lvbiBvZiBJT1MtWFIuIFRoZSBTUi1URQ0KUG9saWN5IGRyYWZ0IGlz
IA0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJldmlkaS1pZHItc2VnbWVudC1yb3V0
aW5nLXRlLXBvbGljeS0wNS50eHQuDQpUaGFua3MsDQpBY2VlIA0KDQpPbiA1LzI1LzE3LCA5OjU0
IEFNLCAiSWRyIG9uIGJlaGFsZiBvZiBKb2IgU25pamRlcnMiIDxpZHItYm91bmNlc0BpZXRmLm9y
Zw0Kb24gYmVoYWxmIG9mIGpvYkBudHQubmV0PiB3cm90ZToNCg0KPkRlYXIgYWxsLA0KPg0KPlRM
O0RSOiBJIGRvIG5vdCBzdXBwb3J0IGFkdmFuY2luZyB0aGlzIGRvY3VtZW50IGF0IHRoaXMgdGlt
ZS4gTGFjayBvZg0KPmZ1bGwtc3BlYyBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlLCBhbmQgbGl0
dGxlIGZlZWRiYWNrIGZyb20gYWN0dWFsDQo+aW1wbGVtZW50ZXJzLCBsZWFkIG1lIHRvIG5vdCBz
dXBwb3J0IHByb2dyZXNzaW9uIG9mIHRoaXMgZG9jdW1lbnQuIEkNCj51bmRlcnN0YW5kIHRoYXQg
dGhpcyBwb3NpdGlvbiBoYXMgbGl0dGxlIHRvIGRvIHdpdGggdGhlIGFjdHVhbCBjb250ZW50cw0K
Pm9mIHRoZSBkb2N1bWVudC4NCj4NCj5PbiBTdW4sIE1heSAyMSwgMjAxNyBhdCAwMzo1ODoyOVBN
IC0wNDAwLCBMb3UgQmVyZ2VyIHdyb3RlOg0KPj4gT24gMDUvMjAvMjAxNyAwMzo0NyBQTSwgSm9o
biBHLiBTY3VkZGVyIHdyb3RlOg0KPj4gPiBBIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGhhcyBi
ZWVuIHJlcXVlc3RlZCBmb3INCj4+ID4gZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2Fwcy0wNC4g
UGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91cg0KPj4gPiBjb21tZW50cy4gQXMgdXN1
YWwgbm90ZSB3ZSBjYW5ub3QgYWR2YW5jZSB0aGUgZHJhZnQgd2l0aG91dA0KPj4gPiBwYXJ0aWNp
cGF0aW9uIGZyb20gdGhlIGdyb3VwLiBQbGVhc2UgZ2V0IHlvdXIgY29tbWVudHMgaW4gYmVmb3Jl
DQo+PiA+IEp1bmUgNSwgMjAxNy4NCj4+IA0KPj4gLSBTaW5jZSB0aGUgcXVlc3Rpb24gd2FzIHJh
aXNlZCBvbiBsaXN0OiBhIHBhcnRpYWwgaW1wbGVtZW50YXRpb24gb2YNCj4+IHRoaXMgZHJhZnQg
Y2FuIGJlIGZvdW5kIGluIEZSUm91dGluZywgbm90YWJseSBiZ3BfZW5jYXBfdGx2LntoLGN9IGlu
DQo+PiBodHRwczovL2dpdGh1Yi5jb20vRlJSb3V0aW5nL2Zyci90cmVlL21hc3Rlci9iZ3BkIC4g
SXQgc3VwcG9ydHM6DQo+PiANCj4+ICBvIGVuY2FwIGF0dHJpYnV0ZSBzZW50IHdpdGggb3RoZXIg
c2FmaXMuICBUaGUgY29kZSB1c2VzIGl0IHdpdGggdGhlDQo+PiAgICBWUE4gc2FmaSB0byBwcm92
aWRlIHVuZGVybGF5IHR1bm5lbCBpbmZvcm1hdGlvbiBmb3IgVlBOIHJvdXRlcyBmb3INCj4+ICAg
IE5WTzMgdHlwZSBhcHBsaWNhdGlvbnMuDQo+PiANCj4+ICBvICJSZW1vdGUgRW5kcG9pbnQgQWRk
cmVzcyBzdWItVExWIiBmb3IgdjQgYW5kIHY2DQo+PiANCj4+ICBvIGVuY29kZS9kZWNvZGUgb2Yg
dHlwZSBzcGVjaWZpYyBhbmQgc3ViLVRMViBmb3JtYXRzDQo+PiAgICBwZXIgZHJhZnQgLTAwIG9y
IC0wMSByZXYgKHRoaXMgbWVhbnMgaXQgaXMgYSBzdWJzZXQgaW1wbGVtZW50YXRpb24uDQo+DQo+
Q29vbCBzdHVmZiwgdGhhbmtzIGZvciBzaGFyaW5nIHRoYXQhDQo+DQo+V2hpbGUgSm9obiBTY3Vk
ZGVyIHBvaW50ZWQgb3V0IHRoYXQgdGhlcmUgaXMgbm8gYmxvY2tpbmcgcmVxdWlyZW1lbnQgZm9y
DQo+YSBkb2N1bWVudCB0byBoYXZlIGltcGxlbWVudGF0aW9ucyBiZWZvcmUgcGFzc2luZyB0aHJv
dWdoIFdHIExDLiBJIChhbmQNCj5wcm9iYWJseSBwYXJ0aWNpcGFudHMgdG9vKSBhbSBvZiB0aGUg
b3BpbmlvbiB0aGF0IGFjdHVhbCBmZWVkYmFjayBmcm9tDQo+aW1wbGVtZW50ZXJzIGlzIGV4dHJl
bWVseSB2YWx1YWJsZS4NCj4NCj5TaG91bGQgYW4gaW1wbGVtZW50ZXIgZmluZCBhbiBhY3R1YWwg
dGVjaG5vbG9neSBpc3N1ZSwgb3IgbGFjayBvZg0KPmNsYXJpdHkgaW4gdGhlIHdvcmRpbmcgb2Yg
dGhlIGRvY3VtZW50LCBhcyBsb25nIGFzIHRoZSBkb2N1bWVudCBpbiB0aGUNCj5XRyBpdCdsbCBi
ZSB0cml2aWFsIHRvIHJlc29sdmUgYW55IGlzc3Vlcy4gSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUg
YXJlDQo+d2F5cyB0byBtb2RpZnkgYSBkb2N1bWVudCBhZnRlciBXRyBMQywgYnV0IEkgdGhpbmsg
aXRzIHNpbXBsZXIgdG8gYmUNCj5hYmxlIHRvIHNheSB0byB0aGUgd29ya2luZyBncm91cCBpdHNl
bGYgInRoaXMgdGVjaG5vbG9neSB3b3JrcywgaSBoYXZlDQo+YW4gaW1wbGVtZW50YXRpb24iLg0K
Pg0KPlNob3VsZCBzb21lb25lIHdyaXRlIGEgcGFydGlhbCBpbXBsZW1lbnRhdGlvbiwgdGhhdCBt
aWdodCBiZSBhIGhpbnQgdGhhdA0KPnRoZSBkb2N1bWVudCBuZWVkcyB0byBiZSBzcGxpdCB1cCAo
b3IgcGVyaGFwcyBpdCBpcyBvZiBubyBzaWduaWZpY2FuY2UpLg0KPlRvIHByb3Blcmx5IGFzc2Vz
cyBhIGRvY3VtZW50LCBJIGhvcGUgZm9yIGZlZWRiYWNrIGZyb20gZnVsbA0KPmltcGxlbWVudGF0
aW9ucyAocGVyaGFwcyB0d28gdGVjaG5vbG9neSBjb21wb25lbnRzIHdpdGhpbiBhIGRvYyBjb25m
bGljdA0KPndpdGggZWFjaCBvdGhlcikuIElmIHBhcnRzIG9mIGFuIEludGVybmV0LURyYWZ0IGFy
ZSBub3QgaW1wbGVtZW50ZWQgYnkNCj5hbnlvbmUsIEknZCBhZHZvY2F0ZSB0aGUgZG9jdW1lbnQg
c2hvdWxkIG5vdCAoeWV0KSBwcm9ncmVzcyBmdXJ0aGVyLg0KPg0KPldpdGggImltcGxlbWVudGF0
aW9uIiBpIGRvbid0IG1lYW4gdGhhdCB5b3UgYXJlIHNoaXBwaW5nIGNvZGUgdG8NCj5jdXN0b21l
cnMsIEknbSBmaW5lIHdpdGggc3R1ZmYgaGFuZ2luZyBpbiBwcml2YXRlIGJldGEgYnJhbmNoZXMg
LSBhbGwNCj5JJ20gbG9va2luZyBmb3IgaXMgYW4gYXR0ZXN0YXRpb24gdGhhdCB0aGUgaW1wbGVt
ZW50ZXIgZm91bmQgdGhlDQo+ZnVsbCBzcGVjaWZpY2F0aW9uIGltcGxlbWVudGFibGUuIFJGQzc5
NDIgaXMgZ29vZCBndWlkYW5jZS4NCj4NCj5JJ2QgbGlrZSB0byByZXF1ZXN0IHRoZSBjaGFpcnMg
dG8gY29uc2lkZXIgYSBzbGlnaHQgYWRqdXN0bWVudCBvZiB0aGUNCj5wcm9jZWR1cmU6IGVuY291
cmFnZSB0aGUgd29ya2luZyBncm91cCB0byBjcmVhdGUgaW1wbGVtZW50YXRpb25zDQo+X2JlZm9y
ZV8gV0dMQywgc28gdGhlIHdvcmtpbmcgZ3JvdXAgY2FuIHRha2UgaW1wbGVtZW50ZXIgZmVlZGJh
Y2sgaW50bw0KPmFjY291bnQgd2hlbiBhc3Nlc3NpbmcgdGhlIHByb3Bvc2VkIGRvY3VtZW50Lg0K
Pg0KPktpbmQgcmVnYXJkcywNCj4NCj5Kb2INCj4NCj5wcy4gaWYgdHdvIGZ1bGwgaW1wbGVtZW50
YXRpb25zIHNob3cgdXAgZHVyaW5nIHRoaXMgV0dMQywgSSB3aWxsDQo+b2Zjb3Vyc2Ugd2l0aGRy
YXcgbXkgbm9uLXN1cHBvcnQuDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj5JZHIgbWFpbGluZyBsaXN0DQo+SWRyQGlldGYub3JnDQo+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0K


From nobody Fri May 26 08:43:05 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA80B12E856; Fri, 26 May 2017 08:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IXb5XKbQK09; Fri, 26 May 2017 08:43:02 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0113.outbound.protection.outlook.com [104.47.34.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9D412E855; Fri, 26 May 2017 08:43:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+UmYa2MXKWg8HhObfZj7Gn28dj9eWxvYy81ZOZjQvkE=; b=XCvnhgfsVhimzHNCyAGJU4/LG4LfP3Z/4TxA9WrlUv4A840VhFjcTQo6IuZkZr/t/JWlpk+GZwGXrl4poocZkpUGlo/iZAkGXGbNYviodBUbGHnzAdh1vQV0cKuOLd2OxHT51fSo7Qe3Bxssmc7YnR+O8WnOumsWmzCKJ3bnAWw=
Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net;
Received: from [172.29.34.170] (66.129.241.10) by BL2PR05MB2180.namprd05.prod.outlook.com (2a01:111:e400:c74e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Fri, 26 May 2017 15:42:59 +0000
To: "Acee Lindem (acee)" , Job Snijders , "idr@ietf.org" , "draft-ietf-idr-tunnel-encaps@ietf.org" 
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> <20170525135424.3v3ea3rfdsquwizu@Vurt.local> 
From: Eric C Rosen 
Message-ID: 
Date: Fri, 26 May 2017 11:42:56 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: [66.129.241.10]
X-ClientProxiedBy: BN6PR19CA0038.namprd19.prod.outlook.com (2603:10b6:404:68::24) To BL2PR05MB2180.namprd05.prod.outlook.com (2a01:111:e400:c74e::12)
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL2PR05MB2180:
X-MS-Office365-Filtering-Correlation-Id: ec480f17-4432-4134-db70-08d4a44de3af
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BL2PR05MB2180; 
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 3:AmdEmG/PLmBGlBalfQp25LBZJas2WP0Prixnx1qvzAA26gAtOaT6Ck26zxR3p9yKg/AY5XxDCzB+3t6GxoVON5gOyDq4RH8L5RmVUS6ZOv8VjP/QGym8bZBJXj/HTAKce427ur6a4AhQTBq/rOLvMgRVLCQG2cMdO4/9RhZx1NS3fhvBQa8QrFJr+sir2cCW3sH+GL4tLw0N+eZJbyrJooIefOXSHOLeHZYYh37rZ9ZtsbkBdqFyV5W+sFUdls237WZ1Bu7ZTmSsvh1l3X/MaRIdKJvRBryifDBnQIaae0gcdZpfr+lfsBnDU7arPTyE5ieJ4R+6unZZKV4YQf1hWx1RYqukq/Kl3+kx2irj8TQ=; 25:uyZQnggpNJDywL2CoDw7qDASZVdx9RsLwbLCMcSOJ4K+sdH4dDLbOxAEdbMQPgqoekb3aiTmqkyzZUy0xYKGScVT1/59r4svHfuaGMWN05kAbEfwsGYqlCHZEoi8DUw574kcBp48yeN+TSqmrNW0feARQgyKDZW/wFVBsTtTkNQ4FdsNWTE8Igc81Ml0XUiUvK6UGtx4ocEE7IRQKl/Hp/EiMNXJ5la3aOCcZKCemdU7Eq5aLvyVEV/1/3l7uWVh2oKKdHfB0p3ZpkiKNZMrOORvSJC07/P847iZWWu57DYH7dF1QfIvB3QbrQzUnxLTvLQ7hhV1AF3B4iq6UuPOtJNbXJv8Z8WGEwGACZvTyqMpIaDqC2F0HNpcKA8teShOMxQjgtQN0bJgwVlVqH9vNnHBBXXp4VvBFlSmvCQ+DNQzVBn7FGS81SfeuaSvurOD60ngNNzLs969w3Ih5MAXWkcktUnAYhZ4OpeB5WFrCGw=
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 31:M7csVr8Ygi2CnkFL2kZUFmRfd08++hD5f41wMjobQFwVycpCLfdx1rKg0ssMYFx8GCP+mIxjebFulrm2grHL8ifWIE2jImAekWlLuqw9+Jc6Jf3JK73mP05ZMTh1QasrfrBwFHXCDP1ifTVb3VPMPRYxBfJ4LjnVkNMQ9BItP8WmY8MBF9W58bSN8wiHMURcDQWc29xxhQNu7/rgufpdrwWirMa0o0+lW/nCyS1O/e0=; 20:Y1qaT8wSAa1vxrAFJOcLuUuZ8SMTiQ9AJK3t4BFfZpEbdywikeTgiyx54234KCtdJDWkpzG6q7qUqbStLtOGIfJ4TpJ5PQK3LN4jrnidiP/4Ige+qO+WbD65ekeJkwFSx1y5mgliQm15cjwmzBTl4mkHRIdv6dGgSW98sz+cHeJVb2QxEk0mVA74jFBITnsTRdY1TZevfNn2X4wVyBxCXF7cmmrkgBccvKW7sPzmLpOD6q+BuKqMj5I5zgOLIwRrZHi8ZDAP7HVyJOos+p/m06+niQW65Aj6ym0dQ/5NuNl5b3cyJypkz1/rhKNITJFiMQwDk53XmveUuqVjkf2EZ/T63HPOmG8UIpXCTPB/QqsVcSP9HQyrgk5r+kaUPBboDsIAk6eW0rLhO8pfLsKpkC/F6NCck6JhQwB8Ntot9CNKxO66ghrFUsG3GJGstwIwHfe+K4lBERO034nyY/DtsrMiA5xGXxbfXyE2hDU4Ycu7ynB8kSFMfxPm7Kkkm1lsv2ze8OU4t6ZcJwJa4zAbbJIm3uzXkk9w5V77xsg4UZarIBL+/iQ3OqEgYEdzot5Jm0zUEEGSLWu79O7ueotwOEUC55RSufQv5X6+r8P2LHc=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(166708455590820);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(6072148); SRVR:BL2PR05MB2180; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2180; 
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 4:IZOb/UZEjTt40qnBTRNdvG7dCAMOvAlRWQUVa5JqRWiTmLkbGj1nWcUaV/5EazcLaT7BaNqv6+tHpzD0hBCGdg1m2GvHZN8bED1E9k6GAnhH7vHoBJ8dAN0HmLJ+owz3laVlfF4uGSQEy2KQj8atCUOVea2kFRRez7vWIwyIywGQ/xTnyeVujmY6flXbWL0ohod1iqjTAFuKn2AvSYrSAWLSOOar2hiYsuue2ewyR/7f2bdCsFvdn18++VT2XZZAbjOis4SohOY7rwiX8A82gOxwiakZH1x1zRQjKh5wwI702J2+f68lM4nZePhLlpUlztoEx7VXNrI16FAfZo1WESafFTvdTwvEjV9Aaw6qbqYvpP9SBTzvusNUHZt9gJMJK/OFgdGYgytJjcpuStZ8bEgA/A40DgGLc9dS3y2a5po20BWYkjz56QbVLGoUow2g6C5xIoc437psiaHgcc7b3AwJdD152kSf2FGVn6g5AdiDU8Qb6jWHpFDB+isvxaYXK0Pyy0Ak6cz1JzYEZaqWFBoKLJ+Ly5gNlB9M4y1Z+JGNspHdMYT9OVgihqlGB2rHe+1TNpOSQ4xnBygQLglKnffvWXojCBOx26woLGcu1AgDllzWg0pyWOEkPiDEdki4cpzbO7HIMfPSQgWDqXYixncz3WfucmlkSkT2PKHzm0vqFC9EgVrFO3q8Hg8QqLhH9lkRuSbZKGbrqmMWX1YuB3TrdSgFTdTYArwInjWrymUhBBs4Z01P/pFRKJ+iTWWPV6UcJsmWXeqbj346lsnG8ksp4hykiH2T1jOfv6TQ8xgoq3SaYV6g1nul+tUhpNQD6JetNcyFlXMqe7JFgVh+pHqgr49ZXF44sRoFbP+Wb30=
X-Forefront-PRVS: 031996B7EF
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39860400002)(39850400002)(39400400002)(39410400002)(39840400002)(39450400003)(24454002)(377454003)(6306002)(77096006)(38730400002)(33646002)(6486002)(42186005)(64126003)(6116002)(478600001)(2950100002)(53546009)(3846002)(3260700006)(25786009)(50986999)(230700001)(54356999)(53936002)(76176999)(50466002)(31686004)(2501003)(31696002)(4001350100001)(83506001)(6246003)(36756003)(66066001)(65806001)(65956001)(2906002)(305945005)(7736002)(5660300001)(47776003)(23676002)(8676002)(6666003)(81166006)(93886004)(230783001)(229853002)(86362001)(966005)(2201001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2180; H:[172.29.34.170]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDJQUjA1TUIyMTgwOzIzOkJBZ1lOcEtFZzhRSW1NVDZyYVVUVDRsM2R4?= =?utf-8?B?eVFwZ1h0U0JZTURQMVozT2pWaEFJQzcvVGh6d0VEZXBtcHoxWHdsckJQcCtG?= =?utf-8?B?aWJyZTZQMld5Z1BiRzNLcjZIQ1pRNGUvbW03dkxPdzk4b2VGWGVrSU9IM3dq?= =?utf-8?B?OFNxeDhMNGVaZXNLV3ovbG92TDYra0t2OTJ5WkdFSE9rUi9HYnRhbEhEODIr?= =?utf-8?B?THd5NzYzbEFOd3F4TXNpUmJMV2d0YnpiZi9CVHcvMHFjZlRpYkpTUnVnRXV6?= =?utf-8?B?ck9wUWRYZUNpQmtwN3k5VlkybFhldHpsSFhRMUNqaUxCQ2VybEVIcmdUK2xm?= =?utf-8?B?d1ZXdWFRWmZKcXpoSUE3QTE1RTJXaUF2eDV3S1ZJRVVMa3NOcW1FS2pkR1N5?= =?utf-8?B?NFBUcm0wSlRMdy9aY09Uek9CZTkxVzRINGthZ0NPU05iYmxjZTBYT0F4T2t6?= =?utf-8?B?VDBaem9rQ09DWTQ5YjlWWm9oRlorVUpTbmZyQXpPNytVTVRWYWk0N2Yzbmdl?= =?utf-8?B?RXBzOE16bW5Pd1JGS0dsS3RVbHE2QUNJaGh2a2V2NWdUZWdpQmUvZGNmT1Ir?= =?utf-8?B?b1p4Z2d5Y3ZDSFh0MmpXVHhPMFhVanN4eFlUTkZmUkFBNUpwYmxjVkdWQnhI?= =?utf-8?B?RW9sN2FyTjV1d1ZuZmFKQ1NhUm1VU1QzYXg2WnlXR3ZVZ00rZUY4WlFEdzJn?= =?utf-8?B?RDFMQUVwMWUxeXlHVnZFMFk0ZmRMQnBINU4zTmZaWi9XOEI4R2pUSDZ1TmUy?= =?utf-8?B?OGFpVmM3SUN4UTEwSDByRDI0WWZaZFlhWU5QRWNXNVlCNENIcFhJelFLNHla?= =?utf-8?B?cS8xRm14ZEhad241M3NIOTdDRVgwNmRKZENYVVVCekh4M3M1M1Boa0p0d0l4?= =?utf-8?B?cnlLckF3aEN2MW9zVHpqSUhGUjJTYm8vdkdYNDNFTzhpdWQ3Wk5ON0kxQUxT?= =?utf-8?B?OWdiZGo4VHVlM0s3NDVzcHhINHY0cGpPY2VOQk5TdUs4ODJKNW8zbEFoaWpV?= =?utf-8?B?bU1MOUdNbjdzNjlZenlWbHZrSGRvK3RGMHlsRUdSL095VDdrUERJSG9JNmV1?= =?utf-8?B?dVlDRTl4aVAvVmVCblA0ekdTSjZETHlXZUFseXNBZkpxeDdsTFpIZmk0WkpJ?= =?utf-8?B?YzExREdvUEFyWnU3aitiampqbitNTHcxYk5JSWtzU05WVnhiMEVnYkJDOGhU?= =?utf-8?B?ZncyTVhDNUhJMnBGZ0xLdTc3TG1JMXBiME1ObmEwcDZ0MTJCRFpVREJub3Qr?= =?utf-8?B?cEpVUndDZGxBUnF3TC9XRDc5TTA1NWpJVEhCZUk4MERnaC9IbTZyZ21BbWx5?= =?utf-8?B?cW16RFJwUzM0eVB1bXVyd2tpT1V3Q2hBZnlRS3habUpVMytiZk40UkJNaTVD?= =?utf-8?B?NEo4c1lHS2pKSnl5c3pFUlZ6WlN3TjRRckwzU1M1eXY0dlBXUS9XVjRuTGF1?= =?utf-8?B?WUlsZ3hqa0pkUHhUVGFBRnNleXNwWHJXYm5SOE81dFFoU3oxSVF2a0dyaUgv?= =?utf-8?B?MGwyZkVzZ3BUQlZjNzRTajZneWNnWHhQMFVoT3BLWkV1K210MWFkOHRGclRm?= =?utf-8?B?c3pWWEtYUUMwU1A1R05RN3hnUWdIRlUxemIvTi9qaEFZOHJMRXY0UksvVHdP?= =?utf-8?B?OFlmYW94bGpTb1p2SDlXWlRScDlNUUdiRUtNMnpXS0dLeGtMRjZDK1B0NEZI?= =?utf-8?B?RmhOMjU1MXhmWEdHZmdsT3NqYlFGWjFTNkxSMUN4aXY4MTRTWFBWMW1nbll4?= =?utf-8?B?OFdaZEUwelBaSFM5K1FpOHNBcUpLNnEvbWFHdHFBZ0duY1RXVlA0SUhoZWJX?= =?utf-8?B?WHF1T3BnakZyTVhQY3BIR3k5Y0hOVlMyTXZsQW1VNTJSeUJidFM0L1lmNWVx?= =?utf-8?Q?oWVCGLROAIPw5Im1Z5+ARaw03MQC9Drf?=
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 6:dXQ+hbwrTSa0CJqelG1BKvf22/y+476A8sGj4N0+mBSdCvt882VFHZguwrJu0uvNEj7NvrMflo4gyHSD7X4rzXiDR1y3cntDKkammNdt+o3xhEr/DBOmk/pDmP5Bpr6bTPbFth/RBASxXTdL8LSLFfvv3jRHSFUVAhW8Gq66HH6LYpaLekGO2j1kYz64EF5aEx7EGJMkJHTJtoB5k1hlwiRuKsx08bGU3OSm6o76qCfdQ1aD/5gx3CVzxgvUWkzI1GkLapvwYHC+2L/OgQ9QoZb0mpv4OvRUYMdLSpWvKEua8vOErdVy9IjBjvfd8ROld6k+gKmFBPED24MDS3g5rRn+GtrPoxLKtzl7DcNDLsZcSMiTlZ3Q6EwhYZCn+0cupdw5PJytYxG3SGR4htO9op4y6qEDvJkT7c8uts0PJk4uoxPs+s73i/IOGwX4i2Z1CgSdSxVoA75Y1dKGzNvfjNqM/m7YlGRu1tfg34pZpG/zAQE4OFn1cGREG+uPqRMMG7Fqwgi8G9m38JQaDHMscwaW3O5PP9Us9k4l2VtQF5I=; 5:3PXTkdV5UJXvQUwqB2HAez6/T0FmnzLdOmm1G+VnV+2o39+Q7gmPcZ9B6wkK7Mjfjc7GTCta4aPW7uAQowkXT1M5tsz1f+VdoLe7uNjkx+xFTff+Sj5IQ+844mIs/2y04G70u2LG1nWmuv7SRkWSxw==; 24:Wu1XN5+03lG/snwpTd9uxvpT+i0fTHhs5xz7ApZzGD/sFdS/DDAAvkdqIpCmDqtMb9QCnTk/wg6w/PJrtzkxVO9phtuz7UYcCEuuDbYyvIk=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 7:759mQLZBIYKx5BG96T+r+aeEwBFJT4on5NJhC7AfTD5jukA4dQLy3gHQY/Pqr19rOYX3Ciob1aZtp7vnJ0LLMxd0YJkcr/a4AjOOXEo/mB1dhCrQoextSC5eShkIawzMtzx1YibpwW4HRvN8CHeeKPr4KD9lafR+ri5/wZcPXXxTpDraCSZJtREbvKtiRxxWPdi771lTq9kcY3wPIVz+husBL05f2hG6rbM+o0ypX5bK3FAiQgzs/k2LYV+LOji6qppsGQextfWJoI3fOYkzsjiPiQKdMiPF/ZNBXoy0sci/f1A18ZVUWrJKyCDZKT1vrULhqrf6+9OU1TN6WJsGrw==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2017 15:42:59.9534 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2180
Archived-At: 
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 15:43:05 -0000

Juniper also has an implementation of various parts of the draft, as 
needed to support the segment-routing-te-policy draft.  Some other parts 
of the draft have also been implemented as well.

On 5/26/2017 11:26 AM, Acee Lindem (acee) wrote:
> Hi Job,
> Cisco is supporting Tunnel Attribute parsing and propagation as well as
> the TE-Policy tunnel type in an unreleased version of IOS-XR. The SR-TE
> Policy draft is
> https://www.ietf.org/id/draft-previdi-idr-segment-routing-te-policy-05.txt.
> Thanks,
> Acee
>
> On 5/25/17, 9:54 AM, "Idr on behalf of Job Snijders"  on behalf of job@ntt.net> wrote:
>
>> Dear all,
>>
>> TL;DR: I do not support advancing this document at this time. Lack of
>> full-spec implementation experience, and little feedback from actual
>> implementers, lead me to not support progression of this document. I
>> understand that this position has little to do with the actual contents
>> of the document.
>>
>> On Sun, May 21, 2017 at 03:58:29PM -0400, Lou Berger wrote:
>>> On 05/20/2017 03:47 PM, John G. Scudder wrote:
>>>> A working group last call has been requested for
>>>> draft-ietf-idr-tunnel-encaps-04. Please reply to the list with your
>>>> comments. As usual note we cannot advance the draft without
>>>> participation from the group. Please get your comments in before
>>>> June 5, 2017.
>>> - Since the question was raised on list: a partial implementation of
>>> this draft can be found in FRRouting, notably bgp_encap_tlv.{h,c} in
>>> https://github.com/FRRouting/frr/tree/master/bgpd . It supports:
>>>
>>>   o encap attribute sent with other safis.  The code uses it with the
>>>     VPN safi to provide underlay tunnel information for VPN routes for
>>>     NVO3 type applications.
>>>
>>>   o "Remote Endpoint Address sub-TLV" for v4 and v6
>>>
>>>   o encode/decode of type specific and sub-TLV formats
>>>     per draft -00 or -01 rev (this means it is a subset implementation.
>> Cool stuff, thanks for sharing that!
>>
>> While John Scudder pointed out that there is no blocking requirement for
>> a document to have implementations before passing through WG LC. I (and
>> probably participants too) am of the opinion that actual feedback from
>> implementers is extremely valuable.
>>
>> Should an implementer find an actual technology issue, or lack of
>> clarity in the wording of the document, as long as the document in the
>> WG it'll be trivial to resolve any issues. I understand that there are
>> ways to modify a document after WG LC, but I think its simpler to be
>> able to say to the working group itself "this technology works, i have
>> an implementation".
>>
>> Should someone write a partial implementation, that might be a hint that
>> the document needs to be split up (or perhaps it is of no significance).
>> To properly assess a document, I hope for feedback from full
>> implementations (perhaps two technology components within a doc conflict
>> with each other). If parts of an Internet-Draft are not implemented by
>> anyone, I'd advocate the document should not (yet) progress further.
>>
>> With "implementation" i don't mean that you are shipping code to
>> customers, I'm fine with stuff hanging in private beta branches - all
>> I'm looking for is an attestation that the implementer found the
>> full specification implementable. RFC7942 is good guidance.
>>
>> I'd like to request the chairs to consider a slight adjustment of the
>> procedure: encourage the working group to create implementations
>> _before_ WGLC, so the working group can take implementer feedback into
>> account when assessing the proposed document.
>>
>> Kind regards,
>>
>> Job
>>
>> ps. if two full implementations show up during this WGLC, I will
>> ofcourse withdraw my non-support.
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr


From nobody Fri May 26 08:45:40 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75D412E855 for ; Fri, 26 May 2017 08:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.418
X-Spam-Level: 
X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=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 ETQ17-tuyefl for ; Fri, 26 May 2017 08:45:38 -0700 (PDT)
Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) (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 4159712E6A3 for ; Fri, 26 May 2017 08:45:33 -0700 (PDT)
Received: by mail-wm0-f46.google.com with SMTP id 7so130898215wmo.1 for ; Fri, 26 May 2017 08:45:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=M1uBwcxrtTOPRFCTI2+g4WWOUwhUtEuj5aZZKD1PHvI=; b=tOnQpJjCPWuFYtrB9653Q75v2BodjvfnzOzqf9p2NttM3i0+/wyvREArzd8Hltb2Kb 47U91m0VbScewhuNJ8X+y4YPYTGYB6EhN7VGvZ9AMcERnzklGhpYteLPtLr37SxVNwAp ohI7Lja7VOZgyDPWy4+1vH6XHBBehiIqOIWTrt0u9StjnG0Hgxr4B6uY1mVnm3fiwcy1 ZMbmG9ZgNRs7noQV2kObfw0M1PyRf9iFNM8mbxeLuiv+cb+Kuv9VCF+96VQtSx/05O13 unB+WflAIWZlK4BKYSlNh1CkvpGd9caaI3+DneH2wauAbUusiuBT6wEzV/Glxy7nmZrd bMMA==
X-Gm-Message-State: AODbwcB7FgrbRmCKuZzAKJoWswZQoaaBehOC84fbtHYxQL+A18ZkjsN+ UzOYAbW/Ka9g7ow0
X-Received: by 10.80.214.215 with SMTP id l23mr2757054edj.147.1495813531674; Fri, 26 May 2017 08:45:31 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:a0d4:a036:684a:8eb4]) by smtp.gmail.com with ESMTPSA id h33sm589906edh.50.2017.05.26.08.45.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 May 2017 08:45:30 -0700 (PDT)
Date: Fri, 26 May 2017 17:45:29 +0200
From: Job Snijders 
To: "Acee Lindem (acee)" 
Cc: "idr@ietf.org" , "draft-ietf-idr-tunnel-encaps@ietf.org" 
Message-ID: <20170526154529.ugnfgizf2vo5nlnx@Vurt.local>
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> <20170525135424.3v3ea3rfdsquwizu@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: NeoMutt/20170306 (1.8.0)
Archived-At: 
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 15:45:39 -0000

Hi Acee,

On Fri, May 26, 2017 at 03:26:17PM +0000, Acee Lindem (acee) wrote:
> Cisco is supporting Tunnel Attribute parsing and propagation as well
> as the TE-Policy tunnel type in an unreleased version of IOS-XR. The
> SR-TE Policy draft is 
> https://www.ietf.org/id/draft-previdi-idr-segment-routing-te-policy-05.txt.

Since nobody took up John's suggestion to create a wiki page, I've
created this empty page here
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations
and linked it from the main overview
https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports

Can perhaps you or a colleague, and other implementers please fill in
the details? :) 

Kind regards,

Job


From nobody Fri May 26 08:48:56 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79EE12E6A3; Fri, 26 May 2017 08:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 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.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8a7z3C5iXAAg; Fri, 26 May 2017 08:48:52 -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 40B551294AB; Fri, 26 May 2017 08:48:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1224; q=dns/txt; s=iport; t=1495813723; x=1497023323; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CwDiWWJxyqU5pKp0dQFt/UERbhw9QhL4gKqhwGe7QW0=; b=D94ZcwAtAs4iHn217mwJnKdsYKyDeemyY0KR7WyJ7KL71qCqOFBzpoFR Qd+T6fussjBpjnFmGLYHXTgdPlTP2tvmv0uQpMhwJ6y2h9FGpeDR138hC OUfILFusRui2ir/jdKmGoTQv3+iid5OGXtVXt44okzGjQh4a0UciGsuDH k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAQDFTShZ/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQ0Hg2iKGJFllXmCDy6FdgIagnA/GAECAQEBAQEBAWsohRk?= =?us-ascii?q?BBR0GEUUQAgEIGAICJgICAjAVEAIEDgWKKhCrNoImi1UBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYELhzGDHYRmgxKCYAEEniMBhx+MCIIGhTyKNYkBi0wBHziBCnQ?= =?us-ascii?q?Vh0h2AYd7gQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.38,398,1491264000"; d="scan'208";a="248424876"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 May 2017 15:48:42 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v4QFmgjo001022 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 May 2017 15:48:42 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; Fri, 26 May 2017 11:48:41 -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, 26 May 2017 11:48:41 -0400
From: "Acee Lindem (acee)" 
To: Job Snijders 
CC: "idr@ietf.org" , "draft-ietf-idr-tunnel-encaps@ietf.org" 
Thread-Topic: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
Thread-Index: AQHS0aHyfjzql++v8E6rbs0uznlaOqH/eQWAgAXjmgCAAWjtAIAASHGA//+9zwA=
Date: Fri, 26 May 2017 15:48:41 +0000
Message-ID: 
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> <20170525135424.3v3ea3rfdsquwizu@Vurt.local>  <20170526154529.ugnfgizf2vo5nlnx@Vurt.local>
In-Reply-To: <20170526154529.ugnfgizf2vo5nlnx@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.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6579C80EB77C264BA51DC3FBF3EE2BE8@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 15:48:55 -0000

SGkgSm9iLCANCg0KT24gNS8yNi8xNywgMTE6NDUgQU0sICJKb2IgU25pamRlcnMiIDxqb2JAbnR0
Lm5ldD4gd3JvdGU6DQoNCj5IaSBBY2VlLA0KPg0KPk9uIEZyaSwgTWF5IDI2LCAyMDE3IGF0IDAz
OjI2OjE3UE0gKzAwMDAsIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToNCj4+IENpc2NvIGlzIHN1
cHBvcnRpbmcgVHVubmVsIEF0dHJpYnV0ZSBwYXJzaW5nIGFuZCBwcm9wYWdhdGlvbiBhcyB3ZWxs
DQo+PiBhcyB0aGUgVEUtUG9saWN5IHR1bm5lbCB0eXBlIGluIGFuIHVucmVsZWFzZWQgdmVyc2lv
biBvZiBJT1MtWFIuIFRoZQ0KPj4gU1ItVEUgUG9saWN5IGRyYWZ0IGlzDQo+PiANCj4+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcHJldmlkaS1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBv
bGljeS0wNS50eA0KPj50Lg0KPg0KPlNpbmNlIG5vYm9keSB0b29rIHVwIEpvaG4ncyBzdWdnZXN0
aW9uIHRvIGNyZWF0ZSBhIHdpa2kgcGFnZSwgSSd2ZQ0KPmNyZWF0ZWQgdGhpcyBlbXB0eSBwYWdl
IGhlcmUNCj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9pZHIvd2lraS9kcmFmdC1pZXRmLWlk
ci10dW5uZWwtZW5jYXBzJTIwaW1wbGVtZQ0KPm50YXRpb25zDQo+YW5kIGxpbmtlZCBpdCBmcm9t
IHRoZSBtYWluIG92ZXJ2aWV3DQo+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kv
UHJvdG9jb2wlMjBpbXBsZW1lbnRhdGlvbnMlMjBSZXBvcnRzDQo+DQo+Q2FuIHBlcmhhcHMgeW91
IG9yIGEgY29sbGVhZ3VlLCBhbmQgb3RoZXIgaW1wbGVtZW50ZXJzIHBsZWFzZSBmaWxsIGluDQo+
dGhlIGRldGFpbHM/IDopDQoNClN1cmUgLSB3ZSB3aWxsIHVwZGF0ZS4NCg0KVGhhbmtzLA0KQWNl
ZQ0KPiANCj4NCj5LaW5kIHJlZ2FyZHMsDQo+DQo+Sm9iDQoNCg==


From nobody Fri May 26 09:31:41 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8734129B09; Fri, 26 May 2017 09:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level: 
X-Spam-Status: No, score=-2.022 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_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=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC2JT7qqouqp; Fri, 26 May 2017 09:31:37 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0106.outbound.protection.outlook.com [104.47.41.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D14127873; Fri, 26 May 2017 09:31:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WjyS8NEUf7UwiPW4gbXIxGADKVWsF0jwZ6GIew/4Qj0=; b=ckvfoWPb2m46HgBdVgxaawAAV59avdlrj67RwInMLjNGVMu+214RTwzO+cfImvqhQ7+rpCXn5nf10sJXvl4oH7gDXY/QqYBkfmixqfOkdQFIfUXgqMqXrwUy89QkqKaCs7yC3IHj+I0VOgHqeD7RfzDim+Nvz+w4ytzEOnkiX8o=
Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net;
Received: from [172.29.34.170] (66.129.241.10) by BY2PR05MB2182.namprd05.prod.outlook.com (10.166.112.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.1; Fri, 26 May 2017 16:31:34 +0000
To: Lou Berger , "John G. Scudder" 
Cc: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net>  <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net> <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net> <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net> <017c08ac-55f6-ab12-9b9c-54f03b570f03@labn.net>
From: Eric C Rosen 
Message-ID: <0a0d62b2-a3ce-46d8-1f1c-6ed9034dd072@juniper.net>
Date: Fri, 26 May 2017 12:31:29 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <017c08ac-55f6-ab12-9b9c-54f03b570f03@labn.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: [66.129.241.10]
X-ClientProxiedBy: DM5PR1601CA0034.namprd16.prod.outlook.com (10.174.111.47) To BY2PR05MB2182.namprd05.prod.outlook.com (10.166.112.10)
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BY2PR05MB2182:
X-MS-Office365-Filtering-Correlation-Id: c3b335b0-b58e-4336-04cc-08d4a454ad42
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BY2PR05MB2182; 
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2182; 3:pJ5lcLzGTfvr8AINTOCaV4vQou7AL/3NFLSPMF2ntFmgMmtkJbGfCmjVw7rIGBVea5+ydhj1UZdS1XC9M/7vOtd8OOyNKKz2uOXfD1XA4+lqZ5+La2RXXirU5aXkOp/jVgCQdqWCYSwqFb8I5EIF3BUMqp/iMQJh+2yK0vgcTMczzrB3r38wulXV4NatkXdY5QcVJf9V6uVttp0eAls3HFKBrxLWX2glbORlntBzB3M9WMGtXCNG3g45/MnrBV0A1nbctWHAc1WbZt2z4EDb5ZSHhXHf+FpGBuIGnCj3204cUWBXrOhdf1RHCXv5IvhJmXD7Zg7X14klbE7cp2NynAvB3K/V6bIg0+x4vxKZeAA=; 25:VRPmI5XjXbUfcrPB89iq+VjdsBb2cTjadpGIuXhPIgFi+Lh4/s3uHQZHTI3YrptAkpq5+jYO9GYNQF7LpBpNLdmJGdAFIEtQ4E69XUOkTb+mY3jlkiEkBN+U8rIJzIBfLAY0ch/h0oARPDXIMJsJofd/ri4C3kWRb2mBDbVJ9+IR9j9fKb6BxSBLZWZ30rzA9/Z3TmNQyNEllWKetxkI0A6q69pRj85UpnR2scLaegyfDXMecbHlG7HlbRe8q24UsORjjTWXY5zefcpk9G1LkXKu69FXAWY/T+fx5ywJnXzj+wKdBS8a8Rz9m6Yz+sUqt9rLyA2VQDTZsMXV8qOWWxA4O2uwEOSxaCOYHYohWcIFrGFUNWfjiJtNluLclGDOyd3Xu1oEOZ1iwg/RY+flPEcOrnDVcfwwbPQJAffJT2x1cct5O6ErsJZ2fiU8/o6xkQSX/hDCCqA30M0MDNKsNsYQpRXwy3t/FXhG0ntgWlE=
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2182; 31:doJZg+2oVqfUgi9oxF1SPTcUOTuF6guj97QJXLnHsU1fiEAivcmUWncMu5yt/4K+5JcUJi1bFEF9mIxJUTKrmDwCD9frdrRdDjQadFgTujxg4r3VWwktCxDAtkxBhYmbYBOGcFpwWdztZT7olE5ix+raooEI5nxrBGbhGS3jDW2Y7yng9GDHi1SqG/QyLB/owG3ZxaaUAeT80NNb7zATlhNdhkk2gAmMDWoMEadLKQo=; 20:Mn2b6TAjq8YQ+sQpUhQNUKU1qBIryGRdJONIluK3+KC664H3DPIP8XmLTT/GSjboDxNnVi+ho8g9mlgj8R7ZFfzqv10vnX7s6XDyNiWWXisKssmuX9DDQY4XR4k0LgyGzyim182qFOZEh00Sz8+YWdElM+NrurMNQB6tFOc+f9JIXpRBg4z3vejrti5Hy9ir/7FwtEXYPaF9sJoZJzMoXB9nKuPcZg8YAVk7B9TOXJlDG6wHLb6c77j5iMjOwE+Yumw2VHQ8r9IcZhYt1Q2EbXibhkG7N7NTPhQRuX1Onuz83dQxh+ZRkw5VPSdlKDnown9/c0JQ2CcaUhNf5RKHjIoLBXdbpL8awC0tSUv1Ww93/NPv5NbvfDCNW2+t6JxFkhh4O2rlia+Z0ImyVzty5C6yR3JcQ5XWscUvxhSNYmC2VaVQwcCrCkQXKaFHlxkDNhSUmYysT30wOEhbvwzL0RbNkF7plSUPrssaNf9lzh4PIK896vws1mxfqa0xJzt4X0ap/1aRV7yc/+5YBW6FHpB3jPELRw/WhML1LsGXy/dJHww3rQy2PU6dcYoh9nwhF0PfCk5lqgfbQoqWp+Keyw+zX1ru2QxvmrKKZOGKPRM=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:BY2PR05MB2182; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2182; 
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2182; 4:xlCEnEn9DjWUXms5xCuRqwlYdRdcESs4TJMaL3LxOun7oTgonr4Lxt/9YikPsKy7mzOUu4s9MOX+wjHM5GVIi5MFxfPEQSwzesZ3yJK0xJplU9xOIHy9N/FqjfsQXxFBuDToIBXGqh4qDeFpTz1ywgH0Afu9/8lt5cx0A7IeXYr8LFN7aSJ8SxRUP7Ty9r3PaXxF3hUxU217B8xFG9bjfyTvDD6MRAzQUL3WGWj8H/OYwEQZfmI5gVPD3icxSgnuhOxv9K8ymv5EXL2Xab7hqPBFXitqW92J59Mmy4SYJknzziiZaXGoG3UoLDhvcTInTfWm88f5BrNhqcBXeCgxQ2FrK3Le+261ukOJdhLlhjLD6375waTQ5YgpHhMiK88IQKsH+3Z8fQfTRZGFzQSFWZ44OdOx4QPhZpd0v0swZ9ElHVKdTcvcVnjhaii35728oH6qZobWng/T3p9fZlmH+MlIGW5vE7Dgu2sQhUX/ddk0WHt7f+CzipS3oIxiUGttq4aG3EtpWbnhfg02ErcJkhzkEuDH0ASJb23RmmCSb2KpYfJ5A2NdWhxGkie7pvOZrY+hYH9ACA3xPBip1MF0IL4V2oPMllpi4XEeqPd+brxyluy/WL0A4YJg4N8u17/fDgZD9KMNjtWxtd8VzGsVFQI2DlzQpXSn+tRPmKP+7KygbZHj/VJTtagQDF1s56lTOgTGEQmsuE+afWusM8Nonu8jt5rr3UQw8H757w09971bLD0hVMEUuBhAKFH098x8Y9XpUf4wsHlWSCJTdu3Okh13Z9NLgMDrvFxM+uXMIVIHEauJC2KnDnuRkrlnz8OQ
X-Forefront-PRVS: 031996B7EF
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39840400002)(39850400002)(39410400002)(39400400002)(39450400003)(39860400002)(377454003)(24454002)(189998001)(81166006)(54356999)(53936002)(76176999)(23746002)(478600001)(50466002)(50986999)(230700001)(2906002)(77096006)(6486002)(6246003)(31696002)(90366009)(6116002)(3846002)(4001350100001)(8676002)(5660300001)(86362001)(305945005)(53546009)(229853002)(7736002)(33646002)(25786009)(47776003)(3260700006)(65956001)(2950100002)(66066001)(6666003)(83506001)(6636002)(64126003)(4326008)(65806001)(230783001)(93886004)(36756003)(38730400002)(31686004)(42186005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2182; H:[172.29.34.170]; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY2PR05MB2182; 23:3f4zHGOnTQVIzkI0XdIfU3+APUVhdq9PmEoYZ?= =?Windows-1252?Q?FZYBuTQfF5y3oN9oA+UjcatrqtQ3j2dY4lsQKIvsGlIclU8gABuZbYrj?= =?Windows-1252?Q?rnOrohPeLXP+TW6F2t6EQGkMK4AANL4ywRiyDqv+Fc0bIa1t+HBALh5N?= =?Windows-1252?Q?jFTvSs9VeFJSsxDiolierUesd2NYfERcBDUs4Njf+6oHv7w0aftOAlWy?= =?Windows-1252?Q?1MiqlGFZI27sLObQRT4Ra/ShByEynGMWKUbynmCHV67nSpZpHDuh9vug?= =?Windows-1252?Q?/hAL3b03m1wMRXaM0vSuq8w9hVjLZ9mCnBsPwrhaJMdOeNAu710RZgxt?= =?Windows-1252?Q?XO2CWLor7syVkTp5mDvSo3Q9Q9AMN/LJ99yXBwuq1tV3u176bHBu4Eaz?= =?Windows-1252?Q?3ByZ9XCEBlER/+5o9sZG7QlOOBfAtJHQ12nEoexI9StYA9rAtAo4wrjc?= =?Windows-1252?Q?P2FuQ4Go9uGER0y8HkBIOQiuHT39lpMmMt1v/TZUmV/TDQwRkDH7WZuM?= =?Windows-1252?Q?LMi4xDRsPIBLHu6ruwjM9TJZKQ5jg7kcsII22hOQznJYSvdlRBCFaKCN?= =?Windows-1252?Q?xJrvXiAKOa3tivVfIpArFeOSiIPeY/spy34mklsjoL6eZRGr8EF8Aa5M?= =?Windows-1252?Q?+C7LUUOH2DwHkjOm6+dtQfrnz+vjjRDXqbWkjEL0YLREya7t2PsfSnUW?= =?Windows-1252?Q?F4LAvEEuYUGUzs7CSbuNNv0JhqIAaJdQ3TQ4FYli4On/TOo9d0ut9xPh?= =?Windows-1252?Q?1BuD1BiiW6XCwojKGMiKObrJH2tmpNa0gqIxOV/I/ysQ2Wjl6zWIQL5/?= =?Windows-1252?Q?tJ98nV7iW3rlLDiIaSs+40nOmT/6RsYKu8j12lkccBLP5WhM8Gc2RvUb?= =?Windows-1252?Q?mZauM2looFpaCc3wV0CX735p+LWDH7yyh9EhkMIWmCWNusgm5sFZEYPM?= =?Windows-1252?Q?+4Pcw3lS0o2OySxjDwWzvguUbmFfo/4U0a1yvE2HlgLwAdwL/d4EsZhf?= =?Windows-1252?Q?mgpgsg1jES7dHWfX/JK7aBVxioVegH4jWSHLh+7KGamOlrvwFXBYwf1I?= =?Windows-1252?Q?ouga1DQyvv2G5tg0NX3oTbwbBKzW577Sf9ALuRMupVMJ4G47yR95SpeU?= =?Windows-1252?Q?g6OJKsgV5TA1kalY+V6cFcMAEhSMnnU8ohcaoygS72g0HrLxTw6ggMgi?= =?Windows-1252?Q?1ImO2L6QDHRzUHq+8htxjwvOMS/iNjizEGif2yxMYE0eieyMOetM7p0i?= =?Windows-1252?Q?sImJGysreJVpNbKr3HPV8bUT4pYlc/qVsXVTT+6RnZKYPDfPjkrNg7dS?= =?Windows-1252?Q?6ntpvEy5w5CqoTdbYImEtms3I83zZK8+Shrndi7c4dPokWhlMKpiJSgs?= =?Windows-1252?Q?q4MkQmPXLjKtw7n9tSLFWNdXUH1VJS0aqFkVsllkwREPypLNp6taa0Kj?= =?Windows-1252?Q?TcHQI7MwrYJEBjiifaIfQS/5xMp7gl9s233Mm1rq36ZZ4B127zwH5x0W?= =?Windows-1252?Q?UznIkQ=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2182; 6:Z6HAcSzzFlsJ13EtKxNmMGoe/MDMEZsTk/7LZ+YfkdMB0wJRftRHy+tNoOCiu5zDF+0U8W41xRi3c0ou4I1YiJV+RzMYiCXDH4Yx3EqrG9evjP+oJ497HpAAdhWrb8NTDNk7GdMe/Xg/PioR5jqWKcP0ZWqG4yGGbJIKUIsArhDwrFzr6IajgHQ0C6rYMmkO2qrc0jetIk9a9N1H49ivquSwUfLa6B/ttcYkXQyyvpdzzA25r486GUxRw8P0S/nY4Z0nDleUTAFazNi5TBCmgIiicyyTUtmpF1wq95VF+JcLYXFBGMXF+kkJGPWFtGfEGd4yg3QTEUb7ZvwYpyyZu31838SkZKdqFdck3vUHGQODbtSQ+d05FtP52jJitmm7qntq2n/kfz+6yu/o/aVIFTBb3/zGH8thcklQrGNqctnBzxQlwFkINqHbbCNUUNLgNnKAxKKTotes1BUCgZ5FExMdTJLA1u83wEbOeVr1SMIat+zTKL28ugy+NiqNPJuKDJwNQrG46pEamm0wqUGsVrFcTsl2pkZINlm1Rmqmw+g=; 5:Ae89hrBbQIBV+t1JH8x2ibcPdP1ChLVZU9DREZul+RmGG++DF+2dVHqaeeJN0v1943QB1Vdq7t0vz6Ruh+kn/2MZQWbUcMT30Dk8H69zdctGKePdI3LGNfrA4nbnytNZ2L/Y1TWwIu18vB5a4ys49d6KgGoJMLZkUmJw5/F/I8Q=; 24:jFEk5VxltmUYIeite1u3mEdJp8pbdNf708R7DHHjzjwOyHPsmgHJGs60sno/stpdvK6ai4VnXXE7e+Zc4yrFETzACqeIFy3gyKa5Q4a9YhU=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2182; 7:rzS7fChoe1+iRVb7NCF87tk6g7k9coh1/9oPHR70NsUbaDSj3W+UlfGBqrJZ9KkZCvtJv6rSDqXbrv+RGwbu1ojMvdERI9B9r1M3n0WBJKVNcOfMTi3VHE+lcq1RAUQ0WRQCx7dFnSjxVZnjKe5ripwlogv6aPO5XfiTbNIRFN0SOxnNgiNRhkO9yz2Gtsl5M35JiXTTKOBdBq74uxYug4H/hb/nCjlWibAhU5nWp2BiQpc1k223Foa1c91Xlc1LRYP+D7/RTpZRxJ8DYM4gN9zpQD8JcmbXuFwy14tdiUCwf+5UYKE9GzWgFMHoUZCWOmQRFEsFz5oPH0YIj8lcZg==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2017 16:31:34.3793 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2182
Archived-At: 
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 16:31:40 -0000

On 5/25/2017 4:33 PM, Lou Berger wrote:
> How about something adding something like the following to section 1
>
>    RFC5566 uses the mechanisms defined in RFC5512, while this document replaces RFC5512
>    it does not address how the tunnel types defined in RFC5566 can be used with SAFIs other
>    than the Encapsulation SAFI.

I'll be happy to add this text.

> Allowing a choice of tunnels between a pair of endpoints should not
> require the origination of multiple routes with different NLRIs, or
> (even worse) the use of add-paths.  I don't really see the merit of
> this suggestion.
>> The point is simplification for an unused use case.  Is your position
>> based on theory or actual use?

As it happens, I was just yesterday asked by an implementer whether a 
receiving endpoint could advertise two tunnels and allow the 
transmitting endpoint to select one, so there does seem to be an 
immediate use case.

However, I regard it as very obvious that you might want to advertise 
several tunnels, along with some criteria for selecting which traffic 
goes into which tunnel.   There are numerous cases where this is done by 
configuring the transmitting and receiving endpoints of the tunnel, so I 
don't see why someone would regard the ability to signal this 
information as "theoretical".

> I think such policies will be very application-specific, and thus are
> out of scope of this document.  A draft proposing the use of the
> tunnel encaps attribute for a particular purpose might well have to
> deal with these policy issues.
>
>> Sounds like a future interop issue to me.

Since we don't currently know what policies might be needed by a future 
application, we can't specify them now.  Of course, whenever it is 
necessary to provision policies, there are potential interop issues if 
different implementation cannot support a common set of policies.




From nobody Fri May 26 16:15:11 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BC9129AF6 for ; Fri, 26 May 2017 16:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 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=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HLRLI2XwTlO for ; Fri, 26 May 2017 16:15:08 -0700 (PDT)
Received: from gproxy9.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 1CF46128854 for ; Fri, 26 May 2017 16:15:08 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id CA6D81E0D1A for ; Fri, 26 May 2017 17:15:05 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id RBF11v0282SSUrH01BF4km; Fri, 26 May 2017 17:15:05 -0600
X-Authority-Analysis: v=2.2 cv=VKStp5HX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=tJ8p9aeEuA8A:10 a=OUXY8nFuAAAA:8 a=vEsP9ymbTI8hwHnHsIoA:9 a=xvb0awyGBXDSmEAb:21 a=QNqTX-DYy1Phx641:21 a=CjuIK1q_8ugA:10 a=cAcMbU7R10T-QSRYIcO_:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tEXrzXDV2EHLpqgLSZpNexYQUVdD9i3ylZJmKrQpMyw=; b=C2uc77fjc57aLMHjGnEUjmKOh4 tywXH+91ISm3RdOOdzQgrY/uIqRYz/PQqrWnOqklucHZxVGt6EiYjKeyQ7zd5LjyaPAPMr9YISwje G2fti/pOmGZd587asRHGepWK2;
Received: from md92336d0.tmodns.net ([208.54.35.217]:58325 helo=[IPV6:2607:fb90:1897:7343:0:32:146a:d801]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dEORh-0007g2-C3; Fri, 26 May 2017 17:15:01 -0600
From: Lou Berger 
To: Eric C Rosen , "John G. Scudder" 
CC: , 
Date: Fri, 26 May 2017 19:14:58 -0400
Message-ID: <15c470a9d68.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <0a0d62b2-a3ce-46d8-1f1c-6ed9034dd072@juniper.net>
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net>  <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net> <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net> <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net> <017c08ac-55f6-ab12-9b9c-54f03b570f03@labn.net> <0a0d62b2-a3ce-46d8-1f1c-6ed9034dd072@juniper.net>
User-Agent: AquaMail/1.9.1-360 (build: 100900101)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 208.54.35.217
X-Exim-ID: 1dEORh-0007g2-C3
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: md92336d0.tmodns.net ([IPV6:2607:fb90:1897:7343:0:32:146a:d801]) [208.54.35.217]:58325
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: 
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 23:15:09 -0000

On May 26, 2017 12:32:05 PM Eric C Rosen  wrote:

> On 5/25/2017 4:33 PM, Lou Berger wrote:
>> How about something adding something like the following to section 1
>>
>>    RFC5566 uses the mechanisms defined in RFC5512, while this document 
>>    replaces RFC5512
>>    it does not address how the tunnel types defined in RFC5566 can be used 
>>    with SAFIs other
>>    than the Encapsulation SAFI.
>
> I'll be happy to add this text.
>
>> Allowing a choice of tunnels between a pair of endpoints should not
>> require the origination of multiple routes with different NLRIs, or
>> (even worse) the use of add-paths.  I don't really see the merit of
>> this suggestion.
>>> The point is simplification for an unused use case.  Is your position
>>> based on theory or actual use?
>
> As it happens, I was just yesterday asked by an implementer whether a
> receiving endpoint could advertise two tunnels and allow the
> transmitting endpoint to select one, so there does seem to be an
> immediate use case.
>
> However, I regard it as very obvious that you might want to advertise
> several tunnels, along with some criteria for selecting which traffic
> goes into which tunnel.   There are numerous cases where this is done by
> configuring the transmitting and receiving endpoints of the tunnel, so I
> don't see why someone would regard the ability to signal this
> information as "theoretical".
>

Humm it also seems obvious to define a way to advertise changes in number 
of tunnels and tunnel attributes without also having to re advertising all 
the prefixes reachable over the tunnels - let's do that too as it obviously 
dramatically reduces update processing.  Think of it no need to advertise 
those thousands of prefixes just because some tunnels were added/removed, 
right?

But wait - we did that and have now decided that the complexity of the 
processing isn't worth optimizing such advertisment as *in practice* it is 
a corner use case. So, while I agree that supporting multiple tunnels for 
the same prefix is a real use case, I still question if having a second 
"optimized" mechanism to signal the tunnel information (in multiple 
sub-TLVs in the same attribute) is worth the implementation overhead. Note 
that the " suboptimal" mechanism will still have to be supported anyway 
since it just falls out of the definition, and also supports different 
lifetimes in tunnel endpoint management.

Lou
...



From nobody Mon May 29 12:16:30 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA86912944B; Mon, 29 May 2017 12:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level: 
X-Spam-Status: No, score=-2.022 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_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=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAkgNa0wEr5X; Mon, 29 May 2017 12:16:27 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0092.outbound.protection.outlook.com [104.47.38.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C051212944E; Mon, 29 May 2017 12:16:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nFQjYJ06VEy8hmuHz/LBONC/RtwFT2NuTb3APJfFeKs=; b=WelpT7zWOwfTOQCrNl/GKrEZT34g+XBQSDb4wnToR41BVy9SPSjU8Ffyy2chFG3KIFTar9inLpZ3jSQQUnhQE39X72YY6fiUwMYgjgNpnOAKPFOcDepruM6pIz06w66BZ9P02pFnhhedt63xskQzNrn6pqBAfbuMY48K2u+4V+o=
Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net;
Received: from [172.29.32.7] (66.129.241.10) by CY1PR05MB2185.namprd05.prod.outlook.com (10.166.192.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.1; Mon, 29 May 2017 19:16:24 +0000
To: Xuxiaohu , "John G. Scudder" , "idr@ietf.org" 
Cc: "draft-ietf-idr-tunnel-encaps@ietf.org" 
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBAA236@NKGEML515-MBX.china.huawei.com>
From: Eric C Rosen 
Message-ID: <0a93a6cc-7d53-edf5-0847-abed1f88eb07@juniper.net>
Date: Mon, 29 May 2017 15:16:20 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBAA236@NKGEML515-MBX.china.huawei.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: [66.129.241.10]
X-ClientProxiedBy: BN6PR08CA0058.namprd08.prod.outlook.com (10.172.144.20) To CY1PR05MB2185.namprd05.prod.outlook.com (10.166.192.9)
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY1PR05MB2185:
X-MS-Office365-Filtering-Correlation-Id: 1dfad354-8510-4b08-12c4-08d4a6c732f2
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR05MB2185; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 3:0QDBuYQ3LrE1kkWZ8vAUckUEByYL7s722uLA6iUl/CUrm4eOMo/oASoKI8Dr5cON/u5sHKMcbpz1nbo2ArPpbkK1+eCnUska2ZtYufvM6Esf2/HZE5XvEV0sFVM1WAZ9yeo6q4gnzAbxyc7e8pdB5uaPX+vn3IkTv+2EUl/Dhxw+nGPXSpGZm2HIxn5ftXGTPIuyU55kKiopEjjG5YUK5P0sMpgVGZb/8zFqzVfdg5kkJpoUhcK+/8OG8jjSWv66uS0bYzly7ZdfCgvF9LqhecYbcInvZ7NnknztZWAFTdmeNmOUu9WaapGqcePcrHwN52EQ/+uTedyaLGPjRM6kY8/aqakwZ2uPzOaH9IlSVrQ=; 25:tlKjVMZ7eoLEkY/QfkV25VfDt/o9t0ddn1HvyZAQ73mx8WupakQ4AmAmmF5Fq3MLAu2VmN/SF2swIfn4jmomPGvIs23EvIPhb8APn9nASkEjs0+O+2BV849cIytkBFAO8lAIw1tUFrUBgEfeCmwKjDT/De5a0fciKdogLTtN5OVCzHy2aT0G5Gfnxk6jJQD3HVb1InVMYafaHH/9uM9kiTqPKWVNFxkfq4vM8Z6d9m7BO7A+/LZq5G2tC5e8SupPOFou0Ks0ZFJCNha5kikytThziYyuASgmfAD6UqJCYfGZLyd9YqU4gpGRP7kWWlDLwPQ3O6ZvYv5FBfpzxdyZcYpAySbFx5F3zBQCctZ8wUJtI7O4bkNt+gJMmkgNO2lp+q/Y1FKN0zaKThZugrxQG/K11CfnRyXVEQyTVSqrhAywhrOkILagIw6VzOc68QQUc6eY1ob3UiULBTLmr4XoHQ3aBNrJ3orjoPb9RnZpyXY=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 31:XouK0Xzfxlid09heyhGoEx6FIOHmxvs4eWgKRRbeyhJia2qL74AO4A66gGkYn7jv8sV4Orcu6a/HmmaaH0PdQQRLCUsTqbpJ+yixhvjyTz4B7niQF2NqOEc9caNmC490DN0VMOMRrQhIP4TvsAADdeJLKrNsQDcvuGi8soeVtcaqw6rJ0Bi0UPUb/yy1sVCvV5tiUwud2ypSs2iwqIhvxlBegssEFg0zHk9g8VaRg3A=; 20:tHj8m/Hq8r0klyK0SwMI/16xGND86qrLfu98pY8hw+S7WRBdXZgRynnDVqwNNcIbI8snJ7A1zZ0kcCJcv3HXiQZAdLtyZ5mjfC+UkmQZil2AOL/lPvIDRt4xkKbhJ9ZmSUbUxQkTx2syoFXxelVA5YDPeVUtEWmKdIhesbvDlrDvYWreoMw2BixwEYRX7FaYM3I0S+Qmwz8nPvpJEgimPEv3Dv+O0vFm5F0yfq6Wn6vm40ix421tYRNvz5MQTq4y6rk/lCKGvdiOuoXOyoMOazrbYj+LO3U+RX0i+0a3dBSLRMa51uHjf1kD4sTuqGnebxQVj0KheMaxKMX7RrGQ1baMI9H9mQuJAJZdu2KKmAqoKmjh0XpDJti+tnwlyKR5/YToAWkS/GCe8Ila6dAew046XAFUYdIFkboq/XmGTgj95M1boNm2dQFr3KLbWD3bGNiEuFifM/ddzOpbeVb2B8Ne7xWFGkmqL5A1kRGPLwDX9SOdIQiTiUlxae7EFkHrtzJyLHhX1OfGTyHevTGLfx56BqsAjqQNp44oOjMduBzfOGIqvTYpkCuF7Xp3Tl6eVDPVLMnRac/cUf1lnIC42ZAU67nO5aW+sGpRc0yd76o=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700073)(100105000095)(100000701073)(100105300095)(100000702073)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703073)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148)(100000704073)(100105200095)(100000705073)(100105500095); SRVR:CY1PR05MB2185; BCL:0; PCL:0; RULEID:(100000800073)(100110000095)(100000801073)(100110300095)(100000802073)(100110100095)(100000803073)(100110400095)(100000804073)(100110200095)(100000805073)(100110500095); SRVR:CY1PR05MB2185; 
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1TUIyMTg1OzQ6TmNIV1ZpVGxGNTFYVDhKZ2tLNmRpUWo2R3lK?= =?utf-8?B?a3pObUZGY1FhL05CY2kramt1SGk2WFN2ZEV5Q3RmTVhVN05UNXRGanBBZTly?= =?utf-8?B?ekhqNmZXRERMK0xDM25yQ3QrRzM2dDRORXU1ZGtRVDdLNi9tWHZrMUgrMXZ2?= =?utf-8?B?ZGxCSmMvcS9zZXVlb1NaWnliazZDNzZHQ295dGNCSkUyeVVtWVJyZjlDeGsy?= =?utf-8?B?ZGdFNXB3U29WWlpoaEg4MGNNdEM5WU85RWxmSThTMU1oZFQ0TDZITjVBcWJ4?= =?utf-8?B?MmFCb1hGcStDQUM2cGdoS1E4TnBXSno3VVN0QTUwUjVwT2pwRnRHaXFUeHow?= =?utf-8?B?NU8yNkxRQTBQSnBtbFNRcUdlZjJCeW1UdHhwU2JodmVFSmptZkR0QWNQQ3Rz?= =?utf-8?B?aDU4VUk4ZW9YNzRtN0c4eE1ZS3BhbjFrOUxMUjdPT1pDNW1YMGxmQTBrMnV1?= =?utf-8?B?bGZ3cHJ5UkhJT1JSS3M2UTY3NVgwa3ljMitpbGU3QVJ5UDZuRlFodE5JaFBF?= =?utf-8?B?aEdwNXR2VngxSXlTc3VUMzU0TWdnOEdxNFFjM2IwYTNmODIrWDVhT1Z0YnRn?= =?utf-8?B?RnliSWVzaW80TDdrNlA5N2RhcHg4OXVyUHVJc3U2RVZuRmtsaWk3L2RoTmlN?= =?utf-8?B?RDlaUjBacU1jcGlQYjNqWTVhbC8rcjlqTUZnbXNTdFV5Vm93bXJRY0gwOUJa?= =?utf-8?B?a25QdnFRaGgxLzNHSzJObHVxWnJqRVRNVzg3akFKM2pXaGx4QzlVNE9ROWt4?= =?utf-8?B?VTZFZFVCZkxYb0VnZ1NoVFpPWVhkT2gzYitwNDlDZGJhTzJyR1hYMXZ4cGJk?= =?utf-8?B?NDdsYllIczJTU1F4MFJKV1dXQ21LWnlMaXl4c1YyV1JrQVl6b0Y1aHZQaEsw?= =?utf-8?B?cytzVGZPYVd4RlAyZTlIU3JrbWtEek9wZUFyQURGZDdldmcwRjFCQ1l4ZGNk?= =?utf-8?B?czIyZnlHVUlOZit5c044Q3NzRjdrR3c1Y2ZxQnh0dzhmek8vVDFOaHF0cmN2?= =?utf-8?B?NG42bHBMS1gxaWpMTHRPbEZQRXNGN09CRjRsaDlIUWhvalJLdkdHWHcyOVhH?= =?utf-8?B?ZlJmelhVWnA0SGlMT1N1TFpucXQzeFNaWjlQelVsZUZ4dTVldzFJdGpFdlp6?= =?utf-8?B?eXJpN0VmeEtqZTRXcHpnbkwxTFNxaUJtZmpMbFU5TFVYSUg5SmJtaEE5cy83?= =?utf-8?B?YWxtQWFMTWNoQmRyV2lMbGVUY3YwSXc1dWJBQUlUV3hrdjJqc2MwQkJRbDFw?= =?utf-8?B?Y0pISE1zMGhaVTEwUjh2TWpab21hY1BSUzUvSXBkQndVRnJ0TmFHUlVCUFU2?= =?utf-8?B?aTBJV0ZvckcwTFlRNmt4ZHlnWWtUVU1BSjkyNUZNVXpCNkovZXo4VVkxNTEz?= =?utf-8?B?WHJlUHZpVExGTUpJYzQyc2NyUm0rWE1rNktjaXdsZlBnZzNDTTVDYlFXM3JT?= =?utf-8?B?WFVXdlRrMDBtOXd3YVJlaTNYM1hRbnlmWStveVAvN3FqMzZRd0szaXRXZGdu?= =?utf-8?B?NnNIcmlaTkxaWTdyUWhJNm5CY2FmdWQ0RVVkcW0wQ205WXJGRUJaYW1iWTJX?= =?utf-8?B?UVMzQnRwUzNCSlZPWTFvb0JuU04zZz09?=
X-Forefront-PRVS: 0322B4EDE1
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39400400002)(39450400003)(39850400002)(39410400002)(39840400002)(39860400002)(377454003)(24454002)(76176999)(54356999)(2906002)(50986999)(31686004)(42186005)(7736002)(53936002)(83506001)(6246003)(50466002)(6306002)(3260700006)(53546009)(64126003)(25786009)(81166006)(478600001)(305945005)(38730400002)(4326008)(23676002)(230700001)(230783001)(6666003)(86362001)(229853002)(6486002)(2950100002)(90366009)(77096006)(2501003)(189998001)(224303003)(33646002)(3846002)(66066001)(4001350100001)(36756003)(6116002)(5660300001)(65826007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2185; H:[172.29.32.7]; FPR:; SPF:None;  MLV:sfv; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1TUIyMTg1OzIzOnlyR0VUdnBETElFeGJIQ1Z6YjUxT2R2ZUhG?= =?utf-8?B?M0s3TWVHeldtUFhmMkJ3NUpXTU9ueE1tRUhadlFsUVBYQy9zbWRKWHY4Rlpx?= =?utf-8?B?c0V0ckFNeGtGMmxUbkhJMzFzbkFmTEgyaHo5SnNMUzVPN05Ha3J4aU9WbG9Y?= =?utf-8?B?cTdJSWdwMTE3d0xQaUUrS2M1NmNqSVZneU5tL1JwN3cvNkJNb0lvcjUwYkZh?= =?utf-8?B?RmZTc1o3SmRkRFduWU9uSnN0bWI1SCtRWVN4SG51SHhjd0JoS1l2Vm1KN0NH?= =?utf-8?B?cGJQTnNaVFpWWC9qYS9td0pud0NRaUZLQ0Jab3d6c1pmajZ4TkQyT1U2VXpZ?= =?utf-8?B?UGhOai9ndzNOY0Z5SjR0NVlHRFNmSEJFZ1dORHIzMy9hS3JZQ2E3MHlCaDk1?= =?utf-8?B?bU9uS3ZPUG5menhEVmpJRlZiTlhCU0xQSDljaDZnQ2JTUnBPLzN5cXRxaGZn?= =?utf-8?B?Tno3cFdvVkJsaCtwQnM2My8zOEl1U3JhL29lYi9nVGFpeHZiVitnT003azk4?= =?utf-8?B?YWd5bTEzTDN4Zlk0MlJYVk1wNlRHeTVKTzNUNW9KSW1ONHE5d2FkQ2w1bytN?= =?utf-8?B?RVJRVTUvNVp4Z0VzaUdRRnpubVk3T1cxeXlTRUNta1c3bFpINXAxU0tMYWJt?= =?utf-8?B?S1hsR2JDYXRPRDZjS0l1Vkt1ZG1MWFkzRWZVMzUvcy8zTkhCcFNaWUYzdU55?= =?utf-8?B?eEFxenQ1dnViUElKS01sSjJXSERnTUtXcmVYd0lNV25nNS9sM2NPRHc3QjUw?= =?utf-8?B?eHQxa3NrOWhLdVdMQ20rNnByRlEvY3FOR1pzNmlMZHcybWdsaHBNN0RoNEdC?= =?utf-8?B?cHAyN1ZZUHI3U25KM1hsQmUwSDFBdUU1Vi82aHh5TzAxR3NaVEJrQjV1M3pO?= =?utf-8?B?MjNqOE9JWkVidTRuQTdheG9NTXBhbEZ6dktUcGNCSXhuQUpRV3JiTUJHanA1?= =?utf-8?B?WWJJc2Y1UXdjN1lwMmxZaTh3VkE4emxJM2hWa2FHcXhCdldWaGdtbXJ5a0o4?= =?utf-8?B?T25ycDFqZitQVFRMRndOWjErWmxXNFp5VkoxaGVQcktNWTBXVFQ4L0xlRnlK?= =?utf-8?B?UDBnbFJ3cFRoWUdwU1B3a2t0ODg5OWdqakxUSjlRYm42a0R5aUZVZ0k1dGpi?= =?utf-8?B?S1dpOFc0R3A5b1hDMU84WG9tN01XTnFlMnV6am5YY3dLK1dUTlU4OGlkUzB1?= =?utf-8?B?MVdrM2t4d3hsMUdNbURVdG40OGhvd3VlNCt3emRtb1VCYThMdWhjZHBjaStw?= =?utf-8?B?eVpkWUIwNkZQODBpY0oxL254WVdOaVZuSzNwbmVhUWJ1QWk5dXpjZkkvaU1B?= =?utf-8?B?THFib0JRamExK05yS2taaGYreFkxd1VyQi9jcEdpU3c1S29qM3Nrb3FieWox?= =?utf-8?B?RmoydS9WTTVmUEdlRzRXK3lXVEZWaHM2d3Qxa1RKcms5MEorUjNEUmt3ajdl?= =?utf-8?B?SWVka0VMeDNDSHNuN0VVK1ozblJJNVA5cUVUdDVqMnJydjJ4dnFOSlpyRm1N?= =?utf-8?B?a09WSEZXRUhUbDBQeTlvbWc0anF0TTd0YWY3N0VhV0tyeWx5WG56Uk1mZ1ZH?= =?utf-8?B?VU93akFXMldPeTROMWpiWjVYK1YyTEJ5V3F4ZmFBdml2OUkvTDdHWWRob0J4?= =?utf-8?B?eG5CWGNHQXlrSHA1WVJEMUZ6OVVnVVlrY1RrWE9DVEFDSlRkLzhFU2IyZkpJ?= =?utf-8?B?UWJUam11UUlMeWlCQXZNV2ZNUnhXalBvUDloQ0kwVVhsa3JSYi9RZHJ0bjZu?= =?utf-8?Q?q207n2U2jQVoNMpI0e7q8+9C26RvNwpUNOFbI=3D?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 6:ikEYomt3EQ3UhFOh24nW+Oin2Syrpyn2CbcyH3KZ7s48MdAqbRQRjWtOvGQnraRim0jY7JHGgCzbHxpZE7KoescIKsbdnmBxzKFOCQOKPAOAkyJaZA0cWQ43WgHBYta9xr0Qx7CVFZHwrVI+bXr+0vE64h0lFyJfEygdak3Ps65QLjY5yretFnVwVNHyT3N+lHDhfC3qIEJ8wlYkbXQer3SJVTAaM1CehhoWTgVXPO3kHwY/60YyFWr8AjPxwlWGlNm0mIZBY/tM1LSt+0STPgc7//Vkz11KVC/9dKrxzkokqUG/9lvff69IGUc3bSgOMXjI87z69lNdmbxTQZB9o4gl/RtbwcHQoTeiTBR5YwVi2nM/gH2jXEB0pf0X4Nmriwt64AcColWPUvPtd++xu/Cddn9NkXhOPWibQukskTzXWhF/4eyLGytOlhW3VGjS4ZTJtFnQeYULl/v1pqjjYKzM2wRLH6z1M2gp9VBM3i3/jRnwguAociH3M46bjPftOg6IEZfsexUSTKCNxWj1FBYDNyq9XXiR+4l1+HvtaQY=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 5:UQm1a0cevkXzSp4wOMXP/mBuhuYn9b8Ewj9HhN89FyHyGwUzR7wqOHXdb4NVNCzWMiJrM/jFwV4gq+X8kfBorgI9AN2RsBmGUvsFxzxDL+0SQ7I9r4dT42Ya9/ue5Q1f4+AD7v9Lp0vkwvqfHNd/psdY2jFm/NE80LB9U766l+J6kX7ow5YitTUjShBDRtJRAbzmwniYv+7LayjRjW8sL9bB8XmTfIIy9rDA1lpS1h0YJGNr/XnlG5zbq6NmRBHmzrrFrSpHtcOFRx7odSieFH62oMNgAVY061yAU4amGy9ap5Fv2DOuBimCtrzw8IvHGFyddKZk6lHz+41FXL3QTao8mF9WlMrwoh17UOUsmSJgLVFxvkMs3xs7NEb5vo4Oa/d8XEauGa0J4IQsTswpjnQhLXnxcsfHydO7BcgtCQM7+2gRYz9+I9aNADvn4V95SofXg56ex4WCdwx6a8ZD4w2dbcXUXnxsudGF6KPks/hpRKQGmMn759zer17cRzVi; 24:N7mbaJsKtpfEaFiRS1QUaYYf/uz7Y0XmpxbGw2wEiTjunbTXe2CYq7JETucqnhWrsNCD8gG1K5JJK4zMfokGRGjCEsI4f5TJFsffu5jmOCg=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2185; 7:0tPhqURJWOtcPnQ6BHslcbvJpBpIqeqWuOZkP1e0k3/yRTHmHevihPvD2D2mnu3WHEVhbkDqjidsAPyE3t3Sqad+o3enBOC/Zve6x4TLQ5sdpuFtBmp0hWeeLKI7YJWmbGa+txwLB5zqvyUVMIjJoHHPu/tLK7X1mZYrTILamSzsbdYcRHK3f8VrzCRcp3c/PBKG2IBa3NZJEyBVNfTNXnOYFECEo/GYltE4azkaiZXzZ4cNNHs+eaQ+3fkBn4lu37rnNLD+pt9G5Ymeh/lIRwT4QLFbWl/Tng/1OmpE9cEzR6JRg5sM6FNJ1nUMhlEN7grwFGCVfJEAZL0MLbCUEg==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 May 2017 19:16:24.1072 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2185
Archived-At: 
Subject: Re: [Idr]  =?utf-8?b?562U5aSNOiAgV29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9y?= =?utf-8?q?_draft-ietf-idr-tunnel-encaps-04?=
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 May 2017 19:16:29 -0000

On 5/24/2017 8:32 AM, Xuxiaohu wrote:
> Since the NVGRE header has a protocol field, it seems unnecessary to add the fake MAC header when encapsulating IP packets over NVGRE in the inter-subnet scenario, as described in (https://tools.ietf.org/html/draft-yong-l3vpn-nvgre-vxlan-encap-00#page-3).

The intention of section 3.2.3 (NVGRE) in the tunnel encaps draft is to 
provide the encapsulation information that is needed to form an NVGRE 
encapsulation as specified in RFC 7637.  If I'm understanding correctly, 
the draft cited above is an extension to or modification of RFC 7637, 
but was never adopted.  Am I wrong about that?





From nobody Tue May 30 04:35:06 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A45B129BDE for ; Tue, 30 May 2017 04:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 bdWoOZqTHU4i for ; Tue, 30 May 2017 04:35:03 -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 32F07129BD4 for ; Tue, 30 May 2017 04:35:03 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id e127so96477055wmg.1 for ; Tue, 30 May 2017 04:35:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=E6MlQU2BCvi6swIc6rq9PrEvwDwIodj6TjNyJFXuI1E=; b=hhXNR/yyD8dM1HO3wzsGFKyEUmfFUy6zdvhFu0A/dMSsAy/gqOuBCyC/yW1NDHi/0a H9FQKWcDFbACASn8hVxUzSTl4S4iDphR9DBbgdOcyCJMbkci8T0GTN1rBrCZppgpTFxv XDFToUaYhbFi3aj4zwaCbzi0NWR8qDlZ2D4S25Rf4ZWTEfvfJOWqP4u6XULpUCqCbAAM vq5XLMeAOMNIPOEEMkeznBVgyTId2tRJOiyX/ZHVvrrfjml30ylSAnUXvfJ4T0cyUOdu /CBvWyGmWCLR9eDdvyYtfOO1Q7upQwrzmkx7NN1Y9D/AGdyUVCByVmCnuk3deI9L+FTd X7zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=E6MlQU2BCvi6swIc6rq9PrEvwDwIodj6TjNyJFXuI1E=; b=riznBsrVwzIt8FO1gnExLFORkD2VDsi/8un9iMZGszZ8pEH1cRv78FyCKBZ1r7II1x Wijju5MNomEsd2Ff5AIT/EJhpXs8pOYlw8v9VSj4MGr+skLqvldcRP6lrvD/o/ZjkRlU 77+uOCcSr9kHlQNhGZfW+qKbjuJcmR0LjjxVYKpjhLd8EByfmTQGyOqfqBeON1T+/UAX 2L3rZ5WGyaYyuhJiQodr0r0S9DMGVZxE1san2mKcjF25xy83xB27eAXhDiRj/q4COXoV ROUD/yW239NQygWbdPYUrUschu6nrz3JXiGKohMlr7KeZ0nbc/tZs3kH2qKNIP2BoLQE K1Pw==
X-Gm-Message-State: AODbwcAiSXEJHA3ewG3LS2IQpLa3MiQHi3+6nKWzLVe8EmT8nj58VGpO OTuZcJf3+5oIRgKsZoN1EA==
X-Received: by 10.28.209.141 with SMTP id i135mr1286168wmg.123.1496144101249;  Tue, 30 May 2017 04:35:01 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:21e5:a4c6:148d:8fa7]) by smtp.gmail.com with ESMTPSA id q98sm8351537wrb.3.2017.05.30.04.35.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 04:35:00 -0700 (PDT)
Date: Tue, 30 May 2017 13:34:59 +0200
From: Job Snijders 
To: idr@ietf.org
Message-ID: <20170530113459.pauvpic623ibecj4@hanna.meerval.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170428 (1.8.2)
Archived-At: 
Subject: [Idr] draft-ietf-idr-rs-bfd state distribution
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 11:35:05 -0000

Hi all,

Perhaps this has been covered in prior discussion, if so, my apologies.
Some individuals in the working group made every effort to drown out
discussion of meaningful deployment scenarios.

In reviewing draft-ietf-idr-rs-bfd-02 it occurred to me that there might
be an optimalisation to be made. At the last IETF I questioned whether
the Route Server itself really needs to be aware of reachability between
Route Server participants, and I still think that is not necessity.

OLD:
    This document proposes the use of BFD between the two peering
    routers to detect a data plane failure, and then uses a newly
    defined BGP SAFI to signal the state of the data link to the route
    server(s).
NEW:
    This document proposes the use of BFD between the two peering
    routers to detect a data plane failure. The Route Server facilitates
    setup and teardown of such BFD sessions through a newly defined BGP
    SAFI in which it announces a next-hop's capability and willingness
    to setup a direct BFD session.

OLD:
    To remedy this, two basic problems need to be solved:
    1.  Client routers must have a means of verifying connectivity
        amongst themselves, and
    2.  Client routers must have a means of communicating the knowledge
        of the failure back to the route server.
NEW:
    To remedy this, a basic problem need to be solved:
    1.  Client routers must have a means of verifying connectivity
        amongst themselves.

etc..

Operation:
----------

Scenario: ISP_A and ISP_B are connected to common layer-2 fabric IXP_C,
and both have a BGP session with Route Server RS_R.

ISP_A and ISP_B are both support draft-ietf-idr-rs-bfd-XX, and in the
OPEN message to RS_R they announce support for idr-rs-bfd through a BGP
capability. Since RS_R received this capability from both ISP_A and
ISP_B, it _can_ announce in a newly defined SAFI ISP_A's next-hop to
ISP_B, and _can_ ISP_B's next-hop to ISP_A.

Note: if ISP_A did not announce the capability, ISP_A's nexthop will not
be announced to ISP_B, and ISP_A will of course not receive messages in
context of the newly defined SAFI.

If RS_R announces a path to ISP_B for which the next-hop is ISP_A, it
must also announce a ISP_A's next-hop in the newly defined SAFI to
indicate that ISP_A expressed a willingness and capability to set up a
BFD session. However, since a Route Server allows for facilitation of
unidirectional traffic flows, and BFD is a bidirectional construct, RS_R
must also announce ISP_B's next-hop in the newly defined SAFI to ISP_A. 

The above 'pairwise' announcement style might violate RFC 4271 section
9.1: "The function that calculates the degree of preference for a given
route SHALL NOT use any of the following as its inputs: the existence of
other routes, the non-existence of other routes, or the path attributes
of other routes." But since this is a Route Server, it is perhaps
permissible to add yet another crime to the Route Server's rap sheet.

Implementers might want to add a degree of dampening for the newly
defined SAFI to mitigate all to fast setup and teardown of BFD sessions.

Rationale:
----------

Should there be a fault of sorts on the IXP where for some reason ISP_A
and ISP_B can no longer reach each other, but they can reach RS_R, I'd
argue this is a matter solely between ISP_A and ISP_B.

They both were facilitated by RS_R to set up BFD to each other, they
have a BFD session, the BFD session goes down because of the incident,
as a consequence they'll consider each other's next-hop to be
inadmissible for route selection and proceed to treat routes with each
other's next-hop as withdrawn. Life is good.

Should ISP_A and ISP_B have a feedback loop to RS_R to inform the RS
that they no longer can reach each other, what do we expect RS_R to do?
Calculate new best-paths for each client? Why is this useful? By the
time any flavor of draft-ietf-idr-rs-bfd-XX is implemented, we might
anticipate more use of ADD-PATH. But even without ADD-PATH, there is no
real harm in using a few routes from the RS_R when the IXP has gone
split-brain, the way any Route Server is used on the Internet, they only
carry partial routing tables anyway. 

My main concern is that in real life, when RS_R receives from hundreds
of clients on one side of the IXP that they cannot reach the other side
of the IXP, and the hundreds on the other side of the IXP informs RS_R
that they cannot reach the side I first mentioned, this will create a
stampede for both Route Server and Route Server Participants.

    1)  All Participants observe that 100s of BFD sessions go down
    2)  All Participants immediately proceed to deprecate those paths in
        their own RIBs, sending out withdraws to downstream BGP
        speakers.
    3)  The Route Server receives from n*100s of clients that they can't
        reach various next-hops. These notifications may arrive in a
        staggered fashion.
    3a) The Route Server may observe BGP sessions going down with a
        subset of the participants, since IXP faults like these rarely
        are clean-cut. 
    4)  The Route Server has to run a per-client best-path-selection
        process within each RIB
    4a) Participants see churn in the announcements received in the
        newly defined SAFI, and will proceed with teardown / setup of
        BFD sessions.
    5)  The Route Server has to announce the newly selected best paths

Knowing that at the larger IXPs the Route Servers are already at the
upper bound of their scaling capabilities, and many routing engines used
by IXP participants are somewhat underscaled. With the current proposal
I see a lot, perhaps too much of stirring in the convergence soup.

In making the Route Server aware of link-failures _between_ Route Server
Participants, the totality of all stakeholders depends not only on local
convergence, but now convergence at the Route Server plays a significant
role, which in turn can impact the participant's convergence.

Another issue that under the current proposal, should a Route Server
participant oscilate within the RS-Reachable SAFI, this oscilation can
place a significant additional burden on the Route Server since the
per-client Loc-RIBs needs to be recomputed. This risk does not exist in
a mode of operation where less state is made known to the Route Server.

Another note, instead of "The RS-Reachable Control Extended Community",
shouldn't "Enhanced Route Refresh" (RFC 7313) be used?

It appears to me that the only argument for storing client-to-client
data-link reachability state at the Route Server, is to mitigate Path
Hiding (rfc7947 section 2.3.1) - but it appears to me that it comes at a
too high computational cost. Should the path hiding really need to be
mitigated for the duration of a catastrophic failure at the IXP,
ADD-PATH can be used. 

Kind regards,

Job


From nobody Tue May 30 05:32:43 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39273129C15 for ; Tue, 30 May 2017 05:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[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, URIBL_BLOCKED=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 nQwDau3uNVzO for ; Tue, 30 May 2017 05:32:39 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 9B195129526 for ; Tue, 30 May 2017 05:32:39 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id c15so40504395ith.0 for ; Tue, 30 May 2017 05:32:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=v6b5rxZMeKj8bO4iT8jARGmBHdr4Couqp7TaF1jA2Kc=; b=ejccx7CKI6TXxUEtS0L4cAOBOcrD6Eqkif0j4XiI28Z3JiJZdZVk/8+ghZrLXmvMtC +Jog56npcD3zHmT0HZB4yC519SUBggyc+Sk5WvqMkbbRtWrWRGlIySjFTvOvyHfC7hZ/ 0p5tWyBrrCqul7PrwGWUJyOjwbEH/kl8UASDmTBVAaUiF5Izw9X1YTmQqBEQVfqzhqTL IalZ/SqWu2QeX8UoP/cjXPcagvN7RKKJoxIFb6zwkRGtgXEh2oLfqa/WGh4Y6BVkarxT HdKRDAAuQofZCRFClUOoyVL733kJ4AsL9oUKiAgvkbsYZrVUzCKO415S+l54YN3w4RBt uFjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=v6b5rxZMeKj8bO4iT8jARGmBHdr4Couqp7TaF1jA2Kc=; b=FVovJMmB19mgL23uq/JPyoN0lKesIjVL2emO1iGWLejEdCXH6WxOtcU1gddxhNnaQC lP+h2xT3aNFqbR68snrVG0l+Vpd/fo967VuiagEbOA6vdXlvyNY5z5mXpP9auGKMYG06 KPM4fwiKDpoIPYq4VtoD35MmgO3Lehp2u/7aXjKmQbMaZW+LHP0RnOoGR4uxRHiQpzhM aovuzGYGDS7jAbxKYLyEFBUjEbDcaPsjVD7UY1RZ1koHUigvzFFaL+gWjIDV1p5tBZxY Q9xajchSJhiFZGtKbt8RqHqEE2t417Lnvfa1A9ZHnySy7pLotqPIkFQdX7uh+UiLBXei 3zqg==
X-Gm-Message-State: AODbwcCH7QD1pC4vJoA23X2asxelpuTK+m1Ow5PjorKnX0RTj4hbXEho lMaiepq1yBt2uQJT2uc3/uclqkLxtqL9
X-Received: by 10.36.121.22 with SMTP id z22mr1574792itc.59.1496147558976; Tue, 30 May 2017 05:32:38 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.62.24 with HTTP; Tue, 30 May 2017 05:32:38 -0700 (PDT)
In-Reply-To: <20170530113459.pauvpic623ibecj4@hanna.meerval.net>
References: <20170530113459.pauvpic623ibecj4@hanna.meerval.net>
From: Robert Raszuk 
Date: Tue, 30 May 2017 14:32:38 +0200
X-Google-Sender-Auth: uHjnqGLhBi3r2-k0-m6zRLndzTo
Message-ID: 
To: Job Snijders 
Cc: idr wg 
Content-Type: multipart/alternative; boundary="001a114a9e6cc8d3a50550bcff87"
Archived-At: 
Subject: Re: [Idr] draft-ietf-idr-rs-bfd state distribution
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 12:32:42 -0000

--001a114a9e6cc8d3a50550bcff87
Content-Type: text/plain; charset="UTF-8"

Hi Job,

This is going into right direction !

However if the change is really about adding new SAFI to so to say
"negotiate" BFD between clients why instead of new SAFI basically define a
new attribute or community for that matter and attach it to original SAFI
1/1 & 2/1.

I take that we are no longer sending only next hops in this SAFI as this
would still keep RS aware of client to client failures. If so I really do
not think new SAFI brings any value and I would suggest to get rid of it.

Then we will have nice and clean spec :)

Cheers,
R.


On Tue, May 30, 2017 at 1:34 PM, Job Snijders  wrote:

> Hi all,
>
> Perhaps this has been covered in prior discussion, if so, my apologies.
> Some individuals in the working group made every effort to drown out
> discussion of meaningful deployment scenarios.
>
> In reviewing draft-ietf-idr-rs-bfd-02 it occurred to me that there might
> be an optimalisation to be made. At the last IETF I questioned whether
> the Route Server itself really needs to be aware of reachability between
> Route Server participants, and I still think that is not necessity.
>
> OLD:
>     This document proposes the use of BFD between the two peering
>     routers to detect a data plane failure, and then uses a newly
>     defined BGP SAFI to signal the state of the data link to the route
>     server(s).
> NEW:
>     This document proposes the use of BFD between the two peering
>     routers to detect a data plane failure. The Route Server facilitates
>     setup and teardown of such BFD sessions through a newly defined BGP
>     SAFI in which it announces a next-hop's capability and willingness
>     to setup a direct BFD session.
>
> OLD:
>     To remedy this, two basic problems need to be solved:
>     1.  Client routers must have a means of verifying connectivity
>         amongst themselves, and
>     2.  Client routers must have a means of communicating the knowledge
>         of the failure back to the route server.
> NEW:
>     To remedy this, a basic problem need to be solved:
>     1.  Client routers must have a means of verifying connectivity
>         amongst themselves.
>
> etc..
>
> Operation:
> ----------
>
> Scenario: ISP_A and ISP_B are connected to common layer-2 fabric IXP_C,
> and both have a BGP session with Route Server RS_R.
>
> ISP_A and ISP_B are both support draft-ietf-idr-rs-bfd-XX, and in the
> OPEN message to RS_R they announce support for idr-rs-bfd through a BGP
> capability. Since RS_R received this capability from both ISP_A and
> ISP_B, it _can_ announce in a newly defined SAFI ISP_A's next-hop to
> ISP_B, and _can_ ISP_B's next-hop to ISP_A.
>
> Note: if ISP_A did not announce the capability, ISP_A's nexthop will not
> be announced to ISP_B, and ISP_A will of course not receive messages in
> context of the newly defined SAFI.
>
> If RS_R announces a path to ISP_B for which the next-hop is ISP_A, it
> must also announce a ISP_A's next-hop in the newly defined SAFI to
> indicate that ISP_A expressed a willingness and capability to set up a
> BFD session. However, since a Route Server allows for facilitation of
> unidirectional traffic flows, and BFD is a bidirectional construct, RS_R
> must also announce ISP_B's next-hop in the newly defined SAFI to ISP_A.
>
> The above 'pairwise' announcement style might violate RFC 4271 section
> 9.1: "The function that calculates the degree of preference for a given
> route SHALL NOT use any of the following as its inputs: the existence of
> other routes, the non-existence of other routes, or the path attributes
> of other routes." But since this is a Route Server, it is perhaps
> permissible to add yet another crime to the Route Server's rap sheet.
>
> Implementers might want to add a degree of dampening for the newly
> defined SAFI to mitigate all to fast setup and teardown of BFD sessions.
>
> Rationale:
> ----------
>
> Should there be a fault of sorts on the IXP where for some reason ISP_A
> and ISP_B can no longer reach each other, but they can reach RS_R, I'd
> argue this is a matter solely between ISP_A and ISP_B.
>
> They both were facilitated by RS_R to set up BFD to each other, they
> have a BFD session, the BFD session goes down because of the incident,
> as a consequence they'll consider each other's next-hop to be
> inadmissible for route selection and proceed to treat routes with each
> other's next-hop as withdrawn. Life is good.
>
> Should ISP_A and ISP_B have a feedback loop to RS_R to inform the RS
> that they no longer can reach each other, what do we expect RS_R to do?
> Calculate new best-paths for each client? Why is this useful? By the
> time any flavor of draft-ietf-idr-rs-bfd-XX is implemented, we might
> anticipate more use of ADD-PATH. But even without ADD-PATH, there is no
> real harm in using a few routes from the RS_R when the IXP has gone
> split-brain, the way any Route Server is used on the Internet, they only
> carry partial routing tables anyway.
>
> My main concern is that in real life, when RS_R receives from hundreds
> of clients on one side of the IXP that they cannot reach the other side
> of the IXP, and the hundreds on the other side of the IXP informs RS_R
> that they cannot reach the side I first mentioned, this will create a
> stampede for both Route Server and Route Server Participants.
>
>     1)  All Participants observe that 100s of BFD sessions go down
>     2)  All Participants immediately proceed to deprecate those paths in
>         their own RIBs, sending out withdraws to downstream BGP
>         speakers.
>     3)  The Route Server receives from n*100s of clients that they can't
>         reach various next-hops. These notifications may arrive in a
>         staggered fashion.
>     3a) The Route Server may observe BGP sessions going down with a
>         subset of the participants, since IXP faults like these rarely
>         are clean-cut.
>     4)  The Route Server has to run a per-client best-path-selection
>         process within each RIB
>     4a) Participants see churn in the announcements received in the
>         newly defined SAFI, and will proceed with teardown / setup of
>         BFD sessions.
>     5)  The Route Server has to announce the newly selected best paths
>
> Knowing that at the larger IXPs the Route Servers are already at the
> upper bound of their scaling capabilities, and many routing engines used
> by IXP participants are somewhat underscaled. With the current proposal
> I see a lot, perhaps too much of stirring in the convergence soup.
>
> In making the Route Server aware of link-failures _between_ Route Server
> Participants, the totality of all stakeholders depends not only on local
> convergence, but now convergence at the Route Server plays a significant
> role, which in turn can impact the participant's convergence.
>
> Another issue that under the current proposal, should a Route Server
> participant oscilate within the RS-Reachable SAFI, this oscilation can
> place a significant additional burden on the Route Server since the
> per-client Loc-RIBs needs to be recomputed. This risk does not exist in
> a mode of operation where less state is made known to the Route Server.
>
> Another note, instead of "The RS-Reachable Control Extended Community",
> shouldn't "Enhanced Route Refresh" (RFC 7313) be used?
>
> It appears to me that the only argument for storing client-to-client
> data-link reachability state at the Route Server, is to mitigate Path
> Hiding (rfc7947 section 2.3.1) - but it appears to me that it comes at a
> too high computational cost. Should the path hiding really need to be
> mitigated for the duration of a catastrophic failure at the IXP,
> ADD-PATH can be used.
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

--001a114a9e6cc8d3a50550bcff87
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Job,

This is going into right direction !

However if the change is really about=
 adding new SAFI to so to say "negotiate" BFD between clients why=
 instead of new SAFI basically define a new attribute or community for that=
 matter and attach it to original SAFI 1/1 & 2/1.=C2=A0

I take that we are no longer sending =
only next hops in this SAFI as this would still keep RS aware of client to =
client failures. If so I really do not think new SAFI brings any value and =
I would suggest to get rid of it.=C2=A0

<=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small">Then we will have nice and clean spec :)=C2=A0

Cheers,
R.


On Tue, May 30, 2017 at 1:34 PM, Job Snijders <job@instituut.net&=
gt; wrote:
Hi all,



Perhaps this has been covered in prior discussion, if so, my apologies.

Some individuals in the working group made every effort to drown out

discussion of meaningful deployment scenarios.



In reviewing draft-ietf-idr-rs-bfd-02 it occurred to me that there might
be an optimalisation to be made. At the last IETF I questioned whether

the Route Server itself really needs to be aware of reachability between
Route Server participants, and I still think that is not necessity.



OLD:

=C2=A0 =C2=A0 This document proposes the use of BFD between the two peering=


=C2=A0 =C2=A0 routers to detect a data plane failure, and then uses a newly=


=C2=A0 =C2=A0 defined BGP SAFI to signal the state of the data link to the =
route

=C2=A0 =C2=A0 server(s).

NEW:

=C2=A0 =C2=A0 This document proposes the use of BFD between the two peering=


=C2=A0 =C2=A0 routers to detect a data plane failure. The Route Server faci=
litates

=C2=A0 =C2=A0 setup and teardown of such BFD sessions through a newly defin=
ed BGP

=C2=A0 =C2=A0 SAFI in which it announces a next-hop's capability and wi=
llingness

=C2=A0 =C2=A0 to setup a direct BFD session.



OLD:

=C2=A0 =C2=A0 To remedy this, two basic problems need to be solved:

=C2=A0 =C2=A0 1.=C2=A0 Client routers must have a means of verifying connec=
tivity

=C2=A0 =C2=A0 =C2=A0 =C2=A0 amongst themselves, and

=C2=A0 =C2=A0 2.=C2=A0 Client routers must have a means of communicating th=
e knowledge

=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the failure back to the route server.

NEW:

=C2=A0 =C2=A0 To remedy this, a basic problem need to be solved:

=C2=A0 =C2=A0 1.=C2=A0 Client routers must have a means of verifying connec=
tivity

=C2=A0 =C2=A0 =C2=A0 =C2=A0 amongst themselves.



etc..



Operation:

----------



Scenario: ISP_A and ISP_B are connected to common layer-2 fabric IXP_C,

and both have a BGP session with Route Server RS_R.



ISP_A and ISP_B are both support draft-ietf-idr-rs-bfd-XX, and in the

OPEN message to RS_R they announce support for idr-rs-bfd through a BGP

capability. Since RS_R received this capability from both ISP_A and

ISP_B, it _can_ announce in a newly defined SAFI ISP_A's next-hop to
ISP_B, and _can_ ISP_B's next-hop to ISP_A.



Note: if ISP_A did not announce the capability, ISP_A's nexthop will no=
t

be announced to ISP_B, and ISP_A will of course not receive messages in

context of the newly defined SAFI.



If RS_R announces a path to ISP_B for which the next-hop is ISP_A, it

must also announce a ISP_A's next-hop in the newly defined SAFI to

indicate that ISP_A expressed a willingness and capability to set up a

BFD session. However, since a Route Server allows for facilitation of

unidirectional traffic flows, and BFD is a bidirectional construct, RS_R
must also announce ISP_B's next-hop in the newly defined SAFI to ISP_A.=




The above 'pairwise' announcement style might violate RFC 4271 sect=
ion

9.1: "The function that calculates the degree of preference for a give=
n

route SHALL NOT use any of the following as its inputs: the existence of
other routes, the non-existence of other routes, or the path attributes

of other routes." But since this is a Route Server, it is perhaps

permissible to add yet another crime to the Route Server's rap sheet.


Implementers might want to add a degree of dampening for the newly

defined SAFI to mitigate all to fast setup and teardown of BFD sessions.


Rationale:

----------



Should there be a fault of sorts on the IXP where for some reason ISP_A

and ISP_B can no longer reach each other, but they can reach RS_R, I'd<=
br>
argue this is a matter solely between ISP_A and ISP_B.



They both were facilitated by RS_R to set up BFD to each other, they

have a BFD session, the BFD session goes down because of the incident,

as a consequence they'll consider each other's next-hop to be

inadmissible for route selection and proceed to treat routes with each

other's next-hop as withdrawn. Life is good.



Should ISP_A and ISP_B have a feedback loop to RS_R to inform the RS

that they no longer can reach each other, what do we expect RS_R to do?

Calculate new best-paths for each client? Why is this useful? By the

time any flavor of draft-ietf-idr-rs-bfd-XX is implemented, we might

anticipate more use of ADD-PATH. But even without ADD-PATH, there is no

real harm in using a few routes from the RS_R when the IXP has gone

split-brain, the way any Route Server is used on the Internet, they only
carry partial routing tables anyway.



My main concern is that in real life, when RS_R receives from hundreds

of clients on one side of the IXP that they cannot reach the other side

of the IXP, and the hundreds on the other side of the IXP informs RS_R

that they cannot reach the side I first mentioned, this will create a

stampede for both Route Server and Route Server Participants.



=C2=A0 =C2=A0 1)=C2=A0 All Participants observe that 100s of BFD sessions g=
o down

=C2=A0 =C2=A0 2)=C2=A0 All Participants immediately proceed to deprecate th=
ose paths in

=C2=A0 =C2=A0 =C2=A0 =C2=A0 their own RIBs, sending out withdraws to downst=
ream BGP

=C2=A0 =C2=A0 =C2=A0 =C2=A0 speakers.

=C2=A0 =C2=A0 3)=C2=A0 The Route Server receives from n*100s of clients tha=
t they can't

=C2=A0 =C2=A0 =C2=A0 =C2=A0 reach various next-hops. These notifications ma=
y arrive in a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 staggered fashion.

=C2=A0 =C2=A0 3a) The Route Server may observe BGP sessions going down with=
 a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 subset of the participants, since IXP faults li=
ke these rarely

=C2=A0 =C2=A0 =C2=A0 =C2=A0 are clean-cut.

=C2=A0 =C2=A0 4)=C2=A0 The Route Server has to run a per-client best-path-s=
election

=C2=A0 =C2=A0 =C2=A0 =C2=A0 process within each RIB

=C2=A0 =C2=A0 4a) Participants see churn in the announcements received in t=
he

=C2=A0 =C2=A0 =C2=A0 =C2=A0 newly defined SAFI, and will proceed with teard=
own / setup of

=C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD sessions.

=C2=A0 =C2=A0 5)=C2=A0 The Route Server has to announce the newly selected =
best paths



Knowing that at the larger IXPs the Route Servers are already at the

upper bound of their scaling capabilities, and many routing engines used
by IXP participants are somewhat underscaled. With the current proposal

I see a lot, perhaps too much of stirring in the convergence soup.



In making the Route Server aware of link-failures _between_ Route Server
Participants, the totality of all stakeholders depends not only on local
convergence, but now convergence at the Route Server plays a significant
role, which in turn can impact the participant's convergence.



Another issue that under the current proposal, should a Route Server

participant oscilate within the RS-Reachable SAFI, this oscilation can

place a significant additional burden on the Route Server since the

per-client Loc-RIBs needs to be recomputed. This risk does not exist in

a mode of operation where less state is made known to the Route Server.



Another note, instead of "The RS-Reachable Control Extended Community&=
quot;,

shouldn't "Enhanced Route Refresh" (RFC 7313) be used?



It appears to me that the only argument for storing client-to-client

data-link reachability state at the Route Server, is to mitigate Path

Hiding (rfc7947 section 2.3.1) - but it appears to me that it comes at a
too high computational cost. Should the path hiding really need to be

mitigated for the duration of a catastrophic failure at the IXP,

ADD-PATH can be used.



Kind regards,



Job



_______________________________________________

Idr mailing list

Idr@ietf.org

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





--001a114a9e6cc8d3a50550bcff87--


From nobody Tue May 30 07:43:20 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF111286B1 for ; Tue, 30 May 2017 07:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01, URIBL_BLOCKED=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 V5u-xUUZWOKd for ; Tue, 30 May 2017 07:43:17 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d: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 77B89127286 for ; Tue, 30 May 2017 07:43:17 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id u75so70084359qka.3 for ; Tue, 30 May 2017 07:43:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:embedded-html; bh=yXusTWRj7ArtXJSmWoWjclR0DUDZt4uiXxrSaRgqggI=; b=PSlySc48H3Ak22uo9rht/Sw/P3BtEOm2aNpyYTJSwIRs4d+f80MjDL7DKWGscE5am8 uv6xYWfOrk4xhEtpdM3piv/VKlKa9Ialwjx37ckFOAwjfFxDS2xnm+bA0+MMfMgr9HN3 0soPmbGKmmvQbij4Vvl9L4J7hCoaE5x+J0273eExyMWt9EyxJrj6JzdYiWL5nqqLPOVb HNvwKfBx51Tfz6A/Bl2TXNticjPSO8KJU+rGXewjJPZ6EDkP3DzusampDD41rFwhHvjZ yR4G+GtaT1cpGakJsCozFwOr9f6IsrtQgpCxG8OnCz9+qx9B8tmr3fMRCnrdTXm11Sr0 p4BQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:embedded-html; bh=yXusTWRj7ArtXJSmWoWjclR0DUDZt4uiXxrSaRgqggI=; b=aL8PbyCoD6uJ8ZZiiyekuwlHuoT63yxmjGwlBnbp/7YDxpfNw4v9xqBsbT1kuqesVj oifX2k6/brUrIDeiinY5vbImbwBrYxYgG3Mj4ckJWRNSMo0aBMYnHZNV/YW1qfS5Nz/6 hHkkd9Q1VX7aoS7dlLi6xCATWe1l3Rqov4YQD8RpJTWkXf2dZqjSrslRa8b0d7YgBch1 NL/f5seUP3jVMoCy9xWYt5DuFPPKkk+2B1bCiE15/BzIH6Ixip92Size8WqtF5Ncg+B0 up0id2coeWZ/G38F/lIwaxwrmIXtU1i73Do6D+Tl3r2J+JaSdrlAUmz8XhJL1X++avT2 XeAg==
X-Gm-Message-State: AODbwcCPtY1qt2hb9r+djbvXNXEoWY4ZejGcw7H/3INARe5fPlXRmUOv uFmiUSjWsyJq8Ahrfg8=
X-Received: by 10.55.126.69 with SMTP id z66mr21404669qkc.137.1496155396574; Tue, 30 May 2017 07:43:16 -0700 (PDT)
Received: from [200.7.87.94] ([2001:13c7:7001:7000:59d:44e:4975:eba2]) by smtp.gmail.com with ESMTPSA id l36sm8563141qtl.32.2017.05.30.07.43.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 07:43:15 -0700 (PDT)
From: "Carlos M. Martinez" 
To: "Susan Hares" 
Cc: "idr wg" 
Date: Tue, 30 May 2017 11:43:12 -0300
Message-ID: <69FCB964-61A1-407D-8BD0-129856BAE842@gmail.com>
In-Reply-To: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com>
References: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_DDF9D4C2-909E-4F54-A5D7-FBE4B4B613F1_="
Embedded-HTML: [{"HTML":[1381, 1624], "plain":[65, 304], "uuid":"BB8C830C-E6A1-47FC-BAD1-19CA282F373C"}]
X-Mailer: MailMate (1.9.6r5347)
Archived-At: 
Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 14:43:19 -0000

--=_MailMate_DDF9D4C2-909E-4F54-A5D7-FBE4B4B613F1_=

Support adoption

On 20 May 2017, at 6:33, Susan Hares wrote:

> This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy
> (5/20 to 6/3/2017)
>
>
>
> The authors should indicate if they know of any IPR related to this
> document.  You can find the document at:
>
>
>
> https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/
>
>
>
> Sue Hares


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

--=_MailMate_DDF9D4C2-909E-4F54-A5D7-FBE4B4B613F1_=
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable









Support adoption


On 20 May 2017, at 6:33, Susan Hares wrote:






This begins a 2 week WG Adoption call for draft-ymbk-i=
dr-bgp-open-policy (5/20 to 6/3/2017) 
 
The authors should indicate if=
 they know of any IPR related to this document.  You can find the do=
cument at: 
 
https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-o=
pen-policy/
 
<=
p class=3DMsoNormal>Sue Hares 
&n=
bsp;
 




____________________________________________=
___

Idr mailing list

Idr@ietf.org

https://www.ietf.or=
g/mailman/listinfo/idr







--=_MailMate_DDF9D4C2-909E-4F54-A5D7-FBE4B4B613F1_=--


From nobody Tue May 30 09:27:20 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE780126CD6 for ; Tue, 30 May 2017 09:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.398
X-Spam-Level: 
X-Spam-Status: No, score=-5.398 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_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 XNmT2psWsVSu for ; Tue, 30 May 2017 09:27:16 -0700 (PDT)
Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2C1129AA4 for ; Tue, 30 May 2017 09:27:16 -0700 (PDT)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id D2929405CC; Tue, 30 May 2017 18:27:14 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id AA14D1C0069; Tue, 30 May 2017 18:27:14 +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.0339.000; Tue, 30 May 2017 18:27:14 +0200
From: 
To: Susan Hares , 'idr wg' 
Thread-Topic: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).
Thread-Index: AdLRTCaZKPuw1yo2RQSbPHINWp1hYAIFIUbw
Date: Tue, 30 May 2017 16:27:13 +0000
Message-ID: <6485_1496161634_592D9D62_6485_13175_1_53C29892C857584299CBF5D05346208A31D3244C@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <001e01d2d14c$32ed2e10$98c78a30$@ndzh.com>
In-Reply-To: <001e01d2d14c$32ed2e10$98c78a30$@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.5]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A31D3244COPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 16:27:19 -0000

--_000_53C29892C857584299CBF5D05346208A31D3244COPEXCLILM21corp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Sue, authors, all,

Unfortunately, I'm not up-to-date on this subject, so please take my commen=
ts with a grain of salt.

Support.
As it looks like a valid idea, with incremental deployment and incremental =
benefits.

Possible comments:
- possibly, there could be additional usage/value if the iOTC attribute wer=
e carrying the role within the AS, rather than being only a flag. For examp=
le it could be used in routing policies (as a read-only-memory) e.g. to set=
 the preference of routes. Indeed, my understanding is that this info is do=
uble checked hence more reliable than a BGP community that the receiver cou=
ld set with no additional checks. So a priori a better source of info for a=
 routing policy
- a priori, as per current text, the iOTC attribute seems advertised over E=
BGP session and not removed on the reception side. I'm not sure whether thi=
s is a design goal or a bug.
- Possibly, the "Strict mode" could be the only one/the mandated behavior. =
To allow for backward compatibility, the non-compliant peer could tag route=
s with "well-known" BGP communities, to be defined by this document, and in=
dicating the role (on a per route basis).

Regards,
--Bruno


From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Saturday, May 20, 2017 11:34 AM
To: 'idr wg'
Subject: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to=
 6/3/2017).

This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy (5=
/20 to 6/3/2017)

The authors should indicate if they know of any IPR related to this documen=
t.  You can find the document at:

https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/

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_53C29892C857584299CBF5D05346208A31D3244COPEXCLILM21corp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Sue, authors, all,<=
o:p>


 


Unfortu=
nately, I’m not up-to-date on this subject, so please take my comment=
s with a grain of salt.


&n=
bsp;


Support=
.


As it l=
ooks like a valid idea, with incremental deployment and incremental benefit=
s.


&n=
bsp;


Possibl=
e comments:


- possi=
bly, there could be additional usage/value if the iOTC attribute were carry=
ing the role within the AS, rather than being only a flag. For example it c=
ould be used in routing policies (as a
 read-only-memory) e.g. to set the preference of routes. Indeed, my underst=
anding is that this info is double checked hence more reliable than a BGP c=
ommunity that the receiver could set with no additional checks. So a priori=
 a better source of info for a routing
 policy


- a pri=
ori, as per current text, the iOTC attribute seems advertised over EBGP ses=
sion and not removed on the reception side. I'm not sure whether this is a =
design goal or a bug.


- Possi=
bly, the "Strict mode" could be the only one/the mandated behavio=
r. To allow for backward compatibility, the non-compliant peer could tag ro=
utes with "well-known" BGP communities, to be defined
 by this document, and indicating the role (on a per route basis).


&n=
bsp;


Regards=
,


--Bruno=



&n=
bsp;


&n=
bsp;








From: Idr [mai=
lto:idr-bounces@ietf.org]
On Behalf Of Susan Hares

Sent: Saturday, May 20, 2017 11:34 AM

To: 'idr wg'

Subject: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (=
5/20 to 6/3/2017).






 


This begins a 2 week WG Adoptio=
n call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017)



 


The authors should indicate if =
they know of any IPR related to this document.  You can find the docum=
ent at:



 


https://datatracker.ietf.org/=
doc/draft-ymbk-idr-bgp-open-policy/


 


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_53C29892C857584299CBF5D05346208A31D3244COPEXCLILM21corp_--


From nobody Tue May 30 12:44:57 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0600A126D73; Tue, 30 May 2017 12:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z_-xA2EHBhT; Tue, 30 May 2017 12:44:53 -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 286311250B8; Tue, 30 May 2017 12:44:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qUcBwri2HNHvFsHvHdaeyQuWHAwNVR9/489RPZlT+hs=; b=XQkFEEf8utJrpQ6Dc3O76CrhGfNpceLKf2VhLZJufLDTr/tWdA4y1LIcEuA1eIB3YjVPanB5pia/wi1YHLz9I9ZTpBKzy+RFVuGd0kP+mOeCJpIqLHBWZBZCgZnq5rIOyo0kLFJJ7vQahgMg9JsL6kXVe7pPMN2bKRdRHFmxRzA=
Received: from CO2PR05MB618.namprd05.prod.outlook.com (10.141.198.146) by CO2PR05MB2504.namprd05.prod.outlook.com (10.166.95.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.6; Tue, 30 May 2017 19:44:51 +0000
Received: from CO2PR05MB618.namprd05.prod.outlook.com ([10.141.198.146]) by CO2PR05MB618.namprd05.prod.outlook.com ([10.141.198.146]) with mapi id 15.01.1143.009; Tue, 30 May 2017 19:44:51 +0000
From: John E Drake 
To: John Scudder , "idr@ietf.org" 
CC: "draft-ietf-idr-tunnel-encaps@ietf.org" 
Thread-Topic: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
Thread-Index: AQHS0aHtgmiwFo/ZwE+Npslhnc8W56INVC7g
Date: Tue, 30 May 2017 19:44:51 +0000
Message-ID: 
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net>
In-Reply-To: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO2PR05MB2504; 7:/xU1996ZVebCUwucOAQa69C+IdN3nrkaNyQVnqjj209crrN4XndxuHoPjezNkyn1vTTU7qAn9C4EtclcyUUnnIsy9V//TyIlAnNL+SggznxhvTA++0NfFZPqaMS3Q2cWj0ECAWM2C5OHtrXNFddA7Sv412jWuyFP1MEI9G4oaaI8U3ygBijV70PoemjaWgnk1rsAWNX2OiaGx5fjud4lSDr61mGyLbCiiRUv0foArsDpK+zS1/ptnk4YvJVSg0pnMG1DOUyCJCoCzZxvRm5GQf3bh+8oqlj+6Ox0hv+O781yY7y04tY3NC2SKw/DtZBaIzLyBut39stak+piABILcQ==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39450400003)(39410400002)(39850400002)(39840400002)(39860400002)(13464003)(377454003)(53754006)(33656002)(6116002)(2950100002)(102836003)(3846002)(450100002)(3280700002)(4326008)(189998001)(122556002)(6246003)(53546009)(25786009)(53936002)(99286003)(230783001)(86362001)(66066001)(6306002)(9686003)(55016002)(7696004)(50986999)(54356999)(76176999)(77096006)(38730400002)(6506006)(14454004)(6436002)(478600001)(2900100001)(3660700001)(5660300001)(7736002)(2906002)(81166006)(305945005)(74316002)(8676002)(8936002)(229853002)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2504; H:CO2PR05MB618.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-ms-traffictypediagnostic: CO2PR05MB2504:
x-ms-office365-filtering-correlation-id: 21d2a836-f761-4bcf-a4a9-08d4a7945679
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:CO2PR05MB2504; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700073)(100105000095)(100000701073)(100105300095)(100000702073)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703073)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704073)(100105200095)(100000705073)(100105500095); SRVR:CO2PR05MB2504; BCL:0; PCL:0; RULEID:(100000800073)(100110000095)(100000801073)(100110300095)(100000802073)(100110100095)(100000803073)(100110400095)(100000804073)(100110200095)(100000805073)(100110500095); SRVR:CO2PR05MB2504; 
x-forefront-prvs: 032334F434
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2017 19:44:51.3112 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2504
Archived-At: 
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 19:44:55 -0000

John,

I support advancing this draft as it extremely solid and comprehensive and =
it has already proven to be extensible to solve a number of problems, e.g.,=
 SR traffic engineering, SR DCI, and SFC, for which it was not originally d=
esigned.

Yours Irrespectively,

John


> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder
> Sent: Saturday, May 20, 2017 3:47 PM
> To: idr@ietf.org
> Cc: draft-ietf-idr-tunnel-encaps@ietf.org
> Subject: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-0=
4
>=20
> Hi All,
>=20
> A working group last call has been requested for draft-ietf-idr-tunnel-en=
caps-04.
> Please reply to the list with your comments. As usual note we cannot adva=
nce
> the draft without participation from the group. Please get your comments =
in
> before June 5, 2017.
>=20
> Authors, please confirm that any relevant IPR has been disclosed.
>=20
> https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-04
>=20
> Thanks,
>=20
> --John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Wed May 31 02:22:06 2017
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 D02A61287A3; Wed, 31 May 2017 02:21:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: idr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.52.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149622251880.19925.2579141881607192213@ietfa.amsl.com>
Date: Wed, 31 May 2017 02:21:58 -0700
Archived-At: 
Subject: [Idr] I-D Action: draft-ietf-idr-eag-distribution-04.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 09:21:59 -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           : Distribution of MPLS-TE Extended admin Group Using BGP
        Authors         : Zitao Wang
                          Qin Wu
                          Jeff Tantsura
	Filename        : draft-ietf-idr-eag-distribution-04.txt
	Pages           : 5
	Date            : 2017-05-30

Abstract:
   As MPLS-TE network grows, administrative Groups advertised as a
   fixed-length 32-bit Bitmask is quite constraining.  "Extended
   Administrative Group" IGP TE extensions sub-TLV is introduced to
   provide for additional administrative groups (link colors) beyond the
   current limit of 32.  This document describes extensions to BGP
   protocol, that can be used to distribute extended administrative
   groups in MPLS-TE.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-eag-distribution/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-eag-distribution-04
https://datatracker.ietf.org/doc/html/draft-ietf-idr-eag-distribution-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-eag-distribution-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 Wed May 31 02:28:42 2017
Return-Path: 
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0E51287A3 for ; Wed, 31 May 2017 02:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level: 
X-Spam-Status: No, score=-4.222 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.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 FnFAwdsYwusk for ; Wed, 31 May 2017 02:28:40 -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 A2653126DD9 for ; Wed, 31 May 2017 02:28:39 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOD23168; Wed, 31 May 2017 09:28:37 +0000 (GMT)
Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 31 May 2017 10:28:18 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.49]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0301.000; Wed, 31 May 2017 17:27:32 +0800
From: wangzitao 
To: "idr@ietf.org" 
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-eag-distribution-04.txt
Thread-Index: AQHS2e92IhMFfAWgJE6+zWUvx4w0/KIOK4oQ
Date: Wed, 31 May 2017 09:27:32 +0000
Message-ID: 
References: <149622251880.19925.2579141881607192213@ietfa.amsl.com>
In-Reply-To: <149622251880.19925.2579141881607192213@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.79.161]
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.592E8CC5.012D, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.3.49, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 5729ee6e185bd974a7c3663f60c93e38
Archived-At: 
Subject: Re: [Idr] I-D Action: draft-ietf-idr-eag-distribution-04.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 09:28:42 -0000

SGkgV0csDQoNCldlIHVwZGF0ZWQgdGhlIGRyYWZ0LWlldGYtaWRyLWVhZy1kaXN0cmlidXRpb24g
ZG9jdW1lbnQuDQpJbiB0aGlzIHZlcnNpb24sIHdlIGZpeGVkIHRoZSBpZC1uaXRzLiBBbmQgbW9y
ZSBkZXRhaWxzIHBsZWFzZSBzZWUgdGhlIGRyYWZ0Lg0KDQpCZXN0IFJlZ2FyZHMhDQotTWljaGFl
bA0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNA
aWV0Zi5vcmddILT6se0gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQq3osvNyrG85DogMjAxN8Tq
NdTCMzHI1SAxNzoyMg0KytW8/sjLOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCrOty806IGlkckBp
ZXRmLm9yZw0K1vfM4jogW0lkcl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pZHItZWFnLWRpc3Ry
aWJ1dGlvbi0wNC50eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv
bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlz
IGEgd29yayBpdGVtIG9mIHRoZSBJbnRlci1Eb21haW4gUm91dGluZyBvZiB0aGUgSUVURi4NCg0K
ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBEaXN0cmlidXRpb24gb2YgTVBMUy1URSBFeHRlbmRl
ZCBhZG1pbiBHcm91cCBVc2luZyBCR1ANCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogWml0YW8g
V2FuZw0KICAgICAgICAgICAgICAgICAgICAgICAgICBRaW4gV3UNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgSmVmZiBUYW50c3VyYQ0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtaWRy
LWVhZy1kaXN0cmlidXRpb24tMDQudHh0DQoJUGFnZXMgICAgICAgICAgIDogNQ0KCURhdGUgICAg
ICAgICAgICA6IDIwMTctMDUtMzANCg0KQWJzdHJhY3Q6DQogICBBcyBNUExTLVRFIG5ldHdvcmsg
Z3Jvd3MsIGFkbWluaXN0cmF0aXZlIEdyb3VwcyBhZHZlcnRpc2VkIGFzIGENCiAgIGZpeGVkLWxl
bmd0aCAzMi1iaXQgQml0bWFzayBpcyBxdWl0ZSBjb25zdHJhaW5pbmcuICAiRXh0ZW5kZWQNCiAg
IEFkbWluaXN0cmF0aXZlIEdyb3VwIiBJR1AgVEUgZXh0ZW5zaW9ucyBzdWItVExWIGlzIGludHJv
ZHVjZWQgdG8NCiAgIHByb3ZpZGUgZm9yIGFkZGl0aW9uYWwgYWRtaW5pc3RyYXRpdmUgZ3JvdXBz
IChsaW5rIGNvbG9ycykgYmV5b25kIHRoZQ0KICAgY3VycmVudCBsaW1pdCBvZiAzMi4gIFRoaXMg
ZG9jdW1lbnQgZGVzY3JpYmVzIGV4dGVuc2lvbnMgdG8gQkdQDQogICBwcm90b2NvbCwgdGhhdCBj
YW4gYmUgdXNlZCB0byBkaXN0cmlidXRlIGV4dGVuZGVkIGFkbWluaXN0cmF0aXZlDQogICBncm91
cHMgaW4gTVBMUy1URS4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3Ig
dGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll
dGYtaWRyLWVhZy1kaXN0cmlidXRpb24vDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNp
b25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm
LWlkci1lYWctZGlzdHJpYnV0aW9uLTA0DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9odG1sL2RyYWZ0LWlldGYtaWRyLWVhZy1kaXN0cmlidXRpb24tMDQNCg0KQSBkaWZmIGZyb20g
dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtaWRyLWVhZy1kaXN0cmlidXRpb24tMDQNCg0KDQpQ
bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg
dGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy
ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxz
byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl
cm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo=