From nobody Mon May 1 03:34:24 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B5B128BA2; Mon, 1 May 2017 03:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 6Zz85c2F8kbm; Mon, 1 May 2017 03:34:20 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570511293E0; Mon, 1 May 2017 03:32:36 -0700 (PDT) Received: from [192.168.0.200] (Lenovo-X1Carbon.win2004.cysol.co.jp [192.168.0.200]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.9/8.14.9) with ESMTP id v41AWQna007825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 May 2017 19:32:27 +0900 (JST) (envelope-from glenn@cysols.com) To: Hiroshi Tsunoda References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey (Zhaohui) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" From: Glenn Mansfield Keeni Message-ID: <1848f053-9a5e-2f52-09b4-ce0e1688b557@cysols.com> Date: Mon, 1 May 2017 19:32:22 +0900 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: <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Archived-At: Subject: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-07 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 10:34:22 -0000 Dear Tsuno/Zhang Thanks for waiting. The review of draft-ietf-bess-l2l3-vpn-mcast-mib-07 follows. Glenn C1. Abstract: The draft now defines 2 MIB modules. Please revise the abstract and probably the title of the document too. C2. The MIBs (L2L3-VPN-MCAST-TC-MIB, L2L3-VPN-MCAST-MIB) compile OK. (Three {type-unref} warnings are there, may be ignored.) C3. Page 4: s/3. Summary of MIB Module/ 3. Summary of MIB Modules/ C4. Page 6: L2L3VpnMcastProviderTunnelPointer DESCRIPTION s/"Denotes a pointer to the row pertaining to a table entry/ /"This textual convention represents a pointer to a row in the table represented by the following object of type L2L3VpnMcastProviderTunnelPointerType./ C5. Page 7: L2L3VpnMcastProviderTunnelPointer DESCRIPTION The explanation in the last paragraph seems out of place. It may be removed. C6 Page 7: L2L3VpnMcastProviderTunnelPointerType DESCRIPTION it is unclear when the value 'null(0)' will be used. Is this allowed only when the corresponding object of type L2L3VpnMcastProviderTunnelPointer has a value that is a zero-length string ? If yes, please make that clear. C7. Page 9: l2L3VpnMcastPmsiTunnelAttributeTable DESCRIPTION s/created by a PE router/maintained by a PE router/ C8. Page 12: l2L3VpnMcastPmsiTunnelAttributeId Do you really want to keep this object in L2L3-VPN-MCAST-MIB. It will change every time a new "tunnel type" is added to L2L3VpnMcastProviderTunnelType. That will defeat the purpose of separating L2L3-VPN-MCAST-TC-MIB from L2L3-VPN-MCAST-MIB It may be a good idea to define a textual convention like L2L3VpnMcastPmsiTunnelAttributeId in the L2L3-VPN-MCAST-TC-MIB and use that textual convention in the L2L3-VPN-MCAST-MIB C9. Page 13: l2L3VpnMcastPmsiTunnelAttributeId DESCRIPTION A. s/Thus, the size of this object is 16 octets in IPv4/ Thus, the size of this object is 8 octets in IPv4/ B. The last 2 paragraphs do not tie up well with the previous paragraphs in the DESCRIPTION. C. In the last paragraph "this object is a pair of source and group IP addresses" is unlcear. Please clarify. C10. Page 15: Security Considerations I would think that any field that reveals information about a Multicast VPN and/or its members is sensitive. Does the l2L3VpnMcastPmsiTunnelAttributeId field reveal information about the participating members? If yes, it must be marked as sensitive. C11. Editorial: A. This does not pertain to the MIBs as such, but I am uncomfortable with the several variations of the phrase "Layer 2 and Layer 3 Virtual Private Networks (VPN) that support multicast" that appears in the text. I do not have a solution on hand but it would be perhaps be more readable to define and use a simple name/notation the beast for which the MIB is being designed (e.g. "L2L3VPNMCast"). B. Same with the phrase "Layer 2 (L2) and Layer 3 (L3) VPN (Virtual Private Network) it would be probably be easier on the reader if an abbreviation like L2L3VPNs was used where ever applicable. C12. P2:Para4: s/within MIB module specifications//; C13. General: A. The DESCRIPTION clauses could do would some more packing. (Too much space at the end of lines) B. Please check the articles a/an/the once again. Some usages do not seem right to me. From nobody Tue May 2 05:48:10 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D9E12955F for ; Tue, 2 May 2017 05:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=ieee-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgUdWbKnSek4 for ; Tue, 2 May 2017 05:48:05 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553EE124217 for ; Tue, 2 May 2017 05:44:56 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id u68so31055635qkd.0 for ; Tue, 02 May 2017 05:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lMPVHHyIXuM+CYGb63QhRhoRf0yBDEfrwvw4HBrrPks=; b=eORROj34Wz5GUVgmScgZfBXkptQNoSmrxCg3+DBp2ihtw/bIoCRvNHDGljw3kIcrTz sP6nBdd2cLd88PYtTkBEU49lDK40CWftJUfLM+vWW0u6HXwjTYnXYZgVrBeF9t/oLl0v hfZ5rJzs/9TiB5YLjy5YKHeRdxxTAJgCPm9eZzeaNaZcW567SSkpBNEwgsTHjWos8a1E 5l+4yAHxiXRs0rhhKUZpzmoru3s2ZGIOoVM5g0pqma7orfPYBRD+X1ik72k74a+giwvt 8WSef/AiNOilTOP67ciIq03FncpPZrPRwz+Mpn+a7Xkg6pjwn82AxL3Os6qVqvf/Xm7t BJ8g== 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=lMPVHHyIXuM+CYGb63QhRhoRf0yBDEfrwvw4HBrrPks=; b=fh0Zi/jY2dxg/dmuLHzx16E6mBXiO1OELpHPmfbaiykMVe5Lsqv6ONBxbszkISp7eZ h93U8TQQedv0jHWgfaWqocYM3/6e58tvnOVuk3Lai3H3FhJ67wOQTxVogTTktxg12JJy uwP30MNRE3kjvWS55qoA0F+pJJ3sXTlrnu89q8ByWqPDk9hueZloMyaru6w7B524/1Qb RppSAs5Z2Y8Ze9CYUfxCqMzgQZGEIAFFqLES0i/2iW2yrYEITayj5Gpp1uzplzOHg1+9 a8SsLr+i9/Mha8A4Q1Dn5YuGOG8I4tZ+bcXMpZlsAW7ehf1EbQmrH+JSW0ssDCfPJL02 qCqw== X-Gm-Message-State: AN3rC/4E3X0g8eKGaebyhLXrvFkt77UPr7A11XDRuYBfIuA+Cpnbrein t6YsG/0ivJNbj5XAE19basnAgeKtbicO X-Received: by 10.55.113.134 with SMTP id m128mr25448371qkc.258.1493729095315; Tue, 02 May 2017 05:44:55 -0700 (PDT) MIME-Version: 1.0 Sender: dr.h.t@ieee.org Received: by 10.140.30.52 with HTTP; Tue, 2 May 2017 05:44:14 -0700 (PDT) In-Reply-To: <1848f053-9a5e-2f52-09b4-ce0e1688b557@cysols.com> References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> <1848f053-9a5e-2f52-09b4-ce0e1688b557@cysols.com> From: Hiroshi Tsunoda Date: Tue, 2 May 2017 14:44:14 +0200 X-Google-Sender-Auth: j6ZyOQim-7mU7tkJNF96zyYEFfU Message-ID: To: Glenn Mansfield Keeni Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey (Zhaohui) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-07 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 12:48:09 -0000 Dear Glenn, Thank you very much for your thorough review. I have greatly appreciated it. I am going to check and update the draft taking into account your comments. I try to submit the updated draft by the end of next week. Best regards, -- tsuno 2017-05-01 12:32 GMT+02:00 Glenn Mansfield Keeni : > Dear Tsuno/Zhang > Thanks for waiting. The review of > draft-ietf-bess-l2l3-vpn-mcast-mib-07 follows. > > Glenn > > C1. Abstract: > The draft now defines 2 MIB modules. Please revise the abstract > and probably the title of the document too. > > C2. The MIBs (L2L3-VPN-MCAST-TC-MIB, L2L3-VPN-MCAST-MIB) compile OK. > (Three {type-unref} warnings are there, may be ignored.) > > C3. Page 4: > s/3. Summary of MIB Module/ > 3. Summary of MIB Modules/ > > C4. Page 6: L2L3VpnMcastProviderTunnelPointer DESCRIPTION > s/"Denotes a pointer to the row pertaining to a table entry/ > /"This textual convention represents a pointer to a row in > the table represented by the following object of type > L2L3VpnMcastProviderTunnelPointerType./ > > C5. Page 7: L2L3VpnMcastProviderTunnelPointer DESCRIPTION > The explanation in the last paragraph seems out of place. > It may be removed. > > C6 Page 7: L2L3VpnMcastProviderTunnelPointerType DESCRIPTION > it is unclear when the value 'null(0)' will be used. > Is this allowed only when the corresponding object of type > L2L3VpnMcastProviderTunnelPointer has a value that is a > zero-length string ? If yes, please make that clear. > > C7. Page 9: l2L3VpnMcastPmsiTunnelAttributeTable DESCRIPTION > s/created by a PE router/maintained by a PE router/ > > C8. Page 12: l2L3VpnMcastPmsiTunnelAttributeId > Do you really want to keep this object in L2L3-VPN-MCAST-MIB. > It will change every time a new "tunnel type" is added to > L2L3VpnMcastProviderTunnelType. That will defeat the purpose > of separating L2L3-VPN-MCAST-TC-MIB from L2L3-VPN-MCAST-MIB > It may be a good idea to define a textual convention like > L2L3VpnMcastPmsiTunnelAttributeId > in the L2L3-VPN-MCAST-TC-MIB and use that textual convention > in the L2L3-VPN-MCAST-MIB > > C9. Page 13: l2L3VpnMcastPmsiTunnelAttributeId DESCRIPTION > A. s/Thus, the size of this object is 16 octets in IPv4/ > Thus, the size of this object is 8 octets in IPv4/ > B. The last 2 paragraphs do not tie up well with the previous > paragraphs in the DESCRIPTION. > C. In the last paragraph > "this object is a pair of source and group IP addresses" > is unlcear. Please clarify. > > C10. Page 15: Security Considerations > I would think that any field that reveals information about > a Multicast VPN and/or its members is sensitive. > Does the l2L3VpnMcastPmsiTunnelAttributeId field reveal > information about the participating members? If yes, it must > be marked as sensitive. > > C11. Editorial: > > A. This does not pertain to the MIBs as such, > but I am uncomfortable with the several variations > of the phrase > "Layer 2 and Layer 3 Virtual Private Networks (VPN) > that support multicast" > that appears in the text. I do not have a solution > on hand but it would be perhaps be more readable to > define and use a simple name/notation the beast for > which the MIB is being designed (e.g. "L2L3VPNMCast"). > > B. Same with the phrase > "Layer 2 (L2) and Layer 3 (L3) VPN (Virtual Private > Network) > it would be probably be easier on the reader if an > abbreviation like L2L3VPNs was used where ever > applicable. > > C12. P2:Para4: s/within MIB module specifications//; > > C13. General: > A. The DESCRIPTION clauses could do would some more > packing. (Too much space at the end of lines) > B. Please check the articles a/an/the once again. Some > usages do not seem right to me. > > > > From nobody Wed May 3 00:10:52 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD761200F3; Wed, 3 May 2017 00:10:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: Cc: draft-ietf-bess-evpn-vpws.all@ietf.org, ietf@ietf.org, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149379545069.21463.6266932682208619112@ietfa.amsl.com> Date: Wed, 03 May 2017 00:10:50 -0700 Archived-At: Subject: [bess] Genart telechat review of draft-ietf-bess-evpn-vpws-12 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 07:10:50 -0000 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-bess-evpn-vpws-?? Reviewer: Roni Even Review Date: 2017-05-03 IETF LC End Date: 2017-04-28 IESG Telechat date: 2017-05-11 Summary: The document is ready for publication. Major issues: Minor issues: Nits/editorial comments: From nobody Fri May 5 07:11:28 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A2C1289B5; Fri, 5 May 2017 07:11:25 -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=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 mFiJDlOW4QSu; Fri, 5 May 2017 07:11:23 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0108.outbound.protection.outlook.com [104.47.42.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5B1127735; Fri, 5 May 2017 07:11:23 -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=OU9GYpEbj4Nqon0CeuHQeLr1Hx61HVonDBH1z8Au4+w=; b=TVSjOk/WHxkjGGV/2dhamaobEvpoxZe0DUnFxcIAT9TNbL2SBEXk9mWf8EqK4P26skLLwKjQUNknTtw+rbnA12s6iMUeMnzFPXrJbF+LOKZ96/rWcS5EKVjUt8hFVFltZbOM516Uc+KLj3K5QnXDNkUChr6qYCmNiX8KOz9k8n8= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1909.namprd02.prod.outlook.com (10.163.75.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Fri, 5 May 2017 14:11:22 +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; Fri, 5 May 2017 14:11:22 +0000 From: Jonathan Hardwick To: BESS CC: "sfc@ietf.org" Thread-Topic: [bess] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure Thread-Index: AQHStIBopR5ttV6D/Uy/LpRDB7dIPqHl6aKw Date: Fri, 5 May 2017 14:11:22 +0000 Message-ID: References: In-Reply-To: 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: [86.175.167.173] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1909; 7:DKvuWxR9e/BiGkIiHuQkpFv0IiXbiqFLvsF3HZ5vP8/DvLj6+OY2X5g/JBSaGmfpEhIe8YsN9EwajuyEI4yOd8NdySC36N8kw27i472qpTKWms8Wx1Z8383DtsMk2eDR+oE248piETn9CCCNNty3JcvKPAEsljrBcQiZNfDr6Zt9qppakLB0Mx13Oe7+HDA7tvb6LpGLopGanvNSpHrQKfieV9ZWSDni5bkGouR0XEDg2ERw5O0XbJtzHl9kf9WdBUXp8CEn/zoe2acFmUXQH0HCB4V2d///zYPVH936nQHwsFUyjomXRow0cJZlYIR8yWgBx16Apfs+1bV1hNX4/g== x-ms-office365-filtering-correlation-id: 18d01191-54d2-41ff-ffa3-08d493c09c0d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BY2PR0201MB1909; 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)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(6072148); SRVR:BY2PR0201MB1909; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1909; x-forefront-prvs: 02981BE340 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39400400002)(39410400002)(13464003)(230783001)(189998001)(33656002)(50986999)(122556002)(54356999)(86362001)(76176999)(66066001)(6116002)(229853002)(38730400002)(3846002)(102836003)(6246003)(110136004)(6506006)(53936002)(6436002)(6306002)(25786009)(5660300001)(53546009)(9686003)(2906002)(4326008)(7736002)(3660700001)(77096006)(305945005)(74316002)(3280700002)(450100002)(99286003)(7696004)(81166006)(2900100001)(8936002)(2950100002)(6916009)(55016002)(478600001)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1909; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2017 14:11:22.5698 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1909 Archived-At: Subject: Re: [bess] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 14:11:25 -0000 I support the adoption of this draft. Best regards Jon -----Original Message----- From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Martin Vigoureux Sent: 13 April 2017 19:04 To: BESS Cc: sfc@ietf.org Subject: [bess] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-= plane adoption following the IPR disclosure WG Given the IPR disclosed [1] against draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for comment= specifically to let people express a revised opinion on how draft-ietf-bes= s-nsh-bgp-control-plane should be pursued in BESS. This call for comment is open until the 5th of May Thanks M&T [1] https://datatracker.ietf.org/ipr/2980/ _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess From nobody Fri May 5 10:06:33 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D70127863; Fri, 5 May 2017 10:06:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149400399182.8471.4939599601893600928@ietfa.amsl.com> Date: Fri, 05 May 2017 10:06:31 -0700 Archived-At: Subject: [bess] I-D Action: draft-ietf-bess-evpn-vpws-13.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 17:06:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : VPWS support in EVPN Authors : Sami Boutros Ali Sajassi Samer Salam John Drake Jorge Rabadan Filename : draft-ietf-bess-evpn-vpws-13.txt Pages : 14 Date : 2017-05-05 Abstract: This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws-13 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-vpws-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-vpws-13 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 13:40:42 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 581EA128990; Fri, 5 May 2017 13:40:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: draft-ietf-bess-evpn-vpws@ietf.org, aretana@cisco.com, "Zhaohui \(Jeffrey\) Zhang" , bess-chairs@ietf.org, zzhang@juniper.net, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149401683435.8520.15797203657822854882.idtracker@ietfa.amsl.com> Date: Fri, 05 May 2017 13:40:34 -0700 Archived-At: Subject: [bess] Alia Atlas' Yes on draft-ietf-bess-evpn-vpws-13: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 20:40:34 -0000 Alia Atlas has entered the following ballot position for draft-ietf-bess-evpn-vpws-13: 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-bess-evpn-vpws/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my Discuss on clarifying the use of VXLAN & that it is the tunneling technology and how it pertains to the services supported. ===================== From nobody Sat May 6 00:16:57 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAAD1292FD for ; Sat, 6 May 2017 00:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 mpQ0L5a0vImS for ; Sat, 6 May 2017 00:16:53 -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 9EC24124D85 for ; Sat, 6 May 2017 00:16:53 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id e65so19967144ita.1 for ; Sat, 06 May 2017 00:16:53 -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=ZsTOl0iv8ZIG4j++LHmDFVpNr10JTjD4UCLAaKotxLE=; b=lDUOG++AhKVZoy7lDj8EJI/22nSPzJqRy8tIZkH6P7+mk0gLil1xAFr0iuEXYRP1I3 wkDbqQRKGe/xRLojXBaKlJMcC7JPDE4gIxOfvc1tjKCNDwdb4SLoQe6MizlwBpFM4Tjg DX0jxC8DncJ+TVYeUZzNuX9g7YFvwWaGMZQP0/VCWX6Pe4rYehl/u06zqtroL3ieT/+2 iNP90WD4rJwFqkP24cQ5DlS01N/zJ9rGF7iA3OLutIBgJFsdg/ezlHjd/GAeFaS0DR1C 6b2dFUZo/qZ1RaEg8ZpEOS5HzXtKonJV1wTLn/SgaIcPaMzSG/dwLQZwd7EVMB5JVTBq fOSg== 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=ZsTOl0iv8ZIG4j++LHmDFVpNr10JTjD4UCLAaKotxLE=; b=NtyhVTt+1mUtZyJimOIgZolPuDJUJeoEkOXA+gD+yE1oUWSpEeoMoa1zQsbn2RPU1Y CPbJNATAyC2XQcB+dQ1Jq9SFVW2W4VOg5buJHXdgvZec7V20ycBaFXXGio33mjJNNjZN xOg4+WFi+pMFOBLVGy/BxcChtH88g7eSEifobTETEp5QqMPFAvJcbo0AI2WxE483HQ7A 4Uix40iYLHK+vRnGI0nuX2Dmdgo5aZ8gcamT4IN1BSWe8SkZWIXkY+pQmffOZMe8zXRt nqNOPi1DlqNT1kOanu1BIW53hLDibROw+aADRjZ5HJZen4qbo+fMS/hpwTGOhmrhxbEE VvYQ== X-Gm-Message-State: AN3rC/4GPq+Sgd5mycggjQLMHCvWYiYdFb8eZMXtRacQlYL6mM4uR9rR XM+AaFQMcJDhRpBoK5aUP0OtkZCDiw== X-Received: by 10.36.245.201 with SMTP id k192mr13290201ith.104.1494055012991; Sat, 06 May 2017 00:16:52 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Sat, 6 May 2017 00:16:52 -0700 (PDT) From: Robert Raszuk Date: Sat, 6 May 2017 09:16:52 +0200 X-Google-Sender-Auth: I9GPOQ72fQiyiDXbU-dJ7KwjIzw Message-ID: To: Warren Kumari Cc: "Alvaro Retana (aretana)" , "bess@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c041c70530d2c054ed5ca94 Archived-At: Subject: [bess] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 07:16:56 -0000 --94eb2c041c70530d2c054ed5ca94 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Warren, This is clearly not unanimous/ not everyone is happy, but (in my view) > there is *rough* consensus for this to progress. > =E2=80=8BThe group of users of BGP which this update impacts the most are m= embers of BESS WG (cc-ed) and not IDR WG due to the fact that this proposal applies to all AFI/SAFIs. IMO before you progress anywhere with this IETF LC BESS WG should express their formal opinion on it. Example of in or out eBGP policy where you are sending MAC addresses in EVPN AF needs to be provided and explained why it makes sense. Likewise examples of RTC AF for L3VPN Inter-as needs to be discussed. Otherwise the group of people which defined a lot of non ISP uses of BGP may be suddenly surprised down the read for keeping them out of the loop and have customers loosing reachability upon compliant non sequential router OS upgrade. Cheers, Robert. REF: https://tools.ietf.org/html/draft-ietf-grow-bgp-reject-06 --94eb2c041c70530d2c054ed5ca94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Warren,

=
This is clearly not unanimous/ not every= one is happy, but (in my view)
there is *rough* consensus for this to progress.

<= /div>
=E2=80=8BThe group of users of BGP which this = update impacts the most are members=C2=A0
of BESS W= G (cc-ed) and not IDR WG due to the fact that this proposal applies to all = AFI/SAFIs.=C2=A0

IMO b= efore you progress anywhere with this IETF LC BESS WG should express=C2=A0<= /div>
their formal opinion on it.=C2=A0

Example of in or out eBGP policy wher= e you are sending MAC addresses in=C2=A0
EVPN AF ne= eds to be provided and explained why it makes sense. Likewise=C2=A0
examples of RTC AF for L3VPN Inter-as needs to be discusse= d.=C2=A0

Otherwise the= group of people which defined a lot of non ISP uses of BGP may be=C2=A0
suddenly surprised down the read for keeping them out= of the loop and have=C2=A0
customers loosing reach= ability upon compliant non sequential router OS upgrade.=C2=A0

Cheers,
Ro= bert.

REF:=C2=A0https://to= ols.ietf.org/html/draft-ietf-grow-bgp-reject-06


--94eb2c041c70530d2c054ed5ca94-- From nobody Sat May 6 10:11:05 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@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" Cc: Warren Kumari , "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=94eb2c04b7c0d293d6054ede161c Archived-At: Subject: [bess] Point #3 on draft-ietf-grow-bgp-reject X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list 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:50 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@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" Cc: Warren Kumari , "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=001a1140574e038d29054ede1da5 Archived-At: Subject: Re: [bess] Point #3 on draft-ietf-grow-bgp-reject X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list 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 Sat May 6 10:54:26 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441C2129432 for ; Sat, 6 May 2017 10:54:17 -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=unavailable 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 8OEXVTgouF6I for ; Sat, 6 May 2017 10:54:16 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED26128616 for ; Sat, 6 May 2017 10:54:13 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id g49so23050659uaa.1 for ; Sat, 06 May 2017 10:54:13 -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=34vfjUqCs0gK7BO0ELDHABntz++3ym7GQeYOt5tC6wo=; b=f5U3ucE/pNmIRrieUtM04o+2yzH1J1EGZdZG8OkGkbiMg+KsfySQQ4aGSlG1473awH Vhjg/+1effuv2bukR3htAV/7cC7lMDKZyLbjxSY3KJkjG7rQ0MQnsTz8jdpoTR1TbGxZ yhSDCChrxN0JFsoZHI6J0AicXvM1FUoGthyoICptwjkd6Q9rrApssGW5VYcrlB+9zpGd c289udc3ImBkUIIBeU6gXxpsVeM+eoaCj1dPyE2YDe+TPTtUGU2044juXC/9t4c1UtHi 6rYcJLE3wR3lD2LicbEZFcQEDiWmeLB2nw2+DszDyMi52Mt6aV4GuGExbE/DUpPwVUo5 dulQ== 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=34vfjUqCs0gK7BO0ELDHABntz++3ym7GQeYOt5tC6wo=; b=NpT9H/bS9Se6Fn2BRyY0YTSTmArqETJwatOklThMzDlthTj1gpYNUDYlD3V3I4wBW/ 41HmywJzzddotwCEcNuHhReGKCMg/Y426rtfZwdMc8xFqGz0ZS4JWKjppNINwF3AohdI eKJ/KdL+fbxWt/givewkXOAx1StoagRn01vjdbnG7vR9v6LyBlyIOeC1tvFHjTGWIBrD Bw7lZKHX8DZvyRFGQoH4D1Bv0G9ZomBhtPKdUxB8vIT8rN+rZvAbDkkSN1MyOGXvFkM6 SAUmdvzgUiYB6jLnN4DewTHeAvr5Lo6m7eRi2+uoV9r9qaqEagOJ1YbISQAx0P5a5w2l 5/2Q== X-Gm-Message-State: AN3rC/6vqdfpzhNpOejq+i72bWJjYZroUR80YDmcadBnHP43eJzYkiWE TJ7aj2g6n/Rm54SjGPQ4T/ynW88GGCyz X-Received: by 10.159.32.67 with SMTP id 61mr23309742uam.133.1494093252193; Sat, 06 May 2017 10:54:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.80.235 with HTTP; Sat, 6 May 2017 10:53:31 -0700 (PDT) In-Reply-To: References: From: Warren Kumari Date: Sat, 6 May 2017 13:53:31 -0400 Message-ID: To: Robert Raszuk , draft-ietf-grow-bgp-reject.all@ietf.org Cc: "Alvaro Retana (aretana)" , "bess@ietf.org" , "grow@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [bess] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 17:54:17 -0000 [ + authors ] On Sat, May 6, 2017 at 3:16 AM, Robert Raszuk wrote: > Hi Warren, > >> This is clearly not unanimous/ not everyone is happy, but (in my view) >> there is *rough* consensus for this to progress. > > > The group of users of BGP which this update impacts the most are members > of BESS WG (cc-ed) and not IDR WG due to the fact that this proposal applies > to all AFI/SAFIs. I'll happily admit that I have not been following BESS at all, and so know very little of what y'all do ("Hi Bess!"). Alvaro, please advise if BESS is affected to the level that they should have been explicitly invited to comment? > IMO before you progress anywhere with this IETF LC BESS WG should express > their formal opinion on it. > > Example of in or out eBGP policy where you are sending MAC addresses in > EVPN AF needs to be provided and explained why it makes sense. Likewise > examples of RTC AF for L3VPN Inter-as needs to be discussed. > > Otherwise the group of people which defined a lot of non ISP uses of BGP may > be > suddenly surprised down the read for keeping them out of the loop and have > customers loosing reachability upon compliant non sequential router OS > upgrade. The authors are busy incorporating some final edits (including some suggested by Alvaro). I would have hoped that all affected parties would have seen the discussions on GROW / IDR / the IETF LC. I ask people to please withhold judgment until the new version is released. I'm about to board a plane (to Budapest), and will be out of email for many hours... W > > Cheers, > Robert. > > REF: https://tools.ietf.org/html/draft-ietf-grow-bgp-reject-06 > > -- 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 Sat May 6 17:47:33 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89169128C82; Sat, 6 May 2017 17:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 lMEvr_dQZky5; Sat, 6 May 2017 17:47:31 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 EC4AF128B37; Sat, 6 May 2017 17:47:30 -0700 (PDT) Received: from mb.local (c-174-62-74-200.hsd1.ca.comcast.net [174.62.74.200]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v470lTQU058186 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 7 May 2017 00:47:29 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-174-62-74-200.hsd1.ca.comcast.net [174.62.74.200] claimed to be mb.local To: Warren Kumari , Robert Raszuk , draft-ietf-grow-bgp-reject.all@ietf.org Cc: "grow@ietf.org" , "bess@ietf.org" References: From: joel jaeggli Message-ID: Date: Sat, 6 May 2017 17:47:23 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Thunderbird/53.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8K5iJBs5AtHaHMv6o1gPQM9cjVjL8OElI" Archived-At: Subject: Re: [bess] [GROW] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 00:47:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8K5iJBs5AtHaHMv6o1gPQM9cjVjL8OElI Content-Type: multipart/mixed; boundary="jBiQpq4umSh17tW7xTWvXHwIig8Rc1kKE"; protected-headers="v1" From: joel jaeggli To: Warren Kumari , Robert Raszuk , draft-ietf-grow-bgp-reject.all@ietf.org Cc: "grow@ietf.org" , "bess@ietf.org" Message-ID: Subject: Re: [GROW] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard References: In-Reply-To: --jBiQpq4umSh17tW7xTWvXHwIig8Rc1kKE Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/6/17 10:53 AM, Warren Kumari wrote: > [ + authors ] >=20 > On Sat, May 6, 2017 at 3:16 AM, Robert Raszuk wrote= : >> Hi Warren, >> >>> This is clearly not unanimous/ not everyone is happy, but (in my view= ) >>> there is *rough* consensus for this to progress. >> >> >> The group of users of BGP which this update impacts the most are membe= rs >> of BESS WG (cc-ed) and not IDR WG due to the fact that this proposal a= pplies >> to all AFI/SAFIs. I think this statement elides that the largest impact here is on operators, which might be participants of either working group but are by in large not at the ietf. As an operator the ability to make recommendations based on practice that has proven to be problematic is ought to be something others in the ietf would be interested in. e.g. default accept policies have been shooting operators in the foot with v4 and v6 unicast AFI's since literally the dawn of time. > I'll happily admit that I have not been following BESS at all, and so > know very little of what y'all do ("Hi Bess!"). Alvaro, please advise > if BESS is affected to the level that they should have been explicitly > invited to comment? >=20 >> IMO before you progress anywhere with this IETF LC BESS WG should expr= ess >> their formal opinion on it. >> >> Example of in or out eBGP policy where you are sending MAC addresses i= n >> EVPN AF needs to be provided and explained why it makes sense. Likewis= e >> examples of RTC AF for L3VPN Inter-as needs to be discussed. >> >> Otherwise the group of people which defined a lot of non ISP uses of B= GP may >> be >> suddenly surprised down the read for keeping them out of the loop and = have >> customers loosing reachability upon compliant non sequential router OS= >> upgrade. >=20 > The authors are busy incorporating some final edits (including some > suggested by Alvaro). I would have hoped that all affected parties > would have seen the discussions on GROW / IDR / the IETF LC. >=20 > I ask people to please withhold judgment until the new version is relea= sed. >=20 >=20 > I'm about to board a plane (to Budapest), and will be out of email for > many hours... > W >=20 > > >> Cheers, >> Robert. >=20 >> >> REF: https://tools.ietf.org/html/draft-ietf-grow-bgp-reject-06 >> >> >=20 >=20 >=20 --jBiQpq4umSh17tW7xTWvXHwIig8Rc1kKE-- --8K5iJBs5AtHaHMv6o1gPQM9cjVjL8OElI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlkObpsACgkQ8AA1q7Z/VrIolgCdH6lskPOrEMFIEGqUOqwCkicS l6oAnRwJUAfTkKgWSh/iOJO6l2q+64Hh =zsNf -----END PGP SIGNATURE----- --8K5iJBs5AtHaHMv6o1gPQM9cjVjL8OElI-- From nobody Sun May 7 10:05:45 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A38128796; Sun, 7 May 2017 10:05:35 -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-bess-evpn-vpws@ietf.org, aretana@cisco.com, "Zhaohui \(Jeffrey\) Zhang" , bess-chairs@ietf.org, zzhang@juniper.net, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149417673555.23196.14417727329971821809.idtracker@ietfa.amsl.com> Date: Sun, 07 May 2017 10:05:35 -0700 Archived-At: Subject: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 17:05:36 -0000 Warren Kumari has entered the following ballot position for draft-ietf-bess-evpn-vpws-13: 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-bess-evpn-vpws/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [ For -11 / -12 ] This document is very heavy on the acronyms, and could do with some expanding of these -- for example, the document starts out with "This document describes how EVPN can be used...". I'm no MPLS VPN person, so much time was spent searching to try figure out what everything meant. I also agree with Spencer's "In multihoming scenarios, both B and P flags MUST NOT be both set. " being hard to parse, and disagree with Acee that is it clear. [ For -13 ] The draft was revised to address Alia's DISCUSS, and also Spencer's "traditional way" and "both B and P flags MUST NOT be both set" comment, but still does not expand EVPN; I also agree with Spencer that it would be helpful to expand P2P on first use. I reread the document and have some additional comments - note that these are are only comments, but I think that they would make the document more readable... 1: Introduction: "that in EVPN terminology would mean a single pair of Ethernet Segments ES(es)." - I'm confused by the 'ES(es)' - guessing this was an editing failure and 'Ethernet Segments (ES)' was intended? If not, You use both "Ethernet AD" and "Ethernet A-D" - please choose and stick with one. 1.1: Terminology: "EVI: EVPN Instance." -- Ok, but EVPN is still not defined / referenced. 3.1 EVPN Layer 2 attributes extended community " A PE that receives an update with both B and P flags set MUST treat the route as a withdrawal. If the PE receives a route with both B and P clear, it MUST treat the route as a withdrawal from the sender PE." Do the above 2 sentences say the same thing? It sure sounds like repetition, if not, please explain the difference. If not, removing one would make this less confusing. Figure 3: EVPN-VPWS Deployment Model You use the terms / labels "PSN1", "PSN2" - what are these? "Provider Network"? From nobody Sun May 7 10:35:21 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C86128B4E; Sun, 7 May 2017 10:35:19 -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 otDTb3wqExHW; Sun, 7 May 2017 10:35:17 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 65CE512441E; Sun, 7 May 2017 10:35:17 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id f102so38198261ioi.2; Sun, 07 May 2017 10:35:17 -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=pmjHCazBBctvnUeBL8x/jhcY7Wwz83AiqCvtXo5GjTk=; b=Ee/Ru6kHUjw1a+63kHnD0if5KsJtDyofltHc+Rp+/kie13y0uHqNADjLjl9Zel1pO1 IktemjEtWgemNH87S7RijpYF8eFwFmJPWI4OmmEkbpuvrDMarvq5vgBrV9gqjb/K1p2/ MrSAAn4FxoUYjEi8wkG9hm/Qb/6NPf78Yp7sDwqcMIYqNa46e4ivQc4wnzuTi7ofZu4J qOdD561JOZtD+lLARijJqIBJLbOpuhbXtPeHnAWkguy/kHz9qzrK9iCUAYy/qBZ7OxzN YSX/nxUIBh3qnPuzkuLqgOy2yZY7toX2KJrsJEVt9Kn4eCVhNREVM+Px5fRTg/vOVwb2 KgBA== 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=pmjHCazBBctvnUeBL8x/jhcY7Wwz83AiqCvtXo5GjTk=; b=pVYCViPz2grP87MnJ5BJQRh46eT0/apmPcD3HjbEVt59fd+/pJY+1kQ4OlnF5X8PSb XcPxZGMyE99zEDmc8VePad3jyEcyn7hGYtUYJe/amMyasu4aVQVwnMwvxtnLB6774TXt Bdt5LiI3IgpXqevV6kZ7OYJLBzEqugFNrwzT2Ynr530Hg1BKQSUhHfI1rZPOEnZQQ5GK x6hylaIF9RLINm82gdUrG3FrK0AAN6r+JUSaAD7d2UdYjThYTacgBP7CFPmFcLyWrtXg xPuNMq0JRJIe4Gm5wa2E1kFmKha34NZDjk6HXwWUXMskSC9ko0ftvK+B0sC7JNTjuz3P 86UQ== X-Gm-Message-State: AN3rC/7+Nu4GIczzFS6IyNimaR6AzPYVvqV27dbFBOlNtzNC1vqMMYdP f6LxZwlsvn6SgIhPag2CM/z0NG18eA== X-Received: by 10.107.5.12 with SMTP id 12mr46535584iof.186.1494178516776; Sun, 07 May 2017 10:35:16 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Sun, 7 May 2017 10:35:16 -0700 (PDT) In-Reply-To: <149417673555.23196.14417727329971821809.idtracker@ietfa.amsl.com> References: <149417673555.23196.14417727329971821809.idtracker@ietfa.amsl.com> From: Robert Raszuk Date: Sun, 7 May 2017 19:35:16 +0200 X-Google-Sender-Auth: UVjnOgDvvOt9GQN3R7sbW36Ceag Message-ID: To: Warren Kumari Cc: The IESG , "Jeffrey (Zhaohui) Zhang" , draft-ietf-bess-evpn-vpws@ietf.org, bess-chairs@ietf.org, "bess@ietf.org" , "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=001a113ef634b94289054ef28b9a Archived-At: Subject: Re: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 17:35:20 -0000 --001a113ef634b94289054ef28b9a Content-Type: text/plain; charset=UTF-8 Hi Warren, In the draft you have reviewed EVPN term is use interchangeably with term [RFC7432] which in turn is also already listed and defined in the Normative References section (2nd from the top). Personally if you assume that the reader of this document is not familiar with EVPN I would also recommend to read few other L2 VPN related documents as prerequisite before jumping to this one: - RFC 7209 and all VPN related documents included in its references - RFC 7432 and all VPN related documents included in its references - all VPN related documents included in references of draft-ietf-bess-evpn-vpws - only then the draft in question itself. Kind regards, Robert. On Sun, May 7, 2017 at 7:05 PM, Warren Kumari wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-bess-evpn-vpws-13: 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-bess-evpn-vpws/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [ For -11 / -12 ] > This document is very heavy on the acronyms, and could do with some > expanding of these -- for example, the document starts out with "This > document describes how EVPN can be used...". I'm no MPLS VPN person, so > much time was spent searching to try figure out what everything meant. > > I also agree with Spencer's "In multihoming scenarios, both B and P flags > MUST NOT be both set. " being hard to parse, and disagree with Acee that > is it clear. > > [ For -13 ] > The draft was revised to address Alia's DISCUSS, and also Spencer's > "traditional way" and "both B and P flags MUST NOT be both set" comment, > but still does not expand EVPN; I also agree with Spencer that it would > be helpful to expand P2P on first use. I reread the document and have > some additional comments - note that these are are only comments, but I > think that they would make the document more readable... > > 1: Introduction: > "that in EVPN terminology would mean a single pair of Ethernet Segments > ES(es)." - I'm confused by the 'ES(es)' - guessing this was an editing > failure and 'Ethernet Segments (ES)' was intended? If not, > > You use both "Ethernet AD" and "Ethernet A-D" - please choose and stick > with one. > > 1.1: Terminology: > "EVI: EVPN Instance." -- Ok, but EVPN is still not defined / > referenced. > > 3.1 EVPN Layer 2 attributes extended community > " A PE that receives an update with both B and P flags set MUST treat > the > route as a withdrawal. If the PE receives a route with both B and P > clear, it MUST treat the route as a withdrawal from the sender PE." > Do the above 2 sentences say the same thing? It sure sounds like > repetition, if not, please explain the difference. If not, removing one > would make this less confusing. > > Figure 3: EVPN-VPWS Deployment Model > You use the terms / labels "PSN1", "PSN2" - what are these? "Provider > Network"? > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > --001a113ef634b94289054ef28b9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Warren,

=
In the draft you have reviewed EVPN term is use in= terchangeably with term [RFC7432] which in turn is also already listed and = defined in the Normative References section (2nd from the top).=C2=A0
=

Personally if you assume th= at the reader of this document is not familiar with EVPN I would also recom= mend to read few other L2 VPN related documents as prerequisite before jump= ing to this one:=C2=A0

- RFC 7209 and all VPN related documents included in its references

- RFC 7432 and all VPN r= elated documents included in its references

- all VPN related documents included in references of= draft-ietf-bess-evpn-vpws

- only then the draft in question itself.

=
Kind regards,
Robert.


On Sun, May 7, 2017 at 7:05 PM, Warren Kumari <warren@= kumari.net> wrote:
Warren K= umari has entered the following ballot position for
draft-ietf-bess-evpn-vpws-13: 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/<= wbr>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/dra= ft-ietf-bess-evpn-vpws/



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

[ For -11 / -12 ]
This document is very heavy on the acronyms, and could do with some
expanding of these -- for example, the document starts out with "This<= br> document describes how EVPN can be used...". I'm no MPLS VPN perso= n, so
much time was spent searching to try figure out what everything meant.

I also agree with Spencer's "In multihoming scenarios, both B and = P flags
MUST NOT be both set. " being hard to parse, and disagree with Acee th= at
is it clear.

[ For -13 ]
The draft was revised to address Alia's DISCUSS, and also Spencer's=
"traditional way" and "both B and P flags MUST NOT be both s= et" comment,
but still does not expand EVPN; I also agree with Spencer that it would
be helpful to expand P2P on first use.=C2=A0 I reread the document and have=
some additional comments - note that these are are only comments, but I
think that they would make the document more readable...

1: Introduction:
"that in EVPN terminology would mean a single pair of Ethernet Segment= s
ES(es)." - I'm confused by the 'ES(es)' - guessing this wa= s an editing
failure and 'Ethernet Segments (ES)' was intended? If not,

You use both "Ethernet AD" and "Ethernet A-D" - please = choose and stick
with one.

1.1: Terminology:
"EVI: EVPN Instance." --=C2=A0 Ok, but EVPN is still not defined = /
referenced.

3.1=C2=A0 EVPN Layer 2 attributes extended community
" A PE that receives an update with both B and P flags set MUST treat<= br> the
=C2=A0route as a withdrawal. If the PE receives a route with both B and P =C2=A0clear, it MUST treat the route as a withdrawal from the sender PE.&qu= ot;
Do the above 2 sentences say the same thing? It sure sounds like
repetition, if not, please explain the difference. If not, removing one
would make this less confusing.

Figure 3: EVPN-VPWS Deployment Model
You use the terms / labels "PSN1", "PSN2" - what are th= ese? "Provider
<something> Network"?


_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

--001a113ef634b94289054ef28b9a-- From nobody Sun May 7 12:43:29 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69292127201 for ; Sun, 7 May 2017 12:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 BBUQYvxEhsgd for ; Sun, 7 May 2017 12:43:25 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c: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 A41491292CE for ; Sun, 7 May 2017 12:43:23 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id v20so19344194vke.2 for ; Sun, 07 May 2017 12:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T2ce9X6hs5NofkCt9n7S9a2U2cigUTFW3LeAAMVSSFs=; b=nJm9fgX4j8JMRh1vFnTi+tOWqTG7LX+TiM/NyAJmyAVUulA6oJKWu4Ybs3rPrM4l7C 6w2k/1M9hoz+vOlN2tSHzzY2RYGLWtHnsx6tK3BiLITmZPYEqqIanYT32epSwhAf8xoO 6Tpyluh7vPsbyG0azjqf3G0m5MlfAYEwf3JRturKhq5b6PpLvSJ3/eyV6viPwvA15Pbl MdezJN60LD2wxVgShf3nTuz+nAgZr9MrH3uvXRV6fdW69nN9gM78DBFwJ2NvV/CZ+rAQ LCw274zd9sEMv6Z5AFBxnEz6ATBArKiFIYnoOeuWzDcxMpIEArKFyj9rg2nojWB7t9lW nn8A== 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=T2ce9X6hs5NofkCt9n7S9a2U2cigUTFW3LeAAMVSSFs=; b=r4loeeK9fih3xqaSOGwMZcqokdcIlIGaA0JHkwtlsjCvdQ5AKM9nUqw0eztEc6J82l pWUP3OTOwpIIJp0ePYO0awWoVW+gA4s15YJUcqg5rz60ceVg/5Mi02K8xJdqNVCLwOTG YW/Fmf0eSi5GQq291GAoHhWye4623lvaMan2XVhNEYJVRDUpnWYU1RD2jUZVpuQRR9iO nKG2SvrZmgo12RPlnpDcJjz8vWCKxtQqbT9Z1NTdDOFT1ZnGMC6g87qhFsUsXkyFXr6x a0uvchYiq503ekcLQKNrhejgzn+2ekWVE0Q4TZBvlbYVgk1p6GPXCk6wsqcoCkCbpVo5 QOUg== X-Gm-Message-State: AN3rC/5h2THALLnK2Mj15I6N7BJI/NV/9K81yA3lUt5XP7ntpaNJNqgg MzTwlxUuXhSNCbWu5KmkHrAhY2eCYr5N X-Received: by 10.31.96.8 with SMTP id u8mr8956595vkb.124.1494186202638; Sun, 07 May 2017 12:43:22 -0700 (PDT) MIME-Version: 1.0 References: <149417673555.23196.14417727329971821809.idtracker@ietfa.amsl.com> In-Reply-To: From: Warren Kumari Date: Sun, 07 May 2017 19:43:12 +0000 Message-ID: To: Robert Raszuk Cc: "Alvaro Retana (aretana)" , "Jeffrey (Zhaohui) Zhang" , The IESG , bess-chairs@ietf.org, "bess@ietf.org" , draft-ietf-bess-evpn-vpws@ietf.org Content-Type: multipart/alternative; boundary=001a114e61b8d63cf6054ef45564 Archived-At: Subject: Re: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 19:43:27 -0000 --001a114e61b8d63cf6054ef45564 Content-Type: text/plain; charset=UTF-8 On Sun, May 7, 2017, 7:35 PM Robert Raszuk wrote: > Hi Warren, > > In the draft you have reviewed EVPN term is use interchangeably with term > [RFC7432] which in turn is also already listed and defined in the Normative > References section (2nd from the top). > Yes, and I read RFC7432 when I first reviewed this document - but I only knew that was the one to read after grepping though RFCs for "EVPN" -- is there any reason for the authirs *not* to make things easier for your readers by saying: " This document describes how EVPN [RFC7432] can be ..."? > Personally if you assume that the reader of this document is not familiar > with EVPN I would also recommend to read few other L2 VPN related documents > as prerequisite before jumping to this one: > > - RFC 7209 and all VPN related documents included in its references > > - RFC 7432 and all VPN related documents included in its references > > - all VPN related documents included in references of > draft-ietf-bess-evpn-vpws > That sounds like a fine idea - perhaps the authors should add something like "Readers of this document are expected to be familiar with RFC7209 and RFC7432." Mainly I don't understand why we wouldn't want to make it easier for someone new to the technology... W > - only then the draft in question itself. > > Kind regards, > Robert. > > > On Sun, May 7, 2017 at 7:05 PM, Warren Kumari wrote: > >> Warren Kumari has entered the following ballot position for >> draft-ietf-bess-evpn-vpws-13: 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-bess-evpn-vpws/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> [ For -11 / -12 ] >> This document is very heavy on the acronyms, and could do with some >> expanding of these -- for example, the document starts out with "This >> document describes how EVPN can be used...". I'm no MPLS VPN person, so >> much time was spent searching to try figure out what everything meant. >> >> I also agree with Spencer's "In multihoming scenarios, both B and P flags >> MUST NOT be both set. " being hard to parse, and disagree with Acee that >> is it clear. >> >> [ For -13 ] >> The draft was revised to address Alia's DISCUSS, and also Spencer's >> "traditional way" and "both B and P flags MUST NOT be both set" comment, >> but still does not expand EVPN; I also agree with Spencer that it would >> be helpful to expand P2P on first use. I reread the document and have >> some additional comments - note that these are are only comments, but I >> think that they would make the document more readable... >> >> 1: Introduction: >> "that in EVPN terminology would mean a single pair of Ethernet Segments >> ES(es)." - I'm confused by the 'ES(es)' - guessing this was an editing >> failure and 'Ethernet Segments (ES)' was intended? If not, >> >> You use both "Ethernet AD" and "Ethernet A-D" - please choose and stick >> with one. >> >> 1.1: Terminology: >> "EVI: EVPN Instance." -- Ok, but EVPN is still not defined / >> referenced. >> >> 3.1 EVPN Layer 2 attributes extended community >> " A PE that receives an update with both B and P flags set MUST treat >> the >> route as a withdrawal. If the PE receives a route with both B and P >> clear, it MUST treat the route as a withdrawal from the sender PE." >> Do the above 2 sentences say the same thing? It sure sounds like >> repetition, if not, please explain the difference. If not, removing one >> would make this less confusing. >> >> Figure 3: EVPN-VPWS Deployment Model >> You use the terms / labels "PSN1", "PSN2" - what are these? "Provider >> Network"? >> >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > > --001a114e61b8d63cf6054ef45564 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, May 7, 2017, 7:= 35 PM Robert Raszuk <robert@raszuk.= net> wrote:
Hi Warren,

In the draft you have reviewed EVPN term is use interchangeably wi= th term [RFC7432] which in turn is also already listed and defined in the N= ormative References section (2nd from the top).=C2=A0


= Yes, and I =C2=A0read RFC7432 when I first reviewed this document - but I o= nly knew that was the one to read after grepping though RFCs for "EVPN= " -- is there any reason for the authirs *not* to make things easier f= or your readers by saying: "
This document describes how EVPN [R= FC7432] can be ..."?

Personally if you assume that the reader of this = document is not familiar with EVPN I would also recommend to read few other= L2 VPN related documents as prerequisite before jumping to this one:=C2=A0=

- RFC 7209 and all VP= N related documents included in its references
=
- RFC 7432 and all VPN related documents inclu= ded in its references

= - all VPN related documents included in references of draft-ietf-bess-evpn-= vpws

=
That sounds like a fine idea - perhaps the authors should add somethin= g like "Readers of this document are expected to be familiar with RFC7= 209 and RFC7432."
Mainly I don't understand why we would= n't want to make it easier for someone new to the technology...

W




- only then the draft in questio= n itself.

Kind regards= ,
Robert.


On Sun, May 7, 2017 at 7:= 05 PM, Warren Kumari <warren@kumari.net> wrote:
Warren Kumari has entered the following ballot position for draft-ietf-bess-evpn-vpws-13: 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/s= tatement/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-ie= tf-bess-evpn-vpws/



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

[ For -11 / -12 ]
This document is very heavy on the acronyms, and could do with some
expanding of these -- for example, the document starts out with "This<= br> document describes how EVPN can be used...". I'm no MPLS VPN perso= n, so
much time was spent searching to try figure out what everything meant.

I also agree with Spencer's "In multihoming scenarios, both B and = P flags
MUST NOT be both set. " being hard to parse, and disagree with Acee th= at
is it clear.

[ For -13 ]
The draft was revised to address Alia's DISCUSS, and also Spencer's=
"traditional way" and "both B and P flags MUST NOT be both s= et" comment,
but still does not expand EVPN; I also agree with Spencer that it would
be helpful to expand P2P on first use.=C2=A0 I reread the document and have=
some additional comments - note that these are are only comments, but I
think that they would make the document more readable...

1: Introduction:
"that in EVPN terminology would mean a single pair of Ethernet Segment= s
ES(es)." - I'm confused by the 'ES(es)' - guessing this wa= s an editing
failure and 'Ethernet Segments (ES)' was intended? If not,

You use both "Ethernet AD" and "Ethernet A-D" - please = choose and stick
with one.

1.1: Terminology:
"EVI: EVPN Instance." --=C2=A0 Ok, but EVPN is still not defined = /
referenced.

3.1=C2=A0 EVPN Layer 2 attributes extended community
" A PE that receives an update with both B and P flags set MUST treat<= br> the
=C2=A0route as a withdrawal. If the PE receives a route with both B and P =C2=A0clear, it MUST treat the route as a withdrawal from the sender PE.&qu= ot;
Do the above 2 sentences say the same thing? It sure sounds like
repetition, if not, please explain the difference. If not, removing one
would make this less confusing.

Figure 3: EVPN-VPWS Deployment Model
You use the terms / labels "PSN1", "PSN2" - what are th= ese? "Provider
<something> Network"?


_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

--001a114e61b8d63cf6054ef45564-- From nobody Sun May 7 13:05:45 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7328C12932A; Sun, 7 May 2017 13:05:36 -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 d93C9woNlNyx; Sun, 7 May 2017 13:05:33 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 B2F5E120721; Sun, 7 May 2017 13:05:33 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id k91so39665230ioi.1; Sun, 07 May 2017 13:05:33 -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=AUJ3/PJg/ql2PmtClptSyQ0xK/plpLvJfByVi47fryI=; b=h9oOFVrztO3kZtryIto2Z1BA8sY3DAqzuNONJisMegxYbFneFQWu+YlhOQsjjM74N9 b3Nj+JE95nV5CNK26L50xvqlrGv36frUm/vehLEQ2mMhL01EDxeGwBfrIRRSYs8//Y1M joQnMzb5Q5CMapCDTKvdv+GlBo9qRLRyyE1cU3YNPYJ4WjJqbjjkkXWT+N2sqyTaloUa 1OY+MFS0g1Yza1mm3LYH0ri6Rc0AXWWNapqLOrQM0QNWvHZXZZApTFpn/bnXjqoTMISv xOdU536ccqTuV5nUfXnvaeaQE2mu4xi0LvSY6KwS2HorXmTp4wcxqEl1p5rASoMkPWlM pskw== 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=AUJ3/PJg/ql2PmtClptSyQ0xK/plpLvJfByVi47fryI=; b=JwzKbykXokEtgW9f7EhzUlQdDMK/xJ7WJTAhNsEcgOj+p1AYAM9q1LIeAM/4BF1hTw PNHCuMSJ/+CmvcswEpgRw2RdV4psa3CBix5eEVwLwN3CssfYpr3qZ5FUVrJXRi3FBlCq fyNH6XdJRYCS3dhffQGdqv8zEXZbmt6lgfrK6uToSnLY0wOwBEDtVK66y8fbiCza9yyW 8L7i93wNM1Qwq3/DPGYEh/o5ULIefyUcpPazAA2LZxAbItoHduEyrKn1M11Gwu+as1/l Y+a1DCv+shexmeYXLOSUrLT0hPx4aPG2CjO3pLgf4qPNorxZMI+QNCED4q3EZLj2Z3Vi 2yTA== X-Gm-Message-State: AN3rC/4YY72jkZeumpmIZBpZPXExi2XrSjdiRzt3CrqOuWsaODgYM/dy jSHET2HJ3g3CiyufPUwJZkvr4tm/ig== X-Received: by 10.107.189.198 with SMTP id n189mr54351850iof.179.1494187533072; Sun, 07 May 2017 13:05:33 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Sun, 7 May 2017 13:05:32 -0700 (PDT) In-Reply-To: References: <149417673555.23196.14417727329971821809.idtracker@ietfa.amsl.com> From: Robert Raszuk Date: Sun, 7 May 2017 22:05:32 +0200 X-Google-Sender-Auth: 45ibfCzaUslIftmT1jMScvu41fw Message-ID: To: Warren Kumari Cc: "Alvaro Retana (aretana)" , "Jeffrey (Zhaohui) Zhang" , The IESG , bess-chairs@ietf.org, "bess@ietf.org" , draft-ietf-bess-evpn-vpws@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0c85e42300e1054ef4a5c4 Archived-At: Subject: Re: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 20:05:37 -0000 --94eb2c0c85e42300e1054ef4a5c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > is there any reason for the authirs *not* to make things easier for your > readers by saying: " > This document describes how EVPN [RFC7432] can be ..."? > =E2=80=8BThat clearly is a good edit suggestion for all alone occurrences o= f [RFC7432] in the draft. =E2=80=8B That sounds like a fine idea - perhaps the authors should add something > like "Readers of this document are expected to be familiar with RFC7209 a= nd > RFC7432." > Mainly I don't understand why we wouldn't want to make it easier for > someone new to the technology... > =E2=80=8BI think in number of IETF drafts extending existing specifications= there is an implicit assumption that the reader is =E2=80=8Bfamiliar with the bas= e spec or specs around it related to new work. IMHO normative or informative references is a good place for it. So Adding RFC7209 to the latter may be indeed helpful. - - - Regarding the draft itself my personal comment is that just like other specs defining VPWS service this proposal also fails to include OEM section describing or even defining tools which will allow user of such emulated circuit to get all errors (or even MTU fluctuations) from the underlay it traverses to be exposed and reported to the wire/circuit end points. Being on the enterprise side which uses such circuits I can only see now that there is huge missing gap between providing spec to construct given service and the perspective of actual use of such emulated wires established over third party IP or IP/MPLS networks. IMO OEM NNI between those two planes should be made mandatory in all specs. Kind regards, //Robert. --94eb2c0c85e42300e1054ef4a5c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0
is there any reason for the authirs *not* to make things easier for yo= ur readers by saying: "
This document describes how EVPN [RFC743= 2] can be ..."?

=E2=80=8BThat clearly is a good edit suggestion for all alone occ= urrences of [RFC7432] in the draft. =E2=80=8B


That sounds like a fi= ne idea - perhaps the authors should add something like "Readers of th= is document are expected to be familiar with RFC7209 and RFC7432."
=
Mainly I don't understand why we wouldn't want to= make it easier for someone new to the technology...


=E2=80=8BI think in numbe= r of IETF drafts extending existing specifications there is an implicit ass= umption that the reader is =E2=80=8Bfamiliar with the base spec or specs ar= ound it related to new work. IMHO normative or informative references is a = good place for it. So Adding RFC7209 to the latter may be indeed helpful.

- - -

Regarding the draft itself my persona= l comment is that just like other specs defining VPWS service this proposal= also fails to include OEM section describing or even defining tools which = will allow user of such emulated circuit to get all errors (or even MTU flu= ctuations) from the underlay it traverses to be exposed and reported to the= wire/circuit end points.=C2=A0

Being on the enterprise side which uses such circuits I can only = see now that there is huge missing gap between providing spec to construct = given service and the perspective of actual use of such emulated wires esta= blished over third party IP or IP/MPLS networks.=C2=A0

IMO OEM NNI between those two planes shoul= d be made mandatory in all specs.

Kind regards,
//Robert.

--94eb2c0c85e42300e1054ef4a5c4-- From nobody Sun May 7 13:54:17 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A971279E5 for ; Sun, 7 May 2017 13:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 FwlFu8fiL6Ys for ; Sun, 7 May 2017 13:54:08 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 A513A128D19 for ; Sun, 7 May 2017 13:54:05 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id 203so21660110ywe.0 for ; Sun, 07 May 2017 13:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CHUEkeGgqqX+6SxG02d0NQEF6wENEy+DKxEk4Lj2TaM=; b=TlOgKmKmxtAE8KO4NqolEkqEq6Oaun4ajHNCbp8nPuX1uXrtudL11QZRD4AHAqXeYL R7EPq53IBj7fjFySJY3n1ZhRsP/LqjL5N+HLw0iF67pVrGoS96rUC43FaAVQZcHedIuj 5LdXdCYW1M+E46IAy3ObbFbTHx6ICweC7iyrj6wR/n9Y9uS0h9/Av1mm9GD9A5SyFb7t hF6g/hxpaPjhBEIcdYD/yMQvjXVDMUBRF1ZWiC2BogmRkuqZWrog9Fd+J322CAt6551D n0k8WwZBG1Q23X7kNoVUxPNUHQ6A+mthvQBxhWSNaYYTg1w4PQin/dcWzCvIuhCrEGFQ na1Q== 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=CHUEkeGgqqX+6SxG02d0NQEF6wENEy+DKxEk4Lj2TaM=; b=bsqmd47+Q2FQQTnHxxWET6ceGN67UIGXJ2v2eE1Tyb3z1Ad4kQCQTQeSRre5K75pB0 zNmocdXBLcduTxxsNFBmqk6pl7LiWbNGu/TUZMtBmFGLNGMGRtf0I4p6++uiZQX51oyA bNohhm+wAD3Oco9m1mzHOy1BWSnhyiEKVlk7tGILBFJlQf54XQeLt+Z7YG1RxzLdYDDk pflTNna+lgv90xnJ7oYmJGqRqdRkgbsZazBGMfB2y8ZovdiVj06r94jXS/nqPZN6weDE zuV0O0mU9+Cfly49EPox9Ut2aWg5bWFgcyuPsXvOLFcdZ/VNESX7X8Qo5d6VRbNLpPSa ZeLQ== X-Gm-Message-State: AODbwcAPWbHmvRqBS6UPVBxCAsW22vil/WyeD5+FhqWfPawkBi6pOQk4 cGYJv3R6OfKPhr7Q7VDi54CVtWVEBA== X-Received: by 10.129.146.210 with SMTP id j201mr5611665ywg.3.1494190444897; Sun, 07 May 2017 13:54:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Sun, 7 May 2017 13:53:24 -0700 (PDT) In-Reply-To: References: <149417673555.23196.14417727329971821809.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Sun, 7 May 2017 13:53:24 -0700 Message-ID: To: Robert Raszuk Cc: Warren Kumari , draft-ietf-bess-evpn-vpws@ietf.org, "Jeffrey (Zhaohui) Zhang" , The IESG , "Alvaro Retana (aretana)" , bess-chairs@ietf.org, "bess@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c092a40b1f202054ef55210 Archived-At: Subject: Re: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 20:54:09 -0000 --94eb2c092a40b1f202054ef55210 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, May 7, 2017 at 1:05 PM, Robert Raszuk wrote: > > >> is there any reason for the authirs *not* to make things easier for your >> readers by saying: " >> This document describes how EVPN [RFC7432] can be ..."? >> > > =E2=80=8BThat clearly is a good edit suggestion for all alone occurrences= of > [RFC7432] in the draft. =E2=80=8B > > > That sounds like a fine idea - perhaps the authors should add something >> like "Readers of this document are expected to be familiar with RFC7209 = and >> RFC7432." >> Mainly I don't understand why we wouldn't want to make it easier for >> someone new to the technology... >> > > > =E2=80=8BI think in number of IETF drafts extending existing specificatio= ns there > is an implicit assumption that the reader is =E2=80=8Bfamiliar with the b= ase spec > or specs around it related to new work. > I'm sure this is true, but as someone who reads a lot of specs, this one is unusually reader-unfriendly to someone who is being asked to pick it up and review it. It's not unreasonable to expect that: 1. Acronyms be expanded on first use. 2. Terms of art come with citations to where they are defined. -Ekr --94eb2c092a40b1f202054ef55210 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, May 7, 2017 at 1:05 PM, Robert Raszuk <robert@raszuk.net&g= t; wrote:
=C2=A0=
is= there any reason for the authirs *not* to make things easier for your read= ers by saying: "
This document describes how EVPN [RFC7432] can = be ..."?

=E2=80=8BThat = clearly is a good edit suggestion for all alone occurrences of [RFC7432] in= the draft. =E2=80=8B


That sounds like a fine idea - perhaps = the authors should add something like "Readers of this document are ex= pected to be familiar with RFC7209 and RFC7432."
= Mainly I don't understand why we wouldn't want to make it easier fo= r someone new to the technology...

=E2=80=8BI think in number of IETF drafts extending existing= specifications there is an implicit assumption that the reader is =E2=80= =8Bfamiliar with the base spec or specs around it related to new work.

I'm sure this= is true, but as someone who reads a lot of specs, this one is unusually
reader-unfriendly to someone who is being asked to pick it up and r= eview it. It's
not unreasonable to expect that:
1. Acronyms be expanded on first use.
2. Terms of art= come with citations to where they are defined.

-E= kr
=C2=A0
--94eb2c092a40b1f202054ef55210-- From nobody Sun May 7 15:55:40 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D083126CF9; Sun, 7 May 2017 15:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.802 X-Spam-Level: X-Spam-Status: No, score=-4.802 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_H2=-2.8, 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 i79tLVsQioZI; Sun, 7 May 2017 15:55:29 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0125.outbound.protection.outlook.com [104.47.37.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 583EE126C3D; Sun, 7 May 2017 15:55: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=erycTIpK2c3Y4SOaHehwE51E2SRSbklkGn2s4qR84h4=; b=P78/0VoEp5FyLX0fYwLB0M2R445iIylf7JGXYq6Vp6F24shAlrsKBGcsl8nNvIntdlohygOW1UtIXg5+xR/6HS9y4F7PAjagkGGuZYZTSYHGXmyyhNn3nGGyxQJWns0FSLeEXaEnBWX1Jcjax2TBDtWY7BdAklWhot6LKtnVIbY= Received: from CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) by CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Sun, 7 May 2017 22:55:27 +0000 Received: from CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) by CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) with mapi id 15.01.1084.015; Sun, 7 May 2017 22:55:27 +0000 From: John Scudder To: Eric Rescorla CC: "draft-ietf-bess-evpn-vpws@ietf.org" , The IESG , "bess@ietf.org" Thread-Topic: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with COMMENT) Thread-Index: AQHSx4UEvx2VRRs2VkqDI9R/IkR1lg== Date: Sun, 7 May 2017 22:55:27 +0000 Message-ID: <00E6B9C6-645D-4363-8174-12D3C6EE4615@juniper.net> References: <149417673555.23196.14417727329971821809.idtracker@ietfa.amsl.com> In-Reply-To: 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=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [75.151.14.9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR05MB2507; 7:S2fScsOkRRuQdlW5NPeoxMPvPEvR2PvvZmIA+4EjHuBJlAF/fZ6WGna/RqqtsXaGt6r6p7oSrZGDCy/BwzI/QzRWr+ay8+w5+R6G9uBhPdITkBTRa/u4meNiT+rf1PQuGW5SFzyo5+wlYcuMTfAuPKTKYS1qB5EHAqENYzzE8cIpv0Iur0+TAupWRMjyk2F3KjAh9a7jbcfSl463Qh75DgJnBHCI4CIT/VyntAC3sHJByep5zxM9P9g57PV8Wt7QydBgwVp/lP8jT9IOIGnB2ztY+q9fF/Obljlgkbk2z49JDgZJOWp4/O7DPoog+ecUqpH3WtC6ccjNbwsI7lf2qQ== x-ms-office365-filtering-correlation-id: 9469af63-f12c-40a5-4bcb-08d4959c278f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:CY1PR05MB2507; 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)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39400400002)(39850400002)(39410400002)(24454002)(377454003)(305945005)(6916009)(110136004)(2950100002)(38730400002)(558084003)(3660700001)(3280700002)(7736002)(229853002)(93886004)(8936002)(25786009)(8676002)(81166006)(230783001)(478600001)(76176999)(82746002)(2900100001)(83716003)(4326008)(66066001)(189998001)(36756003)(6512007)(53936002)(3846002)(6116002)(102836003)(5660300001)(54906002)(50986999)(54356999)(99286003)(86362001)(2906002)(122556002)(77096006)(6486002)(6436002)(33656002)(6506006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:CY1PR05MB2507.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <357DA200AD9E9646A9A9D4826A647134@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2017 22:55:27.6291 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Subject: Re: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 22:55:31 -0000 On May 7, 2017, at 4:53 PM, Eric Rescorla wrote: >=20 > It's > not unreasonable to expect that: >=20 > 1. Acronyms be expanded on first use. All the more so since the RFC Editor will insist on this anyway. --John From nobody Mon May 8 12:49:52 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AD81296C9; Mon, 8 May 2017 12:49:51 -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 y_9Yo8-NwoiX; Mon, 8 May 2017 12:49:50 -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 ECC40124D37; Mon, 8 May 2017 12:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1040; q=dns/txt; s=iport; t=1494272990; x=1495482590; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OgZP5wFsioPNG1VV/1OzHVSeVqZb4LzRDZRTOH3LVZo=; b=NJ+bqHMEvxDoY33m/htfXBqXMwlFNNvjp9ou+4LzEQtzqnxrzqVYeHdO +GzHKkmDjN5fJYCcXeBhOW8GWe0nXWklFtJ1kHZ7jDqOs+B66oc1PlEpY 5ovcrWLyFqqwc1HoJzBosX0izPPrb/S2GsAc8RhsPe81tmGxHrOoySzEk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AQAGyxBZ/5pdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1WBbgeDYYoYkTaWE4IPhiQCGoRLPxgBAgEBAQEBAQFrKIUWBiMRRRA?= =?us-ascii?q?CAQgaAh8HAgICMBUQAgQBDQWKILNjgiaKdQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?R2BC4VUgV4rC4JlhGODCi6CEh8BBJZmhxMBkxeCBIU8iiyIfItBAR84gQpwFVg?= =?us-ascii?q?BhRaBSnaHXoENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,310,1491264000"; d="scan'208";a="24773882" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2017 19:49:48 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v48Jnm2l031132 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 May 2017 19:49:49 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 8 May 2017 14:49:48 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Mon, 8 May 2017 14:49:48 -0500 From: "Alvaro Retana (aretana)" To: Warren Kumari , Robert Raszuk , "draft-ietf-grow-bgp-reject.all@ietf.org" CC: "bess@ietf.org" , "grow@ietf.org" Thread-Topic: IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard Thread-Index: AQHSxji99stFecQnLU2C/b5WAbJ/26Hn6riAgAMCGIA= Date: Mon, 8 May 2017 19:49:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/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: <098051FF8144AC4996D4DE425A25D814@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 19:49:52 -0000 SGkhDQoNClRoZSB3YXkgSSBzZWUgaXQsIHRoZSBjaGFuZ2UgcHJvcG9zZWQgaW4gdGhpcyBkb2N1 bWVudCBpcyBhIGNoYW5nZSB0byB0aGUgYmFzZSBCR1Agc3BlYyDigJMgYXMgc3VjaCwgbWFueS9h bGwgdXNlcnMgb2YgQkdQIHdpbGwgYmUgYWZmZWN0ZWQuICBJIGV4cGVjdCBiZXNzIHBhcnRpY2lw YW50cyB0byBhbHNvIHBhcnRpY2lwYXRlIGluIGlkciDigJMgSSBkb27igJl0IHNlZSB0aGUgbmVl ZCB0byBleHRlbmQgdGhlIGRpc2N1c3Npb24uDQoNCkFsdmFyby4NCg0KDQpPbiA1LzYvMTcsIDE6 NTMgUE0sICJXYXJyZW4gS3VtYXJpIiA8d2FycmVuQGt1bWFyaS5uZXQ+IHdyb3RlOg0KDQo+DQo+ VGhlIGdyb3VwIG9mIHVzZXJzIG9mIEJHUCB3aGljaCB0aGlzIHVwZGF0ZSBpbXBhY3RzIHRoZSBt b3N0IGFyZSBtZW1iZXJzDQo+b2YgQkVTUyBXRyAoY2MtZWQpIGFuZCBub3QgSURSIFdHIGR1ZSB0 byB0aGUgZmFjdCB0aGF0IHRoaXMgcHJvcG9zYWwgYXBwbGllcw0KPnRvIGFsbCBBRkkvU0FGSXMu DQoNCkknbGwgaGFwcGlseSBhZG1pdCB0aGF0IEkgaGF2ZSBub3QgYmVlbiBmb2xsb3dpbmcgQkVT UyBhdCBhbGwsIGFuZCBzbw0Ka25vdyB2ZXJ5IGxpdHRsZSBvZiB3aGF0IHknYWxsIGRvICgiSGkg QmVzcyEiKS4gQWx2YXJvLCBwbGVhc2UgYWR2aXNlDQppZiBCRVNTIGlzIGFmZmVjdGVkIHRvIHRo ZSBsZXZlbCB0aGF0IHRoZXkgc2hvdWxkIGhhdmUgYmVlbiBleHBsaWNpdGx5DQppbnZpdGVkIHRv IGNvbW1lbnQ/DQoNCg0KDQo= From nobody Tue May 9 04:40:36 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF96D129BA8 for ; Tue, 9 May 2017 04:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.693 X-Spam-Level: X-Spam-Status: No, score=-2.693 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=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 Jg0PzZwZSYxz for ; Tue, 9 May 2017 04:40:33 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10091.outbound.protection.outlook.com [40.107.1.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 B6C0B1201FA for ; Tue, 9 May 2017 04:40:32 -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=hQqwjEx+6K1xgU78Tfyd3aYZczhXbqOyhotkLvfjPFs=; b=UZSz05415yjP8hTK2Tosp9jjoun0A4w15RHDy14si9BDDZN7t9dXzhXn2OfvmMQjvOvc+N1n06asM5bPY4IXZJ0avXJa1V+MsQS4566NHmnOeUTy1eMMSxm0mJRUsUaKR9rQvEUYiqnh+U9mGl+O+CJNlX7dgryqalKxVTIDD+s= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; Received: from [192.168.1.5] (90.92.95.79) by AM5PR0701MB2466.eurprd07.prod.outlook.com (10.169.153.23) 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 11:40:30 +0000 To: BESS References: From: Martin Vigoureux Message-ID: Date: Tue, 9 May 2017 13:40:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [90.92.95.79] X-ClientProxiedBy: DB6PR0802CA0019.eurprd08.prod.outlook.com (10.172.224.29) To AM5PR0701MB2466.eurprd07.prod.outlook.com (10.169.153.23) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 803d1c16-d5c5-426b-7158-08d496d03209 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2466; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2466; 3:Tv86bovuNvM9MMWOtrGC4AmWGhzKVCbURzPT98fEZo6n2sFD01U282LhxLY88Fz7bmq0THUvYZJN+tpQKb2C/Ob2MU5zSZPsMLAuakl7GFxmZfhnz7fvoyfeTnAefOzrnql43XMA9jhkdAgG0oipIp0E4nMCI385KlVcv+dyn1ML29v878WzwiwpDXDP/QWWL585euNuHtbbd77CYweyvJmNKS6HcBkcaQaSn5xsfQU8VIqFrm7Z9PkqVKSe3+faWlsE0I2wkXO1iMn1XHw4mmITVXzB8y9k3gGi8JrLQL3xLJ3aFfj6zPKSP5a0u+OCwPCZCvFid+7rxlDHM9agBtdJ58FGA+9ShyA58+Tb338=; 25:/GE0PdBWF3RYJEg+wKJNzjGFn92P2R392K3C8nU0X1eHSD5B4PEG+TOV1qYCdK9fN6bhDigZDVv1qd/s4Ya7M9Mw8Wj6SaCyFxG6852gNjh8X+QATboTTl+JiREQceegKFGeUWnLkhUQWpOo8VjE1HL8L8FBVXmi4VlPSh5LQH1ZPK4nc2Eze4x6ezIgGXIBul+3L3TpFSD8OXNqrpgNUE62365usaDR1VOUPMyO7ghORko7LPIKIzsWicv6lZTnbugjhco9YLyfPBAJnGZyodqqQRBieaj5pk72bCcdKbxFkqnhv6uXqVWmyAjwsuxSceodSxFVktipQNUFyvyuYv47t8U0ULiiDD+kSQEolbe+d8NPtKOEAloIHBBWpbIRZkVQNvvGRr2bDav2s+W0C1xxOwLpvD1aRo1zhybF+nMtoPQzVtTmZBfkdmcrcK5L79avpjKuwvAF1wGfvFoOCXS3wm+1J61aIr9vfCzLeJE= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2466; 31:EFG+U6XV5tP/WOyEtzLGMWpsU3oHU+IfH8fnHNnupvv98VmbGUN06HWj7kniSUN66Hu0CCZEIyuQ0bKY58ELmgbRQkF5W3EFHwJ1I5WOqH9b0ZUsZXF/XqEJYsZnMcEKrVmcyjOOvfKivu0yROwl6hZS7ChZJ6s5CCrWhZ/Prr+T3qKvMiEo4MSHf9OuZsHJqQDWz040Vi//m4AGPY8EeVmoqLNoQ7Qd8e9Q8ir6luGrrsGPguXPacCnAg+ZZGPgaSBCKHY56AuUJW3D2J8oKg==; 20:GEOnrgvTUgkBj8mE8Zjcg8RY+cvLENTigDUKcxCRSkemmSU9YO2p7nuvfexwkeYKxoRQCHqP+RBjU1ha3Urqg6nDBzNlOQkM/Ar9/LhTBGjqhG2X4yDUgmH4h9+v7N2jvnt8t0MXgoXSRQ2JwcdI75r1xBm10u51fKxsh8/5C9EkDwTkbP1NiOtWtwMZJZV2JEwRrKn2tp0qGO9b+PhJYRfZTGQ/oqC+uuTBMMAINAbnP4nDP6IopLk9lOLxuQJf6+e2hpmuJStnjKuWXJVDU6eQGiNDTf1g9Te3BUEkrqB3fdfCdRghgngiEVqqV+Pn5id3J6NRfbSMYyjsjfb6KhrIKgJF6iXtoXNybneewqnlOUjxMC6xE0mmsrv/OZnhwTtYSGBckAYGXamfnU4TfMc5mn3cIO5IkRHH1mMDLO7fi7BIhqkLewXLHR5KYfwstcIrauo2Ijx9EyWkbkUn6Urz7PpGsG4Lw1WAdu46nFC7CqbjKr/ZEdQOp6EIaeSv 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)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:AM5PR0701MB2466; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2466; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2466; 4:zGfo8hoiKmCxlEqYapACox1kUq7JKNi13ieUxO2JxTX14gJxn0GC/Rcrki4uXIjxozvMA28kTxm1+XMtJCbj1H5tZGUJKlzVIta5XtdIPFLCcN8PAnhpsMP5BHf3ak4k0a2Pn9mzU4+FMxDtcUt/2kglDAw6XECaEhHmJxTS9e101kRrp0rJZtTEbYWbikp6JJfEKmvvtRSYVuh4A7FIoqe4Z7n/3mpBMyX5WAcfKTPu4TRzcPnWhwboPYNLpj99POFrhXHo81QH+YVwsqo2xZcSMUQifBu2i/LN2YnHuPqMOHjwns/OmnYIvqkYyD778sU9kXdxyIVkdHU/+kmf7eMhTxYJ5yja9/1AvkMzXdBbegkMCf6Hk0XlS3RU5kfw1R/FTqXvHAvmtC8jnkS7MLYW54cr/J86T56VmLQsNww60OdqUVwcNS3M64UfzHrgUuPl3APXaLcPNZSEISwG94nan08mB0EH51xBBJRUkonZhiwaPWXwkF9dJO/zW38I7msMguXcp+f5KtZSxeoJHdYPNCgXsufHfDNUm01kxYSb0BwGdCLx4EuTyzG0rhFxg7izaTSx7n8DRQhPQhJq3Qd0C2RTvgWyh+6DFsL02WIQJ4J0Bg+Nll5rpvDejKPavDYfNdScb8cel3i/G4+BATI8J+paimJPP4mPRmHgPoopbYayngutNHIVy3QcLnbSZyUHyI5fcpHGPEMKyG/NPt9F6KNRY/VV3kIS6CPgpjqb7kQTvR8Q3h+0FDS3FYuxY/ueXKeH+2YeGRngXUsDyZWWzUW77V4/kiGrU2kqpAEegKz4WEmrh4zNRqggs3nK6/19XNU30TNigbIyItl9HxPtvOemG3cXEnweQnMaT6s= X-Forefront-PRVS: 0302D4F392 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39410400002)(39850400002)(39860400002)(39450400003)(39840400002)(39400400002)(2870700001)(117156002)(25786009)(33646002)(54356999)(50466002)(50986999)(47776003)(6306002)(230783001)(2906002)(189998001)(38730400002)(305945005)(110136004)(76176999)(6486002)(478600001)(229853002)(31696002)(6116002)(86362001)(3846002)(5660300001)(6666003)(65826007)(77096006)(31686004)(81166006)(6916009)(2950100002)(8676002)(64126003)(36756003)(7736002)(66066001)(23746002)(53936002)(42186005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2466; H:[192.168.1.5]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM5PR0701MB2466; 23:Yh4GXoowVpbKqhuVLXXGNe8cmRxt/ZLMnRU?= =?Windows-1252?Q?QNwGt9RblhpLBRWIjBBu3OfAYUC3fjd6E5RK4wnbmtzlnC83byfXFMdH?= =?Windows-1252?Q?dIKxC62IptfhZFUzI8rtp0iBMjtZqJ9tL9G22GD7RwGH2/DROm0qdOjk?= =?Windows-1252?Q?NTU3eE5ppsaxhbn3AUCRe+VeagvZNAjKPFTinDu/I+65chvAZLJa3i+r?= =?Windows-1252?Q?sJ0NMYDlZbLcrE/ltIBNo9w9yUmWtgWV8EduHba0Ekb0HjzWZjjxKgkH?= =?Windows-1252?Q?EO/AH+7xwAbTM4cRicQttnL+FVfTplVwsrUxvGxJPhrRkg69viEMK7mM?= =?Windows-1252?Q?tVxg7/W2HlZprnvAYjxXO15Ar1rGX9DH37eINLLL/te2CkL27KrP4QzV?= =?Windows-1252?Q?DH3EWdS4Rg1jJ5ehvhkMVnEMeY6gYinFZWgfIMQL8LBVLL92wszLf0Gp?= =?Windows-1252?Q?USx8PYPQPAWMquCJx6u7vcHG762b7VXP0QlbVJCzwrK8lRKUE9KusqeA?= =?Windows-1252?Q?O5jFhkx6r/Fvis4tu4MaO4vsdym4MmR4IjgTBXpzzkXhgKZZvL6//oPY?= =?Windows-1252?Q?w2w4RNzOMmNaZCC53J8Y0ww2PdH5h0ddD1z2fjSLFF8O0b4zH1j6vGvd?= =?Windows-1252?Q?2QqvdqklfwttJNxVXgiW9lUC9lzSfWrdQjotG2NBvlwBJ4duhVZ/J6OG?= =?Windows-1252?Q?RDhLIhBWfmqaP31CRp0XYVeKL2FhiwdYQHXG284ta5xZcgdjYWrUD8DK?= =?Windows-1252?Q?ERWE7n00UYEpNf4OK1MG7rxiO5tH2v1j4/mL5w/g6a9usotFP2vuZ094?= =?Windows-1252?Q?G0XN+WaK3G+c2o9O7e3ag5/9FaP4bDHdpRs3S4gcFuKoBUnGZPNY+Tmd?= =?Windows-1252?Q?LPA+b549R+anpJLHh3KnOid7yMlnN843F8qM7mHMUYo6scl3Ab0N/CbE?= =?Windows-1252?Q?oPSrz7PiQ/Axg9VBiSl+1ysiPnIw9hm959w7SemQDNmpeyd+6FhqC/za?= =?Windows-1252?Q?N1AjpcA+GU3YsFAugPFdK8F1ncfO39QfwDyA8TaALppUXTiqGoACAE5P?= =?Windows-1252?Q?WSJlfMWZ01OJAHnKUKjj/BoOJ2C2eExNxD9l3PllxlITHY5jvMebPpCA?= =?Windows-1252?Q?DrLgUs0AgGQ7xOQpGrJx3CpycUK6Tt+PsUJulflbECWGmxPFGiqqnRCk?= =?Windows-1252?Q?fi+H6Cjj29WdJ7nk9UTG+XETvmW2AHFzzTSztVqrh2bNuxzUT9pJ8dXO?= =?Windows-1252?Q?viHUvREDT/PwozY070QCnz9bwYqSO2w+p0WfC6M04jzsxFp5EpZyzsw3?= =?Windows-1252?Q?Oxd+L?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2466; 6:mvpUD8Yg8sNV4TfJBYpNvhf1l8ZPYZfPaOk1qEvTmOpzAxvhoJ91sxHthRh0WcLVE8Et9ek6PqHiaqJNV1Np50I+6qefkw0MhTSrPPaQIXJIqEYibKpHqj3DHaaXDvVPCplGaxpLj8WvtFeZizcUBhkvGg76y1luVQJETc3r0YlaPO9oZ1w/Z2TQM7vi4YLm9AyVfdgnMJmbsugSFfw+kSBtxza+xrvgOo9U2/ziMIdwZkhcQTN53mYGeUHy80pSEYeTruGjkp7yhIshn+5WW4AtORmPt23+nhdnOWgfAYOEKBI3M8j8Ze+yKjDZfSVtnJmIS+eIWNC2NwuVA0XwjnbnygwYW1srIB3Q819w2Uhm0gltWors6YuEgQjL2RXdNyjs4ynCGZuq37+aIJH2L7F9SogQxQYAFYWW83N3XdVjofuL6erFFt9PTJ/nPzWbVvEwidO9NW0gPnZGBNUq25mg0kHyoz0+53aoMJdnF7PMR4HOymXJegNunokzq0vqQUhTyWv7sYNCtNT1CK03n22yNTWEdSKTOgvAxCNM2FA=; 5:WMGhFA4LGzHeBxRUyPzYL7jTv3f8RdKroONHGTJtjdn1uEX8ueuoU0UFO/1HGO1ewXGwZB9yvVZvM4tA8fMsbpW/TX4nBxWXbxs6pLvJ9duYqXArYFm0bgaP8RKEbfdT+GQNp5/6FQ+FksYVRCb9Lw==; 24:G6ZHR++Rlr6N1tYp1+lGQHfygqRlB2XLAtmOZX7yoI4zdqLIQXfZ3N1VJTrlLRj72VQupxNIxG7jkXx6hlCFe0F6kXEBpS2SOov2tiUcA4M= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2466; 7:p07pDF0c5jpLOhWWPx2/MayAFsV0ROD1L0Z/BC2JkqtevaQ2yq5Sf3wJKeah4OaHAAoyp0TbSZ+N0JK4tnkD/YF5Qtq6uubIRluYLAr9AT6AWJgIcVqZF+scPuIGb6YVzeGeyXQuuiFrSLEQE8WiAIhClRjk9+TlM4rxe9BNC1jxRHSL/M6VxsBDI9mpH9A96bMIBpK8Z9y1LREOXPsqhDqCIsUoNv1ts/12uiJoGnzxhzpJK5N0T7mh4XH504juVujw/Gn8PFtGxQUYBi3sob7yRi8LNCNmN26gk/bHkF47MbKiefaZ70v9OBMheXyQexB7IoxpmTchWJUvfa56lA== X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2017 11:40:30.0724 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2466 Archived-At: Subject: Re: [bess] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 11:40:35 -0000 WG, there is a clear renewed support for this document, so we'll continue as normal. Thank you. M&T Le 13/04/2017 à 20:04, Martin Vigoureux a écrit : > WG > > Given the IPR disclosed [1] against > draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for > comment specifically to let people express a revised opinion on how > draft-ietf-bess-nsh-bgp-control-plane should be pursued in BESS. > > This call for comment is open until the 5th of May > > Thanks > M&T > > [1] https://datatracker.ietf.org/ipr/2980/ From nobody Tue May 9 08:09:15 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@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: [bess] 3107bis LC discussion on MPLS list X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list 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 15:09:15 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2FF1200F1 for ; Tue, 9 May 2017 15:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.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 PUZszI8coEXG for ; Tue, 9 May 2017 15:09:12 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0041.outbound.protection.outlook.com [104.47.42.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 525171279E5 for ; Tue, 9 May 2017 15:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=A+0bAISnVnAutKwFmUs7WfeHFYBGtNNV53kZZhRUqpA=; b=RYHDs4WzOjtnYyeCidUXfe5a+TgpezUf2m+KzHrOKiG42AcFOqS4HhdkHlDsXctkNrlbUOMCpVEOrg9R5rV8I36NYlaO5SOmnMXCvmf7wutRdfAHByaM3TT2qLFWKDw0VqaXwt2dIETwFYO7srk32y8T5W9oNrk02/IULZdYUBQ= Received: from BN6PR05MB3009.namprd05.prod.outlook.com (10.173.19.15) by BN6PR05MB3011.namprd05.prod.outlook.com (10.173.19.17) 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 22:09:10 +0000 Received: from BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) by BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) with mapi id 15.01.1084.015; Tue, 9 May 2017 22:09:10 +0000 From: Sami Boutros To: "martin.vigoureux@nokia.com" , "thomas.morin@orange.com" CC: John E Drake , "Patrice Brissette (pbrisset)" , "Ali Sajassi (sajassi)" , "bess@ietf.org" Thread-Topic: WG adoption for draft-boutros-bess-evpn-vpws-service-edge-gateway-03 Thread-Index: AQHSyRDiVvOaPtjRvUi5XAdwCKnLBA== Date: Tue, 9 May 2017 22:09:10 +0000 Message-ID: <8E7F13CA-FEB1-4EA9-886F-C43F30E52C6C@vmware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=vmware.com; x-originating-ip: [208.91.2.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR05MB3011; 7:C0H18D53mOJyOv7YPn1b+pR3o73ZqUmYOmQDst1JpiMzhZixEEtU0b8c9GpCTSg3oJlfVfzcN+I3nSbSi60OgYXuym8aOHJpq8QEHV1AhYRMcfOdQKS1h17xGsUIUNX1VU9Zj5C8b649i/cue2FjN57cEqG1qkISh+gAQqOr6y8sWMBrvxOZVd0DEVlY7/K4/RBuapNqyhQf0SExYHnXguT1ktFLhs83viGttvBNrhDm7Av8syyfOvSVFxGv4WF7xzuZCAx5EK4yhsuUgciiIfj+BTx9J2+U3Lu4hwBoqjqd87poO7QbWtF2MkfXINLturVi+Lmcj6G8XciFCsCg0A==; 20:fwfKGUXzjwROgIT5pOmDUEln1+8mx6DKlGhMMNZWZpyCkOuOUX5Gba0WW9YdPbLsM2FxTnJrIM0XO5luirDPjXTff7icPYS+FGr6QCL3vSf6JYjzAk4htDKRyu1NSnslzFtANsVjizyUzULEYBvynL3TN94fH1OhmMCesMKmlO8= x-ms-office365-filtering-correlation-id: b8be9e4f-00b9-41e8-887d-08d497280514 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR05MB3011; 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)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:BN6PR05MB3011; BCL:0; PCL:0; RULEID:; SRVR:BN6PR05MB3011; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39410400002)(39400400002)(39450400003)(39850400002)(54896002)(230783001)(82746002)(4326008)(25786009)(8666007)(6512007)(6486002)(6436002)(99286003)(2501003)(558084003)(5660300001)(6506006)(83716003)(53936002)(3280700002)(54356999)(77096006)(8936002)(8676002)(81166006)(50986999)(66066001)(3660700001)(7736002)(38730400002)(2906002)(189998001)(3846002)(102836003)(478600001)(2900100001)(86362001)(33656002)(36756003)(122556002)(6116002)(54906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR05MB3011; H:BN6PR05MB3009.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_8E7F13CAFEB14EA9886FC43F30E52C6Cvmwarecom_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2017 22:09:10.4839 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3011 Archived-At: Subject: [bess] WG adoption for draft-boutros-bess-evpn-vpws-service-edge-gateway-03 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 22:09:14 -0000 --_000_8E7F13CAFEB14EA9886FC43F30E52C6Cvmwarecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluIGFuZCBUaG9tYXMsDQoNCldlIHdvdWxkIGxpa2UgdG8gYXNrIGZvciBXRyBhZG9w dGlvbiBmb3IgdGhpcyBkcmFmdCwgYXMgdGhlcmUgYXJlIHZlbmRvciBwbGFubmVkIGltcGxlbWVu dGF0aW9ucyBmb3IgaXQuDQoNClRoYW5rcywNCg0KU2FtaQ0K --_000_8E7F13CAFEB14EA9886FC43F30E52C6Cvmwarecom_ Content-Type: text/html; charset="utf-8" Content-ID: <05A455BB963C244FBDD92B24A38319C2@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkhpIE1hcnRpbiBhbmQgVGhvbWFzLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ V2Ugd291bGQgbGlrZSB0byBhc2sgZm9yIFdHIGFkb3B0aW9uIGZvciB0aGlzIGRyYWZ0LCBhcyB0 aGVyZSBhcmUgdmVuZG9yIHBsYW5uZWQgaW1wbGVtZW50YXRpb25zIGZvciBpdC48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PlNhbWk8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8E7F13CAFEB14EA9886FC43F30E52C6Cvmwarecom_-- From nobody Tue May 9 17:44:29 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF9212EB7F; Tue, 9 May 2017 17:44:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149437706765.8272.4288248858181847295@ietfa.amsl.com> Date: Tue, 09 May 2017 17:44:27 -0700 Archived-At: Subject: [bess] I-D Action: draft-ietf-bess-evpn-etree-10.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 00:44:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : E-TREE Support in EVPN & PBB-EVPN Authors : Ali Sajassi Samer Salam John Drake Jim Uttaro Sami Boutros Jorge Rabadan Filename : draft-ietf-bess-evpn-etree-10.txt Pages : 19 Date : 2017-05-09 Abstract: The Metro Ethernet Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet Tree (E-Tree). A solution framework for supporting this service in MPLS networks is proposed in RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network"). This document discusses how those functional requirements can be easily met with Ethernet VPN (EVPN) and how EVPN offers a more efficient implementation of these functions. This document makes use of the most significant bit of the scope governed by the IANA registry created by RFC7385, and hence updates RFC7385 accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-etree-10 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-etree-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-etree-10 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 17:51:49 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA1312EB78; Tue, 9 May 2017 17:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, 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 YTlWVRjrIwSa; Tue, 9 May 2017 17:51:44 -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 83DFE1200FC; Tue, 9 May 2017 17:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=88014; q=dns/txt; s=iport; t=1494377503; x=1495587103; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GVljkI6aVPd2X+XRk3SdDSCZw6/5zdDc1aEFQ26hKIs=; b=QpZTjWW1XtJ3O0fnM8ME3lmGrEGSg9Q5Y7zLGlu8O+cUfLDWhKfOqlmW sa998RyL7DaTEuObGWrvstfo3YgDO0wyZmncNalPabCNPtyTKL96r8HhS kxp7gsA6+b0c4aQFT2+I5EBPjRHIORTwsfM9gjDJkbJ8xxyi6X0FaYXEj A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAADKYhJZ/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm48K2KBDAeERYk1kVWVcoIPLIV4AoRvPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQMaXxACAQgRAwECIQEGBzIUCQgCBAENBRQHigYOtGsrikUBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYg9gxuFA4VJBZAihkuHGAGKT4hKggSFO4NmhkaUQQE?= =?us-ascii?q?fOIEKcBVGhHYcgWN2AQGHZYENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,316,1491264000"; d="scan'208,217";a="421226699" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 May 2017 00:51:41 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v4A0pf8n023219 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2017 00:51:41 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 May 2017 20:51:40 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1210.000; Tue, 9 May 2017 20:51:40 -0400 From: "Ali Sajassi (sajassi)" To: "Alvaro Retana (aretana)" , "draft-ietf-bess-evpn-etree@ietf.org" CC: "bess-chairs@ietf.org" , "bess@ietf.org" , Thomas Morin Thread-Topic: AD Review of draft-ietf-bess-evpn-etree-09 Thread-Index: AQHSrYuq8cG6jBFZoU6tpElXD7ib+aHswcQA Date: Wed, 10 May 2017 00:51:40 +0000 Message-ID: References: <8A9E130E-0A0C-4DE5-BB35-98EE3C305E4B@cisco.com> In-Reply-To: <8A9E130E-0A0C-4DE5-BB35-98EE3C305E4B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.52] Content-Type: multipart/alternative; boundary="_000_D52F7FE91ECBB4sajassiciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 00:51:48 -0000 --_000_D52F7FE91ECBB4sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Thank you for your thorough review and comments. I have addressed all of t= hem. Please refer inline for details on each. I just posted a new rev (rev1= 0) that covers all the comment resolutions addressed here. https://www.ietf.org/id/draft-ietf-bess-evpn-etree-10.txt From: "Alvaro Retana (aretana)" > Date: Tuesday, April 4, 2017 at 2:37 PM To: "draft-ietf-bess-evpn-etree@ietf.org" > Cc: "bess-chairs@ietf.org" >, "bess@ietf.org" >, Thomas Morin > Subject: AD Review of draft-ietf-bess-evpn-etree-09 Resent-From: > Resent-To: Cisco Employee >, >, >, >, >, > Resent-Date: Tuesday, April 4, 2017 at 2:37 PM Dear authors: I just finished reading this document. In general, the document could bene= fit from an editorial pass to improve readability; I put in some suggestion= s below, but I=92m sure I didn=92t mention all. I don=92t think that my co= mments (even the Major ones) will be hard to resolve =96 most are around pr= oviding clarity and consistency. I=92ll wait for a revised draft before st= arting the IETF Last Call. Thanks! Alvaro. Major: M1. Both the Introduction and the Abstract mention that =93this document di= scusses how the functional requirements for E-Tree service can be easily me= t=85=94 It seems to me that RFC7387 is used as the building block for this= document. Why is it not a Normative reference? Because RFC7387 is informational RFC (and the framework RFC) and the idnits= complains of a downref: Normative reference to an informational RFC M2. There is no reference to E-Tree. Please add a Normative one. Added a reference for E-TREE definition in MEF. M3. In Section 2.2 (Scenario 2: Leaf OR Root site(s) per AC): =93=85then a = single RT per EVI MAY be used=85=94 I think that =93MAY=94 is out of place= because it seems to be expressing just a fact. Also, please keep the norm= ative language where the operation is defined (in this case in 3.1). Changed =93MAY=94 to =93can=94. M4. Section 3.1 (Known Unicast Traffic) talks about how in the =93multi-hom= ing scenario of section 2.2=85the PE MAY advertise leaf indication along wi= th the Ethernet A-D per EVI route=94. Given that the text later says that = =93in case of discrepancy, the multi-homing for that pair of PEs is assumed= to be in default "root" mode=94, I find the =93MAY=94 not sufficient. If = we want to prevent as many discrepancies as possible, shouldn=92t that be a= =93SHOULD=94 (or even a =93MUST=94)? Given the local configuration, why = would the PE not want to include the leaf indication=85ever=85? It is cleaned up. M5. In Section 5.1 (E-TREE Extended Community) there is redundant informati= on (first and last paragraphs). Among that redundant information there is = no consistency: =93the Leaf Label field is set to a valid MPLS label=94 and= =93the Leaf Label MUST be set to a valid MPLS label=94 =96 please be consi= stent and specify things just once. Removed the replicated/redundant text M5.1. BTW, that is a =93valid MPLS label=94? How would a receiver recogniz= e it? Please add a reference to avoid confusion. Added a brief description of =93valid MPLS label=94 and provided the refere= nce M6. Definition of the E-TREE Extended Community M6.1. Only one Flag is defined. What about the others? Please set up a re= gistry. If needed in the future, we will setup a registry. M6.2. [Minor] Please put a Figure number and heading for the community form= at. Done. M6.3. It looks like the Reserved fields are set to 0. What should happen i= f the receiver gets something else? Added a sentence that =93the receiver should ignore the reserved bits=94 M6.4. =93=85the Leaf-Indication flag MUST be set to one and Leaf Label is s= et to zero. The received PE should ignore Leaf Label and only processes Lea= f-Indication flag.=94 What if the Leaf Label is not set to zero? The seco= nd sentence says to ignore it, but the first one that it =93MUST be=85set t= o zero=94. Which one is it? Maybe both=85 Be specific! For MPLS label, changed it to =93the transmitter SHOULD set it to zero and = the receiver SHOULD ignore it=94. M6.5. =93=85the Leaf Label MUST be set to a valid MPLS label and the Leaf-I= ndication flag should be set to zero. The received PE should ignore the Lea= f-Indication flag.=94 Similar question for the Leaf-Indication bit. For Leaf-Inication flag, change it to "the transmitter SHOULD set it to zer= o and the receiver SHOULD ignore it" M6.6. =93A non-valid MPLS label when sent along with the Ethernet A-D per E= S route, should be logged as an error.=94 I=92m assuming that not only the= logging is needed, but is the route ignored/discarded too? Added =93the route should be ignored" M7. The PMSI Tunnel Attribute: Please be clear to the fact that the C bit = is being defined/introduced in this document (and not just start talking ab= out it as if it is well-known to every reader). Modified the 1st para to make it explicit: "This draft defines a new Composite tunnel type by introducing a new "Comp= osite Tunnel' bit in the Tunnel Type field and adding a MPLS label to the T= unnel Identifier field of PMSI Tunnel attribute as detailed below. This dra= ft uses all other remaining fields per existing definition." M7.1. It is not clear to me how the C bit is to be used. Section 5.2 says = that =93the high-order bit of the tunnel type field (C bit - Composite tunn= el bit) is set while the remaining low-order seven bits indicate the tunnel= type as before.=94 But 3.3.1 says that the =93new composite tunnel type = is advertised by the root PE to simultaneously indicate a P2MP tunnel in tr= ansmit direction and an ingress-replication tunnel in the receive direction= =85=94. Knowing, from 5.2 that when the C bit is set =93Tunnel Types=850x0= 6 'Ingress Replication' is invalid=94, then does the C bit have a set meani= ng or ??? [BTW, s/is/are] The description in section 3.3.1 is consistent with this section 5.2. Basic= ally, Composite Tunnel type, as its name implies consist of two tunnels: a = P2MP tunnel in the transmit direction and a MP2P tunnel in the receive dire= ction. The MP2P tunnel in the receive direction is used by Leaf PE devices = for their BUM traffic transmission. The "ingress replication tunnel type=94= is not valid because for that we don=92t need composite tunnel type!! I added the following sentence to the 1st paragraph to clarify it more: "Composite tunnel type is advertised by the root PE to simultaneously indic= ate a P2MP tunnel in transmit direction and an ingress-replication tunnel i= n the receive direction for the BUM traffic." M7.2. [Minor] In some places you talk about the =93C bit=94 or =93Composite= tunnel bit=94, but later mention the =93Composite flag=94. I=92m assuming= it is the same thing =96 please be consistent! OK, changed it to "Composite Tunnel bit". M7.3. =93invalid tunnel type=94 RFC6514 talks about an =93undefined tunnel= type=94. Do you mean the same thing? If you do, please use the right ter= minology and put a reference to rfc6514 here to remind people where the act= ion is defined. Added a sentence that it should be treated as malformed per section 5 of [R= FC6514]. M8. Section 8.1 (Considerations for PMSI Tunnel Types). M8.1. What should the name of the bit be? C bit, =93composite tunnels=94 o= r =93Composite tunnel bit=94 =96 all 3 versions are used, and IANA will wan= t specific directions. Now, using =93Composite Tunnel bit=94 everywhere. M8.2. =93=85by removing the entries for 0xFB-0xFE and 0x0F=94 The range be= tween 0x80-0xFA also needs to be changed/updated. s/0x0F/0xFF. It may be = clearer to write that this document updates the range 0x80-0xFF. The ranges =930xFB-0xFE=94 and 0x0F have been replaced with =930x7B-0x7E=94= and 0x7F. M8.3. =93=85and replacing them by=85=94 Please format the table so that s= pacing is aligned (for better clarity for IANA). Also, please include in i= t all the reallocated space; for example: Value Meaning Reference 0x0B-0x7A Unassigned 0x7B-0x7E Reserved for Experimental Use [this document] 0x7F Reserved [this document] 0x80-0xFF Composite Tunnels [this document] Done. M8.4. What is 0x7F reserved for? It doesn=92t seem to be used in this docu= ment. Why a different registration procedure? 0x7F just replaces 0x0F - i.e. No new registration procedure Minor: P1. s/and RFC called "A Framework for E-Tree Service over MPLS Network"./RF= C7387 ("A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol= Label Switching (MPLS) Network"). Done. P2. Please expand EVPN on first use. I know that this is a well-known term= =96 please consider talking to the RFC Editor (once this document gets to = them) in order to include =93EVPN=94 in the =93RFC Editor Abbreviations Lis= t=94 [1]. Done and we=92ll do. P2.1. Please also expand: DF, BUM=85 Done. [1] https://www.rfc-editor.org/materials/abbrev.expansion.txt P3. The abbreviation for Ethernet Segment is introduced in Section 3.2=85pl= ease introduce it on first mention (Section 2) as it gets used before 3.2. = Also, the abbreviation for Attachment Circuit is introduced after AC has b= een used several times. EC is used w/out definition. Done. P4. =93E-TREE for VPLS=94 Please add an Informative reference to rfc7796. Done. P5. =93=85new BGP Extended Community for leaf indication as shown later in = this document.=94 Please include a forward reference to Section 5.1. Done. P6. =93MAC mobility procedures=94 What are those? Please add a reference. Done. P7. Section 3.2.1 (BUM traffic originated from a single-homed site on a lea= f AC) starts by talking about =93a special MPLS label=94 =96 even though th= ere=92s a reference later to 5.1, please be explicit (writing something lik= e this): =93the PE adds the Leaf Label advertised using the E-Tree Extended= Community (Section 5.1)=94. Simplifying the text will go a long way to= making implementation easier. Done. P8. =93IRB use case is outside the scope of this document.=94 An Informati= ve reference to draft-ietf-bess-evpn-inter-subnet-forwarding would be nice. Done. P9. It would be nice to include a =93map=94 of the document in the Introduc= tion: (something like) =93Section 2 talks about blah=85Section 3 defines=85= =94. Done. P10. s/EVPN MAC Advertisement route/MAC/IP Advertisement Route Please b= e specific! Done. P11. =93To support multicast/broadcast from Root to Leaf sites, either a P2= MP tree rooted at the PE(s) with the Root site(s) or ingress replication ca= n be used.=94 References would be very nice! Done. P12. Section 5.3 doesn=92t exist. Corrected. P13. Both Sections 3 and 4 mention the same things (other tagging mechanism= s and IRB) out of scope. It would be nice to mention common pieces of the = operation in a single place. They are for two different solutions =96 one for EVPN and the other for PBB= -EVPN. It is done intentionally for ease of reference. P14. =93This document defines two new BGP Extended Community for EVPN.=94 = I only see one. It used to be two :-) I corrected it. P15. A Normative reference to rfc4360 is needed in 5.1. Done. P16. There=92s no need to the reference to rfc7153 because you=92re referri= ng to the registry itself. It doesn=92t hurt :-) P17. The 'Updates: ' line in the draft header should list only the _numbers= _ of the RFCs which will be updated by this document (if approved); it shou= ld not include the word 'RFC' in the list. Done. Also added 6514 to the list. P18. There is no reference to rfc5226. Done. Nits: N1. There are a lot of very long sentences=85 It would be nice if the idea= s were composed so that the overall document was easier to read. For an ex= ample, take a look at the last paragraph in 2.2=85 No specific action requ= ired here, but it would be nice to give it an editing pass. I did an editorial pass through this section to improve its readability. N2. s/ each of its MAC/IP Advertisement route/each of its MAC/IP Advertisem= ent routes Done. N3. Another example of where the text is not as clear as it could be for a = specification is Section 3.2, where tagging MPLS frames is mandated (=93the= MPLS-encapsulated frames MUST be tagged with an indication when they origi= nated from a Leaf AC=94), but there is no indication on how to do this unti= l 3 paragraphs later =96 a seemingly unrelated discussion is held in betwee= n=85 I did an editorial pass through this section to improve its readability. N4. =93we=94 is used a couple of times (outside the Acknowledgements) =96 p= lease change that to =93this document=94 (or something similar). Done. N5. s/where and Ethernet Segment/where an Ethernet Segment Done. N6. s/draft/document Done. --_000_D52F7FE91ECBB4sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <882852A4C99E2B4EA64CB967A8021000@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

Thank you &n= bsp;for your thorough review and comments. I have addressed all of them. Pl= ease refer inline for details on each. I just posted a new rev (rev10) that covers all the comment resolutions addr= essed here.



From: "Alvaro Retana (aretana)= " <aretana@cisco.com> Date: Tuesday, April 4, 2017 at 2:3= 7 PM
To: "draft-ietf-bess-evpn-etree@ietf.org"= <draft-ietf-bess= -evpn-etree@ietf.org>
Cc: "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@= ietf.org>, Thomas Morin <thomas.morin@o= range.com>
Subject: AD Review of draft-ietf-be= ss-evpn-etree-09
Resent-From: <alias-bounces@ietf.org>
Resent-To: Cisco Employee <sajassi@cisco.com>, <ssalam@cisco.com>, <ju1738@att.com>, <jdrake@juniper.net>, <sboutros@vmware.com>, &l= t;jorge.rabadan@nokia.com>= ;
Resent-Date: Tuesday, April 4, 2017= at 2:37 PM

Dear authors:<= /o:p>

 

I just finished rea= ding this document.  In general, the document could benefit from an ed= itorial pass to improve readability; I put in some suggestions below, but I= =92m sure I didn=92t mention all.  I don=92t think that my comments (even the Major ones) will be hard to resolve =96 most ar= e around providing clarity and consistency.  I=92ll wait for a revised= draft before starting the IETF Last Call.

 

Thanks!<= /span>

 

Alvaro.<= /span>

 

 

 

Major:

 

M1. Both the Introd= uction and the Abstract mention that =93this document discusses how the fun= ctional requirements for E-Tree service can be easily met=85=94  It se= ems to me that RFC7387 is used as the building block for this document.  Why is it not a Normative reference?

 
Because RFC7387 is informational RFC (and the framework RFC) and = the idnits complains of a downref: Normative reference to an informational RFC

 

M2. There is no ref= erence to E-Tree.  Please add a Normative one.

 
Added a reference for E-TREE definition in MEF.

 

M3. In Section 2.2 = (Scenario 2: Leaf OR Root site(s) per AC): =93=85then a single RT per EVI M= AY be used=85=94  I think that =93MAY=94 is out of place because it se= ems to be expressing just a fact.  Also, please keep the normative language where the operation is defined (in this case in 3.1= ).

 
Changed =93M= AY=94 to =93can=94.

 

M4. Section 3.1 (Kn= own Unicast Traffic) talks about how in the =93multi-homing scenario of sec= tion 2.2=85the PE MAY advertise leaf indication along with the Ethernet A-D= per EVI route=94.  Given that the text later says that =93in case of discrepancy, the multi-homing for that pair of PEs= is assumed to be in default "root" mode=94, I find the =93MAY=94= not sufficient.  If we want to prevent as many discrepancies as possi= ble, shouldn=92t that be a =93SHOULD=94 (or even a =93MUST=94)?   Given the local configuration, why would the PE not want to include the le= af indication=85ever=85?

 
It is cleaned up.

 

M5. In Section 5.1 = (E-TREE Extended Community) there is redundant information (first and last = paragraphs).  Among that redundant information there is no consistency= : =93the Leaf Label field is set to a valid MPLS label=94 and =93the Leaf Label MUST be set to a valid MPLS label=94 = =96 please be consistent and specify things just once. 

 
Removed the replicated/redundant text

M5.1. BTW, that is a =93valid MPLS label= =94?  How would a receiver recognize it?  Please add a reference = to avoid confusion.

 

Added a brief description of =93valid MPLS la= bel=94 and provided the reference

&n= bsp;

M6. Definition of the E-TREE Extended Comm= unity

 

M6.1. Only one Flag is defined.  What= about the others?  Please set up a registry.

If needed in the future, we will setup a registry.&= nbsp;

 

M6.2. [Minor] Please put a Figure number a= nd heading for the community format.

Done.

 

M6.3. It looks like the Reserved fields ar= e set to 0.  What should happen if the receiver gets something else?

Added a sentence that =93the receiver should i= gnore the reserved bits=94

 

M6.4. =93=85the Leaf-Indication flag MUST = be set to one and Leaf Label is set to zero. The received PE should ignore = Leaf Label and only processes Leaf-Indication flag.=94  What if the Le= af Label is not set to zero?  The second sentence says to ignore it, but the first one that it =93MUST be=85set to zero=94.&= nbsp; Which one is it?  Maybe both=85  Be specific!

For MPLS label, changed it to =93the transmitt= er SHOULD set it to zero and the receiver SHOULD ignore it=94.

 

M6.5. =93=85the Leaf Label MUST be set to = a valid MPLS label and the Leaf-Indication flag should be set to zero. The = received PE should ignore the Leaf-Indication flag.=94  Similar questi= on for the Leaf-Indication bit.

 
For Leaf-Inication flag, change it to "the transmitter SHOULD set it t= o zero and the receiver SHOULD ignore it"

M6.6. =93A non-valid MPLS label when sent = along with the Ethernet A-D per ES route, should be logged as an error.=94&= nbsp; I=92m assuming that not only the logging is needed, but is the route = ignored/discarded too?

 
Added =93the route should be ignored"

 

M7. The PMSI Tunnel Attribute:  Pleas= e be clear to the fact that the C bit is being defined/introduced in this d= ocument (and not just start talking about it as if it is well-known to ever= y reader).

Modified the 1st para to make it explicit:
"This draft defines a new Composite tunnel type by introduci= ng a new  "Composite Tunnel' bit in the Tunnel Type field and adding a MPLS label to the Tunnel Identif= ier field of PMSI Tunnel attribute as detailed below. This draft uses all o= ther remaining fields per existing definition."

 

M7.1. It is not clear to me how the C bit = is to be used.  Section 5.2 says that =93the high-order bit of the tun= nel type field (C bit - Composite tunnel bit) is set while the remaining lo= w-order seven bits indicate the tunnel type as before.=94   But 3.3.1 says that the =93new composite tunnel = type is advertised by the root PE to simultaneously indicate a P2MP tunnel = in transmit direction and an ingress-replication tunnel in the receive dire= ction=85=94.  Knowing, from 5.2 that when the C bit is set =93Tunnel Types=850x06 'Ingress Replication' is invalid=94, then do= es the C bit have a set meaning or ???   [BTW, s/is/are]

 
The description in section 3.3.1 is consistent with= this section 5.2. Basically, Composite Tunnel type, as its name implies co= nsist of two tunnels: a P2MP tunnel in the transmit direction and a MP2P tu= nnel in the receive direction. The MP2P tunnel in the receive direction is used by Leaf PE devices for t= heir BUM traffic transmission. The "ingress replication tunnel type=94=  is not valid because for that we don=92t need composite tunnel type!!=
I added the following sentence to the 1st para= graph to clarify it  more:
"Composite tunnel type is advertised by the ro= ot PE to simultaneously indicate a P2MP tunnel in transmit direction and an= ingress-replication tunnel in the receive direction for the BUM traffic.&q= uot;

M7.2. [Minor] In some places you talk abou= t the =93C bit=94 or =93Composite tunnel bit=94, but later mention the =93C= omposite flag=94.  I=92m assuming it is the same thing =96 please be c= onsistent!

OK, changed it to= "Composite Tunnel bit&q= uot;.

 

M7.3. =93invalid tunnel type=94  RFC6= 514 talks about an =93undefined tunnel type=94.  Do you mean the same = thing?  If you do, please use the right terminology and put a referenc= e to rfc6514 here to remind people where the action is defined.<= /span>

 
Added a sentence that it should be treated as = malformed per section 5 of [RFC6514].

 

M8. Section 8.1 (Considerations for PMSI T= unnel Types).

 

M8.1. What should the name of the bit be?&= nbsp; C bit, =93composite tunnels=94 or =93Composite tunnel bit=94 =96 all = 3 versions are used, and IANA will want specific directions.

Now, using = =93Composite Tunnel bit=94 everywhere.

 

M8.2. =93=85by removing the entries for 0x= FB-0xFE and 0x0F=94  The range between 0x80-0xFA also needs to be chan= ged/updated.  s/0x0F/0xFF.  It may be clearer to write that this = document updates the range 0x80-0xFF.

The ranges =930xFB-0xFE=94 and 0x0F have been = replaced with =930x7B-0x7E=94 and 0x7F.

 

M8.3. =93=85and replacing them by=85=94&nb= sp;  Please format the table so that spacing is aligned (for better cl= arity for IANA).  Also, please include in it all the reallocated space= ; for example:

 

   Value      &n= bsp;  Meaning         &nb= sp;            =    Reference

0x0B-0x7A  =    Unassigned        &nbs= p;     

 0x7B-0x7E =     Reserved for Experimental Use   [this document= ]

0x7F   = ;       Reserved     = ;            &n= bsp;      [this document]

0x80-0xFF  =    Composite Tunnels       &nb= sp;       [this document] 

 

Done.


 = ;

M8.4. What is 0x7F reserved for?  It = doesn=92t seem to be used in this document.  Why a different registrat= ion procedure?

 

0x7F j= ust replaces 0x0F - i.e.  No new registration procedure

 

 

Minor:

 

P1. s/and RFC called "A Framework for= E-Tree Service over MPLS Network"./RFC7387 ("A Framework for Eth= ernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Net= work").

 
Done.

P2. Please expand EVPN on first use. = I know that this is a well-known term =96 please consider talking to the R= FC Editor (once this document gets to them) in order to include =93EVPN=94 = in the =93RFC Editor Abbreviations List=94 [1].

 
Done and we=92ll do.

P2.1.  Please also expand: DF, BUM=85=

 
Done.

[1] https://www.rfc-editor.org/materials/abbrev.expansion.txt

 

P3. The abbreviation for Ethernet Segment = is introduced in Section 3.2=85please introduce it on first mention (Sectio= n 2) as it gets used before 3.2.  Also, the abbreviation for Attachmen= t Circuit is introduced after AC has been used several times.  EC is used w/out definition.

 
Done.

P4. =93E-TREE for VPLS=94  Please add= an Informative reference to rfc7796.

Done.

 

P5. =93=85new BGP Extended Community for l= eaf indication as shown later in this document.=94  Please include a f= orward reference to Section 5.1.

 
Done.

P6. =93MAC mobility procedures=94  Wh= at are those?  Please add a reference.

Done.

 

P7. Section 3.2.1 (BUM traffic originated = from a single-homed site on a leaf AC) starts by talking about =93a special= MPLS label=94 =96 even though there=92s a reference later to 5.1, please b= e explicit (writing something like this): =93the PE adds the Leaf Label advertised using the E-Tree Extended Communi= ty (Section 5.1)=94.     Simplifying the text will go a= long way to making implementation easier.

Done.

 

P8. =93IRB use case is outside the scope o= f this document.=94  An Informative reference to draft-ietf-bess-evpn-= inter-subnet-forwarding would be nice.

Done.

 

P9. It would be nice to include a =93map= =94 of the document in the Introduction: (something like) =93Section 2 talk= s about blah=85Section 3 defines=85=94.

Done.

 

P10. s/EVPN MAC Advertisement route/MAC/IP= Advertisement Route     Please be specific!=

 
Done.

P11. =93To support multicast/broadcast fro= m Root to Leaf sites, either a P2MP tree rooted at the PE(s) with the Root = site(s) or ingress replication can be used.=94  References would be ve= ry nice!

 
Done.

P12. Section 5.3 doesn=92t exist.


Corrected.

 

P13. Both Sections 3 and 4 mention the sam= e things (other tagging mechanisms and IRB) out of scope.  It would be= nice to mention common pieces of the operation in a single place.


They are for two different solutions =96 = one for EVPN and the other for PBB-EVPN. It is done intentionally for = ease of reference.

 

P14. =93This document defines two new BGP = Extended Community for EVPN.=94  I only see one.

It used to be two :-) I corrected it.

 

P15. A Normative reference to rfc4360 is n= eeded in 5.1.

Done.

 

P16. There=92s no need to the reference to= rfc7153 because you=92re referring to the registry itself.

It doesn=92t hurt :-)

 

P17. The 'Updates: ' line in the draft hea= der should list only the _numbers_ of the RFCs which will be updated by thi= s document (if approved); it should not include the word 'RFC' in the list.=

 
Done. Also added 6514 to the list.

P18. There is no reference to rfc5226.&nbs= p;

 
Done.

 

Nits:

 

N1. There are a lot of very long sentences= =85  It would be nice if the ideas were composed so that the overall d= ocument was easier to read.  For an example, take a look at the last p= aragraph in 2.2=85  No specific action required here, but it would be nice to give it an editing pass.

 
I did an editorial pass through this section t= o improve its readability.

N2. s/ each of its MAC/IP Advertisement route/each of its MAC/IP Advertisemen= t routes

 
Done.

N3. Another example of where the text is n= ot as clear as it could be for a specification is Section 3.2, where taggin= g MPLS frames is mandated (=93the MPLS-encapsulated frames MUST be tagged w= ith an indication when they originated from a Leaf AC=94), but there is no indication on how to do this until 3 p= aragraphs later =96 a seemingly unrelated discussion is held in between=85

 
I did an editorial pass through= this section to improve its readability.

N4. =93we=94 is used a couple of times (ou= tside the Acknowledgements) =96 please change that to =93this document=94 (= or something similar).

Done.

 

N5. s/where and Ethernet Segment/where an = Ethernet Segment

Done.

 

N6. s/draft/document

Done.

 --_000_D52F7FE91ECBB4sajassiciscocom_-- From nobody Wed May 10 22:19:26 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE79127601; Wed, 10 May 2017 22:19:17 -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-bess-evpn-vpws@ietf.org, aretana@cisco.com, "Zhaohui \(Jeffrey\) Zhang" , bess-chairs@ietf.org, zzhang@juniper.net, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149447995711.16699.7473400423711449897.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 22:19:17 -0700 Archived-At: Subject: [bess] Adam Roach's Discuss on draft-ietf-bess-evpn-vpws-13: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 05:19:17 -0000 Adam Roach has entered the following ballot position for draft-ietf-bess-evpn-vpws-13: Discuss 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-bess-evpn-vpws/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Looking at the Shepherd write up and the Ballot, I see no mention of the normative reference to RFC 7348, which is informational and part of the Independent Submission stream. As I mention in my comments below, I can't fully follow the technical contents of this document, but this seems like a red flag to me and -- as far as I can tell -- it hasn't been discussed yet. It's possible that the reference just ended up in the wrong section (and should actually be informative), but it's not immediately obvious on a casual examination whether that's true. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I strongly second Mirja's comment requesting positive confirmation from the WG that is is collectively aware of the associated IPR declarations. >From https://www.rfc-editor.org/materials/abbrev.expansion.txt: > It is common in technical writing to abbreviate complex technical terms > by combining the first letters. The resulting abbreviations are often > called acronyms. Editorial guidelines for the RFC series generally > require expansion of these abbreviations on first occurrence in a > title, in an abstract, or in the body of the document. These guidelines go on to point out which acronyms are common enough not to require expansion on first use. The following acronyms are not considered common, and require expansion on first use *and* in the title (I'm being very careful to cite only those which are *not* expanded on first use, so each of these should be actionable): - VPWS - EVPN - P2P - MAC (which is, itself, ambiguous without an expansion on first use) - PE - CE - L2 - DF - iBGP - eBGP I don't think "encap" is a word. I have not made a complete effort to understand the technical aspects of this document as its acronym use is literally too thick for me to read and comprehend its contents. I presume it is readable to its community of interest (as three implementations already exist); but finding ways to write in prose instead of acronyms where possible would be highly welcome. From nobody Thu May 11 05:36:20 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5B312EBEB; Thu, 11 May 2017 05: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 Mjmlu4uSil8h; Thu, 11 May 2017 05:36:09 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E17712EC76; Thu, 11 May 2017 05:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2698; q=dns/txt; s=iport; t=1494505999; x=1495715599; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=01Rv7kBQuLZ5NO2Onf6LzAqWp8p9FinCzYnWoHn67RE=; b=RzKeotZ2ay/JXGzrJhrJcOJHFS+WIsdpmHg6Xzh/PaHpf/UwygVa07NU dC91v4kNKID/Awg/DaiytrBIiIl9ootj5IUGlUNZOvOFCPiCAvVvbz4nP TUBmW3oByLaXRiV0RWqajZJUxarFX5eUqRyo9PlOor3lMKgUy0wIesLmC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAACRWRRZ/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2KKGKdQgg8whXQCGoRxPxgBAgEBAQEBAQFrKIUWBiM?= =?us-ascii?q?RRRACAQgaAiYCAgIwFRACBAENBYoiDrB1giaKcwEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFgQuFVIIJgnCDIYFCgxIvgjEBBIlEjSuHGwGHG4t/kWuUQgEfOIEKcBV?= =?us-ascii?q?YAYRjHBmBSnYFiAeBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,324,1491264000"; d="scan'208";a="424793118" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2017 12:33:18 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v4BCXIAO022848 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 May 2017 12:33:18 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 11 May 2017 07:33:17 -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; Thu, 11 May 2017 07:33:17 -0500 From: "Alvaro Retana (aretana)" To: Adam Roach , The IESG CC: "draft-ietf-bess-evpn-vpws@ietf.org" , "Zhaohui (Jeffrey) Zhang" , "bess-chairs@ietf.org" , "bess@ietf.org" Thread-Topic: Adam Roach's Discuss on draft-ietf-bess-evpn-vpws-13: (with DISCUSS and COMMENT) Thread-Index: AQHSyhYmdgZUma0WKEO/bCH1ULA9pqHvIh+A Date: Thu, 11 May 2017 12:33:17 +0000 Message-ID: <7473B8FC-34C0-466F-AEC2-A9053DD9EE4E@cisco.com> References: <149447995711.16699.7473400423711449897.idtracker@ietfa.amsl.com> In-Reply-To: <149447995711.16699.7473400423711449897.idtracker@ietfa.amsl.com> 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: <34026652ED317E4EA58F926339537E7A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Adam Roach's Discuss on draft-ietf-bess-evpn-vpws-13: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 12:36:12 -0000 T24gNS8xMS8xNywgMToxOSBBTSwgIkFkYW0gUm9hY2giIDxhZGFtQG5vc3RydW0uY29tPiB3cm90 ZToNCg0KQWRhbToNCg0KSGkhDQoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+DQo+IExvb2tpbmcgYXQgdGhlIFNoZXBoZXJkIHdyaXRlIHVwIGFuZCB0aGUg QmFsbG90LCBJIHNlZSBubyBtZW50aW9uIG9mIHRoZQ0KPiBub3JtYXRpdmUgcmVmZXJlbmNlIHRv IFJGQyA3MzQ4LCB3aGljaCBpcyBpbmZvcm1hdGlvbmFsIGFuZCBwYXJ0IG9mIHRoZQ0KPiBJbmRl cGVuZGVudCBTdWJtaXNzaW9uIHN0cmVhbS4gQXMgSSBtZW50aW9uIGluIG15IGNvbW1lbnRzIGJl bG93LCBJIGNhbid0DQo+IGZ1bGx5IGZvbGxvdyB0aGUgdGVjaG5pY2FsIGNvbnRlbnRzIG9mIHRo aXMgZG9jdW1lbnQsIGJ1dCB0aGlzIHNlZW1zIGxpa2UNCj4gYSByZWQgZmxhZyB0byBtZSBhbmQg LS0gYXMgZmFyIGFzIEkgY2FuIHRlbGwgLS0gaXQgaGFzbid0IGJlZW4gZGlzY3Vzc2VkDQo+IHll dC4gSXQncyBwb3NzaWJsZSB0aGF0IHRoZSByZWZlcmVuY2UganVzdCBlbmRlZCB1cCBpbiB0aGUg d3Jvbmcgc2VjdGlvbg0KPiAoYW5kIHNob3VsZCBhY3R1YWxseSBiZSBpbmZvcm1hdGl2ZSksIGJ1 dCBpdCdzIG5vdCBpbW1lZGlhdGVseSBvYnZpb3VzIG9uDQo+IGEgY2FzdWFsIGV4YW1pbmF0aW9u IHdoZXRoZXIgdGhhdCdzIHRydWUuDQoNClRoaXMgZG9jdW1lbnQgd2FzIG9yaWdpbmFsbHkgc2No ZWR1bGVkIGZvciB0aGUgQXByLzI3IFRlbGVjaGF0LCBidXQgYXMgYSByZXN1bHQgb2YgQWxpYeKA mXMgRElTQ1VTUyBbMV0sIHRoZSByZWZlcmVuY2UgdG8gcmZjNzM0OCB3YXMgY2hhbmdlZCB0byBO b3JtYXRpdmUuICBUaGUgV0cgd2FzIGNj4oCZZWQgZHVyaW5nIHRoZSBkaXNjdXNzaW9uLCBhbmQg SSB0aGVuIHJlcmFuIHRoZSBJRVRGIExDIHdpdGggdGhlIGRvd25yZWYgZXhwbGljaXRseSBtZW50 aW9uZWQgWzJdLiAgSSBoYXZlIG5vIGNvbmNlcm5zIGFib3V0IGl0Lg0KDQpZZXMsIHRoZSBTaGVw aGVyZOKAmXMgd3JpdGUtdXAgc2hvdWxkIGhhdmUgYmVlbiB1cGRhdGVkLg0KDQoNCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IEkgc3Ryb25nbHkgc2Vj b25kIE1pcmphJ3MgY29tbWVudCByZXF1ZXN0aW5nIHBvc2l0aXZlIGNvbmZpcm1hdGlvbiBmcm9t DQo+IHRoZSBXRyB0aGF0IGlzIGlzIGNvbGxlY3RpdmVseSBhd2FyZSBvZiB0aGUgYXNzb2NpYXRl ZCBJUFINCj4gZGVjbGFyYXRpb25zLg0KDQpJbiBteSByZXBseSB0byBNaXJqYSBbM10gSSBwb2lu dGQgb3V0IHRoYXQgdGhlIFdHIHdhcyBtYWRlIGF3YXJlIG9mIHRoZSBJUFIuDQoNClRoYW5rcyEN Cg0KQWx2YXJvLg0KDQoNCg0KWzFdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9t c2cvYmVzcy9Uai14dmJiWlJ4RmVnSWVvd0UyYnVtQkpvWVUvP3FpZD0xNzY3YWE4NTdjNTI5NmZk Yjc5MWIwMTMwNTA4NGJiYiANClsyXSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL2lldGYtYW5ub3VuY2UvTHBUNFhwNEhXWGY0NGp1aFRZNl9FbkMxSkJRLz9xaWQ9MTc2N2Fh ODU3YzUyOTZmZGI3OTFiMDEzMDUwODRiYmIgDQpbM10gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy9iZXNzL3NnWXRhcWhTQ19kbFF0Vm93VEI2elpkaGxTNC8/cWlkPTE3Njdh YTg1N2M1Mjk2ZmRiNzkxYjAxMzA1MDg0YmJiIA0KDQo= From nobody Thu May 11 06:52:10 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F84512ECEF; Thu, 11 May 2017 06:52:01 -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 9eCGxQAf3RWn; Thu, 11 May 2017 06:52:00 -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 A880512EBA3; Thu, 11 May 2017 06:47:20 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4BDlFO4026019 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 May 2017 08:47:15 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: "Alvaro Retana (aretana)" , The IESG Cc: "Zhaohui (Jeffrey) Zhang" , "draft-ietf-bess-evpn-vpws@ietf.org" , "bess-chairs@ietf.org" , "bess@ietf.org" References: <149447995711.16699.7473400423711449897.idtracker@ietfa.amsl.com> <7473B8FC-34C0-466F-AEC2-A9053DD9EE4E@cisco.com> From: Adam Roach Message-ID: Date: Thu, 11 May 2017 08:47:09 -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: <7473B8FC-34C0-466F-AEC2-A9053DD9EE4E@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [bess] Adam Roach's Discuss on draft-ietf-bess-evpn-vpws-13: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 13:52:02 -0000 On 5/11/17 07:33, Alvaro Retana (aretana) wrote: > On 5/11/17, 1:19 AM, "Adam Roach" wrote: > > Adam: > > Hi! > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Looking at the Shepherd write up and the Ballot, I see no mention of the >> normative reference to RFC 7348, which is informational and part of the >> Independent Submission stream. As I mention in my comments below, I can't >> fully follow the technical contents of this document, but this seems like >> a red flag to me and -- as far as I can tell -- it hasn't been discussed >> yet. It's possible that the reference just ended up in the wrong section >> (and should actually be informative), but it's not immediately obvious on >> a casual examination whether that's true. > This document was originally scheduled for the Apr/27 Telechat, but as a result of Alia’s DISCUSS [1], the reference to rfc7348 was changed to Normative. The WG was cc’ed during the discussion, and I then reran the IETF LC with the downref explicitly mentioned [2]. I have no concerns about it. > > Yes, the Shepherd’s write-up should have been updated. Thanks for the clarification. I'm clearing my discuss. /a From nobody Thu May 11 07:46:54 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B73713145A for ; Thu, 11 May 2017 07:46:53 -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 YxElHcVxZqya for ; Thu, 11 May 2017 07:46:51 -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 76BD9131481 for ; Thu, 11 May 2017 07:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4682; q=dns/txt; s=iport; t=1494513596; x=1495723196; h=from:to:cc:subject:date:message-id:mime-version; bh=46l2cxOGhZVLezqU2DAGcTxNRZ+08uSsh19a6eAUhCw=; b=Hxp2ScchC1XFPdPOodeP7g2+9MRuMPGpmU91hk6qeIktLjuXBTEG4KCu cVbkao3UnEL+24W6cEJ9KA2aZ0hJuYvGU3+jEAT2/gs7gXzMQhq06esNX yeSogTjY/KYHzZmLAMqvyVBtG6PRS/WNwFU9R2vR6gCGO/Krr0dBpriE2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzAwBKdxRZ/4QNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm5nYoETg2KsMIdHhiQchHJDFAECAQEBAQEBAWsohT8KTBIBDD4CBDA?= =?us-ascii?q?nBAENiiexF4ImK4pLAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZfggmEFIZRL4IxB?= =?us-ascii?q?Z4KAZMakWuUQgE2IYEKcBVYAYZiiEUBgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.38,324,1491264000"; d="scan'208,217";a="422863845" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2017 14:39:55 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v4BEdtFM026768 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 May 2017 14:39:55 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 11 May 2017 10:39:54 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Thu, 11 May 2017 10:39:54 -0400 From: "Parag Jain (paragj)" To: "martin.vigoureux@nokia.com" , "thomas.morin@orange.com" CC: Sami Boutros , "Samer Salam (ssalam)" , "bess@ietf.org" Thread-Topic: WG Adoption request for draft-jain-bess-evpn-lsp-ping-04 Thread-Index: AQHSymR0Qvbnqj2af02B/CV7ztfhlg== Date: Thu, 11 May 2017 14:39:54 +0000 Message-ID: <391A5AB0-14E7-4ADE-B0C4-29E20E8ABBB2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.58] Content-Type: multipart/alternative; boundary="_000_391A5AB014E74ADEB0C429E20E8ABBB2ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [bess] WG Adoption request for draft-jain-bess-evpn-lsp-ping-04 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 14:46:53 -0000 --_000_391A5AB014E74ADEB0C429E20E8ABBB2ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluIGFuZCBUaG9tYXMsDQoNCldlIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBXRyBhZG9w dGlvbiBmb3IgZHJhZnQtamFpbi1iZXNzLWV2cG4tbHNwLXBpbmctMDQgZHJhZnQuIFRoZSBkcmFm dCB3YXMgcHJlc2VudGVkIGluIElFVEYtOTMgKFByYWd1ZSkuIFdlIGhhZCByZWNlaXZlZCBjb21t ZW50cyBvbiB0aGUgZHJhZnQgYW5kIHRoZXkgd2VyZSBpbmNvcnBvcmF0ZWQgaW4gdGhlIGN1cnJl bnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIEZZSSwgIHRoZSBkcmFmdCBpcyBwbGFubmVkIHRvIGJl ICBpbXBsZW1lbnRlZC4NCg0KVGhhbmtzLA0KUGFyYWcNCg== --_000_391A5AB014E74ADEB0C429E20E8ABBB2ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJp O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjciLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGkgTWFydGluIGFuZCBUaG9tYXMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3Nw YWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6 bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldlIHdvdWxkIGxpa2UgdG8gcmVx dWVzdCBXRyBhZG9wdGlvbiBmb3IgZHJhZnQtamFpbi1iZXNzLWV2cG4tbHNwLXBpbmctMDQgZHJh ZnQuIFRoZSBkcmFmdCB3YXMgcHJlc2VudGVkIGluIElFVEYtOTMgKFByYWd1ZSkuIFdlIGhhZCBy ZWNlaXZlZCBjb21tZW50cyBvbiB0aGUgZHJhZnQgYW5kIHRoZXkgd2VyZQ0KIGluY29ycG9yYXRl ZCBpbiB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gRllJLCAmbmJzcDt0aGUgZHJh ZnQgaXMgcGxhbm5lZCB0byBiZSZuYnNwOyBpbXBsZW1lbnRlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGFyYWc8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_391A5AB014E74ADEB0C429E20E8ABBB2ciscocom_-- From nobody Thu May 11 09:50:38 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@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: [bess] Closed -- Working Group Last Call on draft-ietf-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list 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 Fri May 12 12:23:23 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA3F12940E; Fri, 12 May 2017 12:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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, T_KAM_HTML_FONT_INVALID=0.01, 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 KZxZEcwIm9FL; Fri, 12 May 2017 12:23:15 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F9D129AB5; Fri, 12 May 2017 12:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32770; q=dns/txt; s=iport; t=1494616714; x=1495826314; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OSSATzj9Gr7I3XbYeAG5hit9yiDwdgSRjWjsFzn8GQ4=; b=LGg8gBab3jhbf+mgnkjd3iS+EDyaD9ihptNSje1eT2xB3LfuKBbHxx/7 nlynfCi44As5Hfc1GjgkFtqhHL+PwPNLpowMHdJgRuGqqhNiN5h8rb7uW rsPvkY5g0N766gW8C0yaebJevIWcZgDygeBlgKIKpzHCbSONWko9yUN0U 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyAAB3CRZZ/4kNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4NkihiRX5V0gg8shXgCGoR/PxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?ZAQQBI1YFCwIBBgI4BwMCAgIwFBECBAENBRQHigAIDpEbnWCCJiuKJQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFhl+BXiuCcId1L4IxBZAihk2HGwGHG4M1iEoLgXm?= =?us-ascii?q?FO4NmhkaIf4tDAR84gQpwFUYSAYRoF4FjdgGHXYENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,330,1491264000"; d="scan'208,217";a="248278929" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 May 2017 19:18:33 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v4CJIXQU029257 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 May 2017 19:18:33 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 12 May 2017 14:18:32 -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, 12 May 2017 14:18:33 -0500 From: "Alvaro Retana (aretana)" To: "Ali Sajassi (sajassi)" , "draft-ietf-bess-evpn-etree@ietf.org" CC: "bess-chairs@ietf.org" , "bess@ietf.org" , Thomas Morin Thread-Topic: AD Review of draft-ietf-bess-evpn-etree-09 Thread-Index: AQHSrYuq8cG6jBFZoU6tpElXD7ib+aHswcQAgASc/gA= Date: Fri, 12 May 2017 19:18:33 +0000 Message-ID: References: <8A9E130E-0A0C-4DE5-BB35-98EE3C305E4B@cisco.com> In-Reply-To: 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: multipart/alternative; boundary="_000_EEAED7EBABE740E58E72CE47630A7326ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 19:23:22 -0000 --_000_EEAED7EBABE740E58E72CE47630A7326ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gNS85LzE3LCA4OjUxIFBNLCAiQWxpIFNhamFzc2kgKHNhamFzc2kpIiA8c2FqYXNzaUBjaXNj by5jb208bWFpbHRvOnNhamFzc2lAY2lzY28uY29tPj4gd3JvdGU6DQoNCkFsaToNCg0KSGkhDQoN Cldl4oCZcmUgb24gdGhlIHJpZ2h0IHBhdGgsIGJ1dCBub3QgdGhlcmUgeWV0LiAgUGxlYXNlIHNl ZSBteSBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQoNCuKA pg0KPiA+IE0xLiBCb3RoIHRoZSBJbnRyb2R1Y3Rpb24gYW5kIHRoZSBBYnN0cmFjdCBtZW50aW9u IHRoYXQg4oCcdGhpcyBkb2N1bWVudCBkaXNjdXNzZXMNCj4gPiBob3cgdGhlIGZ1bmN0aW9uYWwg cmVxdWlyZW1lbnRzIGZvciBFLVRyZWUgc2VydmljZSBjYW4gYmUgZWFzaWx5IG1ldOKApuKAnSAg SXQgc2VlbXMgdG8NCj4gPiBtZSB0aGF0IFJGQzczODcgaXMgdXNlZCBhcyB0aGUgYnVpbGRpbmcg YmxvY2sgZm9yIHRoaXMgZG9jdW1lbnQuICBXaHkgaXMgaXQgbm90IGENCj4gPiBOb3JtYXRpdmUg cmVmZXJlbmNlPw0KPg0KPiBCZWNhdXNlIFJGQzczODcgaXMgaW5mb3JtYXRpb25hbCBSRkMgKGFu ZCB0aGUgZnJhbWV3b3JrIFJGQykgYW5kIHRoZSBpZG5pdHMNCj4gY29tcGxhaW5zIG9mIGEgZG93 bnJlZjogTm9ybWF0aXZlIHJlZmVyZW5jZSB0byBhbiBpbmZvcm1hdGlvbmFsIFJGQw0KDQpUaGUg c3RhdHVzIG9mIGFuIFJGQyBpcyBub3QgYW4gaW5kaWNhdG9yIG9mIGhvdyBpdCBzaG91bGQgYmUg cmVmZXJlbmNlZCDigJMgY29tcGxhaW50cyBmcm9tIGlkbml0cyBpcyBub3QgYW4gZXhjdXNlLiAg SU9XLCB0aGVyZSBpcyBub3RoaW5nIHRoYXQgcHJldmVudHMgYW4gSW5mb3JtYXRpb25hbCBkb2N1 bWVudCB0byBiZSByZWZlcmVuY2VkIGFzIE5vcm1hdGl2ZSDigJMgd2UganVzdCBuZWVkIHRvIHRh a2UgY2FyZSBvZiB0aGUgcHJvY2Vzczogbm90IGEgYmlnIGRlYWwsIGJ1dCBpbXBvcnRhbnQuDQoN CkxldCBtZSByZXBocmFzZS4gIElzIHJmYzczODcgYSBkb2N1bWVudCB0aGF0IOKAnHRoYXQgbXVz dCBiZSByZWFkIHRvIHVuZGVyc3RhbmQgb3IgaW1wbGVtZW504oCdIFsxXSB3aGF0IGlzIHNwZWNp ZmllZCBpbiB0aGlzIGRvY3VtZW50PyAgQmVjYXVzZSBvZiBob3cgcmZjNzM4NyBpcyBwb3NpdGlv bmVkIGluIHRoZSBBYnN0cmFjdC9JbnRyb2R1Y3Rpb24sIGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhl IGZyYW1ld29yayBtdXN0IGJlIHJlYWQgdG8gdGhlbiB1bmRlcnN0YW5kIGhvdyB0aGlzIGRvY3Vt ZW50IGFkZHJlc3NlcyBpdDoNCg0KDQrigJwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBBIHNvbHV0aW9uDQoNCiAgIGZyYW1ld29yayBmb3Igc3VwcG9ydGluZyB0 aGlzIHNlcnZpY2UgaW4gTVBMUyBuZXR3b3JrcyBpcyBwcm9wb3NlZCBpbg0KDQogICBSRkM3Mzg3 PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3Mzg3PiAoIkEgRnJhbWV3b3JrIGZvciBF dGhlcm5ldCBUcmVlIChFLVRyZWUpIFNlcnZpY2Ugb3ZlciBhDQoNCiAgIE11bHRpcHJvdG9jb2wg TGFiZWwgU3dpdGNoaW5nIChNUExTKSBOZXR3b3JrIikuIFRoaXMgZG9jdW1lbnQNCg0KICAgZGlz Y3Vzc2VzIGhvdyB0aG9zZSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cyBjYW4gYmUgZWFzaWx5IG1l dCB3aXRoDQoNCiAgIEV0aGVybmV0IFZQTiAoRVZQTikgYW5kIGhvdyBFVlBOIG9mZmVycyBhIG1v cmUgZWZmaWNpZW50DQoNCiAgIGltcGxlbWVudGF0aW9uIG9mIHRoZXNlIGZ1bmN0aW9ucy7igJ0N Cg0KWzFdIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L25vcm1hdGl2ZS1pbmZv cm1hdGl2ZS5odG1sDQoNCg0KPiA+IE0yLiBUaGVyZSBpcyBubyByZWZlcmVuY2UgdG8gRS1UcmVl LiAgUGxlYXNlIGFkZCBhIE5vcm1hdGl2ZSBvbmUuDQo+DQo+IEFkZGVkIGEgcmVmZXJlbmNlIGZv ciBFLVRSRUUgZGVmaW5pdGlvbiBpbiBNRUYuDQoNClRoaXMgcmVmZXJlbmNlIG5lZWRzIHRvIGJl IE5vcm1hdGl2ZSDigJMgc2VlIGFib3ZlLg0KDQoNCuKApg0KPiA+IE02LiBEZWZpbml0aW9uIG9m IHRoZSBFLVRSRUUgRXh0ZW5kZWQgQ29tbXVuaXR5DQo+ID4NCj4gPiBNNi4xLiBPbmx5IG9uZSBG bGFnIGlzIGRlZmluZWQuICBXaGF0IGFib3V0IHRoZSBvdGhlcnM/ICBQbGVhc2Ugc2V0IHVwIGEg cmVnaXN0cnkuDQo+DQo+IElmIG5lZWRlZCBpbiB0aGUgZnV0dXJlLCB3ZSB3aWxsIHNldHVwIGEg cmVnaXN0cnkuDQoNClBsZWFzZSBzZXQgaXQgdXAgbm93Lg0KDQrigKYNCj4gPiBNNy4xLiBJdCBp cyBub3QgY2xlYXIgdG8gbWUgaG93IHRoZSBDIGJpdCBpcyB0byBiZSB1c2VkLiAgU2VjdGlvbiA1 LjIgc2F5cyB0aGF0IOKAnHRoZSBoaWdoLQ0KPiA+IG9yZGVyIGJpdCBvZiB0aGUgdHVubmVsIHR5 cGUgZmllbGQgKEMgYml0IC0gQ29tcG9zaXRlIHR1bm5lbCBiaXQpIGlzIHNldCB3aGlsZSB0aGUN Cj4gPiByZW1haW5pbmcgbG93LW9yZGVyIHNldmVuIGJpdHMgaW5kaWNhdGUgdGhlIHR1bm5lbCB0 eXBlIGFzIGJlZm9yZS7igJ0gICBCdXQgMy4zLjEgc2F5cw0KPiA+IHRoYXQgdGhlIOKAnG5ldyBj b21wb3NpdGUgdHVubmVsIHR5cGUgaXMgYWR2ZXJ0aXNlZCBieSB0aGUgcm9vdCBQRSB0byBzaW11 bHRhbmVvdXNseQ0KPiA+IGluZGljYXRlIGEgUDJNUCB0dW5uZWwgaW4gdHJhbnNtaXQgZGlyZWN0 aW9uIGFuZCBhbiBpbmdyZXNzLXJlcGxpY2F0aW9uIHR1bm5lbCBpbiB0aGUNCj4gPiByZWNlaXZl IGRpcmVjdGlvbuKApuKAnS4gIEtub3dpbmcsIGZyb20gNS4yIHRoYXQgd2hlbiB0aGUgQyBiaXQg aXMgc2V0IOKAnFR1bm5lbA0KPiA+IFR5cGVz4oCmMHgwNiAnSW5ncmVzcyBSZXBsaWNhdGlvbicg aXMgaW52YWxpZOKAnSwgdGhlbiBkb2VzIHRoZSBDIGJpdCBoYXZlIGEgc2V0IG1lYW5pbmcNCj4g PiBvciA/Pz8gICBbQlRXLCBzL2lzL2FyZV0NCj4NCj4gVGhlIGRlc2NyaXB0aW9uIGluIHNlY3Rp b24gMy4zLjEgaXMgY29uc2lzdGVudCB3aXRoIHRoaXMgc2VjdGlvbiA1LjIuIEJhc2ljYWxseSwg Q29tcG9zaXRlDQo+IFR1bm5lbCB0eXBlLCBhcyBpdHMgbmFtZSBpbXBsaWVzIGNvbnNpc3Qgb2Yg dHdvIHR1bm5lbHM6IGEgUDJNUCB0dW5uZWwgaW4gdGhlIHRyYW5zbWl0DQo+IGRpcmVjdGlvbiBh bmQgYSBNUDJQIHR1bm5lbCBpbiB0aGUgcmVjZWl2ZSBkaXJlY3Rpb24uIFRoZSBNUDJQIHR1bm5l bCBpbiB0aGUgcmVjZWl2ZQ0KPiBkaXJlY3Rpb24gaXMgdXNlZCBieSBMZWFmIFBFIGRldmljZXMg Zm9yIHRoZWlyIEJVTSB0cmFmZmljIHRyYW5zbWlzc2lvbi4gVGhlICJpbmdyZXNzDQo+IHJlcGxp Y2F0aW9uIHR1bm5lbCB0eXBl4oCdIGlzIG5vdCB2YWxpZCBiZWNhdXNlIGZvciB0aGF0IHdlIGRv buKAmXQgbmVlZCBjb21wb3NpdGUgdHVubmVsDQo+IHR5cGUhIQ0KPiBJIGFkZGVkIHRoZSBmb2xs b3dpbmcgc2VudGVuY2UgdG8gdGhlIDFzdCBwYXJhZ3JhcGggdG8gY2xhcmlmeSBpdCAgbW9yZToN Cj4gIkNvbXBvc2l0ZSB0dW5uZWwgdHlwZSBpcyBhZHZlcnRpc2VkIGJ5IHRoZSByb290IFBFIHRv IHNpbXVsdGFuZW91c2x5IGluZGljYXRlIGEgUDJNUA0KPiB0dW5uZWwgaW4gdHJhbnNtaXQgZGly ZWN0aW9uIGFuZCBhbiBpbmdyZXNzLXJlcGxpY2F0aW9uIHR1bm5lbCBpbiB0aGUgcmVjZWl2ZSBk aXJlY3Rpb24NCj4gZm9yIHRoZSBCVU0gdHJhZmZpYy4iDQoNCkxldCBtZSBzZWUgaWYgSSB1bmRl cnN0YW5kIHdoYXQgeW914oCZcmUgc2F5aW5nOg0KDQpJZiB0aGUgQy1iaXQgaXMgc2V0LCB0aGVu IHRoZSByZWNlaXZlIGRpcmVjdGlvbiBhbHdheXMgaGFzIGFuIElSIHR1bm5lbC4gIFRoZSB0eXBl IG9mIHRoZSBQMk1QIHR1bm5lbCBpcyBkZWZpbmVkIGJ5IG9uZSBvZiB0aGUgb3RoZXIgYml0cy4g IElzIHRoYXQgcmlnaHQ/DQoNCklmIHNvLCBhcmUgYWxsIHRoZSBvdGhlciBiaXRzIHZhbGlkIChh bHdheXMpPyAgVGhlIHRleHQgYWxyZWFkeSBzYXlzIHRoYXQgMHgwMC8weDA2IGFyZSBpbnZhbGlk LCBidXQsIGZvciBleGFtcGxlLCB3aGF0IGFib3V0IDB4MDcgKG1MRFAgTVAyTVAgTFNQKSBvciAw eDBBIChBc3Npc3RlZC1SZXBsaWNhdGlvbiBUdW5uZWwgW2RyYWZ0LWlldGYtYmVzcy1ldnBuLW9w dGltaXplZC1pcl0pPw0KDQpIb3cgY2FuIHlvdSBiZSBzdXJlIHRoYXQgYW55IG90aGVyIHR5cGUg YmVzaWRlcyAweDAwLzB4MDYgd2lsbCBiZSBvaz8NCg0KDQoNCuKApg0KPiA+IE04LjQuIFdoYXQg aXMgMHg3RiByZXNlcnZlZCBmb3I/ICBJdCBkb2VzbuKAmXQgc2VlbSB0byBiZSB1c2VkIGluIHRo aXMgZG9jdW1lbnQuICBXaHkNCj4gPiBhIGRpZmZlcmVudCByZWdpc3RyYXRpb24gcHJvY2VkdXJl Pw0KPg0KPiAweDdGIGp1c3QgcmVwbGFjZXMgMHgwRiAtIGkuZS4gIE5vIG5ldyByZWdpc3RyYXRp b24gcHJvY2VkdXJlDQoNCjB4MEYgaXMgY3VycmVudGx5IFVuYXNzaWduZWQsIG5vdCBSZXNlcnZl ZC4NCg0KDQrigKYNCj4gPiBQMTcuIFRoZSAnVXBkYXRlczogJyBsaW5lIGluIHRoZSBkcmFmdCBo ZWFkZXIgc2hvdWxkIGxpc3Qgb25seSB0aGUgX251bWJlcnNfIG9mIHRoZQ0KPiA+IFJGQ3Mgd2hp Y2ggd2lsbCBiZSB1cGRhdGVkIGJ5IHRoaXMgZG9jdW1lbnQgKGlmIGFwcHJvdmVkKTsgaXQgc2hv dWxkIG5vdCBpbmNsdWRlIHRoZQ0KPiA+IHdvcmQgJ1JGQycgaW4gdGhlIGxpc3QuDQo+DQo+IERv bmUuIEFsc28gYWRkZWQgNjUxNCB0byB0aGUgbGlzdC4NCg0KSG1tLi4uICBJIGRvbuKAmXQgc2Vl IGhvdyB0aGlzIGRvY3VtZW50IFVwZGF0ZXMgcmZjNjUxNOKApi4/Pw0KDQpCdXQgaWYgaXQgZG9l cywgeW91IG5lZWQgdG8gaW5jbHVkZSBzb21lIHRleHQgYWJvdXQgaXQgaW4gYm90aCB0aGUgQWJz dHJhY3QgYW5kIHRoZSBJbnRyb2R1Y3Rpb24uICBCVFcsIHBsZWFzZSBhZGQgc29tZXRoaW5nIGFi b3V0IHRoZSBVcGRhdGUgdG8gcmZjNzM4NSBpbiB0aGUgSW50cm9kdWN0aW9uLg0KDQoNCj4gPiBQ MTguIFRoZXJlIGlzIG5vIHJlZmVyZW5jZSB0byByZmM1MjI2Lg0KPg0KPiBEb25lLg0KDQpUaGlz IG9uZSBtdXN0IGJlIE5vcm1hdGl2ZS4NCg== --_000_EEAED7EBABE740E58E72CE47630A7326ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1h bDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRv d3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4u SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5tc29JbnMN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxp bms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA1LzkvMTcsIDg6NTEgUE0sICZxdW90O0FsaSBTYWph c3NpIChzYWphc3NpKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhamFzc2lAY2lzY28uY29t Ij5zYWphc3NpQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QWxpOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSE8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2XigJlyZSBvbiB0aGUgcmlnaHQgcGF0aCwgYnV0IG5vdCB0aGVyZSB5ZXQuJm5i c3A7IFBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsdmFyby48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+4oCmPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0OyBN MS4gQm90aCB0aGUgSW50cm9kdWN0aW9uIGFuZCB0aGUgQWJzdHJhY3QgbWVudGlvbiB0aGF0IOKA nHRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+ Jmd0OyAmZ3Q7IGhvdyB0aGUgZnVuY3Rpb25hbCByZXF1aXJlbWVudHMgZm9yIEUtVHJlZSBzZXJ2 aWNlIGNhbiBiZSBlYXNpbHkgbWV04oCm4oCdJm5ic3A7IEl0IHNlZW1zIHRvDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7IG1lIHRoYXQgUkZDNzM4NyBpcyB1c2VkIGFz IHRoZSBidWlsZGluZyBibG9jayBmb3IgdGhpcyBkb2N1bWVudC4mbmJzcDsgV2h5IGlzIGl0IG5v dCBhDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7IE5vcm1hdGl2ZSBy ZWZlcmVuY2U/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6YmxhY2siPiZndDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4m Z3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpyZWQiPkJlY2F1 c2UgUkZDNzM4NyBpcyBpbmZvcm1hdGlvbmFsIFJGQyAoYW5kIHRoZSBmcmFtZXdvcmsgUkZDKSBh bmQgdGhlIGlkbml0cw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZndDsgPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOnJlZCI+Y29tcGxhaW5zIG9mIGEg ZG93bnJlZjombmJzcDtOb3JtYXRpdmUgcmVmZXJlbmNlIHRvIGFuIGluZm9ybWF0aW9uYWwgUkZD PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6cmVkIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3RhdHVzIG9mIGFuIFJGQyBpcyBub3QgYW4gaW5k aWNhdG9yIG9mIGhvdyBpdCBzaG91bGQgYmUgcmVmZXJlbmNlZCDigJMgY29tcGxhaW50cyBmcm9t IGlkbml0cyBpcyBub3QgYW4gZXhjdXNlLiZuYnNwOyBJT1csIHRoZXJlIGlzIG5vdGhpbmcgdGhh dCBwcmV2ZW50cyBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IHRvIGJlIHJlZmVyZW5jZWQgYXMg Tm9ybWF0aXZlIOKAkyB3ZSBqdXN0IG5lZWQgdG8gdGFrZSBjYXJlDQogb2YgdGhlIHByb2Nlc3M6 IG5vdCBhIGJpZyBkZWFsLCBidXQgaW1wb3J0YW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5M ZXQgbWUgcmVwaHJhc2UuJm5ic3A7IElzIHJmYzczODcgYSBkb2N1bWVudCB0aGF0IOKAnHRoYXQg bXVzdCBiZSByZWFkIHRvIHVuZGVyc3RhbmQgb3IgaW1wbGVtZW504oCdIFsxXSB3aGF0IGlzIHNw ZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50PyZuYnNwOyBCZWNhdXNlIG9mIGhvdyByZmM3Mzg3IGlz IHBvc2l0aW9uZWQgaW4gdGhlIEFic3RyYWN0L0ludHJvZHVjdGlvbiwgaXQgc2VlbXMgdG8gbWUg dGhhdCB0aGUgZnJhbWV3b3JrIG11c3QNCiBiZSByZWFkIHRvIHRoZW4gdW5kZXJzdGFuZCBob3cg dGhpcyBkb2N1bWVudCBhZGRyZXNzZXMgaXQ6IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6cmVkIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPuKAnCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBBIHNvbHV0aW9uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyBmcmFt ZXdvcmsgZm9yIHN1cHBvcnRpbmcgdGhpcyBzZXJ2aWNlIGluIE1QTFMgbmV0d29ya3MgaXMgcHJv cG9zZWQgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3Mzg3Ij48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dCI+UkZDNzM4Nzwvc3Bhbj48L2E+ICgmcXVvdDtBIEZyYW1ld29yayBmb3IgRXRoZXJu ZXQgVHJlZSAoRS1UcmVlKSBTZXJ2aWNlIG92ZXIgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4m bmJzcDsmbmJzcDsgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpIE5ldHdvcmsm cXVvdDspLiBUaGlzIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNw OyBkaXNjdXNzZXMgaG93IHRob3NlIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGNhbiBiZSBlYXNp bHkgbWV0IHdpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7IEV0aGVybmV0 IFZQTiAoRVZQTikgYW5kIGhvdyBFVlBOIG9mZmVycyBhIG1vcmUgZWZmaWNpZW50PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyBpbXBsZW1lbnRhdGlvbiBvZiB0aGVzZSBmdW5j dGlvbnMu4oCdPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+WzFdIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL2llc2cvc3RhdGVtZW50L25vcm1hdGl2ZS1pbmZvcm1hdGl2ZS5odG1sIj4NCmh0dHBzOi8v d3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L25vcm1hdGl2ZS1pbmZvcm1hdGl2ZS5odG1sPC9h PiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7IE0yLiBUaGVy ZSBpcyBubyByZWZlcmVuY2UgdG8gRS1UcmVlLiZuYnNwOyBQbGVhc2UgYWRkIGEgTm9ybWF0aXZl IG9uZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjpibGFjayI+Jmd0OyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZndDsg PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOnJlZCI+QWRkZWQgYSBy ZWZlcmVuY2UgZm9yIEUtVFJFRSBkZWZpbml0aW9uIGluIE1FRi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpyZWQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoaXMgcmVmZXJlbmNlIG5lZWRzIHRvIGJlIE5vcm1hdGl2ZSDigJMgc2VlIGFib3ZlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj7igKYmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7 IE02LiBEZWZpbml0aW9uIG9mIHRoZSBFLVRSRUUgRXh0ZW5kZWQgQ29tbXVuaXR5PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0 OyAmZ3Q7IE02LjEuIE9ubHkgb25lIEZsYWcgaXMgZGVmaW5lZC4mbmJzcDsgV2hhdCBhYm91dCB0 aGUgb3RoZXJzPyZuYnNwOyBQbGVhc2Ugc2V0IHVwIGEgcmVnaXN0cnkuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6cmVkIj5JZiBuZWVkZWQgaW4gdGhlIGZ1dHVyZSwgd2Ugd2lsbCBzZXR1 cCBhIHJlZ2lzdHJ5LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOnJlZCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHNldCBpdCB1 cCBub3cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj7igKYmbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7ICZndDsgTTcuMS4gSXQg aXMgbm90IGNsZWFyIHRvIG1lIGhvdyB0aGUgQyBiaXQgaXMgdG8gYmUgdXNlZC4mbmJzcDsgU2Vj dGlvbiA1LjIgc2F5cyB0aGF0IOKAnHRoZSBoaWdoLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJs YWNrIj4mZ3Q7ICZndDsgb3JkZXIgYml0IG9mIHRoZSB0dW5uZWwgdHlwZSBmaWVsZCAoQyBiaXQg LSBDb21wb3NpdGUgdHVubmVsIGJpdCkgaXMgc2V0IHdoaWxlIHRoZQ0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0OyByZW1haW5pbmcgbG93LW9yZGVyIHNldmVuIGJpdHMg aW5kaWNhdGUgdGhlIHR1bm5lbCB0eXBlIGFzIGJlZm9yZS7igJ0mbmJzcDsmbmJzcDsgQnV0IDMu My4xIHNheXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7ICZndDsgdGhhdCB0 aGUg4oCcbmV3IGNvbXBvc2l0ZSB0dW5uZWwgdHlwZSBpcyBhZHZlcnRpc2VkIGJ5IHRoZSByb290 IFBFIHRvIHNpbXVsdGFuZW91c2x5DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0 OyAmZ3Q7IGluZGljYXRlIGEgUDJNUCB0dW5uZWwgaW4gdHJhbnNtaXQgZGlyZWN0aW9uIGFuZCBh biBpbmdyZXNzLXJlcGxpY2F0aW9uIHR1bm5lbCBpbiB0aGUNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOmJsYWNrIj4mZ3Q7ICZndDsgcmVjZWl2ZSBkaXJlY3Rpb27igKbigJ0uJm5ic3A7IEtub3dp bmcsIGZyb20gNS4yIHRoYXQgd2hlbiB0aGUgQyBiaXQgaXMgc2V0IOKAnFR1bm5lbA0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0OyBUeXBlc+KApjB4MDYgJ0luZ3Jlc3Mg UmVwbGljYXRpb24nIGlzIGludmFsaWTigJ0sIHRoZW4gZG9lcyB0aGUgQyBiaXQgaGF2ZSBhIHNl dCBtZWFuaW5nDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7IG9yID8/ PyZuYnNwOyZuYnNwOyBbQlRXLCBzL2lzL2FyZV08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7 Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7 IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpyZWQiPlRoZSBkZXNj cmlwdGlvbiBpbiBzZWN0aW9uIDMuMy4xIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGlzIHNlY3Rpb24g NS4yLiBCYXNpY2FsbHksIENvbXBvc2l0ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2si PiZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOnJlZCI+VHVu bmVsIHR5cGUsIGFzIGl0cyBuYW1lIGltcGxpZXMgY29uc2lzdCBvZiB0d28gdHVubmVsczogYSBQ Mk1QIHR1bm5lbCBpbiB0aGUgdHJhbnNtaXQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNr Ij4mZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpyZWQiPmRp cmVjdGlvbiBhbmQgYSBNUDJQIHR1bm5lbCBpbiB0aGUgcmVjZWl2ZSBkaXJlY3Rpb24uIFRoZSBN UDJQIHR1bm5lbCBpbiB0aGUgcmVjZWl2ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2si PiZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOnJlZCI+ZGly ZWN0aW9uIGlzIHVzZWQgYnkgTGVhZiZuYnNwO1BFIGRldmljZXMgZm9yIHRoZWlyIEJVTSB0cmFm ZmljIHRyYW5zbWlzc2lvbi4gVGhlICZxdW90O2luZ3Jlc3MNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOmJsYWNrIj4mZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xv cjpyZWQiPnJlcGxpY2F0aW9uIHR1bm5lbCB0eXBl4oCdJm5ic3A7aXMgbm90IHZhbGlkIGJlY2F1 c2UgZm9yIHRoYXQgd2UgZG9u4oCZdCBuZWVkIGNvbXBvc2l0ZSB0dW5uZWwNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpyZWQiPnR5cGUhITwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymxh Y2siPiZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOnJlZCI+ SSBhZGRlZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIHRvIHRoZSAxc3QmbmJzcDtwYXJhZ3JhcGgg dG8gY2xhcmlmeSBpdCAmbmJzcDttb3JlOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 YmxhY2siPiZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOnJl ZCI+JnF1b3Q7Q29tcG9zaXRlIHR1bm5lbCB0eXBlIGlzIGFkdmVydGlzZWQgYnkgdGhlIHJvb3Qg UEUgdG8gc2ltdWx0YW5lb3VzbHkgaW5kaWNhdGUgYSBQMk1QDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjpibGFjayI+Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6cmVkIj50dW5uZWwgaW4gdHJhbnNtaXQgZGlyZWN0aW9uIGFuZCBhbiBpbmdyZXNzLXJlcGxp Y2F0aW9uIHR1bm5lbCBpbiB0aGUgcmVjZWl2ZSBkaXJlY3Rpb24NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOmJsYWNrIj4mZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpyZWQiPmZvciB0aGUgQlVNIHRyYWZmaWMuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6cmVkIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5MZXQgbWUgc2VlIGlmIEkgdW5kZXJzdGFuZCB3aGF0IHlvdeKAmXJlIHNheWluZzo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIEMtYml0IGlzIHNldCwgdGhlbiB0aGUgcmVjZWl2ZSBk aXJlY3Rpb24gYWx3YXlzIGhhcyBhbiBJUiB0dW5uZWwuJm5ic3A7IFRoZSB0eXBlIG9mIHRoZSBQ Mk1QIHR1bm5lbCBpcyBkZWZpbmVkIGJ5IG9uZSBvZiB0aGUgb3RoZXIgYml0cy4mbmJzcDsgSXMg dGhhdCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgc28sIGFyZSBhbGwgdGhlIG90 aGVyIGJpdHMgdmFsaWQgKGFsd2F5cyk/Jm5ic3A7IFRoZSB0ZXh0IGFscmVhZHkgc2F5cyB0aGF0 IDB4MDAvMHgwNiBhcmUgaW52YWxpZCwgYnV0LCBmb3IgZXhhbXBsZSwgd2hhdCBhYm91dCAweDA3 IChtTERQIE1QMk1QIExTUCkgb3IgMHgwQSAoQXNzaXN0ZWQtUmVwbGljYXRpb24gVHVubmVsIFtk cmFmdC1pZXRmLWJlc3MtZXZwbi1vcHRpbWl6ZWQtaXJdKT8gJm5ic3A7Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhvdyBjYW4geW91IGJlIHN1cmUgdGhhdCBhbnkgb3RoZXIgdHlwZSBi ZXNpZGVzIDB4MDAvMHgwNiB3aWxsIGJlIG9rPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6cmVkIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+4oCmPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0 OyAmZ3Q7IE04LjQuIFdoYXQgaXMgMHg3RiByZXNlcnZlZCBmb3I/Jm5ic3A7IEl0IGRvZXNu4oCZ dCBzZWVtIHRvIGJlIHVzZWQgaW4gdGhpcyBkb2N1bWVudC4mbmJzcDsgV2h5DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7IGEgZGlmZmVyZW50IHJlZ2lzdHJhdGlvbiBw cm9jZWR1cmU/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6YmxhY2siPiZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPjB4N0YganVzdCBy ZXBsYWNlcyAweDBGIC0mbmJzcDtpLmUuICZuYnNwO05vIG5ldyByZWdpc3RyYXRpb24gcHJvY2Vk dXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOnJlZCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MHgwRiBpcyBjdXJyZW50bHkgVW5hc3NpZ25lZCwgbm90IFJlc2VydmVkLjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2si PuKApiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 YmxhY2siPiZndDsgJmd0OyBQMTcuIFRoZSAnVXBkYXRlczogJyBsaW5lIGluIHRoZSBkcmFmdCBo ZWFkZXIgc2hvdWxkIGxpc3Qgb25seSB0aGUgX251bWJlcnNfIG9mIHRoZQ0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0OyBSRkNzIHdoaWNoIHdpbGwgYmUgdXBkYXRlZCBi eSB0aGlzIGRvY3VtZW50IChpZiBhcHByb3ZlZCk7IGl0IHNob3VsZCBub3QgaW5jbHVkZSB0aGU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7IHdvcmQgJ1JGQycgaW4gdGhl IGxpc3QuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6cmVkIj5Eb25lLiBBbHNvIGFkZGVkIDY1MTQgdG8gdGhlIGxp c3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6cmVkIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IbW0uLi4mbmJzcDsgSSBkb27igJl0IHNlZSBob3cg dGhpcyBkb2N1bWVudCBVcGRhdGVzIHJmYzY1MTTigKYuPz88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QnV0IGlmIGl0IGRvZXMsIHlvdSBuZWVkIHRvIGluY2x1ZGUgc29tZSB0ZXh0IGFib3V0IGl0 IGluIGJvdGggdGhlIEFic3RyYWN0IGFuZCB0aGUgSW50cm9kdWN0aW9uLiZuYnNwOyBCVFcsIHBs ZWFzZSBhZGQgc29tZXRoaW5nIGFib3V0IHRoZSBVcGRhdGUgdG8gcmZjNzM4NSBpbiB0aGUgSW50 cm9kdWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0OyBQMTguIFRoZXJlIGlzIG5v IHJlZmVyZW5jZSB0byByZmM1MjI2LiZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0 OyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jmd0 OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6cmVkIj5Eb25lLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPlRoaXMgb25lIG11c3QgYmUgTm9ybWF0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_EEAED7EBABE740E58E72CE47630A7326ciscocom_-- From nobody Fri May 12 15:40:16 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AF112751F; Fri, 12 May 2017 15:40:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149462880650.13435.12645776236593305114@ietfa.amsl.com> Date: Fri, 12 May 2017 15:40:06 -0700 Archived-At: Subject: [bess] I-D Action: draft-ietf-bess-evpn-etree-11.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 22:40:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : E-TREE Support in EVPN & PBB-EVPN Authors : Ali Sajassi Samer Salam John Drake Jim Uttaro Sami Boutros Jorge Rabadan Filename : draft-ietf-bess-evpn-etree-11.txt Pages : 19 Date : 2017-05-12 Abstract: The Metro Ethernet Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet Tree (E-Tree). A solution framework for supporting this service in MPLS networks is proposed in RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network"). This document discusses how those functional requirements can be easily met with Ethernet VPN (EVPN) and how EVPN offers a more efficient implementation of these functions. This document makes use of the most significant bit of the scope governed by the IANA registry created by RFC7385, and hence updates RFC7385 accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-etree-11 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-etree-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-etree-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 Fri May 12 16:19:04 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025ED129571; Fri, 12 May 2017 16:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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, T_KAM_HTML_FONT_INVALID=0.01, 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 9-e2GHL9V7Ce; Fri, 12 May 2017 16:19:00 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99F1129B11; Fri, 12 May 2017 16:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36238; q=dns/txt; s=iport; t=1494630937; x=1495840537; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TL8eCkKoa+d8/uvPmEbxakfFvzwzo2kfaR6gvfrpTjI=; b=Y7rtQQlCVK/XSzoG0nXBazM6V6eHRCGhhLj9tpqd1XUJru4andPdPoqn JZtJuNgP9GhL8R412B4t8x7+KFhCzJYCf+BiT2e1HIoxthVNLdMDDSp7l QR8HYCc/tSRVVRcipPOm6Hsxbswmik2tSuuLfrztUZjFSGtcFIMdf8Swx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAACNQRZZ/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4RHiTWRX5V0gg8shXgChRk/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgF5BQsCAQgRAwECIQEGBzIUCQgCBAENBRQHigAIDrEVK4ohAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWIPYMbhQOFUgWQIoZNhxsBhxuDNYhKggSFO4Nmhka?= =?us-ascii?q?If4tDAR84gQpwFUaEexeBY3YBh12BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,332,1491264000"; d="scan'208,217";a="425599457" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 May 2017 23:15:35 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v4CNFZef012899 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 May 2017 23:15:35 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 12 May 2017 18:15:35 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Fri, 12 May 2017 18:15:35 -0500 From: "Ali Sajassi (sajassi)" To: "Alvaro Retana (aretana)" , "draft-ietf-bess-evpn-etree@ietf.org" CC: "bess-chairs@ietf.org" , "bess@ietf.org" , Thomas Morin Thread-Topic: AD Review of draft-ietf-bess-evpn-etree-09 Thread-Index: AQHSrYuq8cG6jBFZoU6tpElXD7ib+aHswcQAgASc/gCAAA/rAA== Date: Fri, 12 May 2017 23:15:35 +0000 Message-ID: References: <8A9E130E-0A0C-4DE5-BB35-98EE3C305E4B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.52] Content-Type: multipart/alternative; boundary="_000_D53B8CBC1F062Esajassiciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 23:19:03 -0000 --_000_D53B8CBC1F062Esajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Please see my comment resolutions inline. I have updated and posted a new r= ev: https://www.ietf.org/id/draft-ietf-bess-evpn-etree-11.txt From: "Alvaro Retana (aretana)" > Date: Friday, May 12, 2017 at 12:18 PM To: Cisco Employee >, "draft-ie= tf-bess-evpn-etree@ietf.org" > Cc: "bess-chairs@ietf.org" >, "bess@ietf.org" >, Thomas Morin > Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09 On 5/9/17, 8:51 PM, "Ali Sajassi (sajassi)" > wrote: Ali: Hi! We=92re on the right path, but not there yet. Please see my comments inlin= e below. Thanks! Alvaro. =85 > > M1. Both the Introduction and the Abstract mention that =93this documen= t discusses > > how the functional requirements for E-Tree service can be easily met=85= =94 It seems to > > me that RFC7387 is used as the building block for this document. Why i= s it not a > > Normative reference? > > Because RFC7387 is informational RFC (and the framework RFC) and the idni= ts > complains of a downref: Normative reference to an informational RFC The status of an RFC is not an indicator of how it should be referenced =96= complaints from idnits is not an excuse. IOW, there is nothing that preve= nts an Informational document to be referenced as Normative =96 we just nee= d to take care of the process: not a big deal, but important. Let me rephrase. Is rfc7387 a document that =93that must be read to unders= tand or implement=94 [1] what is specified in this document? Because of ho= w rfc7387 is positioned in the Abstract/Introduction, it seems to me that t= he framework must be read to then understand how this document addresses it= : =93 A solution framework for supporting this service in MPLS networks is proposed in RFC7387 ("A Framework for Ethernet = Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network"). This document discusses how those functional requirements can be easily met with Ethernet VPN (EVPN) and how EVPN offers a more efficient implementation of these functions.=94 [1] https://www.ietf.org/iesg/statement/normative-informative.html It is a bit subjective in this case but to be safe and assuming the readers= don=92t have any background in E-TREE (which has been around for a long ti= me =96 e.g., private VLAN), I have moved it to the normative section. > > M2. There is no reference to E-Tree. Please add a Normative one. > > Added a reference for E-TREE definition in MEF. This reference needs to be Normative =96 see above. Done. =85 > > M6. Definition of the E-TREE Extended Community > > > > M6.1. Only one Flag is defined. What about the others? Please set up = a registry. > > If needed in the future, we will setup a registry. Please set it up now. OK, I will set it up. =85 > > M7.1. It is not clear to me how the C bit is to be used. Section 5.2 s= ays that =93the high- > > order bit of the tunnel type field (C bit - Composite tunnel bit) is se= t while the > > remaining low-order seven bits indicate the tunnel type as before.=94 = But 3.3.1 says > > that the =93new composite tunnel type is advertised by the root PE to s= imultaneously > > indicate a P2MP tunnel in transmit direction and an ingress-replication= tunnel in the > > receive direction=85=94. Knowing, from 5.2 that when the C bit is set = =93Tunnel > > Types=850x06 'Ingress Replication' is invalid=94, then does the C bit h= ave a set meaning > > or ??? [BTW, s/is/are] > > The description in section 3.3.1 is consistent with this section 5.2. Bas= ically, Composite > Tunnel type, as its name implies consist of two tunnels: a P2MP tunnel in= the transmit > direction and a MP2P tunnel in the receive direction. The MP2P tunnel in = the receive > direction is used by Leaf PE devices for their BUM traffic transmission. = The "ingress > replication tunnel type=94 is not valid because for that we don=92t need = composite tunnel > type!! > I added the following sentence to the 1st paragraph to clarify it more: > "Composite tunnel type is advertised by the root PE to simultaneously ind= icate a P2MP > tunnel in transmit direction and an ingress-replication tunnel in the rec= eive direction > for the BUM traffic." Let me see if I understand what you=92re saying: If the C-bit is set, then the receive direction always has an IR tunnel. T= he type of the P2MP tunnel is defined by one of the other bits. Is that ri= ght? That=92s correct. The remaining 7 bits indicate the type of tunnel. If so, are all the other bits valid (always)? The text already says that 0= x00/0x06 are invalid, but, for example, what about 0x07 (mLDP MP2MP LSP) or= 0x0A (Assisted-Replication Tunnel [draft-ietf-bess-evpn-optimized-ir])? How can you be sure that any other type besides 0x00/0x06 will be ok? Basically composite tunnel type doesn=92t make sense when ingress replicat= ion (0x06) is used or when tunnel info is not present (0x00). Other than th= at, it can be used with other tunnel types. =85 > > M8.4. What is 0x7F reserved for? It doesn=92t seem to be used in this = document. Why > > a different registration procedure? > > 0x7F just replaces 0x0F - i.e. No new registration procedure 0x0F is currently Unassigned, not Reserved. I meant to say 0xFF. Basically the existing experimental types 0xFB =96 0xF= E and reserved type of 0xFF has moved to new code points of: 0x7B =96 0x7E = and 0x7F. =85 > > P17. The 'Updates: ' line in the draft header should list only the _num= bers_ of the > > RFCs which will be updated by this document (if approved); it should no= t include the > > word 'RFC' in the list. > > Done. Also added 6514 to the list. Hmm... I don=92t see how this document Updates rfc6514=85.?? On the 2nd thought, it doesn=92t updated it because the whole purpose of C-= bit is backward compatibility. So no updates to rfc6514. I removed it from = the text. But if it does, you need to include some text about it in both the Abstract= and the Introduction. BTW, please add something about the Update to rfc73= 85 in the Introduction. Added a sentence to the introduction in last paragraph. > > P18. There is no reference to rfc5226. > > Done. This one must be Normative. Done. --_000_D53B8CBC1F062Esajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Alvaro,

Please see m= y comment resolutions inline. I have updated and posted a new rev:



From: "Alvaro Retana (aretana)= " <aretana@cisco.com> Date: Friday, May 12, 2017 at 12:18= PM
To: Cisco Employee <sajassi@cisco.com>, "draft-ietf-bess-evpn-etree@ietf.org" <draft-i= etf-bess-evpn-etree@ietf.org>
Cc: "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@= ietf.org>, Thomas Morin <thomas.morin@o= range.com>
Subject: Re: AD Review of draft-iet= f-bess-evpn-etree-09

On 5/9/17, 8:51 PM, "Ali Sajassi (sajassi)" <sajassi@cisco.com> wrote:

 

Ali:

 

Hi!

 

We=92re on the right path, but not there yet.  = Please see my comments inline below.

 

Thanks!

 

Alvaro.

 

 <= /span>

=85

> &g= t; M1. Both the Introduction and the Abstract mention that =93this document= discusses

> &g= t; how the functional requirements for E-Tree service can be easily met=85= =94  It seems to

> &g= t; me that RFC7387 is used as the building block for this document.  W= hy is it not a

> &g= t; Normative reference?

>&nb= sp;

> Because RFC7387 is informat= ional RFC (and the framework RFC) and the idnits

> complains of a downref:&nbs= p;Normative reference to an informational RFC

&nbs= p;

The status of an RFC is not an indicator of how it s= hould be referenced =96 complaints from idnits is not an excuse.  IOW,= there is nothing that prevents an Informational document to be referenced = as Normative =96 we just need to take care of the process: not a big deal, but important.

 

Let me rephrase.  Is rfc7387 a document that = =93that must be read to understand or implement=94 [1] what is specified in= this document?  Because of how rfc7387 is positioned in the Abstract/= Introduction, it seems to me that the framework must be read to then understand how this document addresses it:

&nbs= p;

=93  &n=
bsp;            =
;            &n=
bsp;            =
;     A solution
   fram=
ework for supporting this service in MPLS networks is proposed in
   RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service =
over a
   Mult=
iprotocol Label Switching (MPLS) Network"). This document
   disc=
usses how those functional requirements can be easily met with
   Ethe=
rnet VPN (EVPN) and how EVPN offers a more efficient

   impl=
ementation of these functions.=94


&n=
bsp;

[1] https://www.ietf.org/iesg/statement/normative-informative.html  

 

It is a bit subjective i= n this case but to be safe and assuming the readers don=92t have any backgr= ound in E-TREE (which has been around for a long time =96 e.g., private VLAN), I have moved it to the n= ormative section.

> &g= t; M2. There is no reference to E-Tree.  Please add a Normative one.

>&nb= sp;

> Added a reference for E-TRE= E definition in MEF.

&nbs= p;

This reference needs to be Normative =96 see above.<= o:p>

 <= /span>
Done.

&n= bsp;

=85 

> &g= t; M6. Definition of the E-TREE Extended Community

> &g= t; 

> &g= t; M6.1. Only one Flag is defined.  What about the others?  Pleas= e set up a registry.

> 

> If needed in the future, we= will setup a registry. 

&nbs= p;

Please set it up now.

&n= bsp;
OK, I will set it up.

=85&nbs= p;

> &g= t; M7.1. It is not clear to me how the C bit is to be used.  Section 5= .2 says that =93the high-

> &g= t; order bit of the tunnel type field (C bit - Composite tunnel bit) is set= while the

> &g= t; remaining low-order seven bits indicate the tunnel type as before.=94&nb= sp;  But 3.3.1 says

> &g= t; that the =93new composite tunnel type is advertised by the root PE to si= multaneously

> &g= t; indicate a P2MP tunnel in transmit direction and an ingress-replication = tunnel in the

> &g= t; receive direction=85=94.  Knowing, from 5.2 that when the C bit is = set =93Tunnel

> &g= t; Types=850x06 'Ingress Replication' is invalid=94, then does the C bit ha= ve a set meaning

> &g= t; or ???   [BTW, s/is/are]

>&nb= sp;

> The description in section = 3.3.1 is consistent with this section 5.2. Basically, Composite

> Tunnel type, as its name im= plies consist of two tunnels: a P2MP tunnel in the transmit

> direction and a MP2P tunnel= in the receive direction. The MP2P tunnel in the receive

> direction is used by Leaf&n= bsp;PE devices for their BUM traffic transmission. The "ingress

> replication tunnel type=94&= nbsp;is not valid because for that we don=92t need composite tunnel

> type!!

> I added the following sente= nce to the 1st paragraph to clarify it  more:

> "Composite tunnel type= is advertised by the root PE to simultaneously indicate a P2MP

> tunnel in transmit directio= n and an ingress-replication tunnel in the receive direction

> for the BUM traffic."<= o:p>

&nbs= p;

Let me see if I understand what you=92re saying:

 

If the C-bit is set, then the receive direction alwa= ys has an IR tunnel.  The type of the P2MP tunnel is defined by one of= the other bits.  Is that right?

 
That=92s correct. The remaining 7 bits indicat= e the type of tunnel. 

If so, are all the other bits valid (always)?  = The text already says that 0x00/0x06 are invalid, but, for example, what ab= out 0x07 (mLDP MP2MP LSP) or 0x0A (Assisted-Replication Tunnel [draft-ietf-= bess-evpn-optimized-ir])?   

 

How can you be sure that any other type besides 0x00= /0x06 will be ok?

&nbs= p;

&n= bsp;Basically composite tunnel type doesn=92t make sense when ingress replication (0x06) is used or when tunnel info is not present= (0x00). Other than that, it can be used with other tunnel types. 

&n= bsp;

=85

> &g= t; M8.4. What is 0x7F reserved for?  It doesn=92t seem to be used in t= his document.  Why

> &g= t; a different registration procedure?

>&nb= sp;

> 0x7F just replaces 0x0F - i.e.  No= new registration procedure

 

0x0F is currently Unassigned, not Reserved.

 =

I meant to say 0xFF. Basically the existing ex= perimental types 0xFB =96 0xFE and reserved type of 0xFF has move= d to new code points of: 0x7B =96 0x7E and 0x7F.

 <= /span>

=85&nbs= p;

> &g= t; P17. The 'Updates: ' line in the draft header should list only the _numb= ers_ of the

> &g= t; RFCs which will be updated by this document (if approved); it should not= include the

> &g= t; word 'RFC' in the list.

>&nb= sp;

> Done. Also added 6514 to th= e list.

&nbs= p;

Hmm...  I don=92t see how this document Updates= rfc6514=85.??

On the 2nd thought, it doesn=92t updated it be= cause the whole purpose of C-bit is backward compatibility. So no upda= tes to rfc6514. I removed it from the text.

 

But if it does, you need to include some text about = it in both the Abstract and the Introduction.  BTW, please add somethi= ng about the Update to rfc7385 in the Introduction.

&n= bsp;
Added a sentence to the introduction in l= ast paragraph.

&n= bsp;

> &g= t; P18. There is no reference to rfc5226. 

>&nb= sp;

> Done.

 <= o:p>

This one must be Normati= ve.

Done.

 --_000_D53B8CBC1F062Esajassiciscocom_-- From nobody Mon May 15 17:11:09 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3887712EB09; Mon, 15 May 2017 17:11: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: bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149489346118.11855.14992138287467704867@ietfa.amsl.com> Date: Mon, 15 May 2017 17:11:01 -0700 Archived-At: Subject: [bess] I-D Action: draft-ietf-bess-evpn-vpws-14.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 00:11:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : Virtual Private Wire Service support in Ethernet VPN Authors : Sami Boutros Ali Sajassi Samer Salam John Drake Jorge Rabadan Filename : draft-ietf-bess-evpn-vpws-14.txt Pages : 15 Date : 2017-05-15 Abstract: This document describes how Ethernet VPN (EVPN) can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all-active multi-homing with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws-14 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-vpws-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-vpws-14 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 16 12:12:14 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAF412EC33 for ; Tue, 16 May 2017 12:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, 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 CnrUNvvbzAaR for ; Tue, 16 May 2017 12:12:11 -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 250FC129420 for ; Tue, 16 May 2017 12:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7404; q=dns/txt; s=iport; t=1494961621; x=1496171221; h=from:to:cc:subject:date:message-id:mime-version; bh=4tzVumQnDIlN9bAvrjF9Y05lPTneDb8Orj3ct1XY+Jo=; b=UqiMGHy8/B/jTX9fb0sMg1V9Z+2kLGfbwSsujP3JcbOC4O16WcJwgvzk f/4x6YQHnA/7iwt3fn7yYo+XSJ7O+A3MwYSGRTS7PQi1BNUNFSjX0s6nt YHPsgQtcmCiUXyL/HvCDl4x2w50DpxLrogjb0L2oiW3xFfvgZPUB7XRMO M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAQAlTRtZ/4gNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4NlihiRZZA9hTiCD4YkHIU1PxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQMDI1YSAQgRAwECKwIEMB0KBAENBYojrD+CJiuKVQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GX4FeK4JwgSSDX4JyL4IxBZ4KAZMaggSPZ4h/i0MBHziBCnAVWAG?= =?us-ascii?q?GY3aHNgGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,350,1491264000"; d="scan'208,217";a="422369060" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 May 2017 19:07:00 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v4GJ6wPU013812 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 16 May 2017 19:07:00 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 16 May 2017 15:06:58 -0400 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1210.000; Tue, 16 May 2017 15:06:58 -0400 From: "Patrice Brissette (pbrisset)" To: "Parag Jain (paragj)" , "martin.vigoureux@nokia.com" , "thomas.morin@orange.com" CC: "Samer Salam (ssalam)" , Sami Boutros , "bess@ietf.org" Thread-Topic: [bess] WG Adoption request for draft-jain-bess-evpn-lsp-ping-04 Thread-Index: AQHSzneXwNislw6grkSCkt33wx1+Xw== Date: Tue, 16 May 2017 19:06:58 +0000 Message-ID: <604174DB-8D5E-4A23-87F7-5CB8E0C65605@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.224] Content-Type: multipart/alternative; boundary="_000_604174DB8D5E4A2387F75CB8E0C65605ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bess] WG Adoption request for draft-jain-bess-evpn-lsp-ping-04 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 19:12:13 -0000 --_000_604174DB8D5E4A2387F75CB8E0C65605ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFydGluLCBUaG9tYXMsDQoNCldoYXQgaXMgeW91ciBwbGFuPyAgVXBkYXRlPw0KUmVnYXJkcywN ClBhdHJpY2UgQnJpc3NldHRlDQoNCkZyb206IEJFU1MgPGJlc3MtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIFBhcmFnIEphaW4gPHBhcmFnakBjaXNjby5jb20+DQpEYXRlOiBUaHVyc2Rh eSwgTWF5IDExLCAyMDE3IGF0IDEwOjM5IEFNDQpUbzogIm1hcnRpbi52aWdvdXJldXhAbm9raWEu Y29tIiA8bWFydGluLnZpZ291cmV1eEBub2tpYS5jb20+LCAidGhvbWFzLm1vcmluQG9yYW5nZS5j b20iIDx0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbT4NCkNjOiAiU2FtZXIgU2FsYW0gKHNzYWxhbSki IDxzc2FsYW1AY2lzY28uY29tPiwgU2FtaSBCb3V0cm9zIDxzYm91dHJvc0B2bXdhcmUuY29tPiwg ImJlc3NAaWV0Zi5vcmciIDxiZXNzQGlldGYub3JnPg0KU3ViamVjdDogW2Jlc3NdIFdHIEFkb3B0 aW9uIHJlcXVlc3QgZm9yIGRyYWZ0LWphaW4tYmVzcy1ldnBuLWxzcC1waW5nLTA0DQoNCkhpIE1h cnRpbiBhbmQgVGhvbWFzLA0KDQpXZSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgV0cgYWRvcHRpb24g Zm9yIGRyYWZ0LWphaW4tYmVzcy1ldnBuLWxzcC1waW5nLTA0IGRyYWZ0LiBUaGUgZHJhZnQgd2Fz IHByZXNlbnRlZCBpbiBJRVRGLTkzIChQcmFndWUpLiBXZSBoYWQgcmVjZWl2ZWQgY29tbWVudHMg b24gdGhlIGRyYWZ0IGFuZCB0aGV5IHdlcmUgaW5jb3Jwb3JhdGVkIGluIHRoZSBjdXJyZW50IHZl cnNpb24gb2YgdGhlIGRyYWZ0LiBGWUksICB0aGUgZHJhZnQgaXMgcGxhbm5lZCB0byBiZSAgaW1w bGVtZW50ZWQuDQoNClRoYW5rcywNClBhcmFnDQo= --_000_604174DB8D5E4A2387F75CB8E0C65605ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpD YWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lu cw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0i RU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+TWFydGluLCBUaG9tYXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5XaGF0IGlzIHlvdXIgcGxhbj8gJm5ic3A7VXBkYXRlPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6YmxhY2siPlBhdHJpY2UgQnJpc3NldHRlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOg0K PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkJFU1MgJmx0O2Jlc3MtYm91bmNl c0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFBhcmFnIEphaW4gJmx0O3BhcmFnakBjaXNjby5j b20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBNYXkgMTEsIDIwMTcgYXQgMTA6Mzkg QU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O21hcnRpbi52aWdvdXJldXhAbm9raWEuY29tJnF1b3Q7 ICZsdDttYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbSZndDssICZxdW90O3Rob21hcy5tb3JpbkBv cmFuZ2UuY29tJnF1b3Q7ICZsdDt0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSZndDs8YnI+DQo8Yj5D YzogPC9iPiZxdW90O1NhbWVyIFNhbGFtIChzc2FsYW0pJnF1b3Q7ICZsdDtzc2FsYW1AY2lzY28u Y29tJmd0OywgU2FtaSBCb3V0cm9zICZsdDtzYm91dHJvc0B2bXdhcmUuY29tJmd0OywgJnF1b3Q7 YmVzc0BpZXRmLm9yZyZxdW90OyAmbHQ7YmVzc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+W2Jlc3NdIFdHIEFkb3B0aW9uIHJlcXVlc3QgZm9yIGRyYWZ0LWphaW4tYmVzcy1ldnBu LWxzcC1waW5nLTA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0O3RleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5IaSBNYXJ0aW4gYW5kIFRob21hcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtYXV0b3NwYWNlOm5v bmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3Rl eHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XZSB3b3Vs ZCBsaWtlIHRvIHJlcXVlc3QgV0cgYWRvcHRpb24gZm9yIGRyYWZ0LWphaW4tYmVzcy1ldnBuLWxz cC1waW5nLTA0IGRyYWZ0LiBUaGUgZHJhZnQgd2FzIHByZXNlbnRlZCBpbiBJRVRGLTkzIChQcmFn dWUpLiBXZSBoYWQgcmVjZWl2ZWQgY29tbWVudHMgb24gdGhlDQogZHJhZnQgYW5kIHRoZXkgd2Vy ZSBpbmNvcnBvcmF0ZWQgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIEZZSSwg Jm5ic3A7dGhlIGRyYWZ0IGlzIHBsYW5uZWQgdG8gYmUmbmJzcDsgaW1wbGVtZW50ZWQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBhcmFnPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_604174DB8D5E4A2387F75CB8E0C65605ciscocom_-- From nobody Fri May 26 04:50:22 2017 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1481286AB; Fri, 26 May 2017 04:50:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149579941253.8636.6848684365238697522@ietfa.amsl.com> Date: Fri, 26 May 2017 04:50:12 -0700 Archived-At: Subject: [bess] I-D Action: draft-ietf-bess-l2l3-vpn-mcast-mib-08.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 11:50:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : L2L3 VPN Multicast MIB Authors : Zhaohui (Jeffrey) Zhang Hiroshi Tsunoda Filename : draft-ietf-bess-l2l3-vpn-mcast-mib-08.txt Pages : 20 Date : 2017-05-26 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes two MIB modules which will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer 3 Virtual Private Networks that support multicast. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08 https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-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 26 05:26:00 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73661294DF for ; Fri, 26 May 2017 05:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=ieee-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szFl9h3B2LUW for ; Fri, 26 May 2017 05:25:56 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 C6E841294CD for ; Fri, 26 May 2017 05:25:55 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id f55so6641732qta.3 for ; Fri, 26 May 2017 05:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=h7gvtNVWf70Gl2Sm8kVjF3wB18FO/Bs/sIIFJRh3aRc=; b=zyh2NE512544TPeVthVCNBKs9Shika8C8VSK9YVWmUl9DvexTH6r9mHa4ydVsNDD8P Z9aqzNL1Wk2Agf3Grla1toElUcwz756G2K+J1pFZu8VmAdmwADGGUvmsiwHG34BX9SyN t5y4EOxl1oeKUMOJpB6o64YsvGZDga0cd81w/bv1EwRAR1lidabKLUMteDzh0cP2ktbF BRfb45VPQgckv2XcDUQZSzWMg/W3LhZGSt4jlT+1/DY3jFvCSEAaAQnHdCt/JyCsnpQs qZXT6uM9nBZA1B48uu1C4WJClYSh7Mq+0f3NcKuKkzjqgNxXuC8H1NmU3Z7QAweKE0s2 9jsw== 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=h7gvtNVWf70Gl2Sm8kVjF3wB18FO/Bs/sIIFJRh3aRc=; b=M/AB2ePfi22Aq4zdpSMXwd4xuLkD9oEFTXjb64Nia1zMpZMyFhETUIUIM038AM0tLf iWM+Eq10+EtlBt9XUjBcsvxW86D7I3ydyqxVsRnTwG3fVZpxJwjxxqdRCOiemXsytrzc 8eXLmjKlRj1Uf/JKmf99HJPTpNskGbRc9Dx0Yd60b9sAbos9C45cBSCPUgYlzrFNnMxD RPP+OJayTgfeGHdw/M4HahsfBcJNT3W4MJfwpOSLyqJUCd5LPKaK+NnwneyzjWVY0/Ui KgkUQB3YnmjXAIrueKbDiFkgKV8Fcyg2c8DAxLPM4ttzZXY5yR1tO7RFOSVkG2nA8IVp RneA== X-Gm-Message-State: AODbwcBF142ry0+fFhDyr3bt2K0QkX4OKqvou9Ax2eoPw+ZY5taTGHKx oXWguVUHc45JXn0nz+gy3xZN8XnVquFc X-Received: by 10.200.47.73 with SMTP id k9mr1928538qta.11.1495801554816; Fri, 26 May 2017 05:25:54 -0700 (PDT) MIME-Version: 1.0 Sender: dr.h.t@ieee.org Received: by 10.140.101.140 with HTTP; Fri, 26 May 2017 05:25:14 -0700 (PDT) In-Reply-To: References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> <1848f053-9a5e-2f52-09b4-ce0e1688b557@cysols.com> From: Hiroshi Tsunoda Date: Fri, 26 May 2017 14:25:14 +0200 X-Google-Sender-Auth: sVQX3A_JW-9m8hMTw2BFZUNrkhE Message-ID: To: Glenn Mansfield Keeni Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey (Zhaohui) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-07 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 12:25:59 -0000 Dear Glenn, Thank you for your thorough review and waiting for the updated. I posted a new revision taking into account your latest comments. In the new revision, all of your comments are addressed. I also revised the draft to improve the readability. Please see some notes below. URL: https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-08.txt Htmlized(1): https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08 Htmlized(2): https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-08 2017-05-02 14:44 GMT+02:00 Hiroshi Tsunoda : > 2017-05-01 12:32 GMT+02:00 Glenn Mansfield Keeni : >> Dear Tsuno/Zhang >> Thanks for waiting. The review of >> draft-ietf-bess-l2l3-vpn-mcast-mib-07 follows. >> >> Glenn >> >> C1. Abstract: >> The draft now defines 2 MIB modules. Please revise the abstract >> and probably the title of the document too. Fixed. >> C2. The MIBs (L2L3-VPN-MCAST-TC-MIB, L2L3-VPN-MCAST-MIB) compile OK. >> (Three {type-unref} warnings are there, may be ignored.) I have confirmed that the latest version of MIB modules can also be compiled successfully. >> C3. Page 4: >> s/3. Summary of MIB Module/ >> 3. Summary of MIB Modules/ Fixed. >> C4. Page 6: L2L3VpnMcastProviderTunnelPointer DESCRIPTION >> s/"Denotes a pointer to the row pertaining to a table entry/ >> /"This textual convention represents a pointer to a row in >> the table represented by the following object of type >> L2L3VpnMcastProviderTunnelPointerType./ Fixed. >> C5. Page 7: L2L3VpnMcastProviderTunnelPointer DESCRIPTION >> The explanation in the last paragraph seems out of place. >> It may be removed. Fixed. >> C6 Page 7: L2L3VpnMcastProviderTunnelPointerType DESCRIPTION >> it is unclear when the value 'null(0)' will be used. >> Is this allowed only when the corresponding object of type >> L2L3VpnMcastProviderTunnelPointer has a value that is a >> zero-length string ? If yes, please make that clear. 'null(0)' is the default value and indicates that the corresponding L2L3VpnMcastProviderTunnelPointer object is not assigned. In the new revision, this point is described clearly. >> C7. Page 9: l2L3VpnMcastPmsiTunnelAttributeTable DESCRIPTION >> s/created by a PE router/maintained by a PE router/ Fixed. >> C8. Page 12: l2L3VpnMcastPmsiTunnelAttributeId >> Do you really want to keep this object in L2L3-VPN-MCAST-MIB. >> It will change every time a new "tunnel type" is added to >> L2L3VpnMcastProviderTunnelType. That will defeat the purpose >> of separating L2L3-VPN-MCAST-TC-MIB from L2L3-VPN-MCAST-MIB >> It may be a good idea to define a textual convention like >> L2L3VpnMcastPmsiTunnelAttributeId >> in the L2L3-VPN-MCAST-TC-MIB and use that textual convention >> in the L2L3-VPN-MCAST-MIB Thank you for your suggestion. I revised the definition according to your suggestion. >> C9. Page 13: l2L3VpnMcastPmsiTunnelAttributeId DESCRIPTION >> A. s/Thus, the size of this object is 16 octets in IPv4/ >> Thus, the size of this object is 8 octets in IPv4/ Fixed. >> B. The last 2 paragraphs do not tie up well with the previous >> paragraphs in the DESCRIPTION. Those 2 paragraphs are removed in the new revision. >> C. In the last paragraph >> "this object is a pair of source and group IP addresses" >> is unlcear. Please clarify. Fixed. In the new revision, this point is described as follows. "the corresponding Tunnel Identifier is composed of the source IP address and the group IP address." >> C10. Page 15: Security Considerations >> I would think that any field that reveals information about >> a Multicast VPN and/or its members is sensitive. >> Does the l2L3VpnMcastPmsiTunnelAttributeId field reveal >> information about the participating members? If yes, it must >> be marked as sensitive. I revised this point according to your suggestion. >> C11. Editorial: >> >> A. This does not pertain to the MIBs as such, >> but I am uncomfortable with the several variations >> of the phrase >> "Layer 2 and Layer 3 Virtual Private Networks (VPN) >> that support multicast" >> that appears in the text. I do not have a solution >> on hand but it would be perhaps be more readable to >> define and use a simple name/notation the beast for >> which the MIB is being designed (e.g. "L2L3VPNMCast"). >> >> B. Same with the phrase >> "Layer 2 (L2) and Layer 3 (L3) VPN (Virtual Private >> Network) >> it would be probably be easier on the reader if an >> abbreviation like L2L3VPNs was used where ever >> applicable. Thank you for your comments. In the new reivsion the abbreviation "L2L3VPNMCast" is defined and used throughout the draft. >> C12. P2:Para4: s/within MIB module specifications//; Fixed. >> C13. General: >> A. The DESCRIPTION clauses could do would some more >> packing. (Too much space at the end of lines) >> B. Please check the articles a/an/the once again. Some >> usages do not seem right to me. Fixed. Sincerely yours, -- tsuno From nobody Sun May 28 15:35:04 2017 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D42126C23; Sun, 28 May 2017 15:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 NydItzdTKg5i; Sun, 28 May 2017 15:35:01 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE905126BFD; Sun, 28 May 2017 15:35:00 -0700 (PDT) Received: from [192.168.0.92] (cysvpn05.priv.cysol.co.jp [192.168.0.92]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.9/8.14.9) with ESMTP id v4SMYpSC081041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 May 2017 07:34:52 +0900 (JST) (envelope-from glenn@cysols.com) To: Hiroshi Tsunoda Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey (Zhaohui) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" References: <56E7D219.7000902@orange.com> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> <1848f053-9a5e-2f52-09b4-ce0e1688b557@cysols.com> From: Glenn Mansfield Keeni Message-ID: <3c7ef211-7c41-ecee-7465-3987a890ce55@cysols.com> Date: Mon, 29 May 2017 07:34:46 +0900 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=iso-2022-jp; format=flowed; delsp=yes Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-07 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 22:35:03 -0000 Dear Tsuno, Thanks for the good work. I will review and get back to you. Glenn On 2017/05/26 21:25, Hiroshi Tsunoda wrote: > Dear Glenn, > > Thank you for your thorough review and waiting for the updated. > > I posted a new revision taking into account your latest comments. > In the new revision, all of your comments are addressed. > I also revised the draft to improve the readability. > > Please see some notes below. > > URL: > https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-08.txt > Htmlized(1): > https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08 > Htmlized(2): > https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-08 > > 2017-05-02 14:44 GMT+02:00 Hiroshi Tsunoda : >> 2017-05-01 12:32 GMT+02:00 Glenn Mansfield Keeni : >>> Dear Tsuno/Zhang >>> Thanks for waiting. The review of >>> draft-ietf-bess-l2l3-vpn-mcast-mib-07 follows. >>> >>> Glenn >>> >>> C1. Abstract: >>> The draft now defines 2 MIB modules. Please revise the abstract >>> and probably the title of the document too. > > Fixed. > >>> C2. The MIBs (L2L3-VPN-MCAST-TC-MIB, L2L3-VPN-MCAST-MIB) compile OK. >>> (Three {type-unref} warnings are there, may be ignored.) > > I have confirmed that the latest version of MIB modules can also be > compiled successfully. > >>> C3. Page 4: >>> s/3. Summary of MIB Module/ >>> 3. Summary of MIB Modules/ > > Fixed. > >>> C4. Page 6: L2L3VpnMcastProviderTunnelPointer DESCRIPTION >>> s/"Denotes a pointer to the row pertaining to a table entry/ >>> /"This textual convention represents a pointer to a row in >>> the table represented by the following object of type >>> L2L3VpnMcastProviderTunnelPointerType./ > > Fixed. > >>> C5. Page 7: L2L3VpnMcastProviderTunnelPointer DESCRIPTION >>> The explanation in the last paragraph seems out of place. >>> It may be removed. > > Fixed. > >>> C6 Page 7: L2L3VpnMcastProviderTunnelPointerType DESCRIPTION >>> it is unclear when the value 'null(0)' will be used. >>> Is this allowed only when the corresponding object of type >>> L2L3VpnMcastProviderTunnelPointer has a value that is a >>> zero-length string ? If yes, please make that clear. > > 'null(0)' is the default value and indicates that the corresponding > L2L3VpnMcastProviderTunnelPointer object is not assigned. > In the new revision, this point is described clearly. > >>> C7. Page 9: l2L3VpnMcastPmsiTunnelAttributeTable DESCRIPTION >>> s/created by a PE router/maintained by a PE router/ > > Fixed. > >>> C8. Page 12: l2L3VpnMcastPmsiTunnelAttributeId >>> Do you really want to keep this object in L2L3-VPN-MCAST-MIB. >>> It will change every time a new "tunnel type" is added to >>> L2L3VpnMcastProviderTunnelType. That will defeat the purpose >>> of separating L2L3-VPN-MCAST-TC-MIB from L2L3-VPN-MCAST-MIB >>> It may be a good idea to define a textual convention like >>> L2L3VpnMcastPmsiTunnelAttributeId >>> in the L2L3-VPN-MCAST-TC-MIB and use that textual convention >>> in the L2L3-VPN-MCAST-MIB > > Thank you for your suggestion. I revised the definition according to > your suggestion. > >>> C9. Page 13: l2L3VpnMcastPmsiTunnelAttributeId DESCRIPTION >>> A. s/Thus, the size of this object is 16 octets in IPv4/ >>> Thus, the size of this object is 8 octets in IPv4/ > > Fixed. > >>> B. The last 2 paragraphs do not tie up well with the previous >>> paragraphs in the DESCRIPTION. > > Those 2 paragraphs are removed in the new revision. > >>> C. In the last paragraph >>> "this object is a pair of source and group IP addresses" >>> is unlcear. Please clarify. > > Fixed. In the new revision, this point is described as follows. > > "the corresponding Tunnel Identifier is composed of > the source IP address and the group IP address." > >>> C10. Page 15: Security Considerations >>> I would think that any field that reveals information about >>> a Multicast VPN and/or its members is sensitive. >>> Does the l2L3VpnMcastPmsiTunnelAttributeId field reveal >>> information about the participating members? If yes, it must >>> be marked as sensitive. > > I revised this point according to your suggestion. > >>> C11. Editorial: >>> >>> A. This does not pertain to the MIBs as such, >>> but I am uncomfortable with the several variations >>> of the phrase >>> "Layer 2 and Layer 3 Virtual Private Networks (VPN) >>> that support multicast" >>> that appears in the text. I do not have a solution >>> on hand but it would be perhaps be more readable to >>> define and use a simple name/notation the beast for >>> which the MIB is being designed (e.g. "L2L3VPNMCast"). >>> >>> B. Same with the phrase >>> "Layer 2 (L2) and Layer 3 (L3) VPN (Virtual Private >>> Network) >>> it would be probably be easier on the reader if an >>> abbreviation like L2L3VPNs was used where ever >>> applicable. > > Thank you for your comments. > In the new reivsion the abbreviation "L2L3VPNMCast" > is defined and used throughout the draft. > >>> C12. P2:Para4: s/within MIB module specifications//; > > Fixed. > >>> C13. General: >>> A. The DESCRIPTION clauses could do would some more >>> packing. (Too much space at the end of lines) >>> B. Please check the articles a/an/the once again. Some >>> usages do not seem right to me. > > Fixed. > > Sincerely yours, > > -- tsuno >