From nobody Tue Mar 1 01:56:46 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4435D1B37A3; Mon, 29 Feb 2016 09:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Q0cnV1xjdGI; Mon, 29 Feb 2016 09:01:40 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4EE1B377A; Mon, 29 Feb 2016 09:01:39 -0800 (PST) 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.33.75] (66.129.241.14) by CO2PR05MB795.namprd05.prod.outlook.com (10.141.226.20) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 29 Feb 2016 17:01:21 +0000 To: joel jaeggli , Benoit Claise , "Susan Hares" , 'The IESG' References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> <56741869.5020505@juniper.net> <00af01d139c6$898fb720$9caf2560$@ndzh.com> <567859EC.6030103@juniper.net> <006101d13ce1$725cd650$571682f0$@ndzh.com> <56799F9F.4010907@juniper.net> <000d01d13d94$80868a10$81939e30$@ndzh.com> <56966A3D.4000708@juniper.net> <56A88FE9.7000505@cisco.com> <56A90DEF.2000701@juniper.net> <56CF713C.8010105@juniper.net> From: Eric C Rosen Message-ID: <56D4795C.6010300@juniper.net> Date: Mon, 29 Feb 2016 12:01:16 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BY2PR08CA061.namprd08.prod.outlook.com (10.141.248.179) To CO2PR05MB795.namprd05.prod.outlook.com (10.141.226.20) X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB795; 2:D53zQ4F8ET6owObhhja+8yY3oKv6wiE8CsPegR3rYwVP2lAURBXDC4gXF69CC9shZZ/vR+lu2yl9sg0/VMFTytExz1A3QF7WCOcylZyMg1WKzM2Gu8FAfAMycAAwNQ46QadB78DcYklzHtfwnP2O9A==; 3:UaBUgzP3nbErs9jkK9pWZijYlUmNiMz11xvrStVgB9hRrXnbw5ZQNNHsEJlVSy8tA6hPZ350yQtyhkfBbgF+c/whetu9fMSzxzzxP++L1WXTamw48Nyci7QO3IpTGtJY; 25:6uLZrYQV4cTRqEBGcgceFZRb3kjyOABf3rk94zvTt6UFg8GUdKFMHmaUxZy4ZbfwtFcxA4chWVN3sJKoghhH8UNOGV2B8DjUtbXuvBQdlXcmOZGIuRgKgRCklOdSbW5Mpg8Rgv7xH6hf8/TYsvTKoG2Rpfl1g4Zycqihl1ke6y/+VYxAQrVHsejIh0+sJk30u2qWVsKipzf/mn3U0aJCh7h+bNrv+D1UU992UF1ImRl2FQzo6loKpMves2z6nN6rN8tYhJukqmUkRqRayXaDSsgfEvzgAHeTP3VQsYWNp/lTWUTGv0WkKAF3Jd999h8ODxutJdF7A2rxYJYdCkOEgQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB795; X-MS-Office365-Filtering-Correlation-Id: ae00ae1a-09ad-45d8-ca48-08d34129f41a X-LD-Processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB795; 20:mSpYkV/vXL2IagT9ooPVLy0V1f9M0Esh5jJsUhSWGC/vqFRilFhoDqZJpvdDCQzmQd9TI6TCn0sTtMN/jDsVCcUI171DxUhCiwkvlkR0HKz02i8E+eA/5yGK6GJBSHhq8rOXB0GDQL3CA4puk8434l3UilzJ/Xxh8VF3bQQAPB/mRiACXlSlsxHfz1sHZyqS8QGKQoZfjurPyXaHGFSb6KHk8XGTQAchI675QAgntEMTPVnqOdiSErfn6TimF8MGthhu9j1dRo4IDa/IH4Hxq9PjX3y/MJGK2/cNRwtcJdgTLS/ZTmbZnZZAA/2knOjJloDE5jJPpqLe6Yk7O8z9/JpuzwQziUFR10KqMKR/fAVP/S2aHtfXXFyWngnCx6GboAThytxH+bXx6IF4vND8Hu66JP5wboXfW0DKEw7jX+DmHRTl8oXIvXq9hJo0SLoLJevUYcw5gKtGnn6CrEdPUflnEaxmkcDcw4tOc4e8pEwMruUxaHcNKd9LA13IVx4r; 4:Y1kqSAh7Mtz12d0hMjQnfNgrYZDC5YA+0NQvE6uwLOLKfeP2uFKEmhvg5q67WUKkIAGwUCGKhy8ImlXjH4buZH9f4vMEDRCwkTgipMIFWPbcOzcIZ692PB7CZ6SdtHYCPX6ZiGmA+vNbcrzsANmbTR2G26iZ92CrfEurOLLbJ6ewqMapOfo5rQ1Ff9MtYAbjMdFgapzPKpI3GLY80YBVX03Cg8oTKgu599nqYhA7YLvtkhWcFiZs3iHKT/C6Q2OBqrJ3/PODSIoGfAS9wxQ4yLr8t3Qn7GRHFdgAR0TsxB9CrIbbY0ubIa+1e6a1qULLV/pszUNWEkHwmtE9ofIsvl/Y8Vj4ADVuIjdbNj0NFGa53+HsshQpg42kZ/TgPTiT X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CO2PR05MB795; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB795; X-Forefront-PRVS: 0867F4F1AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(377454003)(479174004)(24454002)(66066001)(586003)(6116002)(3846002)(65956001)(1096002)(230700001)(5001770100001)(5008740100001)(2906002)(64126003)(33656002)(77096005)(92566002)(42186005)(40100003)(5004730100002)(87976001)(93886004)(36756003)(122386002)(23676002)(230783001)(87266999)(5001960100002)(4001350100001)(2950100001)(80316001)(47776003)(76176999)(54356999)(50986999)(65816999)(86362001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB795; H:[172.29.33.75]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA1TUI3OTU7MjM6dVVEdEVieDltNXAxTjl4ZlZOb1liVHpscDM0?= =?utf-8?B?VXlDUSttdlZacGJaRk44NzM1bHlEL1hnVFNrT0RHVkNBSFVTajZjWjRpUG5o?= =?utf-8?B?ZG5VN05YRVJpNlRiRmRLaVlPL0ExVDR1aGw1akI1SmlLOURZcEwrb29Gdmxx?= =?utf-8?B?ZnJmOUFpMkttYzBFWndqT1lFNG4wN0hwK08wTEZkZFpDdVNVcWg5ZmdxTUZv?= =?utf-8?B?QkZDUG15TDAwM01vNC9TdWZLc0FYZ3prNGFrMFBUZXhIQXREZ0lzbkUyclNJ?= =?utf-8?B?Q0FwNW5DU3JvMlVmdXJqS1ZXMnhQMHFSQVplRWZDRks4ZFZ5R0wwdlpjWjFW?= =?utf-8?B?aUdxWHorNVBETmJMZE9CTjIvL083azMveFJ5UE92eFFBeFBXeGRtR3FJZjY5?= =?utf-8?B?SHltdnEwRDdRVTd5T3ZvV3lvR1ZGUzlQejc2NSt4dEVDZ2dFM2JXejFsVmNr?= =?utf-8?B?bWNoSW81dU10WE1rdjNlMkFteWpmWGtEUlRCUDdab0ZnSTdBd3Bpa1NYcEM0?= =?utf-8?B?bDdTb1VlMS9kUGtOQVBPVXZ0TFFIMnl1aXREUndaSXErcFo3YndlTk5lYkds?= =?utf-8?B?SXBtNldhS2h5WGdVellzMjdxYm1Xd1dDd0N2UlFZMEpwSjFkSE5FSXJvbzgr?= =?utf-8?B?eDlkb3ZYZEtIQktmZHdSVncvMDRQUTVuQ1NYUHpiVlVsQ2VxeVZrQ3VlSFpZ?= =?utf-8?B?Slk0T2RQK2xhTDZ0aTBKeXVMaWpnekRhd2VLQXY4M1U3bGRYbkNXM1BsUTJo?= =?utf-8?B?cFNBUHpZWi9ZeHZXVlYvZFd5cXNyTjNPZVZSSUtmYUlhWnNzQVM1RUZqU0Q4?= =?utf-8?B?YUk0TlRVSm5RakxyZjg0bktocWd0dVFKMnVTSnZJQ001OG5oK2VoeTMxcGZ5?= =?utf-8?B?b0tsSjdJK1ZrZWpSMFJpaXRHOTRybmNCaDF6b1FKd0grSkY0YTE1QzlPU0dY?= =?utf-8?B?azVXcUhHblh3WHFJZ1AvbnJXSkFWOFJqV1hDa1NRa1ZCL3BocmZRNWJqVmlP?= =?utf-8?B?RlFOOGJ1U3BqUmRJYlZ5S1ZyczRXSWdoaEFKTFNsTUhrcEljOGtieURWOUNi?= =?utf-8?B?U2xXakE0M2hCbTArTmpnaWZDdHpRMmtCMm1DQkhQSlNsZnRURXcrKzEyK0JM?= =?utf-8?B?V1FBRTNibHkreUxaemhwWmZmc0VjYmlOMUEvd0JWYWI2dXoyWVp0VEFoQXM0?= =?utf-8?B?Ly9RZHJEbUNBTk9RT0NnOXcwdThqbUFFbERiMXBDZ3lYOFlkQXJNQWcwUVFI?= =?utf-8?B?dDhwV0h0aklaQUlYdThtcTNxR3JoeE12U1ZRTkNHU1JJRzRJQk5kNlJvME1V?= =?utf-8?B?c00vSVlIazdrSGxvRW1vN0h1aEVmZWlsM0xLMzkwUCt0dVUwY3praUlZbzdl?= =?utf-8?B?WmpITkQyN20yUW1kWmovd0lXejhsSjgyZWliaE4yTEhKSGFReWtwaWh6aG8w?= =?utf-8?B?MVVkRWVGRXNkdnN2Qk8xRnU2S1V3WXppb1hkbkNlazdzMm9DcVJpalFtM2tx?= =?utf-8?B?b1lBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB795; 5:fBgnt5USx4CMmIKEELL188v6IvKBL6BTfaRXYlu5NZ8v5Qi2MEqR4SY74zHvLaRazfKWtWgS9AVnxeiDTrAK5DCp+pHcAGSb5ugJk9wxKijkRzkrACV4lp8flWH700aD/coAei8dEIxdTGmPYuJzZQ==; 24:UrjlZNF3NbcMAupyoFFe31yyffPrBXYfMohzdlJnYPMCsNVTBeOjzHSbH2lw9+PaMbilPwq9R9n7iM9E7MgCjRM0TDmJWC2MkTlYP8n7gIw= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Feb 2016 17:01:21.6732 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB795 Archived-At: X-Mailman-Approved-At: Tue, 01 Mar 2016 01:56:45 -0800 Cc: draft-ietf-bess-mvpn-extranet@ietf.org, aretana@cisco.com, "'John G. Scudder'" , bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 17:01:46 -0000 On 2/28/2016 11:36 AM, joel jaeggli wrote: >> Anyone who understands the normative references will know what a Route >> >Distinguisher is and what a VRF is. The fundamental part of >> >provisioning any RFC4364 VPN is to create the VRFs, and to provision >> >each VRF with Route Distinguishers. > Yeah, I'm not convinced of that, You're not convinced that the normative references explain the concepts of "VRF" and "RD"? > there is eleborate discussion of the > requirement for one RD per VRF and then extranet seperation adds a twist > that. True. Is there something about this that is not explained properly? If so, please say what. From nobody Tue Mar 1 14:43:39 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476941B42CF; Tue, 1 Mar 2016 14:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1L2mN31SvyUt; Tue, 1 Mar 2016 14:43:33 -0800 (PST) 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 40C3F1B42CC; Tue, 1 Mar 2016 14:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3525; q=dns/txt; s=iport; t=1456872213; x=1458081813; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dNfzNJ3a5THafCsFu5AMnHOhs3ics7fx2u9KOVZrGA0=; b=Kj8z6mF8Acp8cyDcJ9q4MFkkafkg+sfWzQ3+Iqh0Pig7pozIfTted98u sXMk5MdRrNfpwtPi21nY9GjFVwz8TAqfkz96DAZbuTcy+IDFNP6rPi4j2 tx3cJpCugCVD4g+0ENKAhj6vh3iUMUNVs5ATS2yJAkuRwh4wdQAAKog/f 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAgAcB9ZW/49dJa1cgzpSbQa4GoITA?= =?us-ascii?q?Q2BZiGFcgKBTjgUAQEBAQEBAWQnhEIBAQR5EAIBCEYyJQIEDgUUiAsOA74cAQE?= =?us-ascii?q?BAQEBAQECAQEBAQEBAQEBAQERBIYShDqEM4Q8BYdXix6EGQGFWIgJgWCERIhSj?= =?us-ascii?q?ksBHgEBQoIDGRSBNGqHQ34BAQE?= X-IronPort-AV: E=Sophos;i="5.22,524,1449532800"; d="scan'208";a="244587790" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Mar 2016 22:43:32 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u21MhWh8019442 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Mar 2016 22:43:32 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 1 Mar 2016 16:43:31 -0600 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.1104.009; Tue, 1 Mar 2016 16:43:31 -0600 From: "Alvaro Retana (aretana)" To: Joel Jaeggli Thread-Topic: Joel Jaeggli's Discuss on draft-ietf-bess-mvpn-extranet-06: (with DISCUSS and COMMENT) Thread-Index: AQHRckZDW7tTttEaaEqPExBoDg17f59FqFOA Date: Tue, 1 Mar 2016 22:43:31 +0000 Message-ID: References: <20160228163705.24380.24145.idtracker@ietfa.amsl.com> In-Reply-To: <20160228163705.24380.24145.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.212.27] Content-Type: text/plain; charset="Windows-1252" Content-ID: <49133C4241241342BF17C0A3C0B930EB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-bess-mvpn-extranet@ietf.org" , "bess@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , Eric C Rosen , The IESG Subject: Re: [bess] Joel Jaeggli's Discuss on draft-ietf-bess-mvpn-extranet-06: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 01 Mar 2016 22:43:35 -0000 On 2/28/16, 5:37 PM, "Joel Jaeggli" wrote: Joel: Hi! How are you? ... >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >After further discussion related to the ops dir review, I'm going to have >to echo Benoit and the Opsdir reviewers concern. I have to say that, as Eric, I am at a loss as to what specifically you want to see in the document. Please see my comments below related to the OpsDir review text. >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Sue Hares performed the opsdir review. benoit holds the discuss for the >points she raised. > >Status: Not ready, three major concerns and two editorial nits: > >Major concerns: > >1) Specification of the Extranet Source Extended Community and Extra >Source extended Community I think the authors took care of this already by making sure that 4.4 includes the text that Sue had proposed [1]. ... >2) Why is there no Deployment considerations section? This seems to be the sticking point. What exactly are you looking for? Please take a look at Sections 1.2. (Scope) and 1.3. (Clarification on Use of Route Distinguishers) -- these are maybe not the best named sections, but in them the authors lay out when this spec is useful: SSM and ASM deployments (not Dense mode), calls out potential problems with BSR, applicable to both PIM and BGP signaling, justified the use of a unique VRF per RD. Section 1.4. (Overview) gives some examples of potential deployments ("only some of its multicast C-sources be treated as extranet C-sources", or "some of its extranet C-sources can transmit only to a certain set of VPNs"), and it talks about the need for the SP to coordinate with the customer during the provisioning process. It seems to me that there's already a pretty good summary in those sections, but they are not called "operational considerations"=8A What is missing? Do you want the above to be in a specific titled section, or maybe there are other details you'd like to see -- if so, what are they? A couple of days ago you raised a specific point [2]: "... there is eleborate discussion of the requirement for one RD per VRF and then extranet seperation adds a twist that. However, when Extranet Separation is used, some of the local-RD routes exported from the VRF will contain the extranet RD. Details concerning the exported routes that contain the extranet RD can be found in Sections 4.1 and 7.3. " It sounds like you may want more clarity/details on parts of that. What? ... >3) Is security section really a security section? It seems more like >=B3do this policy=B2 or this will fail. It should get a stronger review f= rom >the security directorate I am in fact not able to find a SecDir review. However, the SEC AD did put a DISCUSS on this document [3] and later cleared it [4] based on added text. Are there specific security concerns? Thanks! Alvaro. [1] https://mailarchive.ietf.org/arch/msg/bess/h3H9joH90g2B1XplYi_H9QJaf6k [2] https://mailarchive.ietf.org/arch/msg/bess/Gg4e8CvN5TpvhqmvUOCB4vRvlug [3] https://mailarchive.ietf.org/arch/msg/bess/DBdwMh2Z3WE80NJxhA5qDsmlQwI [4] https://mailarchive.ietf.org/arch/msg/bess/sjxLrpyGCCarO86xd5n617Q3fIk From nobody Mon Mar 7 01:05:28 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6091B3854 for ; Mon, 7 Mar 2016 01:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOoJh21dWNcy for ; Mon, 7 Mar 2016 01:05:25 -0800 (PST) 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 1FEA31B3852 for ; Mon, 7 Mar 2016 01:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1844; q=dns/txt; s=iport; t=1457341525; x=1458551125; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ma4yjWBxmI6mqwZO445ZgScw3UPwSCp94ylfEE86ET8=; b=i3vpJ3I+DZKAQTODxiJHiaH9mGDIBPdjZRP5QVeFD2422Y5t1N+aW3tN pt86C+aCNHaAeugLToZxbde/zFxAzd/BeZ1hBLixXTbojRvunuy1MKUTM wXztBmEssdgbjs1nFPamIu7GdICOrFuKRInAc8ld7SshCNN9kW9BSws1Z o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgDoQt1W/4wNJK1dgzpSbQa6OgENg?= =?us-ascii?q?WkXCoVuAoEiOBQBAQEBAQEBZCeEQgEBBAEBATc0CxACAQg2ECcLJQIEAQ0FiCI?= =?us-ascii?q?OvycBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYXhD2EChEBhFgBBJcqAYVihVOCN?= =?us-ascii?q?4FjFoQuiFOOVAEeAQFCg2RqiAs0fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,550,1449532800"; d="scan'208";a="244896881" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2016 09:05:24 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u2795NiA004687 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Mar 2016 09:05:24 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 03:05:23 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 03:05:23 -0600 From: "Dhananjaya Rao (dhrao)" To: Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Thread-Index: AQHRbZJQpHLPkTaW3U6h1WCC55PmEZ9NpEQA Date: Mon, 7 Mar 2016 09:05:23 +0000 Message-ID: References: <56CB3E3E.6080602@alcatel-lucent.com> In-Reply-To: <56CB3E3E.6080602@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.115.108] Content-Type: text/plain; charset="us-ascii" Content-ID: <69C43D40485E88408EFA0BE0A16869CA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-fm-bess-service-chaining@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2016 09:05:27 -0000 Hello Martin, WG, It came to our notice recently that there was an old IPR filing on an earlier related draft that had not been submitted to the IETF. An IPR statement has now been submitted and is in progress. This was an inadvertent oversight, and we apologize for the late disclosure. Regards, -Dhananjaya On 2/22/16, 8:58 AM, "BESS on behalf of Martin Vigoureux" wrote: >Hello working group, > >This email starts a two-week poll on adopting >draft-fm-bess-service-chaining-02 [1] as a working group Document. > >Please state on the list if you support adoption or not (in both cases, >please also state the reasons). > >This poll runs until *the 7th of March*. > >Note that IPR has been disclosed against an earlier version of this >document: >https://datatracker.ietf.org/ipr/2284/ > >Yet, we are *coincidentally* also polling for knowledge of any other >IPR that applies to this draft, to ensure that IPR has been disclosed >in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >and 5378 for more details). > >=3D=3D> *If* you are listed as a document author or contributor please >respond to this email and indicate whether or not you are aware of any >relevant IPR. > >The draft will not be adopted until a response has been received from >each author and contributor. > >If you are not listed as an author or contributor, then please >explicitly respond only if you are aware of any IPR that has not yet >been disclosed in conformance with IETF rules. > >Thank you, > >Martin & Thomas >bess chairs > >[1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Mon Mar 7 04:19:07 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD6D1B4004 for ; Mon, 7 Mar 2016 04:19:04 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5sODAwP7F1D for ; Mon, 7 Mar 2016 04:19:00 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 41C841B3FFB for ; Mon, 7 Mar 2016 04:19:00 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 3C29A8B37402 for ; Mon, 7 Mar 2016 12:18:56 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u27CIvO9002636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 7 Mar 2016 12:18:58 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u27CIux0002491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Mar 2016 13:18:57 +0100 Received: from [135.224.217.109] (135.239.27.41) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 7 Mar 2016 13:18:55 +0100 Message-ID: <56DD71AE.9030104@alcatel-lucent.com> Date: Mon, 7 Mar 2016 13:18:54 +0100 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "bess@ietf.org" Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.41] Archived-At: Subject: [bess] Slots requests for BESS WG session - IETF 95 - Buenos Aires X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2016 12:19:05 -0000 All, it is time we start building the BESS WG agenda for Buenos Aires. The IETF agenda is available at: https://datatracker.ietf.org/meeting/95/agenda.html Please note that it is still a preliminary agenda. The BESS WG session (2h) is currently scheduled on Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time) Please send us your request for a presentation slot, indicating: draft name, speaker and desired duration (covering presentation + discussion) Please send the requests no later than the 20th of March Thank you M&T From nobody Mon Mar 7 04:36:50 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CA01B4030 for ; Mon, 7 Mar 2016 04:36:48 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfhWvEMZ7Npr for ; Mon, 7 Mar 2016 04:36:40 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 91EDF1B4022 for ; Mon, 7 Mar 2016 04:36:40 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 8E497157624EB; Mon, 7 Mar 2016 12:36:36 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u27Cacj0032565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Mar 2016 12:36:38 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u27Ca4pv018973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Mar 2016 13:36:32 +0100 Received: from [135.224.217.109] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 7 Mar 2016 13:35:43 +0100 Message-ID: <56DD759E.1090803@alcatel-lucent.com> Date: Mon, 7 Mar 2016 13:35:42 +0100 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "EXT Dhananjaya Rao (dhrao)" , "bess@ietf.org" References: <56CB3E3E.6080602@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2016 12:36:48 -0000 Hello Dhananjaya, thanks for the notice. WG, I'll let this poll run for at least a week after the disclosure is made. For those who have already stated their position please do not hesitate to communicate a revised position, if desired, in light of this upcoming IPR disclosure. For the rest, please do comment on the list, as I'd like to read more comments/opinions from non-authors. Martin Le 07/03/2016 10:05, EXT Dhananjaya Rao (dhrao) a écrit : > > Hello Martin, WG, > > It came to our notice recently that there was an old IPR filing on an > earlier related draft that had not been submitted to the IETF. An IPR > statement has now been submitted and is in progress. This was an > inadvertent oversight, and we apologize for the late disclosure. > > Regards, > -Dhananjaya > > > > On 2/22/16, 8:58 AM, "BESS on behalf of Martin Vigoureux" > wrote: > >> Hello working group, >> >> This email starts a two-week poll on adopting >> draft-fm-bess-service-chaining-02 [1] as a working group Document. >> >> Please state on the list if you support adoption or not (in both cases, >> please also state the reasons). >> >> This poll runs until *the 7th of March*. >> >> Note that IPR has been disclosed against an earlier version of this >> document: >> https://datatracker.ietf.org/ipr/2284/ >> >> Yet, we are *coincidentally* also polling for knowledge of any other >> IPR that applies to this draft, to ensure that IPR has been disclosed >> in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >> and 5378 for more details). >> >> ==> *If* you are listed as a document author or contributor please >> respond to this email and indicate whether or not you are aware of any >> relevant IPR. >> >> The draft will not be adopted until a response has been received from >> each author and contributor. >> >> If you are not listed as an author or contributor, then please >> explicitly respond only if you are aware of any IPR that has not yet >> been disclosed in conformance with IETF rules. >> >> Thank you, >> >> Martin & Thomas >> bess chairs >> >> [1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess > > > From nobody Mon Mar 7 06:54:37 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7E51B41F4 for ; Mon, 7 Mar 2016 06:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z84CJusAZKYs for ; Mon, 7 Mar 2016 06:54:34 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A4E1B4203 for ; Mon, 7 Mar 2016 06:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1680; q=dns/txt; s=iport; t=1457362473; x=1458572073; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cQFQHacnM81WOYYbXhJ2TEpnbU0FfB8OCcEVm/I/Ick=; b=FSikVJYn/6Qfq43zWmVoF5EX00gKz2H/6vD+xKqpWspT1Js+IptT+i+0 9dkk10GqsPdB77u5zyt5KSeOmPsN9drv2wAaIeqYSoCBfqM3hbSE0FPv+ WVq0TQFYsw9xmn+biUvRXuBtl+cb4XkWQFl4fgCVzctW1Vr1Xh20f50R8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQDUld1W/5NdJa1aA4M6Um0GujoBD?= =?us-ascii?q?YFpFwqFbgKBKTgUAQEBAQEBAWQnhEIBAQQBAQE3LAgLDgICAQg2EBsMCyUCBAE?= =?us-ascii?q?NBYgiDrFkjTEBAQEBAQEBAQEBAQEBAQEBAQEBAQEVBIYThD2EChEBKRYRFYNzB?= =?us-ascii?q?Y0wiXoBhWKICoFjS4N5hzmBGo5UAR4BAUKDZGoBiAMHFx0BfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,551,1449532800"; d="scan'208";a="245808576" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2016 14:54:20 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u27EsKCP006086 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Mar 2016 14:54:20 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 08:54:19 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 08:54:19 -0600 From: "Patrice Brissette (pbrisset)" To: Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] Slots requests for BESS WG session - IETF 95 - Buenos Aires Thread-Index: AQHReIE6wUznt+7TSkygv0D9nFB5aA== Date: Mon, 7 Mar 2016 14:54:19 +0000 Message-ID: References: <56DD71AE.9030104@alcatel-lucent.com> In-Reply-To: <56DD71AE.9030104@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.55] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D6A7529DDE7E24AA1C8254FCF72FDE5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Dhanendra Jain \(dhjain\)" , "Shah, Himanshu" Subject: Re: [bess] Slots requests for BESS WG session - IETF 95 - Buenos Aires X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2016 14:54:36 -0000 Hi Martin, I need a slot for L2VPN, L3VPN and EVPN Yang models Regards, Patrice Patrice Brissette TECHNICAL LEADER.ENGINEERING pbrisset@cisco.com Phone: +1 613 254 3336 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Canada Cisco.com Think before you print.This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here=20 for Company Registration Information. On 2016-03-07, 7:18 AM, "BESS on behalf of Martin Vigoureux" wrote: >All, > >it is time we start building the BESS WG agenda for Buenos Aires. >The IETF agenda is available at: >https://datatracker.ietf.org/meeting/95/agenda.html >Please note that it is still a preliminary agenda. > >The BESS WG session (2h) is currently scheduled on >Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time) > >Please send us your request for a presentation slot, indicating: >draft name, speaker and desired duration (covering presentation + >discussion) > >Please send the requests no later than the 20th of March >Thank you > >M&T > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Mon Mar 7 19:13:40 2016 Return-Path: X-Original-To: bess@ietfc.amsl.com Delivered-To: bess@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 34B651CD82D for ; Mon, 7 Mar 2016 19:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT3D6sRqTWdW for ; Mon, 7 Mar 2016 19:13:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 74B381CD7BB for ; Mon, 7 Mar 2016 19:13:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFL53135; Tue, 08 Mar 2016 03:13:35 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Mar 2016 03:13:35 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Tue, 8 Mar 2016 11:13:28 +0800 From: Haoweiguo To: "Patrice Brissette (pbrisset)" , Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] Slots requests for BESS WG session - IETF 95 - Buenos Aires Thread-Index: AQHReIFQtPs6ujFHb06VMPn6k6b33p9O29qq Date: Tue, 8 Mar 2016 03:13:27 +0000 Message-ID: References: <56DD71AE.9030104@alcatel-lucent.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.56DE4360.0024, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 74ddaebffa0086b7df93fb14c601f8ce Archived-At: Cc: "Shah, Himanshu" , "Dhanendra Jain \(dhjain\)" Subject: Re: [bess] Slots requests for BESS WG session - IETF 95 - Buenos Aires X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2016 03:13:39 -0000 Hi Martin,=0A= I want to apply two slots:=0A= Draft: draft-hao-bess-evpn-centralized-df-00 =0A= Time frame: 5-10min=0A= Presenter: Weiguo=0A= =0A= Draft: draft-hao-bess-mcast-auto-nvo3-01 =0A= Time frame: 5min=0A= Presenter: Weiguo=0A= =0A= Thanks,=0A= weiguo=0A= ________________________________________=0A= From: BESS [bess-bounces@ietf.org] on behalf of Patrice Brissette (pbrisset= ) [pbrisset@cisco.com]=0A= Sent: Monday, March 07, 2016 22:54=0A= To: Martin Vigoureux; bess@ietf.org=0A= Cc: Dhanendra Jain (dhjain); Shah, Himanshu=0A= Subject: Re: [bess] Slots requests for BESS WG session - IETF 95 - Buenos = Aires=0A= =0A= Hi Martin,=0A= =0A= I need a slot for L2VPN, L3VPN and EVPN Yang models=0A= =0A= =0A= Regards,=0A= =0A= Patrice=0A= =0A= Patrice Brissette=0A= TECHNICAL LEADER.ENGINEERING=0A= =0A= pbrisset@cisco.com=0A= Phone: +1 613 254 3336=0A= =0A= Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE=0A= Canada=0A= Cisco.com =0A= =0A= Think before you print.This=0A= email may contain confidential and privileged material for the sole use=0A= of the intended recipient. Any review, use, distribution or disclosure=0A= by others is strictly prohibited. If you are not the intended recipient=0A= (or authorized to receive for the recipient), please contact the sender=0A= by reply email and delete all copies of this message.=0A= Please click here=0A= for=0A= Company Registration Information.=0A= =0A= =0A= =0A= =0A= =0A= =0A= On 2016-03-07, 7:18 AM, "BESS on behalf of Martin Vigoureux"=0A= wrote:=0A= =0A= >All,=0A= >=0A= >it is time we start building the BESS WG agenda for Buenos Aires.=0A= >The IETF agenda is available at:=0A= >https://datatracker.ietf.org/meeting/95/agenda.html=0A= >Please note that it is still a preliminary agenda.=0A= >=0A= >The BESS WG session (2h) is currently scheduled on=0A= >Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time)=0A= >=0A= >Please send us your request for a presentation slot, indicating:=0A= >draft name, speaker and desired duration (covering presentation +=0A= >discussion)=0A= >=0A= >Please send the requests no later than the 20th of March=0A= >Thank you=0A= >=0A= >M&T=0A= >=0A= >_______________________________________________=0A= >BESS mailing list=0A= >BESS@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/bess=0A= =0A= _______________________________________________=0A= BESS mailing list=0A= BESS@ietf.org=0A= https://www.ietf.org/mailman/listinfo/bess=0A= From nobody Tue Mar 8 16:58:02 2016 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 9AB3812DCE4 for ; Tue, 8 Mar 2016 16:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9c8f9vlG84w for ; Tue, 8 Mar 2016 16:57:59 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7021C12DCE0 for ; Tue, 8 Mar 2016 16:57:59 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id l68so172267797wml.0 for ; Tue, 08 Mar 2016 16:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kAuPBYRL6ffFEuMky1oryVzRLhunEYHV2DuF82uGnN0=; b=CbKflX2q/WPPepUbRtjLhsd5uT0z1qsXZl5tIMJ+YrNXmcX8mqOc6xuisfPKZEdAbv Ox5NBSD96pbyVwDmh4OJcCxMZo5sfB1iQ7uq0SFVQw/xIrdCXKqSOrf28TLTceYogiLw Zy1NUuGOpju+KK4rgnYqH7DoFie0JrhqZBgnUrwElzDDsRUzCvQqKKsEMBPP3hM++vpZ yTfL8z2f8rjMISoqY14qbXy7x3vL784U8GzCdRru3DIb+2+21WWJCiPeegwBbPU0zayu 8s8Rz7xhFJBQO/oawZBJ2rU8azsbfFAxSkssK0y7mPDBJW6gZ8/9kJjasXH+ZAECXVIx /S4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kAuPBYRL6ffFEuMky1oryVzRLhunEYHV2DuF82uGnN0=; b=m5mFyhK5GzqoDRYFQ7HR6fQ4HW8NuOayqpE47DISXKHQNplWIYmDsZSQJ5txUzQspG Lddfk+sO18rd0/YVCGPgWu4VxJUi1rsa4Slm83yaN5z0ut/C5Uml5pYvjCGimPAqIH+i 09InznzcMviuQcbC9gU6VaPXIAmBkFLsPufjPFcsksxjkSXNNisQ/IRxkEKVKNJTcQPF WGr2aBLAPFMNqnyGLlVrI8R1TOri2l1SjmTmO97lyK4x/k/OxCgaNlWBeG+9xonsAjov 1NdVTvbdu1RzE+Nv9vuXo9pQySe6VgI4zgsOLFxRMO8cXkkt71TR7QVc0/NWXDAJYpc6 fjOg== X-Gm-Message-State: AD7BkJLYS/iF9ifyshHwWWbbaa5TCl6c/BjIunoQ2GTxl0/Pwo7iWF8uVsa75zyzk+nIT3mNBB7rSROACtycUA== X-Received: by 10.28.153.76 with SMTP id b73mr23422121wme.75.1457485077951; Tue, 08 Mar 2016 16:57:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.26.37 with HTTP; Tue, 8 Mar 2016 16:57:38 -0800 (PST) In-Reply-To: References: From: Sami Boutros Date: Tue, 8 Mar 2016 16:57:38 -0800 Message-ID: To: Thomas Morin , Martin Vigoureux Content-Type: multipart/alternative; boundary=001a114b312c5640a5052d933028 Archived-At: Cc: BESS Subject: Re: [bess] WG adoption for draft-boutros-bess-vxlan-evpn-00.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 00:58:00 -0000 --001a114b312c5640a5052d933028 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 7, 2016 at 10:30 AM, Sami Boutros wrote: > Hi Thomas and Martin, > > The draft has been around for 3 years, and the authors think it is ready > for adoption, can we please ask for a WG poll for it? > > Thanks, > > Sami > --001a114b312c5640a5052d933028 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 7, 2016 at 10:30 AM, Sami Boutros <boutros.sami@gmail= .com> wrote:
Hi Thomas and Martin,

The draft has been aro= und for 3 years, and the authors think it is ready for adoption, can we ple= ase ask for a WG poll for it?

Thanks,

Sami

--001a114b312c5640a5052d933028-- From nobody Tue Mar 8 16:58:32 2016 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 B967612DCED for ; Tue, 8 Mar 2016 16:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGlpt8HMc-gN for ; Tue, 8 Mar 2016 16:58:30 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C882212DCEC for ; Tue, 8 Mar 2016 16:58:29 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id p65so172041087wmp.1 for ; Tue, 08 Mar 2016 16:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=60hmBL58dQ61mXDAYpiKLCpEt1jwvhOb2SM4pzx9hg8=; b=UOeu9/zzrh0bCtl7PSY6nfmgoGRMGzoknwrykPpmT2ngjaQESZAZ20sVPMBeanl5VE CEuIQ2Xrfq3sE/D3zT23R9B3/4Wbwvqv95S7dQsA60qBuJt1kaCzBGC4rvAlhAlF6qAe 4gXWvh7meEOITvKEMC7TklGDFjiTO7lXBqeBwAQ+DmF3+clotIGTctacCdJm+DyaosM2 vONWfQpanMimpkF+5BMtALyd0L9y9gxfDCMv3lSWijUplpZt45cvmUiRpJRVCpMgk62o /aipHh4EU5weZpUDrD/X6B2mE+vWK8nFblHhT5uHHVj6k1z6zXJ/7qvEk3ksDzn68Pyz HNDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=60hmBL58dQ61mXDAYpiKLCpEt1jwvhOb2SM4pzx9hg8=; b=dqzo/nervric2om7Z5sUrOAnH3/jLyKP1R2jKuRCLGrS5KesrQeroxYG8hT6Zk718u 1l9W5CTejT8GULtCZVof2ywg5mTDSF1WXYZnWI0zIEjQ2HchgXCLIKw0VwKPNd6qdskr lOCvG+UaKzE+osPmn9jHcB3tBOIkfYngBVa0bJ3wHvUTgjRbwe5ZmfUUvbsQ0ga9quhM r2ad6SKezyb/Y5gdJBajGXkou4zrBzDJ2ocerIvgTXQQCe/4xk25Yl7jQW8kROJK+Tnc OxynCS8S3JJDLsga+0jCvSxqGdAGQZLph9noBFAwWQEiM8EsqwwaFb1WZuE6zGkqiFTg g6fw== X-Gm-Message-State: AD7BkJIkfaNNC3j7WbX7nag6ucGaVaSZmW5kFp8tSmLjt1crm/YxQVs1VKuDsGZzTbh5J/0+d9sQEpDqZ5OAQQ== X-Received: by 10.28.46.5 with SMTP id u5mr18220742wmu.75.1457485108423; Tue, 08 Mar 2016 16:58:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.26.37 with HTTP; Tue, 8 Mar 2016 16:58:08 -0800 (PST) In-Reply-To: References: <56DD71AE.9030104@alcatel-lucent.com> From: Sami Boutros Date: Tue, 8 Mar 2016 16:58:08 -0800 Message-ID: To: Martin Vigoureux , Thomas Morin Content-Type: multipart/alternative; boundary=001a1142419a27306b052d9332fa Archived-At: Cc: "Patrice Brissette \(pbrisset\)" , "Ali Sajassi \(sajassi\)" , Rex Fernando , BESS Subject: Re: [bess] Slots requests for BESS WG session - IETF 95 - Buenos Aires X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 00:58:31 -0000 --001a1142419a27306b052d9332fa Content-Type: text/plain; charset=UTF-8 On Mon, Mar 7, 2016 at 10:27 AM, Sami Boutros wrote: > We would like to request slots for > > 1- draft-boutros-bess-evpn-auto-provisoning-01 , Speaker : Rex or Sami, 10 > mins. > 2- draft-boutros-bess-evpn-vpws-service-edge-gateway-02 Speaker: Sami or > Patrice 10 mins. > > Thanks, > > Sami > > > On Mon, Mar 7, 2016 at 4:18 AM, Martin Vigoureux < > martin.vigoureux@nokia.com> wrote: > >> All, >> >> it is time we start building the BESS WG agenda for Buenos Aires. >> The IETF agenda is available at: >> https://datatracker.ietf.org/meeting/95/agenda.html >> Please note that it is still a preliminary agenda. >> >> The BESS WG session (2h) is currently scheduled on >> Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time) >> >> Please send us your request for a presentation slot, indicating: >> draft name, speaker and desired duration (covering presentation + >> discussion) >> >> Please send the requests no later than the 20th of March >> Thank you >> >> M&T >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > > --001a1142419a27306b052d9332fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 7, 2016 at 10:27 AM, Sami Boutros &= lt;boutros.sami= @gmail.com> wrote:
We would like to request slots for

1- draft-bout= ros-bess-evpn-auto-provisoning-01 , Speaker : Rex or Sami, 10 mins.
2- d= raft-boutros-bess-evpn-vpws-service-edge-gateway-02 Speaker: Sami or Patric= e 10 mins.

Thanks,

Sami

On Mon= , Mar 7, 2016 at 4:18 AM, Martin Vigoureux <martin.vigoureux@noki= a.com> wrote:
All,

it is time we start building the BESS WG agenda for Buenos Aires.
The IETF agenda is available at:
https://datatracker.ietf.org/meeting/95/agenda.ht= ml
Please note that it is still a preliminary agenda.

The BESS WG session (2h) is currently scheduled on
Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time)

Please send us your request for a presentation slot, indicating:
draft name, speaker and desired duration (covering presentation + discussio= n)

Please send the requests no later than the 20th of March
Thank you

M&T

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


--001a1142419a27306b052d9332fa-- From nobody Tue Mar 8 16:59:20 2016 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 7E09A12DCE4 for ; Tue, 8 Mar 2016 16:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fe29XF6snsr for ; Tue, 8 Mar 2016 16:59:18 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB48512DCEC for ; Tue, 8 Mar 2016 16:59:17 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id p65so50324795wmp.0 for ; Tue, 08 Mar 2016 16:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XzIM5Hm2Mnhua/4Ka8NxZvUpyLkhsHmRT1LsKIaWepY=; b=VI1jG4ZVIdYGPqt5pAbYIb7DwZzFHFGM9+2jp2rr0MHvF1/7vtoYhe0KgFlYzr30A2 GeiEhjSW+jFPVBAyGdCwSNmIARKgNewjN/SZTVojQSx7PuLUTz0IsNUFtrsheNqDUKk3 cbhiMBwcrsmOZgvJdynk6h2LBmSh1Iig6RKntSnCUc2N0L9onvQnvpvLIRTtUsrle+Me fu3Wl58+7ckigUq22rgJyS+aL5K53VcP8BFHquSIQ1lzHnAy8kobZMEQ8zCEZPFY66rb 989ZYHEOGgFpzmVfDZNjFZjRq2lYDiKKDZmluC50QKlAD4GBgNnOCV19YtvdNBZXFWYZ zbbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XzIM5Hm2Mnhua/4Ka8NxZvUpyLkhsHmRT1LsKIaWepY=; b=AwHehJ5eZlBgYqgH2qoMoVpbuBWIWsdhhkNd7RXcKK1Z8hkc85StIQt6swIuWfb4Ok TboudjxvVjtKjf4hSACO0gde3N0hlAkZuY+c5yB04Vn9tuh/lGBEs0r1J85SY8ZEKcHC E38vzgHq0/oypYg14BIuKURmy5OuNDGKczORoM9+RlF5L96z1I2kJNKv7GO89k3jxttN azxJTXtg3JV3OHLh6EuvBEoIuKdUNDObBycAM4TXs0IwROU6qYy6sulVsBDwFDcp3UOV U2swk0+EqFXr6phFHwqXfCxA3rvo3i/jRSCXFfIIVRzoL6K1QlRlAqiRdjX5Ex9QzdIy vvhQ== X-Gm-Message-State: AD7BkJLe9TmuCjVzMmysH0+Pffl9QMJgo1grbVL5aU636wF0TWMn/NIjN56r5Uz4Fq3Yud70Hh8OHX+oOm4WIw== X-Received: by 10.28.212.85 with SMTP id l82mr22811852wmg.82.1457485156540; Tue, 08 Mar 2016 16:59:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.26.37 with HTTP; Tue, 8 Mar 2016 16:58:57 -0800 (PST) In-Reply-To: References: From: Sami Boutros Date: Tue, 8 Mar 2016 16:58:57 -0800 Message-ID: To: Thomas Morin , Martin Vigoureux Content-Type: multipart/alternative; boundary=001a1146ed8c056941052d93359b Archived-At: Cc: BESS Subject: Re: [bess] Requesting WG last call for draft-ietf-bess-evpn-vpws-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 00:59:19 -0000 --001a1146ed8c056941052d93359b Content-Type: text/plain; charset=UTF-8 On Mon, Mar 7, 2016 at 10:19 AM, Sami Boutros wrote: > Hi Martin & Thomas, > > We believe the draft is ready for last call. > > Thanks, > > Sami > --001a1146ed8c056941052d93359b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 7, 2016 at 10:19 AM, Sami Boutros <boutros.sami@gmail= .com> wrote:
Hi Martin & Thomas,

We believe the draft= is ready for last call.

Thanks,

Sami

--001a1146ed8c056941052d93359b-- From nobody Tue Mar 8 19:35:16 2016 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 EF56912DCEB for ; Tue, 8 Mar 2016 19:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvMqzo4Nfii7 for ; Tue, 8 Mar 2016 19:35:14 -0800 (PST) Received: from BLU004-OMC1S5.hotmail.com (blu004-omc1s5.hotmail.com [65.55.116.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E593712DDF8 for ; Tue, 8 Mar 2016 19:29:54 -0800 (PST) Received: from BLU436-SMTP93 ([65.55.116.9]) by BLU004-OMC1S5.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 8 Mar 2016 19:29:53 -0800 X-TMN: [GvOiDB7iCbTGmYV+vZj8ZmZqrGscty3s] X-Originating-Email: [li_zhenqiang@hotmail.com] Message-ID: Date: Wed, 9 Mar 2016 11:37:09 +0800 From: "li_zhenqiang@hotmail.com" To: bess X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 26[cn] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_001_NextPart307314125310_=----" X-OriginalArrivalTime: 09 Mar 2016 03:29:51.0985 (UTC) FILETIME=[F0FFAE10:01D179B3] Archived-At: Subject: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 03:35:16 -0000 ------=_001_NextPart307314125310_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQpJIHVwZGF0ZSBteSBkcmFmdC4gNFBFIGlzIGludHJvZHVjZWQgaW4gdGhp cyBkb2MgdG8gbWVldCB0aGUgZ2FwIHBvaW50ZWQgb3V0IGluIFJGQzc0MzkuIDRQRSByb3V0ZXJz IGluIElQdjYtb25seSBNUExTIG5ldHdvcmsgY2FuIHVzZSBNUC1CR1AgZXh0ZW5kZWQgaW4gdGhp cyBkb2MgdG8gY29ubmVjdCBJUHY0LW9ubHkgaXNsYW5kcy4uIFlvdXIgY29tbWVudHMgYXJlIHZl cnkgYXBwcmVjaWF0ZWQuDQoNCg0KDQpsaV96aGVucWlhbmdAaG90bWFpbC5jb20NCiANCkZyb206 IGludGVybmV0LWRyYWZ0cw0KRGF0ZTogMjAxNi0wMy0wOSAwOTo1NA0KVG86IFpoZW5xaWFuZyBM aQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1iZXNzLTRw ZS0wMS50eHQNCiANCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1saS1iZXNzLTRwZS0wMS50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWmhlbnFpYW5nIExpIGFuZCBw b3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQogDQpOYW1lOiBkcmFmdC1saS1iZXNzLTRw ZQ0KUmV2aXNpb246IDAxDQpUaXRsZTogQ29ubmVjdGluZyBJUHY0IElzbGFuZHMgb3ZlciBJUHY2 IE1QTFMgVXNpbmcgSVB2NCBQcm92aWRlciBFZGdlIFJvdXRlcnMgKDRQRSkNCkRvY3VtZW50IGRh dGU6IDIwMTYtMDMtMDgNCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiA5DQpV Ukw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWxpLWJlc3MtNHBlLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLWJlc3MtNHBlLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1iZXNzLTRwZS0wMQ0KRGlmZjogICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saS1iZXNzLTRwZS0wMQ0K IA0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGV4cGxhaW5zIGhvdyB0byBpbnRlcmNvbm5l Y3QgSVB2NCBpc2xhbmRzIG92ZXIgYQ0KICAgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcg KE1QTFMpLWVuYWJsZWQgSVB2Ni1vbmx5IGNvcmUuICBUaGlzDQogICBhcHByb2FjaCByZWxpZXMg b24gSVB2NCBQcm92aWRlciBFZGdlIHJvdXRlcnMgKDRQRSksIHdoaWNoIGFyZSBEdWFsDQogICBT dGFja3MgaW4gb3JkZXIgdG8gY29ubmVjdCB0byBJUHY0IGlzbGFuZHMgYW5kIHRvIHRoZSBNUExT IGNvcmUuICBUaGUNCiAgIDRQRSByb3V0ZXJzIGV4Y2hhbmdlIHRoZSBJUHY0IHJlYWNoYWJpbGl0 eSBpbmZvcm1hdGlvbiB0cmFuc3BhcmVudGx5DQogICBvdmVyIHRoZSBjb3JlIHVzaW5nIHRoZSBN dWx0aXByb3RvY29sIEJvcmRlciBHYXRld2F5IFByb3RvY29sIChNUC0NCiAgIEJHUCkuICBNUC1C R1AgaXMgZXh0ZW5kZWQgdG8gZG8gdGhpcy4gIEEgbmV3IFN1YnNlcXVlbmNlIEFkZHJlc3MNCiAg IEZhbWlseSBJZGVudGlmaWVyIChTQUZJKSB3aXRoIGNvcnJlc3BvbmRpbmcgbmV3IGZvcm1hdCBO ZXR3b3JrIExheWVyDQogICBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb24gKE5MUkkpLCBpcyBpbnRy b2R1Y2VkLiAgVGhlIEJHUCBOZXh0IEhvcA0KICAgZmllbGQgaXMgdXNlZCB0byBjb252ZXkgdGhl IElQdjQgYWRkcmVzcyBvZiB0aGUgNFBFIHJvdXRlciwgYSBmaWVsZA0KICAgaXMgYWRkZWQgaW4g TmV0d29yayBMYXllciBSZWFjaGFiaWxpdHkgSW5mb3JtYXRpb24gKE5MUkkpIHRvIGNvbnZleQ0K ICAgdGhlIElQdjYgYWRkcmVzcyBvZiB0aGUgNFBFIHJvdXRlciwgc28gdGhhdCBkeW5hbWljYWxs eSBlc3RhYmxpc2hlZA0KICAgSVB2Ni1zaWduYWxlZCBNUExTIExhYmVsIFN3aXRjaGVkIFBhdGhz IChMU1BzKSBjYW4gYmUgdXNlZCB3aXRob3V0DQogICBleHBsaWNpdCB0dW5uZWwgY29uZmlndXJh dGlvbi4NCiANCiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiANCiANClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KIA0KIA0K ------=_001_NextPart307314125310_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Hello all,

I update my draf= t. 4PE is introduced in this doc to meet the gap pointed out in RFC7439. 4PE routers in IPv6-only MPLS network = can use MP-BGP extended in this doc to connect IPv4-only = islands.. Your comments are very appreciated.
=0A

=0A
li_zhenqiang@hotmail.com
= =0A
 
From: <= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts
<= b>Date: 2016-03-09 09:54
Subject= : New Version Notification for draft-li-bess-4pe-01.txt
 
=0A
A new version of I-D, draft-li-bess-= 4pe-01.txt
=0A
has been successfully submitted by Zhenqiang Li an= d posted to the
=0A
IETF repository.
=0A
 
=0A=
Name: draft-li-bess-4pe
=0A
Revision: 01
=0A
Title= : Connecting IPv4 Islands over IPv6 MPLS Using IPv4 Provider Edge Routers= (4PE)
=0A
Document date: 2016-03-08
=0A
Group: Individ= ual Submission
=0A
Pages: 9
=0A
URL:   &= nbsp;        https://www.ietf.org/inter= net-drafts/draft-li-bess-4pe-01.txt
=0A
Status:   =       https://datatracker.ietf.org/doc/draft-li-b= ess-4pe/
=0A
Htmlized:       https:= //tools.ietf.org/html/draft-li-bess-4pe-01
=0A
Diff:  &= nbsp;        https://www.ietf.org/rfcdi= ff?url2=3Ddraft-li-bess-4pe-01
=0A
 
=0A
Abstract:<= /div>=0A
   This document explains how to interconnect IPv4 = islands over a
=0A
   Multiprotocol Label Switching (MP= LS)-enabled IPv6-only core.  This
=0A
   approach = relies on IPv4 Provider Edge routers (4PE), which are Dual
=0A
&n= bsp;  Stacks in order to connect to IPv4 islands and to the MPLS core= .  The
=0A
   4PE routers exchange the IPv4 reacha= bility information transparently
=0A
   over the core u= sing the Multiprotocol Border Gateway Protocol (MP-
=0A
 &nb= sp; BGP).  MP-BGP is extended to do this.  A new Subsequence Add= ress
=0A
   Family Identifier (SAFI) with corresponding= new format Network Layer
=0A
   Reachability Informati= on (NLRI), is introduced.  The BGP Next Hop
=0A
  = field is used to convey the IPv4 address of the 4PE router, a field
= =0A
   is added in Network Layer Reachability Information (N= LRI) to convey
=0A
   the IPv6 address of the 4PE route= r, so that dynamically established
=0A
   IPv6-signaled= MPLS Label Switched Paths (LSPs) can be used without
=0A
 &= nbsp; explicit tunnel configuration.
=0A
 
=0A
&nbs= p;
=0A
         &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;         
=0A
&= nbsp;
=0A
 
=0A
Please note that it may take a coup= le of minutes from the time of submission
=0A
until the htmlized = version and diff are available at tools.ietf.org.
=0A
 =0A
The IETF Secretariat
=0A
 
=0A
 =0A
=0A ------=_001_NextPart307314125310_=------ From nobody Wed Mar 9 06:14:02 2016 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 49FF712D6EB; Wed, 9 Mar 2016 06:14:01 -0800 (PST) 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_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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu1lCuxXD-uH; Wed, 9 Mar 2016 06:13:58 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8977B12D6E4; Wed, 9 Mar 2016 06:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=62910; q=dns/txt; s=iport; t=1457532837; x=1458742437; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KXK5zj4r/UTe626B8+Azvej/E5j2rX6ZtvuQtSpQPfA=; b=V9Jvq6PSsuaBeofXy85fEtWJHoC+z9wE6YQ0EzH0qCbl5ftQubT+ImIK AqkgCOpp8qB2DJXwOONMHfr++1jKYCrHQzivVJHHGwpnMjVTxfXAh1uUX qhRtQTjniqfNAClYKB3M9Yj3L65VeogFvGz+E1KEctwGPJTWJ3Ju9KXpR s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AgDzLuBW/49dJa1egm9MgT8GukoBD?= =?us-ascii?q?YFphg8CgUU4FAEBAQEBAQFkJ4RCAQEEGgFRDRACAQg4AQYHMhQRAgQBDQUZAog?= =?us-ascii?q?JwAoBAQEBAQEBAwEBAQEBAQEBAQEBFYYYg0R+hBWEXwWSe4Q8AY1xgWSERYhTh?= =?us-ascii?q?X2IYAEeAQFCggMFFIFIaogZPH4BAQE?= X-IronPort-AV: E=Sophos; i="5.24,311,1454976000"; d="scan'208,217"; a="84636397" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2016 14:13:55 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u29EDtHt017891 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Mar 2016 14:13:55 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Mar 2016 08:13:54 -0600 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.1104.009; Wed, 9 Mar 2016 08:13:54 -0600 From: "Alvaro Retana (aretana)" To: Thomas Morin , "draft-ietf-bess-multicast-damping@ietf.org" Thread-Topic: AD Review of draft-ietf-bess-multicast-damping-03 Thread-Index: AQHRbo1R5e3rbxWH10Omol5b+cXuqp870IaAgBXjgoA= Date: Wed, 9 Mar 2016 14:13:54 +0000 Message-ID: References: <56CDE11B.1000900@orange.com> In-Reply-To: <56CDE11B.1000900@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.228.39] Content-Type: multipart/alternative; boundary="_000_D305B70611606Baretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-multicast-damping-03 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 14:14:01 -0000 --_000_D305B70611606Baretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 2/24/16, 11:58 AM, "Thomas Morin" > wrote: Thomas: Hi! There are several places where we're still not in sync. Please se below. Maybe talking in person would be good. Thanks! Alvaro. 2016-02-23, Alvaro Retana (aretana): The Abstract says that the procedures are "inspired from BGP unicast route = damping". It seems to me that the intent is in fact to adopt the algorithm= from RFC2439. However, the text is not explicit/clear about that. Saying so would I think actually be a misleading simplification, the reader= may miss the facts: - that the proposal is to keep advertising a dampened multicast VPN state u= p (in RFC2439, a dampened route stops being advertised) - that the document is not BGP-specific but also specifies a mechanism for = the PIM FSM - that only exponential decay is borrowed from RFC2439 This last sentence is what I meant above by "adopt the algorithm from RFC24= 39". In other words, your proposal is to dampen the multicast state using = the exponential decay algorithm defined in RFC2439, right? In your response to my detailed comments there are statements that confuse = me a little=85 I put some more comments/questions below. 1. As you all know, the history behind BGP damping has not been without = it being considered useless and even having recommendations (from RIPE, for= example) not to use it. A few things are important to have in mind: - the application context here is not the Internet - multicast state propagates in a very different fashion - the damping algorithm techniques is not the same - the side-effects of damping unicast and damping multicast as proposed her= e are fundamentally different: here damping causes no impact on the service Overall, I would say that the weaknesses of RFC2439 and the recommendations= in RFC7196 were well known by co-authors and that we came to the conclusio= n that this multicast VPN would not suffer from similar weaknesses. How did you arrive at the default and maximum values? By simulating with simple parameters and choosing conservative low-risk val= ues. Considering that, by design, whatever the parameters, multicast streams wil= l be delivered unchanged and that the only thing you tradeoff against is le= ss dynamicity and a possibly slightly increased bandwidth use, the default = and maximum values do not have to be perfectly tuned. Please include this type of information (above) in the document. Given the= history of dampening in general, understanding the differences considered = will go a long way and avoid more questions. ;-) It concerns me that there are no known implementations (from the Shepherd's= report). This concern is valid. See below... Because of that, I think this document would be better suited as an Experim= ental RFC, with the explicit purpose of gaining experience with the values = and determine the impact in live deployments (which then could support a st= andard version). Please consider changing the intended Status. Let me go back to why this proposal started: some lab testing was done show= ing that it was easy, in the lab, to create significant overload on PE and = RRs BGP stacks by flapping multicast state at the edge. Having a standard = track to provide the appropriate tooling against this DoS risk seems to me = as making sense. I think that the proposed procedures are not close enough= to the solution and problem addressed by RFC2439 to say that RFC2439's his= tory is an argument to pass through an Experimental RFC first. You might be right in this last point (the history of RFC2439 shouldn't aff= ect this document), specially given the explanation you gave earlier (where= you talked about multicast being different, not intended for the Internet,= etc.). However, the rest of your answer (in that last paragraph) points only at ex= perience in seeing the problem and testing the solution "in the lab". Not = outside the lab. In other words, the motivation and problem both came from= lab tests. Augmented by the fact that there are no implementations it ren= ews my proposal to make this document Experimental =97 as I said before, wi= th the explicit purpose of gaining experience: is the problem observed in d= eployed networks, are the conditions there the same/similar as in the lab, = are the parameters adequate. Note that I don't think that an RFC has to be in the Standards Track to pro= ve useful. =85 1. Are you adopting the exponential decay algorithm from RFC2439? That = seems to be what's happening because you are not explicitly defining a new = algorithm, but some of the text leave doubts. For example: * "inspired from BGP unicast route damping" I know the application = is different, but if the algorithm is the same then please say it. The procedures associated to the exponential decay are different. Are you referring to the procedures as to when a penalty is incurred (multi= cast state change vs routing update), action (maintain the state vs stop ad= vertising a route), etc. ?? 1. * Section 5.1. (PIM procedures) * "updating the *figure-of-merit* based on the decay algorithm mu= st be done prior to this increment" This statement seems to directly imply= that the algorithm is used. Please reorder the steps to explicitly call t= his one out, instead of plugging it in as an afterthought. BTW, should the= "must" be "MUST"? Ordering should help you not having to deal with that l= ast question. I've revised the text to describe this step in its own bullet, prior to "up= dating the figure-of-merit", to avoid this "after thought" impression and m= ake it as mandatory as the other steps. 1. * * "Same techniques as the ones described in [RFC2439] can be appl= ied=85" "Can be"? This sentence seems to imply that what is described in= RFC2439 is optional. Are there other ways of determining the same thing? = What about the exponential decay algorithm? No, there are just multiple ways possible to update the figure-of-merit, in= cluding the ones RFC2439 mention or detail. I've reformulated the text to avoid misinterpretation: These specifications do not impose the use of a particular technique to update the *figure-of-merit* following the exponential decay algorithm based on the configured *decay-half-life*. In particular the same techniques as the ones described in [RFC2439] can be applied. The only requirement is that the *figure-of-merit* has to be updated prior to increasing it and that its decay below the *reuse-threshold* has to be timely reacted upon: in particular, if the recomputation is done periodically, the period should be low enough to not significantly delay the inactivation of damping on a multicast state beyond what the operator wanted to configure (i.e. for a *decay-half-life* of 10s, recomputing the *figure-of-merit* each minute would result in a multicast state to remained damped for a much longer time than what the parameters are supposed to command). If I'm understanding (that the algorithm in RFC2439 is one possible way to = update the figure-of-merit, but that there are others possible), then: 1. this text only augments my point about this document being experiment= al; the text is not specific as to how things should work, it leaves the do= or open to almost anything=85which brings me back to the question about how= do you know that the proposed defaults will work with anything=85Experimen= tal, etc. 2. Even for the known method (exponential back off in RFC2439) the text = is not prescriptive enough to be a Standard. 1. * * It would also help if the terminology was consistent. For exam= ple, instead of "damping becomes active" use "suppressed". I can see how "= suppressed" may give the wrong impression as only the propagation of state = is affected. Explaining then how the terminology applies would make it eas= ier to reuse, avoid confusion and be clear. Note that there's no mention o= f RFC2439 in the terminology section. Using the "suppressed" term to describe a state that we artifically keep ac= tive is the most confusing thing that I can think of. As you say this would= give a wrong impression. I would go as far as to say that the document wo= uld be barely understandable. But maybe we can add this to the terminology section: In these specifications, damping of a multicast state will be said to be "a= ctive" or "inactive". Note that the term used for a unicast route which is = dampened is "suppressed", but we avoid this term is these specifications gi= ven that a dampened multicast state is kept active. Would that help ? Yes. That would go in the Terminology section, right? As there are other RFC243= 9 terms, it would be good to make a blanket statement there about that too. 1. * 2. Section 3. (Overview): "=85it is expected that this technique will al= low to meet the goals of protecting the multicast routing infrastructure co= ntrol plane without a significant average increase of bandwidth". In gener= al, I want to make sure that the qualities of the solution and the expected= results are properly reflected in the document. [I'm using the text above = as the base for my comment, but the impact is larger.] Some questions: * "=85it is expected that this technique will=85" I wonder why an a= ssertion can't be made that this technique can (vs just expecting that it w= ill) address specific problems. Is it the case that experience is needed t= o make a stronger assertion? Are the goals the same (or at least similar) = in every network? Are there implementations available? If so, please cons= ider an "Implementation Status" section (see rfc6982). What has been the d= eployment experience? This goes back to my comment above about the Intende= d Status of this document. "It is expected" reflects the idea that the slight increase in bandwidth wi= ll not be significant in most cases. We can expand the text a bit to explain what would be the cases where that = would not work. Let me suggest the following reformulation: "That said, basic simulation of the exponential decay algorithm show that t= he multicast state churn can be drastically reduced without significantly i= ncreasing the duration for which multicast traffic is forwarded. Hence, usi= ng this technique will efficiently protect the multicast routing infrastruc= ture control plane against the issues described here, without a significant= average increase of bandwidth. The exception will be a scenario where the= network dimensioning does not allow to extend the time a multicast flow is= forwarded beyond the duration for which is it needed by receivers". I don't know what the last sentence means. :-( What is "network dimensioni= ng"? It sounds that not extending "the time a multicast flow is forwarded = beyond the duration for which is it needed by receivers" is not a bad thing= =85 Other than that last sentence, the text sounds clearer. You again talk about simulation experience, which as close at it may have b= een to real conditions it is just a simulation. It's ok to mention this be= cause that is the experience you have. You also mention the exponential de= cay algorithm, but the text above about other possible methods takes me bac= k to: what happens if a different method is used? 1. * What specifically are the goals? In a couple of places the text p= oints back at Section 1. (Introduction), but I'm not sure exactly what the = goals are. Of special interest for understanding the goals is the part in = Section 4.2. (Existing PIM, IGMP and MLD timers) where other solutions are = discarded for not meeting them. * There is scattered text that talks about "=85ensure that the lo= ad put on the BGP control plane, and on the P-tunnel setup control plane, r= emains under control=85", "protecting these control planes=85avoiding negat= ive effects=85although at the expense of a minimal increase in average of b= andwidth use=85". However, the description is too vague to point at what = can satisfy these goals and what can't. Section one 1 says: - " Hence, mechanisms need to be put in place to ensure that the load put o= n the BGP control plane, and on the P-tunnel setup control plane, remains u= nder control regardless of the frequency at which multicast memberships cha= nges are made by end hosts." -then "This document describes procedures, remotely inspired from existing= BGP route damping, aimed at protecting these control planes while at the s= ame time avoiding negative effects on the service provided, although at the= expense of a minimal increase in average of bandwidth use in the network." The intent was that the text would be enough to make the goals clear. Would the following change of the second sentence provide suitable detail t= o help understand what can satisfy these goals and what can't : ...? [...] aimed at offering means to set an upper bound to the affected control= planes (BGP RFC6514 processing, and the P-tunnel control plane protocol in= certain cases as well) while at the same time preserving service provided = (delivering the stream to the end user as requested), although at the expen= se of a minimal increase in average of bandwidth use in the network. I see that we can reorder the text to avoid splitting the explanation of go= als. The new text would look like the following: In VPN contexts, providing isolation between customers of a shared infrastructure is a core requirement resulting in stringent expectations with regards to risks of denial of service attacks. By nature multicast memberships change based on the behavior of multicast applications running on end hosts, hence the frequency of membership changes can legitimately be much higher than the typical churn of unicast routing states. Section 16 of [RFC6514] specifically spells out the need for damping the activity of C-multicast and Leaf Auto-discovery routes. Hence, mechanisms need to be put in place to ensure that the load put on the BGP control plane, and on the P-tunnel setup control plane, remains under control regardless of the frequency at which multicast memberships changes are made by end hosts. This document describes procedures, remotely inspired from existing BGP route damping, aimed at offering means to set an upper bound to the amount of processing for the mVPN control planes protocols ([RFC6514], and the P-tunnel control plane protocol in certain cases as well), while at the same time preserving service provided (delivering the stream to the end user as requested), although at the expense of a minimal increase in average of bandwidth use in the network. That text is better, but it still includes statements like "=85ensure that = the load=85remains under control=85", and later "set an upper bound". I'm = not too happy with vague goals as keeping something under control (for exam= ple) can mean many things --- and the upper bound is not clearly defined. = This upper bound is probably a function of the defaults chosen; explaining = that (not in this section) would be nice. =85 1. Section 5.2. (Procedures for multicast VPN state damping) * In the Introduction you write that "Section 16 of [RFC6514] specif= ically spells out the need for damping the activity=85" I think that RFC65= 14 does a lot more than that: Section 16.1. (Dampening C-Multicast Routes)= "proposes OPTIONAL route dampening procedures similar to what is described= in [RFC2439]." Those procedures look very similar to the ones in this do= cument. What is the difference? Is the intent of this document to complem= ent, replace or maybe update what is already specified in RFC6514? Indeed, the base ideas for dampening were already here when we wrote RFC651= 4. draft-ietf-bess-multicast-damping provides precision on how to implement RF= C6514 16.1.1, but this is not an update per se as nothing in RFC6514 is cha= nged. We can make that fully explicit by saying in Section 1: Section 16 of [RFC6514] specifically spells out the need for damping the activity of C-multicast and Leaf Auto-discovery routes, and outlines how to do it by "delay the advertisement of withdrawals of C-multicast routes". These specifications provides appropriate detail on how to implement that and how to make that controllable by the operator. That is an update: by clarifying and providing specifics you are in fact up= dating RFC6514. We want to mark it that way (and be explicit about it) bec= ause we want someone reading RFC6514 to refer to this document if wanting t= o implement dampening. =85 1. Minor: 1. In 4.2 * s/prune override interval/J/P_Override_Interval I'd rather keep the plain text version. "J/P_Override_Interval" is that this interval is called in rfc460bis. =85 1. 2. Section 5.2. (Procedures for multicast VPN state damping) * There are several places in this section where rfc2119 language is= used to describe what an implementation should do that sound to me as an a= ttempt to define functionality that is mandatory to implement (MTI). I fin= d that hard/impossible to enforce and would like to see the rfc2119 languag= e removed. Please see below.. Yes, the MUSTs in this 5.1 and 5.2 intent to carry the meaning of "mandator= y to implement". [Skipping to the specific RFC2119 question.] =85 I understand that you seem to prefer avoiding RFC2119 language for MTI thin= gs. But I don't know another way than RFC2119 language to indicate what is mand= atory to implement to be compliant with a spec, and I think this is a fairl= y well established practice. This is not the first document to use RFC2119 = to indicate MTI things. What is the rationale for not using RFC2119 language ? RFC2119 reads: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Two points from there: 1. If it's not necessary to for interoperation, then don't use them. Us= ing this text as an example: "Implementation of [RFC6513] relying on the us= e of PIM to carry C-multicast routing information MUST support this techniq= ue." Implementing dampening is not necessary for RFC6513 implementations t= o interoperate. In fact, if one implementation enables dampening and the o= ther doesn't, they will still interoperate. 2. Note that the last sentence refers specifically to implementation cho= ices. Using this text as an example: "The choice to implement damping=85is= up to the implementor=85implementing the BGP approach is RECOMMENDED." Th= ere is no need to use "RECOMMENDED" because it is not necessary for interop= erability and by using it you're trying to impose a specific method. =85 1. * * "=85damping SHOULD NOT be applied to BGP routes of the following s= ub-types=85" Are there cases when it is ok? In other words, why is the "S= HOULD NOT" not a "MUST NOT"? Maybe someone can find a case where this does not break things, under some = conditions. We saw nothing mandating the use of "MUST NOT". What conditions? Someone finding a case sounds like Experimentation to me=85 1. 2. Section 6.1. (Damping mVPN P-tunnel change events) "Possible ways to = do so depend on the type of P-tunnel, and local implementation details are = left up to the implementor. The following is proposed as example of how= the above can be achieved." Either you leave it as an implementation deta= il or you provide guidance. If this document was Experimental, then provid= ing guidance it great! There is a gap between "example" and "guidance". I think an example can help the reader (implementor or deployer). Guidance would mean that we start influencing the implementor, which is not= the idea here. You already are influencing! See above about MTI. --_000_D305B70611606Baretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 2/24/16, 11:58 AM, "Thomas Morin" <thomas.morin@orange.com> wrote:

Thomas:

Hi!

There are several places where we're still not in sync.  Please se bel= ow.

Maybe talking in person would be good.

Thanks!

Alvaro.




2016-02-23, Alvaro Retana (aretana):
= The Abstract says that the procedures are "inspired from BGP unic= ast route damping".  It seems to me that the intent is in fact to= adopt the algorithm from RFC2439.  However, the text is not explicit/clear about that.
Saying so would I think actually be a misleading simplification, the reader= may miss the facts:
- that the proposal is to keep advertising a dampened multicast VPN state u= p (in RFC2439, a dampened route stops being advertised)
- that the document is not BGP-specific but also specifies a mechanism for = the PIM FSM
- that only exponential decay is borrowed from RFC2439

This last sentence is what I meant above by "adopt the algorithm from = RFC2439".  In other words, your proposal is to dampen the multica= st state using the exponential decay algorithm defined in RFC2439, right?

In your response to my detailed comments there are statements that confuse = me a little=85  I put some more comments/questions below.  



  1. As you all know, the hi= story behind BGP damping has not been without it being considered useless a= nd even having recommendations (from RIPE, for example) not to use it. = ;

A few things are important to have in mind:
- the application context here is not the Internet
- multicast state propagates in a very different fashion
- the damping algorithm techniques is not the same
- the side-effects of damping unicast and damping multicast as proposed her= e are fundamentally different: here damping causes no impact on the service=

Overall, I would say that the weaknesses of RFC2439 and the recommendations= in RFC7196 were well known by co-authors and that we came to the conclusio= n that this multicast VPN would not suffer from similar weaknesses.

= How did you arrive at the default and maximum values? 

By simulating with simple parameters and choosing conservative low-risk val= ues.
Considering that, by design, whatever the parameters, multicast streams wil= l be delivered unchanged and that the only thing you tradeoff against is le= ss dynamicity and a possibly slightly increased bandwidth use, the default = and maximum values do not have to be perfectly tuned.

Please include this type of information (above) in the document.  Give= n the history of dampening in general, understanding the differences consid= ered will go a long way and avoid more questions. ;-)


= It concerns me that there are no known implementations (from the Sheph= erd's report). 
This concern is valid.
See below...

= Because of that, I think this document would be better suite= d as an Experimental RFC, with the explicit purpose of gaining experience w= ith the values and determine the impact in live deployments (which then could support a standard version).  Please consider chang= ing the intended Status.
Let me go back to why this proposal started: some lab testing was done show= ing that it was easy, in the lab, to create significant overload on PE and = RRs BGP stacks by flapping multicast state at the edge.  Having a stan= dard track to provide the appropriate tooling against this DoS risk seems to me as making sense.  I think t= hat the proposed procedures are not close enough to the solution and proble= m addressed by RFC2439 to say that RFC2439's history is an argument to pass= through an Experimental RFC first.

You might be right in this last point (the history of RFC2439 shouldn't aff= ect this document), specially given the explanation you gave earlier (where= you talked about multicast being different, not intended for the Internet,= etc.).

However, the rest of your answer (in that last paragraph) points only at ex= perience in seeing the problem and testing the solution "in the lab&qu= ot;.  Not outside the lab.  In other words, the motivation and pr= oblem both came from lab tests.  Augmented by the fact that there are no implementations it renews my proposal to make this docum= ent Experimental =97 as I said before, with the explicit purpose of gaining= experience: is the problem observed in deployed networks, are the conditio= ns there the same/similar as in the lab, are the parameters adequate.

Note that I don't think that an RFC has to be in the Standards Track to pro= ve useful.


=85


  1. Are you adopting the ex= ponential decay algorithm from RFC2439?  That seems to be what's happe= ning because you are not explicitly defining a new algorithm, but some of t= he text leave doubts.  For example:
    • "inspired from BGP= unicast route damping"  I know the application is different, but= if the algorithm is the same then please say it.
The procedures associated to the exponential decay are different.

Are you referring to the&= nbsp;procedures as to when a penalty is incurred (multicast state chan= ge vs routing update), action (maintain the state vs stop advertising a route), etc. ??  




    • Section 5.1. (PIM = procedures)
      • "updating the *fig= ure-of-merit* based on the decay algorithm must be done prior to this incre= ment"  This statement seems to directly imply that the algorithm = is used.  Please reorder the steps to explicitly call this one out, instead of plugging it in as an afterthought.  BTW= , should the "must" be "MUST"?  Ordering should he= lp you not having to deal with that last question.

I've revised the text to describe this step in its own bullet, prior to &qu= ot;updating the figure-of-merit", to avoid this "after thought&qu= ot; impression and make it as mandatory as the other steps.


      • "Same techniques a= s the ones described in [RFC2439] can be applied=85"   "Can = be"?  This sentence seems to imply that what is described in RFC2= 439 is optional.  Are there other ways of determining the same thing?  What about the exponential decay algorithm?

No, there are just multiple ways possible to update the figure-of-merit, in= cluding the ones RFC2439 mention or detail.

I've reformulated the text to avoid misinterpretation:

  These specifications do not impose the use of a particular technique=
   to update the *figure-of-merit* following the exponential deca= y
   algorithm based on the configured *decay-half-life*. In partic= ular
   the same techniques as the ones described in [RFC2439] can be<= br>    applied.  The only requirement is that the *figure-of-mer= it* has to
   be updated prior to increasing it and that its decay below the=
   *reuse-threshold* has to be timely reacted upon: in particular= , if
   the recomputation is done periodically, the period should be l= ow
   enough to not significantly delay the inactivation of damping = on a
   multicast state beyond what the operator wanted to configure (= i.e.
   for a *decay-half-life* of 10s, recomputing the *figure-of-mer= it*
   each minute would result in a multicast state to remained damp= ed for
   a much longer time than what the parameters are supposed to co= mmand).

If I'm understanding (that the algorithm in RFC2439 is one possible way to = update the figure-of-merit, but that there are others possible), then:
  1. this text only augments my point about this document being experimental= ; the text is not specific as to how things should work, it leaves the door= open to almost anything=85which brings me back to the question about how d= o you know that the proposed defaults will work with anything=85Experimental, etc.
  2. Even for the known me= thod (exponential back off in RFC2439) the text is not prescriptive enough = to be a Standard.





      • It would also help if the terminology was consistent.  For example= , instead of "damping becomes active" use "suppres= sed".  I can see how "suppressed" may give the wrong&nb= sp;impression as only the propagation of state is affected.  Expl= aining then how the terminology applies would make it easier to reuse, avoid confusion and be clear. =  Note that there's no mention of RFC2439 in the terminology section.

Using the "suppressed" term to describe a state that we artifical= ly keep active is the most confusing thing that I can think of. As you say = this would give a wrong impression.  I would go as far as to say that = the document would be barely understandable.

But maybe we can add this to the terminology section:
In these specifications, damping of a multicast state will be s= aid to be "active" or "inactive". Note that the term us= ed for a unicast route which is dampened is "suppressed", but we = avoid this term is these specifications given that a dampened multicast state is kept active.
Would that help ?

Yes.

That would go in the Terminology section, right?  As there are other R= FC2439 terms, it would be good to make a blanket statement there about that= too.




  2. Section 3. (O= verview): "=85it is expected that this technique will allow to me= et the goals of protecting the multicast routing infrastructure contro= l plane without a significant average increase of bandwidth".  In general, I want to make sure that the qualities of the solut= ion and the expected results are properly reflected in the document. [I'm u= sing the text above as the base for my comment, but the impact is larger.] =  Some questions:
    • "=85it is expected that this technique will=85"  I = wonder why an assertion can't be made that this technique can (vs just= expecting that it will) address specific problems.  Is it the case th= at experience is needed to make a stronger assertion?  Are the goals the same (or at least similar) in every network?  Are there implement= ations available?  If so, please consider an "Implementation Stat= us" section (see rfc6982).  What has been the deployment exp= erience?  This goes back to my comment above about the Intended Status of this document.

"It is expected" reflects the idea that the slight increase in ba= ndwidth will not be significant in most cases.
We can expand the text a bit to explain what would be the cases where that = would not work.

Let me suggest the following reformulation:

"That said, basic simulation of the exponential decay algorithm show t= hat the multicast state churn can be drastically reduced without significan= tly increasing the duration for which multicast traffic is forwarded. Hence= , using this technique will efficiently protect the multicast routing infrastructure control plane against the iss= ues described here, without a significant average increase of bandwidt= h.  The exception will be a scenario where the network dimensioning do= es not allow to extend the time a multicast flow is forwarded beyond the duration for which is it needed by receivers&= quot;.

I don't know what the last sentence means. :-(  What is "network = dimensioning"?  It sounds that not extending "the time a mul= ticast flow is forwarded beyond the duration for which is it needed by rece= ivers" is not a bad thing=85   Other than that last sentence, the text sounds clearer.

You again talk about simulation experience, which as close at it may have b= een to real conditions it is just a simulation.  It's ok to mention th= is because that is the experience you have.  You also mention the expo= nential decay algorithm, but the text above about other possible methods takes me back to: what happens if a different= method is used?




    • What specifically are t= he goals?  In a couple of places the text points back at Section = 1. (Introduction), but I'm not sure exactly what the goals are.  = Of special interest for understanding the goals is the part in Section 4.2. (Existing PIM, IGMP and MLD timers) where other = solutions are discarded for not meeting them.
      • There is scattered text that talks about "=85ensure that the load = put on the BGP control plane, and on the P-tunnel setup control plane,=  remains under control=85", "protecting these control planes= =85avoiding negative effects=85although at the expense of a minimal increase in average of bandwidth use=85".   However, t= he description is too vague to point at what can satisfy these goals a= nd what can't.


Section one 1 says:
- " Hence, mechanisms need to be put in place to ensure that the load = put on the BGP control plane, and on the P-tunnel setup control plane, rema= ins under control regardless of the frequency at which multicast membership= s changes are made by end hosts."
-then  "This document describes procedures, remotely inspired fro= m existing BGP route damping, aimed at protecting these control planes whil= e at the same time avoiding negative effects on the service provided, altho= ugh at the expense of a minimal increase in average of bandwidth use in the network."

The intent was that the text would be enough to make the goals clear.

Would the following change of the second sentence provide suitable detail t= o help understand what can satisfy these goals and what can't : &= nbsp; ...?

[...] aimed at offering means to set an upper bound to the affected control= planes (BGP RFC6514 processing, and the P-tunnel control plane protocol in= certain cases as well) while at the same time preserving service provided = (delivering the stream to the end user as requested), although at the expense of a minimal increase in avera= ge of bandwidth use in the network.

I see that we can reorder the text to avoid splitting the explanation of go= als.

The new text would look like the following:

   In VPN contexts, providing isolation between customers of a sh= ared
   infrastructure is a core requirement resulting in stringent    expectations with regards to risks of denial of service attack= s.

   By nature multicast memberships change based on the behavior o= f
   multicast applications running on end hosts, hence the frequen= cy of
   membership changes can legitimately be much higher than the ty= pical
   churn of unicast routing states.  Section 16 of [RFC6514]=
   specifically spells out the need for damping the activity of    C-multicast and Leaf Auto-discovery routes.

   Hence, mechanisms need to be put in place to ensure that the l= oad put
   on the BGP control plane, and on the P-tunnel setup control pl= ane,
   remains under control regardless of the frequency at which mul= ticast
   memberships changes are made by end hosts.

   This document describes procedures, remotely inspired from exi= sting
   BGP route damping, aimed at offering means to set an upper bou= nd to
   the amount of processing for the mVPN control planes protocols=
   ([RFC6514], and the P-tunnel control plane protocol in certain= cases
   as well), while at the same time preserving service provided    (delivering the stream to the end user as requested), although= at the
   expense of a minimal increase in average of bandwidth use in t= he
   network.

That text is better, but it still includes statements like "=85ensure = that the load=85remains under control=85", and later "set an uppe= r bound".  I'm not too happy with vague goals as keeping somethin= g under control (for example) can mean many things --- and the upper bound is not clearly defined.  This upper bound is probably a f= unction of the defaults chosen; explaining that (not in this section) would= be nice.


=85

  1. Section 5.2. (Proc= edures for multicast VPN state damping)  
    • In the Introduction you write that "Section 16 of [RFC6514] specif= ically spells out the need for damping the activity=85"  I t= hink that RFC6514 does a lot more than that:  Section 16.1. (Damp= ening C-Multicast Routes) "proposes OPTIONAL route dampening proc= edures similar to what is described in [RFC2439]."   Those procedu= res look very similar to the ones in this document.  What is the = difference?  Is the intent of this document to complement, replace or = maybe update what is already specified in RFC6514?

Indeed, the base ideas for dampening were already here when we wrote RFC651= 4.
draft-ietf-bess-multicast-damping provides precision on how to implement RF= C6514 16.1.1, but this is not an update per se as nothing in RFC6514 is cha= nged.

We can make that fully explicit by saying in Section 1:

   Section 16 of [RFC6514] specifically spells out the need for d= amping
   the activity of C-multicast and Leaf Auto-discovery routes, an= d
   outlines how to do it by "delay the advertisement of with= drawals of
   C-multicast routes".  These specifications provides = appropriate
   detail on how to implement that and how to make that controlla= ble
   by the operator.

That is an update: by clarifying and providing specifics you are in fact up= dating RFC6514.  We want to mark it that way (and be explicit about it= ) because we want someone reading RFC6514 to refer to this document if want= ing to implement dampening.


=85

  1. Minor:
  1. In 4.2
    • s/prune override interv= al/J/P_Override_Interval

I'd rather keep the plain text version.

"J/P_Override_Interval" is that this interval is called in rfc460= bis.

=85


  2. Section 5.2. = (Procedures for multicast VPN state damping) 
    • There are several places in this section where rfc2119 language is used= to describe what an implementation should do that sound to me as an a= ttempt to define functionality that is mandatory to implement (MTI). &= nbsp;I find that hard/impossible to enforce and would like to see the rfc2119 language removed.  Please see below.. <= /li>

Yes, the MUSTs in this 5.1 and 5.2 intent to carry the meaning of "man= datory to implement".

[Skipping to the specific RFC2119 question.]
=85
I understand that you seem to pre= fer avoiding RFC2119 language for MTI things.
But I don't know another way than RFC2119 language to indicate what is mand= atory to implement to be compliant with a spec, and I think this is a fairl= y well established practice. This is not the first document to use RFC2119 = to indicate MTI things.

What is the rationale for not using RFC2119 language ?

RFC2119 reads:

6. Guidance in the use of these Impe= ratives

   Imperatives of the type= defined in this memo must be used with care
   and sparingly.  In= particular, they MUST only be used where it is
   actually required for i= nteroperation or to limit behavior which has
   potential for causing h= arm (e.g., limiting retransmisssions)  For
   example, they must not = be used to try to impose a particular method
   on implementors where t= he method is not required for
   interoperability.


Two points from there:
  1. If it's not necessary to for interoperation, then don't us= e them.  Using this text as an example: "Implementation of [RFC6513]= relying on the use of PIM to carry C-multicast routing information MUST support this&nb= sp;technique."  Implementing dampening is not necessary for RFC6513 implementations = to interoperate.  In fact, if one implementation enables dampening and= the other doesn't, they will still interoperate.
  2. Note that the last sentence refers specifically to = implementation choices.  Using this text as an example: "<= span style=3D"font-family: Calibri, sans-serif;">The choice to implement da= mping=85is up to the implementor=85implementing the BGP approach is RECOMMENDED."  There= is no need to use "RECOMMENDED" because it is not necessary for = interoperability and by using it you're trying to impose a specific method.

=85



    • "=85damping SHOULD NOT be applied to BGP routes of the f= ollowing sub-types=85"  Are there cases when it is ok?  In o= ther words, why is the "SHOULD NOT" not a "MUST NOT"?

Maybe someone can find a case where this does not break things, under some = conditions.
We saw nothing mandating the use of "MUST NOT".

What conditions?

Someone finding a case sounds like Experimentation to me=85




  2. Section 6.1. = (Damping mVPN P-tunnel change events) "Possible ways to do so dep= end on the type of P-tunnel, and local implementation details are left= up to the implementor.     The following is proposed as exa= mple of how the above can be achieved."  Either you leave it as = an implementation detail or you provide guidance.  If this docume= nt was Experimental, then providing guidance it great!

There is a gap between "example" and "guidance".
I think an example can help the reader (implementor or deployer).
Guidance would mean that we start influencing the implementor, which is not= the idea here.

You already are influencing!  See above about MTI.
--_000_D305B70611606Baretanaciscocom_-- From nobody Wed Mar 9 07:57:15 2016 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 9A05612E0A3 for ; Wed, 9 Mar 2016 07:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlWLjjNJv47B for ; Wed, 9 Mar 2016 07:56:23 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46A112E151 for ; Wed, 9 Mar 2016 07:44:35 -0800 (PST) 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.142] (66.129.241.13) by DM2PR05MB797.namprd05.prod.outlook.com (10.141.180.13) with Microsoft SMTP Server (TLS) id 15.1.427.16; Wed, 9 Mar 2016 15:44:32 +0000 To: "li_zhenqiang@hotmail.com" , bess References: From: Eric C Rosen Message-ID: <56E044DB.4090302@juniper.net> Date: Wed, 9 Mar 2016 10:44:27 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040908020007060402030007" X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY1PR0501CA0009.namprd05.prod.outlook.com (25.162.139.19) To DM2PR05MB797.namprd05.prod.outlook.com (10.141.180.13) X-MS-Office365-Filtering-Correlation-Id: 8c15a594-8362-4b86-c467-08d34831b646 X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB797; 2:KsyPos+OSlO0WlGndz1RKrBkAFr4m2w6yrAUDqdt+E4OX583AJbkILta7RHMrBToOOuR8rDJygV4o0VlAvPZR+3AeyQ+6/lPE0i+RTGJOb1PhO7A5t5jtzW20AvcSKdMpjdT1WBxQyg+TVnciE9bgLXBUCOGIxgQR3bQfHJRZ9ZuBdA/CbYQJA3z7RqeCqY+; 3:okjIWVGRH5JsvbErolQOUii4ERqTjJhigDvlq5eWDhEZLI/4VVA4+mvxQwfxNrxZLw8NJUZhtVEJulTMt05+jB/mpvXf9YWetel5cAyoawolHQhoeHuQ1JwO2hfYtAno; 25:4/L2ag7s6bPNCEYuMDZdqinK+Nh3GgztOS9ITR6jfRbpcOS1s97rihK/qboIlZditjiSbKorKIT5uMCmx2uizHxF61/OXaMnZPUj9dicbeuoTzZpQFEEdUXjVYGZSnfjqZfW9JCW21WX+F1yEPnN7pU6HAqcViT94JlxNqgVr8c/hSz0po5Qm47l1EJvUsq1+B0AiLsCz2nvpd5C2lcvnszdZq51iCyQFGsW+7gSGQ4Vjq0b4xTwWwl0p47pGNqTMffXbfE4NLQnSQwhj+Qq5w/O1nAFtRbCAiPDvpiGYLGOaoxZDFmv4WEWXhVvk69sMC82PJJTEjRv9BuQOJGNCA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB797; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB797; 20:hlnfW7nXf/pcmE31D2UUTPUSMseMFvaiKaehGQdQFnYok1mKkkQj9dWU4lMzpA6wWax36arrhRzh0o19YVAtXxdC9iZxPZ9xUoS5V4BHC3zhoFkl1NYZJ9a/uH5PmF5aC+wuIK2zb+JuOsszM0f0HaW69C/c/ERA7cHDzwrOUGiMLdGIls6u6wtryClLvEHepXwGLmpZAraHEHzAL7fI4PVunrHXJKcqWxPBPY7XsRTLdtlTS5UdMv3vaLHv/PHzSTv65Fv0hLI2xQCUOXkZFHNeRiyHvOwcilMAx3AyxOxX052pg+G8TT/xYlaJri/DXrtHpOdQiDimH0HmvVDYLDas/IZFAVtlsmRoiAo0/ZY4Z62qpjl6Bl91wZUU/BHgew7v5+E+HF3sMcsOQJKp9qcGYPm4Z0gA35hoEXCAuQkyRtasu/QY6LMa4Uj6ir2Szu43+rikrez8H1NJ0yGyM17wJF4H6BBYai8uPSQFmbuqyNBOPjK7d0T+HFcwnNVY; 4:JUU7sPbPaZTygrpw194RVJ7GyULFyU6kyncBvFTvdmRf6n71NPhsvyeCoK3YFjFOTDicN7zGnRgDKtDiaQz9VPKuvtNjv1yCJ0zSrsBP1mtOENJXp9Ibu3RmPsyOYoBxDmGHNJlS8iYoxlBm4LVdV07JcsvSmiD3xSNwyL/reBPA6wuvUWyD7YV9/+JggSjFHYo5qL+Q1KzbLxMzZ9GrT+2ZMwlJM8OlZn2RSwvbQ0fAt6uCNXyDHNUCuRFg7Gmm5VmL7SHCPeqFDReYC3Tt6+J/vBg1RLLSVX8i605tehwIigVuhDKgMc/OpMknjwh3+RsjfHYYkRtxl6MXjkHD6mTnx8EP1wjSAjI8RlzhqOPsbMW+sBGbdDmpu/vIN45t X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DM2PR05MB797; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB797; X-Forefront-PRVS: 0876988AF0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(53754006)(377424004)(24454002)(479174004)(377454003)(42186005)(65816999)(87266999)(76176999)(15975445007)(54356999)(81166005)(2950100001)(2501003)(230783001)(50986999)(59896002)(2906002)(65956001)(92566002)(65806001)(66066001)(86362001)(561944003)(33656002)(1096002)(3846002)(19580395003)(6116002)(270700001)(36756003)(586003)(19580405001)(83506001)(15650500001)(5001770100001)(77096005)(64126003)(80316001)(512874002)(4001350100001)(107886002)(5008740100001)(5004730100002)(189998001)(16236675004)(19617315012)(84326002)(861004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB797; H:[172.29.35.142]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjA1TUI3OTc7MjM6bDdnanNEL2dwTFhCOUlFdEw0YUtiN2VSa3lY?= =?utf-8?B?T0lpbXAvRW83RzduRnRVVnUrMGFsbXkzUVJ1R2lVVXcrTXVkZXZ2a0hxQkUx?= =?utf-8?B?RnJMMGxVOVp0RVFRTXE4TTNIRUg0R3BpbEdzZTJHZ000WmQza0ZtUVBLeTQr?= =?utf-8?B?N3Uzb2RzYXFST1pUeHZNVnF2TENoT2p3VGJYcnFYV2cxNDY5WVZ1SU9BZkxF?= =?utf-8?B?MTlNa055MlJFMHdueTM3MytkK0JFTmFRR1hNczMvcXZObG1kNXhSbDducElU?= =?utf-8?B?aFZZU083ekRpUkpteVIwS2dpQi9IZ0xjZDVBSGdGdFJxUmc4dm5kVXRmTHBE?= =?utf-8?B?cTJ0UXJJTkdkSmEwWk1uUHBHNjVLeUEvSnRidFRLZXR2bzZINVkyT1hUcDIr?= =?utf-8?B?dEIyYS9kWHJ2djcyOGsybWVldEhISXo1a083eGdyUXZxczRRbnR3OE40b0xZ?= =?utf-8?B?azh2Mjd2ZWFCeWVXck9PYXBMT0w2M3JwbU0vYzZDTXAyZWhVQlRPbWZJUXFh?= =?utf-8?B?OENRTUV4dFdEa0JFK003MmczTUhrcjNTaEl2ZXBjdEdsdTd6OUNBdjlab25q?= =?utf-8?B?V2ZJMlJYQ1BENDVBT2NtUEJ5QWpFU1htTWRHU1YyRDFid3dkendhalJCVkx0?= =?utf-8?B?dk5iRHdtT3BzZGRjMzJhbGpEcy9tNVFjUm9hVlZldEd2dWxlOTVzK2VzNlFK?= =?utf-8?B?TzhZaUFwVHJWbjJZT0U3TjFRV3pwbHlpbmxmcUFQS05lNmtDUm5HNVVtNkpl?= =?utf-8?B?TGNZeFU3bFZKeExFSGp0bFowUnVzd0NFT292NXBidmpwZmNrbGwwQkhxKzI2?= =?utf-8?B?aC9YTlN0S0pORzU5NlF3amQvODdxa3FCbWxJUm5xZytwV1BFS25FbkZqQm9j?= =?utf-8?B?dEx1YXpSaVZKTklxU3Y5ZGRtUWlIeE5RTHVyUVo0ZnlSejgyL2xXNG9xRkk3?= =?utf-8?B?ajJISlRYVkV4VnMwZG5lZWsrb1FlYnFKU2lzUzlrNlp6cldXVnBTaTZZaGlo?= =?utf-8?B?endmTmx2Qzc3YXdSOFNHNlBQYTFCemg0clBjR3lpTWg3V2FteGFHSlJ4N05p?= =?utf-8?B?SXhVSGdlZm01V2dubWNWdXhDcWZkQ0VkeURHWHYreHBqQnlNaXJ1aERWaS9Q?= =?utf-8?B?NHdNS3JxQ2JjTi9MelJONUZoK2NJdmpBbFI4NkhUK3V5Rk1PdXFrbHRIUUJX?= =?utf-8?B?L3pqK2VaOE5RNFgyNzFMMFJXSm1icHVrQ0M2QkdzMEE4TDd3ZUw1U0JyUndK?= =?utf-8?B?NVdvWVFaanhMM2VIcjk0ejduYjROUi9qZDVtdXRodzBmcVNLdFdPMkFaa3BR?= =?utf-8?B?eWl2LzVJY29wVUYzYm1lQ2s1eWVzOHV4L1UrelBPY3BNcmVpTzhQaTRNSC9T?= =?utf-8?B?L3dTbnQ5WnFqMzlBa3VmbTFiNzZWVGVRSFJIVHcrZDNNZTVvS1ZwMjlBMEJ2?= =?utf-8?B?a2ZDYlY5aktUZ0MvMG1xQWh2RldWcjA4MTI5L1BiN3VGK3dKWDhMMFIxcnNr?= =?utf-8?B?MERpa0F4VU5VRjFzWHQyc00rVklmK0Y3TjF0cE1ENUt6d2FRc3VJM0xaYW1w?= =?utf-8?B?Y1BTeklqbHdkT3RwRThUL1pDUmpGMlhJRGdBbVVGdWlscTRaS0svVll1ZGVJ?= =?utf-8?B?NVJNeldjR1RJcHRTOG4xZko0WmpjMXZBOUVtR0VhSzRsYWZOMlRQenBDY0N4?= =?utf-8?B?OVBwNi9sUDJEUC9qakY3NnVSMlZONkQwcGxXRmpCbEJPdU9oV1l5ekd5Qngy?= =?utf-8?B?MHNudkVsemZyaDlseFBhV1puSmZneUgzK0ZoVlcwcUFQSmJXczByWktGcVEz?= =?utf-8?Q?GB3lljSkGQ/n?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB797; 5:gkxQWUfuKFTjH4k8ZtZ9yRBaYiiCS1RtVC3qpb4B4IRf+rmswE/nyO4zZL6dktX8D0oqjMK1zg95nccLbEB+c6KkOjadWeu6MqMpLfZUeuKMpA0EGBkNxuet9HzMHALdsJ2iLtpvkoGEQUuwhUUfYQ==; 24:5tR04zaJWhYRUa67hlN8G+vxiAikB/o50Mx1m1IRkzlAyaZzlp3SNjUSkFseH3CzPjR6NVu8B7I8MNI9VPPi2aetKi+GriWAAAhI2uQ8eOA= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2016 15:44:32.9779 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB797 Archived-At: Subject: Re: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 15:56:26 -0000 --------------040908020007060402030007 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit I think this problem is already solved in RFC 5549. RFC 5549 specifies the procedures for creating a route with IPv4 or VPN-IPv4 NLRI and an IPv6 next hop, which should provide both 4PE and 4vPE functionality. Your proposal seems to differ, in that it puts the v6 next hop address in the NLRI, rather than in the next hop field. I don't think it makes much sense to put the next hop address in the NLRI, as that would then require a special set of rules for bestpath selection. On 3/8/2016 10:37 PM, li_zhenqiang@hotmail.com wrote: > Hello all, > > I update my draft. 4PE is introduced in this doc to meet the gap > pointed out in RFC7439. 4PE routers in IPv6-only MPLS network can use > MP-BGP extended in this doc to connect IPv4-only islands.. Your > comments are very appreciated. > > ------------------------------------------------------------------------ > li_zhenqiang@hotmail.com > > *From:* internet-drafts > *Date:* 2016-03-09 09:54 > *To:* Zhenqiang Li > *Subject:* New Version Notification for draft-li-bess-4pe-01.txt > A new version of I-D, draft-li-bess-4pe-01.txt > has been successfully submitted by Zhenqiang Li and posted to the > IETF repository. > Name: draft-li-bess-4pe > Revision: 01 > Title: Connecting IPv4 Islands over IPv6 MPLS Using IPv4 Provider > Edge Routers (4PE) > Document date: 2016-03-08 > Group: Individual Submission > Pages: 9 > URL: https://www.ietf.org/internet-drafts/draft-li-bess-4pe-01.txt > Status: https://datatracker.ietf.org/doc/draft-li-bess-4pe/ > Htmlized: https://tools.ietf.org/html/draft-li-bess-4pe-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-li-bess-4pe-01 > Abstract: > This document explains how to interconnect IPv4 islands over a > Multiprotocol Label Switching (MPLS)-enabled IPv6-only core. This > approach relies on IPv4 Provider Edge routers (4PE), which are Dual > Stacks in order to connect to IPv4 islands and to the MPLS > core. The > 4PE routers exchange the IPv4 reachability information > transparently > over the core using the Multiprotocol Border Gateway Protocol (MP- > BGP). MP-BGP is extended to do this. A new Subsequence Address > Family Identifier (SAFI) with corresponding new format Network > Layer > Reachability Information (NLRI), is introduced. The BGP Next Hop > field is used to convey the IPv4 address of the 4PE router, a field > is added in Network Layer Reachability Information (NLRI) to convey > the IPv6 address of the 4PE router, so that dynamically established > IPv6-signaled MPLS Label Switched Paths (LSPs) can be used without > explicit tunnel configuration. > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > The IETF Secretariat > > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess --------------040908020007060402030007 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit I think this problem is already solved in RFC 5549.

RFC 5549 specifies the procedures for creating a route with IPv4 or VPN-IPv4 NLRI and an IPv6 next hop, which should provide both 4PE and 4vPE functionality. 

Your proposal seems to differ, in that it puts the v6 next hop address in the NLRI, rather than in the next hop field.  I don't think it makes much sense to put the next hop address in the NLRI, as that would then require a special set of rules for bestpath selection.

On 3/8/2016 10:37 PM, li_zhenqiang@hotmail.com wrote:
Hello all,

I update my draft. 4PE is introduced in this doc to meet the gap pointed out in RFC7439. 4PE routers in IPv6-only MPLS network can use MP-BGP extended in this doc to connect IPv4-only islands.. Your comments are very appreciated.

 
Date: 2016-03-09 09:54
Subject: New Version Notification for draft-li-bess-4pe-01.txt
 
A new version of I-D, draft-li-bess-4pe-01.txt
has been successfully submitted by Zhenqiang Li and posted to the
IETF repository.
 
Name: draft-li-bess-4pe
Revision: 01
Title: Connecting IPv4 Islands over IPv6 MPLS Using IPv4 Provider Edge Routers (4PE)
Document date: 2016-03-08
Group: Individual Submission
Pages: 9
URL:            https://www.ietf.org/internet-drafts/draft-li-bess-4pe-01.txt
Status:         https://datatracker.ietf.org/doc/draft-li-bess-4pe/
Htmlized:       https://tools.ietf.org/html/draft-li-bess-4pe-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-li-bess-4pe-01
 
Abstract:
   This document explains how to interconnect IPv4 islands over a
   Multiprotocol Label Switching (MPLS)-enabled IPv6-only core.  This
   approach relies on IPv4 Provider Edge routers (4PE), which are Dual
   Stacks in order to connect to IPv4 islands and to the MPLS core.  The
   4PE routers exchange the IPv4 reachability information transparently
   over the core using the Multiprotocol Border Gateway Protocol (MP-
   BGP).  MP-BGP is extended to do this.  A new Subsequence Address
   Family Identifier (SAFI) with corresponding new format Network Layer
   Reachability Information (NLRI), is introduced.  The BGP Next Hop
   field is used to convey the IPv4 address of the 4PE router, a field
   is added in Network Layer Reachability Information (NLRI) to convey
   the IPv6 address of the 4PE router, so that dynamically established
   IPv6-signaled MPLS Label Switched Paths (LSPs) can be used without
   explicit tunnel configuration.
 
 
                                                                                 
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
The IETF Secretariat
 
 


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

--------------040908020007060402030007-- From nobody Thu Mar 10 01:25:01 2016 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 2555512D618 for ; Thu, 10 Mar 2016 01:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 NF9vqdQ9xw3t for ; Thu, 10 Mar 2016 01:24:57 -0800 (PST) Received: from BLU004-OMC1S17.hotmail.com (blu004-omc1s17.hotmail.com [65.55.116.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E98012D5E9 for ; Thu, 10 Mar 2016 01:24:49 -0800 (PST) Received: from BLU436-SMTP137 ([65.55.116.7]) by BLU004-OMC1S17.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 10 Mar 2016 01:24:48 -0800 X-TMN: [THYcpP9XWFNqtlQQ4Gclwel/9Y5M6wMoS3Vbrq5Z+Ak=] X-Originating-Email: [li_zhenqiang@hotmail.com] Message-ID: Date: Thu, 10 Mar 2016 17:32:10 +0800 From: "li_zhenqiang@hotmail.com" To: "Eric C Rosen" , bess References: , <56E044DB.4090302@juniper.net> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 26[cn] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_001_NextPart517217812154_=----" X-OriginalArrivalTime: 10 Mar 2016 09:24:47.0438 (UTC) FILETIME=[B07DAEE0:01D17AAE] Archived-At: Subject: Re: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2016 09:25:00 -0000 ------=_001_NextPart517217812154_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBjb21tZW50cywgRXJpYy4NCg0KWWVzLCBSRkM1 NTQ5IGRvZXMgc3BlY2lmeSB0aGUgIHByb2NlZHVyZXMgZm9yIGNyZWF0aW5nIGEgcm91dGUgd2l0 aCBJUHY0IG9yIFZQTi1JUHY0IE5MUkkgYW5kIGFuIElQdjYgbmV4dCBob3AuIElQdjQgTkxSSSB3 aXRoIElQdjYgbmV4dCBob3AgaXMgZm9yIHRoZSBzaXR1YXRpb24gd2hlcmUgYW4gSVB2Ni1vbmx5 IG5ldHdvcmsgY29ubmV0aW5nIElQdjQtb25seSBpc2xhbmRzLiBWUE4tSVB2NCBOTFJJIHdpdGgg SVB2NiBuZXh0IGhvcCBpcyBmb3IgdGhlIDR2UEUgc2l0dWF0aW9uLg0KDQpXaGF0IEkgd2FudCB0 byBzb2x2ZSBpcyB0aGUgNFBFIHNpdHVhdGlvbiwgd2hlcmUgYW4gSVB2Ni1vbmx5IG5ldHdvcmsg cnVubmluZyB3aXRoIE1QTFMgY29ubmVjdGluZyB0aGUgSVB2NC1vbmx5IGlzbGFuZHMuIFRoZSBy b3V0ZXMgaW4gdGhlIDRQRSBOTFJJIGhhdmUgbGFiZWxzIGFzc2lnbmVkIGJ5IHRoZSA0UEUgcm91 dGVycy4NCg0KQmVzaWRlcywgNFBFIHJvdXRlcnMgbmVlZCBib3RoIElQdjQgbmV4dCBob3AgYW5k IElQdjYgbmV4dCBob3AgdG8gYnVpbGQgdGhlaXIgSVB2NCByb3V0aW5nIHRhYmxlIGFuZCBJUHY2 IHJvdXRpbmcgdGFibGUgcmVzcGVjdGl2ZWx5Lg0KDQoNCg0KbGlfemhlbnFpYW5nQGhvdG1haWwu Y29tDQogDQpGcm9tOiBFcmljIEMgUm9zZW4NCkRhdGU6IDIwMTYtMDMtMDkgMjM6NDQNClRvOiBs aV96aGVucWlhbmdAaG90bWFpbC5jb207IGJlc3MNClN1YmplY3Q6IFJlOiBbYmVzc10gRnc6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktYmVzcy00cGUtMDEudHh0DQpJIHRo aW5rIHRoaXMgcHJvYmxlbSBpcyBhbHJlYWR5IHNvbHZlZCBpbiBSRkMgNTU0OS4NCg0KUkZDIDU1 NDkgc3BlY2lmaWVzIHRoZSBwcm9jZWR1cmVzIGZvciBjcmVhdGluZyBhIHJvdXRlIHdpdGggSVB2 NCBvciBWUE4tSVB2NCBOTFJJIGFuZCBhbiBJUHY2IG5leHQgaG9wLCB3aGljaCBzaG91bGQgcHJv dmlkZSBib3RoIDRQRSBhbmQgNHZQRSBmdW5jdGlvbmFsaXR5LiAgDQoNCllvdXIgcHJvcG9zYWwg c2VlbXMgdG8gZGlmZmVyLCBpbiB0aGF0IGl0IHB1dHMgdGhlIHY2IG5leHQgaG9wIGFkZHJlc3Mg aW4gdGhlIE5MUkksIHJhdGhlciB0aGFuIGluIHRoZSBuZXh0IGhvcCBmaWVsZC4gIEkgZG9uJ3Qg dGhpbmsgaXQgbWFrZXMgbXVjaCBzZW5zZSB0byBwdXQgdGhlIG5leHQgaG9wIGFkZHJlc3MgaW4g dGhlIE5MUkksIGFzIHRoYXQgd291bGQgdGhlbiByZXF1aXJlIGEgc3BlY2lhbCBzZXQgb2YgcnVs ZXMgZm9yIGJlc3RwYXRoIHNlbGVjdGlvbi4NCg0KT24gMy84LzIwMTYgMTA6MzcgUE0sIGxpX3po ZW5xaWFuZ0Bob3RtYWlsLmNvbSB3cm90ZToNCkhlbGxvIGFsbCwNCg0KSSB1cGRhdGUgbXkgZHJh ZnQuIDRQRSBpcyBpbnRyb2R1Y2VkIGluIHRoaXMgZG9jIHRvIG1lZXQgdGhlIGdhcCBwb2ludGVk IG91dCBpbiBSRkM3NDM5LiA0UEUgcm91dGVycyBpbiBJUHY2LW9ubHkgTVBMUyBuZXR3b3JrIGNh biB1c2UgTVAtQkdQIGV4dGVuZGVkIGluIHRoaXMgZG9jIHRvIGNvbm5lY3QgSVB2NC1vbmx5IGlz bGFuZHMuLiBZb3VyIGNvbW1lbnRzIGFyZSB2ZXJ5IGFwcHJlY2lhdGVkLg0KDQoNCg0KbGlfemhl bnFpYW5nQGhvdG1haWwuY29tDQogDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHMNCkRhdGU6IDIwMTYt MDMtMDkgMDk6NTQNClRvOiBaaGVucWlhbmcgTGkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtbGktYmVzcy00cGUtMDEudHh0DQogDQpBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtbGktYmVzcy00cGUtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IFpoZW5xaWFuZyBMaSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5 Lg0KIA0KTmFtZTogZHJhZnQtbGktYmVzcy00cGUNClJldmlzaW9uOiAwMQ0KVGl0bGU6IENvbm5l Y3RpbmcgSVB2NCBJc2xhbmRzIG92ZXIgSVB2NiBNUExTIFVzaW5nIElQdjQgUHJvdmlkZXIgRWRn ZSBSb3V0ZXJzICg0UEUpDQpEb2N1bWVudCBkYXRlOiAyMDE2LTAzLTA4DQpHcm91cDogSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogOQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saS1iZXNzLTRwZS0wMS50eHQNClN0YXR1czog ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saS1iZXNzLTRw ZS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGkt YmVzcy00cGUtMDENCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtbGktYmVzcy00cGUtMDENCiANCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVu dCBleHBsYWlucyBob3cgdG8gaW50ZXJjb25uZWN0IElQdjQgaXNsYW5kcyBvdmVyIGENCiAgIE11 bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChNUExTKS1lbmFibGVkIElQdjYtb25seSBjb3Jl LiAgVGhpcw0KICAgYXBwcm9hY2ggcmVsaWVzIG9uIElQdjQgUHJvdmlkZXIgRWRnZSByb3V0ZXJz ICg0UEUpLCB3aGljaCBhcmUgRHVhbA0KICAgU3RhY2tzIGluIG9yZGVyIHRvIGNvbm5lY3QgdG8g SVB2NCBpc2xhbmRzIGFuZCB0byB0aGUgTVBMUyBjb3JlLiAgVGhlDQogICA0UEUgcm91dGVycyBl eGNoYW5nZSB0aGUgSVB2NCByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24gdHJhbnNwYXJlbnRseQ0K ICAgb3ZlciB0aGUgY29yZSB1c2luZyB0aGUgTXVsdGlwcm90b2NvbCBCb3JkZXIgR2F0ZXdheSBQ cm90b2NvbCAoTVAtDQogICBCR1ApLiAgTVAtQkdQIGlzIGV4dGVuZGVkIHRvIGRvIHRoaXMuICBB IG5ldyBTdWJzZXF1ZW5jZSBBZGRyZXNzDQogICBGYW1pbHkgSWRlbnRpZmllciAoU0FGSSkgd2l0 aCBjb3JyZXNwb25kaW5nIG5ldyBmb3JtYXQgTmV0d29yayBMYXllcg0KICAgUmVhY2hhYmlsaXR5 IEluZm9ybWF0aW9uIChOTFJJKSwgaXMgaW50cm9kdWNlZC4gIFRoZSBCR1AgTmV4dCBIb3ANCiAg IGZpZWxkIGlzIHVzZWQgdG8gY29udmV5IHRoZSBJUHY0IGFkZHJlc3Mgb2YgdGhlIDRQRSByb3V0 ZXIsIGEgZmllbGQNCiAgIGlzIGFkZGVkIGluIE5ldHdvcmsgTGF5ZXIgUmVhY2hhYmlsaXR5IElu Zm9ybWF0aW9uIChOTFJJKSB0byBjb252ZXkNCiAgIHRoZSBJUHY2IGFkZHJlc3Mgb2YgdGhlIDRQ RSByb3V0ZXIsIHNvIHRoYXQgZHluYW1pY2FsbHkgZXN0YWJsaXNoZWQNCiAgIElQdjYtc2lnbmFs ZWQgTVBMUyBMYWJlbCBTd2l0Y2hlZCBQYXRocyAoTFNQcykgY2FuIGJlIHVzZWQgd2l0aG91dA0K ICAgZXhwbGljaXQgdHVubmVsIGNvbmZpZ3VyYXRpb24uDQogDQogDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQogDQogDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KIA0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCiANCiANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpCRVNTIG1haWxpbmcgbGlzdApCRVNTQGlldGYub3JnCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVzcwoNCg== ------=_001_NextPart517217812154_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A =0A =0A
Thank you very much for your comments, E= ric.

Yes, RFC5549 does specify the &nbs= p;procedures for creating a route with IPv4 or VPN-IPv4 NLRI a= nd an IPv6 next hop. IPv4 NLRI with IPv6 next hop is for the situation whe= re an IPv6-only network conneting IPv4-only islands. VPN-IPv4 NLRI with IP= v6 next hop is for the 4vPE situation.

Wha= t I want to solve is the 4PE situation, where an IPv6-only network running= with MPLS connecting the IPv4-only islands. The routes in the 4PE NLRI ha= ve labels assigned by the 4PE routers.

Besides, 4= PE routers need both IPv4 next hop and IPv6 next hop to build their IPv4 r= outing table and IPv6 routing table respectively.
=0A

<= hr style=3D"width: 210px; height: 1px;" color=3D"#b5c4df" size=3D"1" align= =3D"left">=0A
li_zhenqiang@hotmail.com
=0A=
 
Date:&= nbsp;2016-03-09 23:44
Subject: Re: [bess] Fw: New Ver= sion Notification for draft-li-bess-4pe-01.txt
=0A =0A =0A =0A =0A I think = this problem is already solved in RFC 5549.
=0A
=0A RFC 5549 = specifies the procedures for creating a route with IPv4 or=0A VPN-IPv4 = NLRI and an IPv6 next hop, which should provide both 4PE=0A and 4vPE fu= nctionality. 
=0A
=0A Your proposal seems to differ, in= that it puts the v6 next hop=0A address in the NLRI, rather than in th= e next hop field.  I don't=0A think it makes much sense to put the= next hop address in the NLRI,=0A as that would then require a special = set of rules for bestpath=0A selection.
=0A
=0A
On 3/8/2016 10:37 PM,=0A li_zhenqiang@hotma= il.com wrote:
=0A
=0A
=0A =0A =0A <= div>Hello all,
=0A

=0A
=0A =
I update my draft. 4PE is introduced in this doc to meet the=0A = gap pointed out in RFC7439. 4PE router= s=0A in IPv6-only MPLS network can u= se=0A MP-BGP extended in this doc to= connect IPv4-only islands.. Your=0A comments are very appreciate= d.
=0A

=0A
=0A
=0A = =0A =0A =
=0A
From:<= /b> internet-drafts
=0A
Date: 2016-03= -09 09:54
=0A = =0A
Subject: New Version Notification for=0A = draft-li-bess-4pe-01.txt
=0A
=0A =0A
=0A
 
=0A
A new = version of I-D, draft-li-bess-4pe-01.txt
=0A
has been s= uccessfully submitted by Zhenqiang Li and=0A posted to the=0A
IETF repository.
=0A
 
=0A=
Name: draft-li-bess-4pe
=0A
Revision: 01=
=0A
Title: Connecting IPv4 Islands over IPv6 MPLS Usin= g IPv4=0A Provider Edge Routers (4PE)
=0A
Do= cument date: 2016-03-08
=0A
Group: Individual Submissio= n
=0A
Pages: 9
=0A =0A =0A =0A =0A
 
=0A
Abst= ract:
=0A
   This document explains how to in= terconnect IPv4=0A islands over a
=0A
 =   Multiprotocol Label Switching (MPLS)-enabled IPv6-only=0A = core.  This
=0A
   approach relies on = IPv4 Provider Edge routers (4PE),=0A which are Dual
=0A =
   Stacks in order to connect to IPv4 islands and to= the=0A MPLS core.  The
=0A
  = ; 4PE routers exchange the IPv4 reachability information=0A tra= nsparently
=0A
   over the core using the Mul= tiprotocol Border Gateway=0A Protocol (MP-
=0A    BGP).  MP-BGP is extended to do this.  A new=0A = Subsequence Address
=0A
   Family = Identifier (SAFI) with corresponding new format=0A Network Laye= r
=0A
   Reachability Information (NLRI), is = introduced.  The=0A BGP Next Hop
=0A
&n= bsp;  field is used to convey the IPv4 address of the 4PE=0A = router, a field
=0A
   is added in Network= Layer Reachability Information=0A (NLRI) to convey
=0A =
   the IPv6 address of the 4PE router, so that=0A = dynamically established
=0A
   IPv6-= signaled MPLS Label Switched Paths (LSPs) can be=0A used withou= t
=0A
   explicit tunnel configuration.
= =0A
 
=0A
 
=0A <= div>           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;       =0A
=0A =
 
=0A
 
=0A
Pleas= e note that it may take a couple of minutes from the=0A time of= submission
=0A
until the htmlized version and diff are= available at=0A tools.ietf.org.
=0A
 <= /div>=0A
The IETF Secretariat
=0A
 <= /div>=0A
 
=0A
=0A
= =0A
=0A
= =0A
=0A 
_____________________________________=
__________=0ABESS mailing list=0ABESS@ietf.org=0Ahttps://www.ie=
tf.org/mailman/listinfo/bess=0A
=0A =0A
= =0A =0A
=0A ------=_001_NextPart517217812154_=------ From nobody Thu Mar 10 06:19:01 2016 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 C004712D7A4 for ; Thu, 10 Mar 2016 06:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia8PjJFGSyRF for ; Thu, 10 Mar 2016 06:18:57 -0800 (PST) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFCC212D9E0 for ; Thu, 10 Mar 2016 06:11:35 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 56A671811E4 for ; Thu, 10 Mar 2016 15:11:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 31CDB1A006F for ; Thu, 10 Mar 2016 15:11:34 +0100 (CET) Received: from [172.31.0.202] (10.168.234.1) by OPEXCLILMA2.corporate.adroot.infra.ftgroup (10.114.31.69) with Microsoft SMTP Server (TLS) id 14.3.279.2; Thu, 10 Mar 2016 15:11:34 +0100 To: References: <56CB3E3E.6080602@alcatel-lucent.com> <56DD759E.1090803@alcatel-lucent.com> From: Organization: Orange Message-ID: <10321_1457619094_56E18096_10321_493_3_56E18095.9000805@orange.com> Date: Thu, 10 Mar 2016 15:11:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56DD759E.1090803@alcatel-lucent.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.168.234.1] Archived-At: Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2016 14:19:00 -0000 FYI, the disclosure has been made March 8th: https://datatracker.ietf.org/ipr/2765/ -Thomas Le 07/03/2016 13:35, Martin Vigoureux a écrit : > Hello Dhananjaya, > thanks for the notice. > > WG, > I'll let this poll run for at least a week after the disclosure is made. > For those who have already stated their position please do not > hesitate to communicate a revised position, if desired, in light of > this upcoming IPR disclosure. > > For the rest, please do comment on the list, as I'd like to read more > comments/opinions from non-authors. > > Martin > > Le 07/03/2016 10:05, EXT Dhananjaya Rao (dhrao) a écrit : >> >> Hello Martin, WG, >> >> It came to our notice recently that there was an old IPR filing on an >> earlier related draft that had not been submitted to the IETF. An IPR >> statement has now been submitted and is in progress. This was an >> inadvertent oversight, and we apologize for the late disclosure. >> >> Regards, >> -Dhananjaya >> >> >> >> On 2/22/16, 8:58 AM, "BESS on behalf of Martin Vigoureux" >> wrote: >> >>> Hello working group, >>> >>> This email starts a two-week poll on adopting >>> draft-fm-bess-service-chaining-02 [1] as a working group Document. >>> >>> Please state on the list if you support adoption or not (in both cases, >>> please also state the reasons). >>> >>> This poll runs until *the 7th of March*. >>> >>> Note that IPR has been disclosed against an earlier version of this >>> document: >>> https://datatracker.ietf.org/ipr/2284/ >>> >>> Yet, we are *coincidentally* also polling for knowledge of any other >>> IPR that applies to this draft, to ensure that IPR has been disclosed >>> in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >>> and 5378 for more details). >>> >>> ==> *If* you are listed as a document author or contributor please >>> respond to this email and indicate whether or not you are aware of any >>> relevant IPR. >>> >>> The draft will not be adopted until a response has been received from >>> each author and contributor. >>> >>> If you are not listed as an author or contributor, then please >>> explicitly respond only if you are aware of any IPR that has not yet >>> been disclosed in conformance with IETF rules. >>> >>> Thank you, >>> >>> Martin & Thomas >>> bess chairs >>> >>> [1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ >>> >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >> >> >> > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Thu Mar 10 06:19:05 2016 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 D41BE12D956 for ; Thu, 10 Mar 2016 06:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAK9GOyFkioc for ; Thu, 10 Mar 2016 06:19:02 -0800 (PST) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id CDFC912D883 for ; Thu, 10 Mar 2016 06:11:40 -0800 (PST) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 21AAC41024E for ; Thu, 10 Mar 2016 15:11:40 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id BED7B41024C for ; Thu, 10 Mar 2016 15:11:39 +0100 (CET) Received: from [172.31.0.202] (10.193.116.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Thu, 10 Mar 2016 15:11:39 +0100 To: References: <56CB3E3E.6080602@alcatel-lucent.com> <56DD759E.1090803@alcatel-lucent.com> From: Thomas Morin Organization: Orange Message-ID: <56E1809A.5010604@orange.com> Date: Thu, 10 Mar 2016 15:11:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56DD759E.1090803@alcatel-lucent.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2016 14:19:04 -0000 FYI, the disclosure has been made March 8th: https://datatracker.ietf.org/ipr/2765/ -Thomas Le 07/03/2016 13:35, Martin Vigoureux a écrit : > Hello Dhananjaya, > thanks for the notice. > > WG, > I'll let this poll run for at least a week after the disclosure is made. > For those who have already stated their position please do not > hesitate to communicate a revised position, if desired, in light of > this upcoming IPR disclosure. > > For the rest, please do comment on the list, as I'd like to read more > comments/opinions from non-authors. > > Martin > > Le 07/03/2016 10:05, EXT Dhananjaya Rao (dhrao) a écrit : >> >> Hello Martin, WG, >> >> It came to our notice recently that there was an old IPR filing on an >> earlier related draft that had not been submitted to the IETF. An IPR >> statement has now been submitted and is in progress. This was an >> inadvertent oversight, and we apologize for the late disclosure. >> >> Regards, >> -Dhananjaya >> >> >> >> On 2/22/16, 8:58 AM, "BESS on behalf of Martin Vigoureux" >> wrote: >> >>> Hello working group, >>> >>> This email starts a two-week poll on adopting >>> draft-fm-bess-service-chaining-02 [1] as a working group Document. >>> >>> Please state on the list if you support adoption or not (in both cases, >>> please also state the reasons). >>> >>> This poll runs until *the 7th of March*. >>> >>> Note that IPR has been disclosed against an earlier version of this >>> document: >>> https://datatracker.ietf.org/ipr/2284/ >>> >>> Yet, we are *coincidentally* also polling for knowledge of any other >>> IPR that applies to this draft, to ensure that IPR has been disclosed >>> in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >>> and 5378 for more details). >>> >>> ==> *If* you are listed as a document author or contributor please >>> respond to this email and indicate whether or not you are aware of any >>> relevant IPR. >>> >>> The draft will not be adopted until a response has been received from >>> each author and contributor. >>> >>> If you are not listed as an author or contributor, then please >>> explicitly respond only if you are aware of any IPR that has not yet >>> been disclosed in conformance with IETF rules. >>> >>> Thank you, >>> >>> Martin & Thomas >>> bess chairs >>> >>> [1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ >>> >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >> >> >> > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Thu Mar 10 07:34:23 2016 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 0E92A12D85C; Thu, 10 Mar 2016 07:34:23 -0800 (PST) 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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuyNxu5y3RhL; Thu, 10 Mar 2016 07:34:21 -0800 (PST) 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 D1CB212D859; Thu, 10 Mar 2016 07:34:18 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:878:8d58:e839:3ee4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u2AFY5LQ025270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Mar 2016 15:34:05 GMT (envelope-from joelja@bogus.com) To: "Alvaro Retana (aretana)" References: <20160228163705.24380.24145.idtracker@ietfa.amsl.com> From: joel jaeggli Message-ID: Date: Thu, 10 Mar 2016 07:34:03 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aOAWFMU9JJHV1iQexfIF2cCJqNJEhcvhS" Archived-At: Cc: "draft-ietf-bess-mvpn-extranet@ietf.org" , "bess@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , Eric C Rosen , The IESG Subject: Re: [bess] Joel Jaeggli's Discuss on draft-ietf-bess-mvpn-extranet-06: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2016 15:34:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aOAWFMU9JJHV1iQexfIF2cCJqNJEhcvhS Content-Type: multipart/mixed; boundary="O2o1jMC3JRKcI8SoiSxEIBvLowedP9Hur" From: joel jaeggli To: "Alvaro Retana (aretana)" Cc: "draft-ietf-bess-mvpn-extranet@ietf.org" , "bess@ietf.org" , "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , Eric C Rosen , The IESG Message-ID: Subject: Re: Joel Jaeggli's Discuss on draft-ietf-bess-mvpn-extranet-06: (with DISCUSS and COMMENT) References: <20160228163705.24380.24145.idtracker@ietfa.amsl.com> In-Reply-To: --O2o1jMC3JRKcI8SoiSxEIBvLowedP9Hur Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/1/16 2:43 PM, Alvaro Retana (aretana) wrote: > On 2/28/16, 5:37 PM, "Joel Jaeggli" wrote: >=20 > Joel: >=20 > Hi! How are you? good > ... >> ----------------------------------------------------------------------= >> >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> After further discussion related to the ops dir review, I'm going to h= ave >> to echo Benoit and the Opsdir reviewers concern. >=20 > I have to say that, as Eric, I am at a loss as to what specifically > you want to see in the document. Please see my comments below > related to the OpsDir review text. >=20 >=20 >> ----------------------------------------------------------------------= >> >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> Sue Hares performed the opsdir review. benoit holds the discuss for th= e >> points she raised. >>=20 >> Status: Not ready, three major concerns and two editorial nits: >>=20 >> Major concerns: >>=20 >> 1) Specification of the Extranet Source Extended Community and >> Extra Source extended Community >=20 > I think the authors took care of this already by making sure that > 4.4 includes the text that Sue had proposed [1]. >=20 > ... >> 2) Why is there no Deployment considerations section? >=20 > This seems to be the sticking point. What exactly are you looking > for? I think the question comes down to, is this document adequately proscriptive when it comes to implementation in a network. This question might be easier to discuss cogently if in fact the document were easier to read. It is not, so you find your CO-ADs relying on the reviews of domain experts, and previous discussion on the list. I have implmented mvpns, I am not a protocol developer. > Please take a look at Sections 1.2. (Scope) and 1.3. (Clarification > on Use of Route Distinguishers) -- these are maybe not the best named > sections, but in them the authors lay out when this spec is useful: > SSM and ASM deployments (not Dense mode), calls out potential > problems with BSR, applicable to both PIM and BGP signaling, > justified the use of a unique VRF per RD. unique RD per VRF, yes it discusses this, then brings in the extranet RD leakage. calling this spongy is maybe an understatement. > Section 1.4. (Overview) gives some examples of potential deployments=20 > ("only some of its multicast C-sources be treated as extranet > C-sources", or "some of its extranet C-sources can transmit only to a > certain set of VPNs"), and it talks about the need for the SP to > coordinate with the customer during the provisioning process. >=20 > It seems to me that there's already a pretty good summary in those=20 > sections, but they are not called "operational considerations"=8A What= > is missing? Do you want the above to be in a specific titled > section, or maybe there are other details you'd like to see -- if so, > what are they? It's also not a summary. You see to be asking us to write the words. I don't intend to take up the pen on the document nor should we be expected to. I'd reference Sue's message from 12/22 to the working group accordingly >=20 > 2) On the deployment section: I given text and examples =96 but I > think you still misunderstand what I am looking for. >=20 > Since you are an author of academic papers, consider I am looking > for an operator-based =93abstract=94 that focuses the reader on the key= > points. I am sure you can create one for this document, but I not > clear why you object to it the concept. >=20 > The =93security consideration =94 in section 10 in the text use > =93security consideration=94 as a euphemism for the traffic being sent = to > the wrong place. This is deployment and security issue =96 not just a > security consideration. The third paragraph of your text in section > 10 starting with =93In general, different VPNs are allowed to have > overlapping IP address=94 needs to clearly state what you stated to me > in this last email. (see the text below). >=20 > To limit the email back-forth, will you please let me know that you > have read my suggested text insertions on both these topics. I will > email Benoit/Joel offline regarding #2 deployment to see if he > believes it is not a DISCUSS criteria. >=20 > Cheerily, >=20 > Sue I'm not actually married to any particular structure which conveys this information. just that there is one. the result of that should be that as an implmentor of the extranet vpn you can also read this document. >=20 > A couple of days ago you raised a specific point [2]: >=20 > "... there is eleborate discussion of the requirement for one RD per > VRF and then extranet seperation adds a twist that. >=20 > However, when Extranet Separation is used, some of the local-RD > routes exported from the VRF will contain the extranet RD. Details > concerning the exported routes that contain the extranet RD can be > found in Sections 4.1 and 7.3. " >=20 > It sounds like you may want more clarity/details on parts of that. > What? >=20 >=20 >=20 > ... >> 3) Is security section really a security section? It seems >> more like =B3do this policy=B2 or this will fail. It should get a >> stronger review from the security directorate >=20 > I am in fact not able to find a SecDir review. However, the SEC AD > did put a DISCUSS on this document [3] and later cleared it [4] based > on added text. >=20 > Are there specific security concerns? >=20 > Thanks! >=20 > Alvaro. >=20 >=20 >=20 > [1] > https://mailarchive.ietf.org/arch/msg/bess/h3H9joH90g2B1XplYi_H9QJaf6k > >=20 [2] https://mailarchive.ietf.org/arch/msg/bess/Gg4e8CvN5TpvhqmvUOCB4vRvlu= g > [3] > https://mailarchive.ietf.org/arch/msg/bess/DBdwMh2Z3WE80NJxhA5qDsmlQwI > >=20 [4] https://mailarchive.ietf.org/arch/msg/bess/sjxLrpyGCCarO86xd5n617Q3fI= k >=20 >=20 --O2o1jMC3JRKcI8SoiSxEIBvLowedP9Hur-- --aOAWFMU9JJHV1iQexfIF2cCJqNJEhcvhS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbhk+wACgkQ8AA1q7Z/VrL6GQCfeJXpZd+cs/B95c4CQ6cpW+/A n6AAn3H5WT3nptuVFvnmAVZG1DMR1fYJ =036X -----END PGP SIGNATURE----- --aOAWFMU9JJHV1iQexfIF2cCJqNJEhcvhS-- From nobody Fri Mar 11 00:18:59 2016 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 81E5E12D570 for ; Fri, 11 Mar 2016 00:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQRIAkXsnLcy for ; Fri, 11 Mar 2016 00:18:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5087B12D56E for ; Fri, 11 Mar 2016 00:18:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKJ00980; Fri, 11 Mar 2016 08:18:50 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Mar 2016 08:18:49 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.102]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Fri, 11 Mar 2016 16:18:44 +0800 From: Zhuangshunwan To: "li_zhenqiang@hotmail.com" , Eric C Rosen , bess Thread-Topic: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt Thread-Index: AQHReq7DU7+os4ku8Ua1EW30yW77I59T5WAw Date: Fri, 11 Mar 2016 08:18:44 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858AA19D9CA@NKGEML515-MBS.china.huawei.com> References: , <56E044DB.4090302@juniper.net> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.254] Content-Type: multipart/alternative; boundary="_000_19AB2A007F56DB4E8257F949A2FB9858AA19D9CANKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56E27F6A.01A6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8e487097d99a1a153823c2340377a532 Archived-At: Subject: Re: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2016 08:18:57 -0000 --_000_19AB2A007F56DB4E8257F949A2FB9858AA19D9CANKGEML515MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHJlYWQgdGhpcyBkb2N1bWVudCwgYW5kIEkgdGhpbmsgdGhhdCBpdCBpcyBhIHVzZWZ1 bCBzb2x1dGlvbiB0byBjb25uZWN0IHRoZSBJUHY0LW9ubHkgaXNsYW5kcyBhY3Jvc3MgdGhlIElQ djYtb25seSBuZXR3b3JrIHJ1bm5pbmcgd2l0aCBNUExTLg0KDQpSZWdhcmRzLA0KU2h1bndhbg0K DQrlj5Hku7bkuro6IEJFU1MgW21haWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBs aV96aGVucWlhbmdAaG90bWFpbC5jb20NCuWPkemAgeaXtumXtDogMjAxNuW5tDPmnIgxMOaXpSAx NzozMg0K5pS25Lu25Lq6OiBFcmljIEMgUm9zZW47IGJlc3MNCuS4u+mimDogUmU6IFtiZXNzXSBG dzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1iZXNzLTRwZS0wMS50eHQN Cg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBjb21tZW50cywgRXJpYy4NCg0KWWVzLCBS RkM1NTQ5IGRvZXMgc3BlY2lmeSB0aGUgIHByb2NlZHVyZXMgZm9yIGNyZWF0aW5nIGEgcm91dGUg d2l0aCBJUHY0IG9yIFZQTi1JUHY0IE5MUkkgYW5kIGFuIElQdjYgbmV4dCBob3AuIElQdjQgTkxS SSB3aXRoIElQdjYgbmV4dCBob3AgaXMgZm9yIHRoZSBzaXR1YXRpb24gd2hlcmUgYW4gSVB2Ni1v bmx5IG5ldHdvcmsgY29ubmV0aW5nIElQdjQtb25seSBpc2xhbmRzLiBWUE4tSVB2NCBOTFJJIHdp dGggSVB2NiBuZXh0IGhvcCBpcyBmb3IgdGhlIDR2UEUgc2l0dWF0aW9uLg0KDQpXaGF0IEkgd2Fu dCB0byBzb2x2ZSBpcyB0aGUgNFBFIHNpdHVhdGlvbiwgd2hlcmUgYW4gSVB2Ni1vbmx5IG5ldHdv cmsgcnVubmluZyB3aXRoIE1QTFMgY29ubmVjdGluZyB0aGUgSVB2NC1vbmx5IGlzbGFuZHMuIFRo ZSByb3V0ZXMgaW4gdGhlIDRQRSBOTFJJIGhhdmUgbGFiZWxzIGFzc2lnbmVkIGJ5IHRoZSA0UEUg cm91dGVycy4NCg0KQmVzaWRlcywgNFBFIHJvdXRlcnMgbmVlZCBib3RoIElQdjQgbmV4dCBob3Ag YW5kIElQdjYgbmV4dCBob3AgdG8gYnVpbGQgdGhlaXIgSVB2NCByb3V0aW5nIHRhYmxlIGFuZCBJ UHY2IHJvdXRpbmcgdGFibGUgcmVzcGVjdGl2ZWx5Lg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbGlfemhlbnFpYW5nQGhvdG1haWwuY29tPG1haWx0bzpsaV96aGVucWlhbmdA aG90bWFpbC5jb20+DQoNCkZyb206IEVyaWMgQyBSb3NlbjxtYWlsdG86ZXJvc2VuQGp1bmlwZXIu bmV0Pg0KRGF0ZTogMjAxNi0wMy0wOSAyMzo0NA0KVG86IGxpX3poZW5xaWFuZ0Bob3RtYWlsLmNv bTxtYWlsdG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPjsgYmVzczxtYWlsdG86YmVzc0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbYmVzc10gRnc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtbGktYmVzcy00cGUtMDEudHh0DQpJIHRoaW5rIHRoaXMgcHJvYmxlbSBpcyBhbHJl YWR5IHNvbHZlZCBpbiBSRkMgNTU0OS4NCg0KUkZDIDU1NDkgc3BlY2lmaWVzIHRoZSBwcm9jZWR1 cmVzIGZvciBjcmVhdGluZyBhIHJvdXRlIHdpdGggSVB2NCBvciBWUE4tSVB2NCBOTFJJIGFuZCBh biBJUHY2IG5leHQgaG9wLCB3aGljaCBzaG91bGQgcHJvdmlkZSBib3RoIDRQRSBhbmQgNHZQRSBm dW5jdGlvbmFsaXR5Lg0KDQpZb3VyIHByb3Bvc2FsIHNlZW1zIHRvIGRpZmZlciwgaW4gdGhhdCBp dCBwdXRzIHRoZSB2NiBuZXh0IGhvcCBhZGRyZXNzIGluIHRoZSBOTFJJLCByYXRoZXIgdGhhbiBp biB0aGUgbmV4dCBob3AgZmllbGQuICBJIGRvbid0IHRoaW5rIGl0IG1ha2VzIG11Y2ggc2Vuc2Ug dG8gcHV0IHRoZSBuZXh0IGhvcCBhZGRyZXNzIGluIHRoZSBOTFJJLCBhcyB0aGF0IHdvdWxkIHRo ZW4gcmVxdWlyZSBhIHNwZWNpYWwgc2V0IG9mIHJ1bGVzIGZvciBiZXN0cGF0aCBzZWxlY3Rpb24u DQpPbiAzLzgvMjAxNiAxMDozNyBQTSwgbGlfemhlbnFpYW5nQGhvdG1haWwuY29tPG1haWx0bzps aV96aGVucWlhbmdAaG90bWFpbC5jb20+IHdyb3RlOg0KSGVsbG8gYWxsLA0KDQpJIHVwZGF0ZSBt eSBkcmFmdC4gNFBFIGlzIGludHJvZHVjZWQgaW4gdGhpcyBkb2MgdG8gbWVldCB0aGUgZ2FwIHBv aW50ZWQgb3V0IGluIFJGQzc0MzkuIDRQRSByb3V0ZXJzIGluIElQdjYtb25seSBNUExTIG5ldHdv cmsgY2FuIHVzZSBNUC1CR1AgZXh0ZW5kZWQgaW4gdGhpcyBkb2MgdG8gY29ubmVjdCBJUHY0LW9u bHkgaXNsYW5kcy4uIFlvdXIgY29tbWVudHMgYXJlIHZlcnkgYXBwcmVjaWF0ZWQuDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpsaV96aGVucWlhbmdAaG90bWFpbC5jb208bWFp bHRvOmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbT4NCg0KRnJvbTogaW50ZXJuZXQtZHJhZnRzPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpEYXRlOiAyMDE2LTAzLTA5IDA5OjU0DQpU bzogWmhlbnFpYW5nIExpPG1haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb20+DQpTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLWJlc3MtNHBlLTAxLnR4dA0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGktYmVzcy00cGUtMDEudHh0DQpoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFpoZW5xaWFuZyBMaSBhbmQgcG9zdGVkIHRvIHRo ZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC1saS1iZXNzLTRwZQ0KUmV2aXNpb246 IDAxDQpUaXRsZTogQ29ubmVjdGluZyBJUHY0IElzbGFuZHMgb3ZlciBJUHY2IE1QTFMgVXNpbmcg SVB2NCBQcm92aWRlciBFZGdlIFJvdXRlcnMgKDRQRSkNCkRvY3VtZW50IGRhdGU6IDIwMTYtMDMt MDgNCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiA5DQpVUkw6ICAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpLWJlc3MtNHBl LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWxpLWJlc3MtNHBlLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1saS1iZXNzLTRwZS0wMQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saS1iZXNzLTRwZS0wMQ0KDQpBYnN0cmFjdDoN CiAgIFRoaXMgZG9jdW1lbnQgZXhwbGFpbnMgaG93IHRvIGludGVyY29ubmVjdCBJUHY0IGlzbGFu ZHMgb3ZlciBhDQogICBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUyktZW5hYmxl ZCBJUHY2LW9ubHkgY29yZS4gIFRoaXMNCiAgIGFwcHJvYWNoIHJlbGllcyBvbiBJUHY0IFByb3Zp ZGVyIEVkZ2Ugcm91dGVycyAoNFBFKSwgd2hpY2ggYXJlIER1YWwNCiAgIFN0YWNrcyBpbiBvcmRl ciB0byBjb25uZWN0IHRvIElQdjQgaXNsYW5kcyBhbmQgdG8gdGhlIE1QTFMgY29yZS4gIFRoZQ0K ICAgNFBFIHJvdXRlcnMgZXhjaGFuZ2UgdGhlIElQdjQgcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9u IHRyYW5zcGFyZW50bHkNCiAgIG92ZXIgdGhlIGNvcmUgdXNpbmcgdGhlIE11bHRpcHJvdG9jb2wg Qm9yZGVyIEdhdGV3YXkgUHJvdG9jb2wgKE1QLQ0KICAgQkdQKS4gIE1QLUJHUCBpcyBleHRlbmRl ZCB0byBkbyB0aGlzLiAgQSBuZXcgU3Vic2VxdWVuY2UgQWRkcmVzcw0KICAgRmFtaWx5IElkZW50 aWZpZXIgKFNBRkkpIHdpdGggY29ycmVzcG9uZGluZyBuZXcgZm9ybWF0IE5ldHdvcmsgTGF5ZXIN CiAgIFJlYWNoYWJpbGl0eSBJbmZvcm1hdGlvbiAoTkxSSSksIGlzIGludHJvZHVjZWQuICBUaGUg QkdQIE5leHQgSG9wDQogICBmaWVsZCBpcyB1c2VkIHRvIGNvbnZleSB0aGUgSVB2NCBhZGRyZXNz IG9mIHRoZSA0UEUgcm91dGVyLCBhIGZpZWxkDQogICBpcyBhZGRlZCBpbiBOZXR3b3JrIExheWVy IFJlYWNoYWJpbGl0eSBJbmZvcm1hdGlvbiAoTkxSSSkgdG8gY29udmV5DQogICB0aGUgSVB2NiBh ZGRyZXNzIG9mIHRoZSA0UEUgcm91dGVyLCBzbyB0aGF0IGR5bmFtaWNhbGx5IGVzdGFibGlzaGVk DQogICBJUHY2LXNpZ25hbGVkIE1QTFMgTGFiZWwgU3dpdGNoZWQgUGF0aHMgKExTUHMpIGNhbiBi ZSB1c2VkIHdpdGhvdXQNCiAgIGV4cGxpY2l0IHR1bm5lbCBjb25maWd1cmF0aW9uLg0KDQoNCg0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpCRVNTIG1haWxpbmcgbGlzdA0KDQpCRVNTQGlldGYub3JnPG1haWx0bzpCRVNT QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3MN Cg0K --_000_19AB2A007F56DB4E8257F949A2FB9858AA19D9CANKGEML515MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlvq7ova/pm4Xpu5E7DQoJcGFub3NlLTE6MiAx MSA1IDMgMiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxA5b6u6L2v6ZuF6buRIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxh aW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH 5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuag vOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7 fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiu vuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkNoYXINCgl7bXNv LXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9 kzt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5DaGFyMA0KCXttc28tc3R5bGUtbmFtZToi57qv5paH5pysIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIHJlYWQgdGhp cyBkb2N1bWVudCwgYW5kIEkgdGhpbmsgdGhhdCBpdCBpcyBhIHVzZWZ1bCBzb2x1dGlvbiB0byBj b25uZWN0IHRoZSBJUHY0LW9ubHkgaXNsYW5kcyBhY3Jvc3MgdGhlIElQdjYtb25seSBuZXR3b3Jr IHJ1bm5pbmcgd2l0aA0KIE1QTFMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaHVu d2FuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkeS7 tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gQkVTUyBbbWFpbHRvOmJlc3MtYm91bmNlc0Bp ZXRmLm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Luj6KGo IDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5s aV96aGVucWlhbmdAaG90bWFpbC5jb208YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gMjAxNjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMi PjM8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjEwPC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVO LVVTIj4gMTc6MzI8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gRXJpYyBDIFJvc2VuOyBiZXNzPGJyPg0KPC9z cGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IFJlOiBbYmVzc10gRnc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt bGktYmVzcy00cGUtMDEudHh0PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsg eW91IHZlcnkgbXVjaCBmb3IgeW91ciBjb21tZW50cywgRXJpYy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+WWVz LCBSRkM1NTQ5IGRvZXMgc3BlY2lmeSB0aGUmbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+Jm5ic3A7cHJvY2VkdXJlcyBmb3IgY3JlYXRpbmcgYSByb3V0ZSB3aXRoIElQdjQgb3Ig VlBOLUlQdjQgTkxSSSBhbmQgYW4gSVB2NiBuZXh0IGhvcC4gSVB2NA0KIE5MUkkgd2l0aCBJUHY2 IG5leHQgaG9wIGlzIGZvciB0aGUgc2l0dWF0aW9uIHdoZXJlIGFuIElQdjYtb25seSBuZXR3b3Jr IGNvbm5ldGluZyBJUHY0LW9ubHkgaXNsYW5kcy4gVlBOLUlQdjQgTkxSSSB3aXRoIElQdjYgbmV4 dCBob3AgaXMgZm9yIHRoZSA0dlBFIHNpdHVhdGlvbi48L3NwYW4+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPldo YXQgSSB3YW50IHRvIHNvbHZlIGlzIHRoZSA0UEUgc2l0dWF0aW9uLCB3aGVyZSBhbiBJUHY2LW9u bHkgbmV0d29yayBydW5uaW5nIHdpdGggTVBMUyBjb25uZWN0aW5nIHRoZSBJUHY0LW9ubHkgaXNs YW5kcy4gVGhlIHJvdXRlcyBpbiB0aGUgNFBFIE5MUkkNCiBoYXZlIGxhYmVscyBhc3NpZ25lZCBi eSB0aGUgNFBFIHJvdXRlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJlc2lkZXMsIDRQRSByb3V0ZXJzIG5l ZWQgYm90aCBJUHY0IG5leHQgaG9wIGFuZCBJUHY2IG5leHQgaG9wIHRvIGJ1aWxkIHRoZWlyIElQ djQgcm91dGluZyB0YWJsZSBhbmQgSVB2NiByb3V0aW5nIHRhYmxlIHJlc3BlY3RpdmVseS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMjEwIiBzdHlsZT0id2lkdGg6MTU3 LjVwdCIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0I1QzRERiIgYWxpZ249ImxlZnQiPg0KPC9z cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ny41cHQ7 bWFyZ2luLXRvcDo3LjVwdDttYXJnaW4tcmlnaHQ6Ny41cHQ7bWFyZ2luLWJvdHRvbTo3LjVwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOmxpX3poZW5xaWFuZ0Bo b3RtYWlsLmNvbSI+bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t bGVmdDo2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxhIGhy ZWY9Im1haWx0bzplcm9zZW5AanVuaXBlci5uZXQiPkVyaWMNCiBDIFJvc2VuPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5EYXRlOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzIwMTYtMDMtMDkmbmJzcDsyMzo0 NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Ubzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8YSBocmVmPSJtYWls dG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29tIj5saV96aGVucWlhbmdAaG90bWFpbC5jb208L2E+ Ow0KPGEgaHJlZj0ibWFpbHRvOmJlc3NAaWV0Zi5vcmciPmJlc3M8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6I0VGRUZFRiI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPlN1YmplY3Q6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7UmU6IFtiZXNzXQ0KIEZ3OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLWJlc3MtNHBlLTAxLnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgdGhpbmsgdGhp cyBwcm9ibGVtIGlzIGFscmVhZHkgc29sdmVkIGluIFJGQyA1NTQ5Ljxicj4NCjxicj4NClJGQyA1 NTQ5IHNwZWNpZmllcyB0aGUgcHJvY2VkdXJlcyBmb3IgY3JlYXRpbmcgYSByb3V0ZSB3aXRoIElQ djQgb3IgVlBOLUlQdjQgTkxSSSBhbmQgYW4gSVB2NiBuZXh0IGhvcCwgd2hpY2ggc2hvdWxkIHBy b3ZpZGUgYm90aCA0UEUgYW5kIDR2UEUgZnVuY3Rpb25hbGl0eS4mbmJzcDsNCjxicj4NCjxicj4N CllvdXIgcHJvcG9zYWwgc2VlbXMgdG8gZGlmZmVyLCBpbiB0aGF0IGl0IHB1dHMgdGhlIHY2IG5l eHQgaG9wIGFkZHJlc3MgaW4gdGhlIE5MUkksIHJhdGhlciB0aGFuIGluIHRoZSBuZXh0IGhvcCBm aWVsZC4mbmJzcDsgSSBkb24ndCB0aGluayBpdCBtYWtlcyBtdWNoIHNlbnNlIHRvIHB1dCB0aGUg bmV4dCBob3AgYWRkcmVzcyBpbiB0aGUgTkxSSSwgYXMgdGhhdCB3b3VsZCB0aGVuIHJlcXVpcmUg YSBzcGVjaWFsIHNldCBvZiBydWxlcyBmb3IgYmVzdHBhdGgNCiBzZWxlY3Rpb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xp u5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+T24gMy84LzIwMTYg MTA6MzcgUE0sDQo8YSBocmVmPSJtYWlsdG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29tIj5saV96 aGVucWlhbmdAaG90bWFpbC5jb208L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjYuMHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5I ZWxsbyBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgdXBkYXRlIG15IGRyYWZ0LiA0UEUgaXMgaW50cm9k dWNlZCBpbiB0aGlzIGRvYyB0byBtZWV0IHRoZSBnYXAgcG9pbnRlZCBvdXQgaW4mbmJzcDtSRkM3 NDM5LiA0UEUgcm91dGVycyBpbiZuYnNwOzxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5J UHY2LW9ubHkgTVBMUw0KIG5ldHdvcmsgY2FuIHVzZSBNUC1CR1AgZXh0ZW5kZWQgaW4gdGhpcyBk b2MmbmJzcDt0byBjb25uZWN0IElQdjQtb25seSBpc2xhbmRzLi4gWW91ciBjb21tZW50cyBhcmUg dmVyeSBhcHByZWNpYXRlZC48L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMSIg d2lkdGg9IjIxMCIgc3R5bGU9IndpZHRoOjE1Ny41cHQiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9y OiNCNUM0REYiIGFsaWduPSJsZWZ0Ij4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjcuNXB0O21hcmdpbi10b3A6Ny41cHQ7bWFyZ2luLXJpZ2h0 OjcuNXB0O21hcmdpbi1ib3R0b206Ny41cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxh IGhyZWY9Im1haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb20iPmxpX3poZW5xaWFuZ0Bob3Rt YWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6Ni4wcHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u 6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDoj RUZFRkVGIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIj5pbnRlcm5ldC1kcmFmdHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRUZFRiI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRh dGU6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7MjAxNi0wMy0wOSZuYnNwOzA5OjU0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 I0VGRUZFRiI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPlRvOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpsaV96aGVucWlhbmdAaG90bWFp bC5jb20iPlpoZW5xaWFuZw0KIExpPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TdWJq ZWN0Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwO05ldyBWZXJzaW9uDQogTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1i ZXNzLTRwZS0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGktYmVzcy00cGUtMDEudHh0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mb hem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5oYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFpoZW5xaWFuZyBMaSBhbmQgcG9zdGVkIHRvIHRoZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+SUVURiByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5OYW1lOiBkcmFmdC1saS1iZXNzLTRw ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+UmV2aXNpb246IDAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaXRsZTogQ29ubmVjdGluZyBJUHY0IElzbGFuZHMgb3Zl ciBJUHY2IE1QTFMgVXNpbmcgSVB2NCBQcm92aWRlciBFZGdlIFJvdXRlcnMgKDRQRSk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRv Y3VtZW50IGRhdGU6IDIwMTYtMDMtMDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPlBhZ2VzOiA5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGktYmVzcy00cGUtMDEudHh0Ij5odHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGktYmVzcy00cGUtMDEudHh0PC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGktYmVz cy00cGUvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saS1iZXNzLTRw ZS88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN CjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1iZXNzLTRwZS0w MSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLWJlc3MtNHBlLTAxPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+RGlmZjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1saS1iZXNzLTRwZS0wMSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWxpLWJlc3MtNHBlLTAxPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BYnN0cmFjdDo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u 6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBUaGlzIGRvY3VtZW50IGV4cGxhaW5zIGhvdyB0byBpbnRlcmNvbm5lY3QgSVB2NCBp c2xhbmRzIG92ZXIgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNo aW5nIChNUExTKS1lbmFibGVkIElQdjYtb25seSBjb3JlLiZuYnNwOyBUaGlzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgYXBwcm9hY2ggcmVsaWVzIG9uIElQdjQgUHJvdmlkZXIgRWRnZSByb3V0ZXJzICg0UEUp LCB3aGljaCBhcmUgRHVhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFN0YWNrcyBpbiBvcmRlciB0byBjb25u ZWN0IHRvIElQdjQgaXNsYW5kcyBhbmQgdG8gdGhlIE1QTFMgY29yZS4mbmJzcDsgVGhlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgNFBFIHJvdXRlcnMgZXhjaGFuZ2UgdGhlIElQdjQgcmVhY2hhYmlsaXR5IGlu Zm9ybWF0aW9uIHRyYW5zcGFyZW50bHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvdmVyIHRoZSBjb3JlIHVz aW5nIHRoZSBNdWx0aXByb3RvY29sIEJvcmRlciBHYXRld2F5IFByb3RvY29sIChNUC08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBCR1ApLiZuYnNwOyBNUC1CR1AgaXMgZXh0ZW5kZWQgdG8gZG8gdGhpcy4mbmJz cDsgQSBuZXcgU3Vic2VxdWVuY2UgQWRkcmVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEZhbWlseSBJZGVu dGlmaWVyIChTQUZJKSB3aXRoIGNvcnJlc3BvbmRpbmcgbmV3IGZvcm1hdCBOZXR3b3JrIExheWVy PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgUmVhY2hhYmlsaXR5IEluZm9ybWF0aW9uIChOTFJJKSwgaXMgaW50 cm9kdWNlZC4mbmJzcDsgVGhlIEJHUCBOZXh0IEhvcDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGZpZWxkIGlz IHVzZWQgdG8gY29udmV5IHRoZSBJUHY0IGFkZHJlc3Mgb2YgdGhlIDRQRSByb3V0ZXIsIGEgZmll bGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBpcyBhZGRlZCBpbiBOZXR3b3JrIExheWVyIFJlYWNoYWJpbGl0 eSBJbmZvcm1hdGlvbiAoTkxSSSkgdG8gY29udmV5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhlIElQdjYg YWRkcmVzcyBvZiB0aGUgNFBFIHJvdXRlciwgc28gdGhhdCBkeW5hbWljYWxseSBlc3RhYmxpc2hl ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IElQdjYtc2lnbmFsZWQgTVBMUyBMYWJlbCBTd2l0Y2hlZCBQYXRo cyAoTFNQcykgY2FuIGJlIHVzZWQgd2l0aG91dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGV4cGxpY2l0IHR1 bm5lbCBjb25maWd1cmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlIElFVEYgU2VjcmV0 YXJpYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5CRVNTIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBo cmVmPSJtYWlsdG86QkVTU0BpZXRmLm9yZyI+QkVTU0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZXNzIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3M8L2E+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_19AB2A007F56DB4E8257F949A2FB9858AA19D9CANKGEML515MBSchi_-- From nobody Fri Mar 11 15:07:29 2016 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 2E7C112DE57; Fri, 11 Mar 2016 15:05:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230540.15028.13476.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:40 -0800 Archived-At: Cc: aretana@cisco.com, bess@ietf.org Subject: [bess] bess - Requested session has been scheduled for IETF 95 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:40 -0000 Dear Martin Vigoureux, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. bess Session 1 (2:00:00) Thursday, Afternoon Session I 1400-1600 Room Name: Atlantico C size: 225 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: BGP Enabled Services Area Name: Routing Area Session Requester: Martin Vigoureux Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: rtgwg idr pals sfc sidr l3sm Second Priority: mpls spring pim nvo3 bier Third Priority: i2rs Special Requests: --------------------------------------------------------- From nobody Sat Mar 12 01:00:56 2016 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 8546712D55D for ; Sat, 12 Mar 2016 01:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNhI83Nzke7b for ; Sat, 12 Mar 2016 01:00:53 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 6595712D51F for ; Sat, 12 Mar 2016 01:00:53 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 5567CFD9863CD for ; Sat, 12 Mar 2016 09:00:49 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2C90px9019351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 12 Mar 2016 09:00:51 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u2C90o0f024753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 12 Mar 2016 10:00:51 +0100 Received: from [135.224.200.1] (135.239.27.40) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 12 Mar 2016 10:00:49 +0100 Message-ID: <56E3DAC1.3020205@alcatel-lucent.com> Date: Sat, 12 Mar 2016 10:00:49 +0100 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <56DD71AE.9030104@alcatel-lucent.com> In-Reply-To: <56DD71AE.9030104@alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.40] Archived-At: Subject: [bess] Slots requests for BESS WG session - IETF 95 - Buenos Aires X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 12 Mar 2016 09:00:55 -0000 All, the scheduling of our session has been confirmed Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time) Please send your requests for slots if you still have some. Thanks -m Le 07/03/2016 13:18, EXT Martin Vigoureux a écrit : > All, > > it is time we start building the BESS WG agenda for Buenos Aires. > The IETF agenda is available at: > https://datatracker.ietf.org/meeting/95/agenda.html > Please note that it is still a preliminary agenda. > > The BESS WG session (2h) is currently scheduled on > Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time) > > Please send us your request for a presentation slot, indicating: > draft name, speaker and desired duration (covering presentation + > discussion) > > Please send the requests no later than the 20th of March > Thank you > > M&T > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > From nobody Sun Mar 13 19:40:49 2016 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 C0DBE12D8F8 for ; Sun, 13 Mar 2016 19:40:47 -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_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 TTC98HyWnytc for ; Sun, 13 Mar 2016 19:40:46 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4616412D912 for ; Sun, 13 Mar 2016 19:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1697; q=dns/txt; s=iport; t=1457923244; x=1459132844; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QagFJmODho63/ix+kFZwtM+wIy3VqJhFl8oPKm5yWTQ=; b=HocNDSCKfsIJSz2hkSXxAxe8K49uW6q3U77w3DsZWFEimiNU93oPTcqq ZnuMU0DCH1huROS6ByvtezmgWkeDZyI/yuCBJxRJTnYx0DhYVfmAY4f+F 6332BX1tK3q3gra1Ocbw98uJVQYV0D2H9jCphOM5kf3dAwtxfPVfdL3gK o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQCPI+ZW/4UNJK1dgz5SbQa6KQENg?= =?us-ascii?q?W0XCoVsAoEmOBQBAQEBAQEBZCeEQgEBBAEBATc0CxACAQg2ECcLJQIEAQ0FiCQ?= =?us-ascii?q?OujEBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYYhEKEChEBhFgBBJdLAYVtiBKBZ?= =?us-ascii?q?YRJiFeOfAEeAQFCg2RqiTE0fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,334,1454976000"; d="scan'208";a="248915026" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Mar 2016 02:40:42 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u2E2egpp000835 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Mar 2016 02:40:42 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 13 Mar 2016 21:40:42 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.009; Sun, 13 Mar 2016 21:40:42 -0500 From: "Dhananjaya Rao (dhrao)" To: Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Thread-Index: AQHRbZJQpHLPkTaW3U6h1WCC55PmEZ9YSdyA Date: Mon, 14 Mar 2016 02:40:41 +0000 Message-ID: References: <56CB3E3E.6080602@alcatel-lucent.com> In-Reply-To: <56CB3E3E.6080602@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.229.93] Content-Type: text/plain; charset="us-ascii" Content-ID: <57EA288597C5A34EA3237C45D8EBBB3A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-fm-bess-service-chaining@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2016 02:40:48 -0000 Hi Martin, As co-author, I support adoption of this draft. I am not aware of any related IPR apart from the ones that have been disclosed. =20 Thanks, -Dhananjaya On 2/22/16, 8:58 AM, "BESS on behalf of Martin Vigoureux" wrote: >Hello working group, > >This email starts a two-week poll on adopting >draft-fm-bess-service-chaining-02 [1] as a working group Document. > >Please state on the list if you support adoption or not (in both cases, >please also state the reasons). > >This poll runs until *the 7th of March*. > >Note that IPR has been disclosed against an earlier version of this >document: >https://datatracker.ietf.org/ipr/2284/ > >Yet, we are *coincidentally* also polling for knowledge of any other >IPR that applies to this draft, to ensure that IPR has been disclosed >in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >and 5378 for more details). > >=3D=3D> *If* you are listed as a document author or contributor please >respond to this email and indicate whether or not you are aware of any >relevant IPR. > >The draft will not be adopted until a response has been received from >each author and contributor. > >If you are not listed as an author or contributor, then please >explicitly respond only if you are aware of any IPR that has not yet >been disclosed in conformance with IETF rules. > >Thank you, > >Martin & Thomas >bess chairs > >[1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Mon Mar 14 11:30:44 2016 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 B93B412D6DF; Mon, 14 Mar 2016 11:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuUlQpA6Qy8y; Mon, 14 Mar 2016 11:30:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A872E12D553; Mon, 14 Mar 2016 11:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DLJX7o5jqT+lySgK03AmaHiK4pWq/6bTw9AXC2/Du6Y=; b=FAnFB4Lm4fk9EdenSVxcq8EN/bnakvW41k6DAf3n3p9EsLwh9ynA4tg/OLGOINTBRVOFHGVqnZl3a4xIqvlXUkU55U3o0kZ1qSJk0jf5Hgy1ODNxtV3Exw7+Ks5WT6k4kb3Bi1kj9yBkYYb4uu3JTBnS8+biI9NokDXNHVNcOHw= 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.227] (66.129.241.13) by DM2PR05MB798.namprd05.prod.outlook.com (10.141.180.21) with Microsoft SMTP Server (TLS) id 15.1.427.16; Mon, 14 Mar 2016 18:30:20 +0000 To: joel jaeggli , "Alvaro Retana (aretana)" References: <20160228163705.24380.24145.idtracker@ietfa.amsl.com> From: Eric C Rosen Message-ID: <56E70337.6040103@juniper.net> Date: Mon, 14 Mar 2016 14:30:15 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: CY1PR14CA0068.namprd14.prod.outlook.com (25.164.65.164) To DM2PR05MB798.namprd05.prod.outlook.com (10.141.180.21) X-MS-Office365-Filtering-Correlation-Id: f63c6407-4d30-4540-cfa4-08d34c36b37f X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB798; 2:kr2lvmb5tCO9eC/W2WlPtT+PZ884hRQp+plKIinADn02YC5PNqwzdckRNnzF06wrSHch82tT7zLMO4Ere+ZCawQ/fh9mAeA1fgZKqT4GtFw1LOHPx8n1XcZsot0APsLHCZzcS1wwTDfSDK/7atkfLsAzX/K5ngW/PS4HTCrdXD+Lic8tW4mqMN8zqLEa2JpG; 3:HO6efUD2mECYFSkLu1EUWyEzrb5yRrmWty5TelaW8H0iw1HHd1I0mkkSMhQ+G3ONFrNUhRJBe65+/FQBiHIase6Y7NdeeSFoGfy1mJ1MfqWlIBowEZppbQq/DBJNs8vU; 25:mAdFhhqs1uRlL28Wa0Pxlhc6zR3nszBKaPC0EkK8z5SUgMMuCqAm+WV5RTzMpwnRjM5Ej/VFj4rIdfAN6nIN5Irue0lM7xDXIzFvUnuOJAv2yyXmM3JDTFkTB0NlCPFKcPHLzZrRwpdMmPEu5VXsqlhVNwodmjQEtLBEAcXnTG3mwppnIKKt2xgYinSEMG/749U+k/lbehjF52KrU1uvC7KcSoaxb3OwBX9NAi409DQfPzyUwiFn9IzFXR57WqOMW2Zwvms0x8w270DJH5as8RNrwBVgeYjx3w2fIXJqf9F0uA5n+hLEEJqppSY+bkJdDqdGYb//ukqvdHkwgP/DIA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB798; X-LD-Processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB798; 20:NIBZeP4cWIUvD8q3fdXyfC+L6dwHNeieXe1DggEuUtA/jOwOY/jOOpnb6cf45hmVfW5CQtebZji9rNOs5Ps+srysIuhIAJzEadhRXzHAUopZzEex9z/EHOoutBtfQf2zIOb6mtnqg4CYYXIA1/ClCmqdkA5CmDBNLjCdO2orybfCdkGWOymj0ugVn0X9MZnkfCdtZ0hLqrB/k5FtPX8fvwMks0ksUwH8qdcgMtI32Re6AiSayvJHOPSP2sokgXa0lTDswnw1H6d2zFYTh+I8OAkz8z/+J8QGUFiShMSIIjt/9pc1Fy7GYL+59a8zCDCX8FtkZMtYCB+B9l14v6ziJ6xEmvLx+I1alKL1CRwRpljB8MCn1W1VGt/ETlq4BGvJfTYkZQjR5zEL4zDHakdKRVSHlrWCC6wR7DGIIdcC7NNC4/OV1S7nsQko+ZeNbPS0wUMn0L3WBymGSzWi6QWQpHRcp6gQQRm4wOjARaIV70MJkMeAhyIIvX8ffNE23ZwO; 4:Fj2SZV0pCwPLlOC7cy30Ct01iAtVNApko5uoV8+w41Cz34ksLntqcU9JQasEpu9FGLuNUnfGWh44H+PLoho5SG8mkAuZSYFozzi4o+o272dFZXpPNUqocpnCJ53qnjaPEinQKADfDL9COYVpESQAfQ2/MK597hcsNGQ2eAKOhMdoLlLxyzy2o7vnE9I5uGAv6bpAwz5NjXA0oxAp7HIpa0/P0M6MtwVGpMeoQ2r+2A5xlNd3jXcYIx1P4CXhENnEkwnVwFFshqU0+7DoP8AXab7ulDWTz1T0Xf8UHnhhAxoGhw1s1lxxZTNwwyZ6o+0LRvTB+nOipH4TkhwXvOFiQyFF8gWCVFTTXS60djOb495VlGQp6H4WIW+2pUY+sqGo X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DM2PR05MB798; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB798; X-Forefront-PRVS: 0881A7A935 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(377454003)(24454002)(479174004)(87266999)(189998001)(4326007)(586003)(5008740100001)(2950100001)(5001770100001)(81166005)(15975445007)(50986999)(47776003)(33656002)(54356999)(76176999)(6116002)(66066001)(86362001)(4001350100001)(83506001)(3846002)(230783001)(19580395003)(2870700001)(554214002)(23746002)(1096002)(5004730100002)(42186005)(50466002)(36756003)(2906002)(64126003)(92566002)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB798; H:[172.29.35.227]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DM2PR05MB798; 23:atH4GGSX+dlowHBvF//q9AyMoE0cmUKQvON3Kv?= =?Windows-1252?Q?HC/fXLA2fDFTF3EeQzdfyXBKd9PVcO1kv6Al3uf5Qm/PC0V5sPcU2mfl?= =?Windows-1252?Q?KhjderlI6ka3GPOVc5NByPKuvlPYlt5K0s3oeuaW9OITtbRNn4X9/ruw?= =?Windows-1252?Q?huYsISJS4WqHWEyu1NPyBbFKHiHF5T663qsjybX/IdMH+XWzHYCSpsC5?= =?Windows-1252?Q?KtMwVGRnqC61xnyyr/utfsJn9BchGPCVHlfcqXiVhx8T7MpLk1lVlTFV?= =?Windows-1252?Q?IhbrDxK2mV2kDNuTqwE+Uvwm2szWfmtzgSUXSzdHxAgQtTNYtdeQc/SL?= =?Windows-1252?Q?nQCl8txBNfbPZw0J+MBWGuQ15uW4hcPunnjhnIOpWP82wop0UzaDBbWu?= =?Windows-1252?Q?MkxOl6HADzBa46jZohC9iDELhiSda198fX9v9Qk4I0oW8gzHy/akz4dv?= =?Windows-1252?Q?TLwDGKTmega9wmvfrjao/wsj6Iea/nliiFS8dOp60pdTU/8nIJw9rqU8?= =?Windows-1252?Q?gPEfllhv1Rhv490JReJib/YqBtLMFdgZWYITNJ8yvzUS8QzguAw53DnN?= =?Windows-1252?Q?flGXNM1vvIC6kJwfWD/+zwoiMKy2vTZJxeoV28p0Mro4MoS2xMrfqKUI?= =?Windows-1252?Q?i/5x9hldi6RdVrJsmr6yzMg8shNRrgGj4YJxTD0oXpSb3jn1Tp6FhY8r?= =?Windows-1252?Q?1k1YFwHgVy5UE743Tv7MsPMFUBJ3j3VUc14nVKj19iWkKz2vjtQpWpmW?= =?Windows-1252?Q?dohJ+fEdduhR/vAocDFBh3hn6WJ9SnQ3+857wNjKRPG3hVI9Wew7MtiS?= =?Windows-1252?Q?eJBFrqN0e5NNxVxFatg1hLWNl4gKm1dRCO8usvd08DyGktgx3aUnwt9O?= =?Windows-1252?Q?j4p9Ykmpeozfy27UkLu4lDe2Ondahbo5G+UTbN/ZQp2i3Ft2a1v09Lyo?= =?Windows-1252?Q?6LqyCgiOC/+OI4TaZ8RaOpyXlSngA8nAaP7Ofa6nQqbhG+a1Tt8ugnIm?= =?Windows-1252?Q?aZNuEuRjUuQAFXpOFlfxtKZZMH6Cil4pcUkjeSKcFlo8UtwcH5DCYTCZ?= =?Windows-1252?Q?3QwH5t4pdVQ5Ld/Y2vD8A0NYYYB7SeyrVegQBjzS62d9fTJ0xIHIPZkA?= =?Windows-1252?Q?wAOeobkafnuMsblwnWoi9ckCG1edZd50c7YNdsYiYV?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB798; 5:TrRQqZ0Vwwkz1STjZ2bjQH8DitoM6k08Ag7nu553BgW7GBvHVFb4qc/AXVfqG3OuYYbl8LcIa42JiH0/BZGgaP+pYFWpZVH3RwPshrKUuWJIRxINsg5m58nmviX51wo6sw0OMN6pEDyq1Df/Sgf83Q==; 24:op+/FEIOOXFhcvdxqMYbMDjHhNIT6aqObBhvKWrnH9clO8WkLCbCjT5GL7DjexVMAbX8Wyr2Z2+/YeEw0lBUDsAUGPAvEgIlZ1FlcfN6jVA= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2016 18:30:20.1564 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB798 Archived-At: Cc: "bess-chairs@ietf.org" , "draft-ietf-bess-mvpn-extranet@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" , The IESG Subject: Re: [bess] Joel Jaeggli's Discuss on draft-ietf-bess-mvpn-extranet-06: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2016 18:30:44 -0000 On 3/10/2016 10:34 AM, joel jaeggli wrote: > I think the question comes down to, is this document adequately > prescriptive when it comes to implementation in a network. As far as I can tell, no one has offered any reason to think that the document is not adequately prescriptive. > You see to be asking us to write the words. No, you are just being asked to state what you think is needed that isn't present. This should be stated with enough precision to enable the authors to know what it would take to lift the DISCUSS. The text you quote from Sue: > I am looking for an operator-based “abstract” that focuses the reader on the key > points. does not help me understand what is claimed to be missing. I do not know what an "operator-based abstract" would be, or where it is stated that such a thing is required. > unique RD per VRF, yes it discusses this, then brings in the extranet RD > leakage. calling this spongy is maybe an understatement. This statement is a good example of the way in which the DISCUSS is unsatisfactory. There is in fact no such technical concept as "RD leakage", and it is impossible to understand from the above text just what objection is being made. Procedures for the use of the extranet RD are defined in such a way that existing procedures using the default RD will still work. > This question > might be easier to discuss cogently if in fact the document were easier > to read. It is not, so you find your CO-ADs relying on the reviews of > domain experts, and previous discussion on the list. Lack of familiarity with the normative references seems to be a factor here. However, I am not aware of any requirement to provide an "executive summary" for people who are not familiar with the normative references. I would like to call your attention to http://www.ietf.org/iesg/statement/discuss-criteria.html. In section 3.2, "DISCUSS Non-Criteria", it says "None of the following are criteria for which the IESG should DISCUSS a document", and among "the following" it lists: Unfiltered external party reviews. While an AD is welcome to consult with external parties, the AD is expected to evaluate, to understand and to concur with issues raised by external parties. Blindly cut-and-pasting an external party review into a DISCUSS is inappropriate if the AD is unable to defend or substantiate the issues raised in the review. Also among the non-criteria is: Stating "I think there's something wrong here, and I'll tell you what it is later" is not appropriate for a DISCUSS; I think this would rule out a DISCUSS based on the feeling that "there might be some mistakes in the part of the document that I don't understand". On that same page, it lists among the valid DISCUSS criteria: It would present serious operational issues in widespread deployment, by for example neglecting network management or configuration entirely. This seems to be the main criterion being used to support the DISCUSS, but given the number of provisioning rules and warnings contained in the document, and the extensive discussion of what has to be configured in the PEs, I don't see how one could claim that network management or configuration are neglected entirely. Thus I think this DISCUSS violates the IETF process in the following ways: - The DISCUSS is too vague to be actionable. - It is not based on a valid DISCUSS criterion. - It relies entirely on an "unfiltered external party review". From nobody Mon Mar 14 12:49:26 2016 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 51B2412D712 for ; Mon, 14 Mar 2016 12:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 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, 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=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZK8t9oF2nT3 for ; Mon, 14 Mar 2016 12:49:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AF212D6AE for ; Mon, 14 Mar 2016 12:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6QePsiMLL8VYR/uhPCZYA45gqsr5lvTRYwSDjDLd/tw=; b=dLktJn02u/VjvyNkBYy3nG8J3BS4UCZnKv67jPLVw9cMmNLy4vKHZT116NTh+QzYJqHJT+Vfay9EcBM5dguLkBuxKZai3rne6vubKAkC4XWKv7H6KNYRnkdp+MniYl6ge+OZqQtqXkilLeyWoTC5+vD/3f2u2CXlCUDjENrcNRs= 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.227] (66.129.241.13) by BLUPR05MB788.namprd05.prod.outlook.com (10.141.209.150) with Microsoft SMTP Server (TLS) id 15.1.434.16; Mon, 14 Mar 2016 19:49:02 +0000 To: "li_zhenqiang@hotmail.com" , bess References: <56E044DB.4090302@juniper.net> From: Eric C Rosen Message-ID: <56E715A9.1080201@juniper.net> Date: Mon, 14 Mar 2016 15:48:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090306060008020708070804" X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: SN1PR11CA0016.namprd11.prod.outlook.com (25.164.10.26) To BLUPR05MB788.namprd05.prod.outlook.com (10.141.209.150) X-MS-Office365-Filtering-Correlation-Id: ee5805e6-9f18-4c4e-c1a2-08d34c41b21b X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 2:z/m+5AdzrLhct58ytlvB9IYOO/4rv3exzqTgiMxbMeIyR7zqDBI4mhZRfXtas9aLMUT3o3KOP++zRTMaGVqwCjWMh2DG9O6PNiWgp966suEfyGecRYFeVlof46Qsg3qpVX3viQ3XiPiMlU34GX9OYfxojLny2eV9ZqvnDwao4YVGePr9/VbuGZlzeIEVmauZ; 3:0dI9sHtTeR0aYtnlYJG9ulQ23goU1BkoRNB32JDOt4+WJpeWWxTFzoTMCZk5WYArZ9yn++PlszyE6n91TfHpnkz/1YoB/5hoWh9s0ypWhuxTiwDoBIp6ZaZsmv0mnTDS; 25:0BfX2ALA7TrU2IOaErgphC4o2K0Fz1stk253hW86muDdtCsfde2z9HO194sa4NV+TfDAeL0Wq9yLJ2hquDJ0ulvXTEc1Y/DWxfUXtaycSDrFATs715X3Hgeotf3DrTBDAXS3xTeVTvhMQaoPsVXcavWdAy3WITbtSWxmpUg1TdQDFkz9+tmIv5EjYBV8Zs5cZ2UsSVEthpDyDfRLmr8SwOhD5Fbu4iLgAQfFR6S4AEFJx2J+9DlOIcJWEVVdYQFsP5O7/Q24NIxnTb2rLW1DgnNdIJoAh8BQGZc9tidcucMBdUYJeXUOoa6z68RsHMNKWdagQsNtrWO/FNGIMnVJnw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB788; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 20:dfL5PaWcENPRmZgVj6WLrVbbU5n4PwPRqYvwta4duWL/mVHSPvMAmzjwBPVDuHk1sM8ogqYrA1l39JDJRXrvnpm/52N5dIGYVip/QJuIdz4GjNara4+Of+lW4QjhlW0E+oEsxLKp5Yi7zY0gCksMvQRlAw3Uh5iNdN1tjyQpXYabNyZqHiRstfDeGoOvtWNuHxnVMlQXfgyJ2lzAzPLAc/K//kE3zzDwwW1PGW/TShhQzV+zt3Y+3mRCCLtSm2BfGJudc/dhV52Oaz7bHNONiDlHmi9k3SWsGK3zf38R60hSutu2P0g8yTwCLNkWWN251yqow3BZlK7+bSBwTtIpPfkppjj2uaJZOHRKHo2nLYd7VjqWR0t7CcCbwV5h6V2SjkTAEb1hqT8o3DJgH1k3/BqQKddXyjL0GtMKSvhhYCy+O/r3Qv7VsYp1OaYPT4sgj8W930pOvt+badpHHA/6rJ1UTcYL3CcS0BZTEzXA/NLagckib1w7ZNy13gBzWbvt; 4:Z3Cx6hMLt/zfL1iqGSR3Y6hOT2Iq42kqX4uuEgaNEmeSQByjfnZcwDkRHlb0HyLq6gpdaDgQ5yrh1GC80G5spjUpyVb0wSWmIDEV24GqWcoQ4cHdFTRSLZ/vAgD99yFymGUu2D0Y4idP6jF+Pk0kR39FuvljMfyEKcEl3CdHUKofJeb3hO+j/k34sdtY2I6l0+VVh22d/1cFl5TvlkNA5tVvj2J83eBuL7MjzRk3lBrD0OyaOx3zhf8z20nm0B9myhjLGoaZTOcsZXK0Kh9uA1AaxP9b09PgmFJQWIyfq6A+tvlBRtZ73sNZOtqLYB1FzgS/dAExGOO++LhIAxvEcA3+sq4dVSmZswaIFWg9giV8noNuvdEFC0AbPVhciZ5b X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR05MB788; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB788; X-Forefront-PRVS: 0881A7A935 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(24454002)(377454003)(45984002)(479174004)(3846002)(5001770100001)(4001350100001)(189998001)(42186005)(107886002)(92566002)(19580395003)(84326002)(36756003)(54356999)(50986999)(64126003)(76176999)(83506001)(66066001)(86362001)(87266999)(19580405001)(2950100001)(230783001)(561944003)(2501003)(33656002)(16236675004)(512874002)(586003)(6116002)(1096002)(2906002)(77096005)(270700001)(5004730100002)(5008740100001)(81166005)(861004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB788; H:[172.29.35.227]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjA1TUI3ODg7MjM6Y0JBdWhWVFcrM01MNkhMcUttdlpacVp4S3dL?= =?utf-8?B?Wkg2cGpDT2VTcmtScnBVVm9hZjRmK2tyUS9DZ1gzNk5jNGdNZVI2d2plSGRU?= =?utf-8?B?ZkhBcHl6eGhZYzhtQVdXeWFnaVJydkhtWTU2ay9aTC9sN2lhNXdrTm9xY0E1?= =?utf-8?B?eGtGWEI5dGRuZ2s5Ti80OVdWVG1iNVlkcjF3K2hoUnpXeThFT0VNME44LzZn?= =?utf-8?B?eG5CTldXQk54MHpOcFoxem9Jd01qYzNtNGpJY29DbWpqZWJVZXhJcnoycllw?= =?utf-8?B?eUZRTmFOVnoybkY2ZTc2Y3F4WGw5a3BsRzcydXowRGRQazlxRG4wYnMvMlVX?= =?utf-8?B?SU1HRHBWbmFhVmdmSFYyWFBhdThud0tZL21qV0I0cWlNWlZxZFVIUVlrNkNQ?= =?utf-8?B?b2hTZnJzNWVGKzBIU0JscS9FUzRzak9MeWVzdVNZN0xJZkhhMUVzeVprcmg1?= =?utf-8?B?T3B6Mm9jVWJNRStHQ3ZHNDloNVVqekw1K24zNitnN1p4dUZxaStRYVpxNEgw?= =?utf-8?B?WFZKVzZ3Rk5zN1BJZE9Rck5aQ1VHU2pMallpK3JVRDloR25jYjNPeU8vVFNL?= =?utf-8?B?aVlvMkJXY0pDeDY5VkR2S2d0b0xiZXYvN3c1WFFjekpRVkdtNWdlM1czYXl0?= =?utf-8?B?TVRQdTR5U3pjTzQzaGhNeW16Y0NENzNZQ2QxY1R4ZWNZbUtxalVuK2Y1TG9Z?= =?utf-8?B?UXhwamZPZVZHaU54RFY0NXpPK3BxMHhDc09rNEZvdXFlbXBNbGhnSkttTUN5?= =?utf-8?B?Y3NoOWxCcG8zalptL0o0TWcya1dmR0YvSTRwK0swQWpNcDl4N3B4MFZFL2xq?= =?utf-8?B?NnVEcEhXazNkb2l3YU1aTFVGeXN5V1kyVStYOHllM0R1cllYUWlFYmk2eG00?= =?utf-8?B?SGYwa0ZDNnpqZk1CM2ZKakpNZk85c20zNmJSaHhxWm5nRVQwb1B2TU52VGdO?= =?utf-8?B?QXlsRXRtcGRwTnBzS01pUUF2L0N2NlR2SDlvRXdlOHhXS05TL291MXE3S0pY?= =?utf-8?B?RE1SRHhPUU5Xd05mSkpYN1dLclVlZ2ovaEZXdkpjN1EzdHhORlN1NUNFRFdO?= =?utf-8?B?RjNLWThwQ2hFRVFnR3BwS3Fka0JaZUllcHFrZUlyRUhXS0pnWHNzMEtVbVBo?= =?utf-8?B?UW8wMzhkWGJrdnhtL3Zoa25NNkZtbGFVUGxmTXBjbnM5YUQrWmdWVDRQbC9U?= =?utf-8?B?M2dUWE5XMml5SkhKZ1dHaVJjU1ZwYVRkN2UxSlVIZmZvSTFhQk81RCtEZlUx?= =?utf-8?B?TExaNjd0YVpNM1Z5dTMrSTNOS005ZXpmRHlVZkNpWkRhdE5Sd0MyU21oSk5L?= =?utf-8?B?OGxueEZVbjdvc1UxUGJ4RXpFZ1grcEtBMWo2K3R2cU1yZmRjUTJMYTcxeFIv?= =?utf-8?B?bFZIci9Yb0N6dEpvUWwyd0xSNXRFa3V5WWp5eXdQejM1bnVCYzVreFk0Smw5?= =?utf-8?B?aUk2MFk4dGN6ektlYTdSVWwyMUZaVWhIV3I2a0ZBdC80MjZmeUd0Znhid1Zv?= =?utf-8?Q?lmUL/LZ/n80OOvTdA9j40p4PHq4+KFVRTUy37sWbPO+Dv?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 5:4AC5S+qYaQqEeeUtw9OVp8Kt8Sl+BbXuWlePWJIpz7R+6+PdDVnAbrooeAosxoZaX58qDV8lcb1yH+rT+KRrc2Auyr6U2TASqXiUHMgbbj2ZRluTtxr+KbhNF7CwwDsE9AV3lcBs24JnmFA+SWTAJQ==; 24:zcuf2J2ytOgYBlNXolXonBMxjXaFZ0IQDXbxgIGtFicb+63r1w3JytAfGxL98+q+L8xaObFeWF1zn9EAifzqBmeaGhZ2Od+4PurMZvxD5R0= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2016 19:49:02.4120 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB788 Archived-At: Subject: Re: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2016 19:49:24 -0000 --------------090306060008020708070804 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 3/10/2016 4:32 AM, li_zhenqiang@hotmail.com wrote: > Thank you very much for your comments, Eric. > > Yes, RFC5549 does specify the procedures for creating a route with > IPv4 or VPN-IPv4 NLRI and an IPv6 next hop. IPv4 NLRI with IPv6 next > hop is for the situation where an IPv6-only network conneting > IPv4-only islands. VPN-IPv4 NLRI with IPv6 next hop is for the 4vPE > situation. > > What I want to solve is the 4PE situation, where an IPv6-only network > running with MPLS connecting the IPv4-only islands. The routes in the > 4PE NLRI have labels assigned by the 4PE routers. RFC 5549 will work when the IPv6-only network runs MPLS. If you want the 4PE routers to send labeled IPv4 routes to each other, they just need to use SAFI 4. If the core runs only IPv6/MPLS, and the next hop of a 4PE route is an IPv4 address, I don't really see how the next hop resolution is going to work, as the next hop (a v4 address) will not appear to be reachable through the v6 core. I think your proposal really is intended to treat the v6 address in the NLRI as the next hop. But that leaves open the question of why you want to put the next hop address in the NLRI field instead of in the next hop field. > > Besides, 4PE routers need both IPv4 next hop and IPv6 next hop to > build their IPv4 routing table and IPv6 routing table respectively. Some people think it's a bad idea for the prefix and the next hop to be of different address families; those folks tend to regard RFC 5549 as a bad solution. However, I don't see what advantage your proposal has over RFC 5549. In order to determine whether a given 4PE route is feasible, or whether it is the bestpath, you still have to resolve the IPv6 next hop, you still have to consider the IGP distance to the IPv6 next hop, etc. > ------------------------------------------------------------------------ --------------090306060008020708070804 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit On 3/10/2016 4:32 AM, li_zhenqiang@hotmail.com wrote:
Thank you very much for your comments, Eric.

Yes, RFC5549 does specify the  procedures for creating a route with IPv4 or VPN-IPv4 NLRI and an IPv6 next hop. IPv4 NLRI with IPv6 next hop is for the situation where an IPv6-only network conneting IPv4-only islands. VPN-IPv4 NLRI with IPv6 next hop is for the 4vPE situation.

What I want to solve is the 4PE situation, where an IPv6-only network running with MPLS connecting the IPv4-only islands. The routes in the 4PE NLRI have labels assigned by the 4PE routers.

RFC 5549 will work when the IPv6-only network runs MPLS.

If you want the 4PE routers to send labeled IPv4 routes to each other, they just need to use SAFI 4.

If the core runs only IPv6/MPLS, and the next hop of a 4PE route is an IPv4 address, I don't really see how the next hop resolution is going to work, as the next hop (a v4 address) will not appear to be reachable through the v6 core.

I think your proposal really is intended to treat the v6 address in the NLRI as the next hop.  But that leaves open the question of why you want to put the next hop address in the NLRI field instead of in the next hop field.


Besides, 4PE routers need both IPv4 next hop and IPv6 next hop to build their IPv4 routing table and IPv6 routing table respectively.

Some people think it's a bad idea for the prefix and the next hop to be of different address families; those folks tend to regard RFC 5549 as a bad solution.

However, I don't see what advantage your proposal has over RFC 5549.   In order to determine whether a given 4PE route is feasible, or whether it is the bestpath, you still have to resolve the IPv6 next hop, you still have to consider the IGP distance to the IPv6 next hop, etc. 


--------------090306060008020708070804-- From nobody Mon Mar 14 23:21:19 2016 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 778BD12D8C9; Mon, 14 Mar 2016 23:21:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160315062114.7863.56501.idtracker@ietfa.amsl.com> Date: Mon, 14 Mar 2016 23:21:14 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-mvpn-mib-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 06:21:14 -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 : MPLS/BGP Layer 3 VPN Multicast Management Information Base Authors : Zhaohui Zhang Saud Asif Andy Green Sameer Gulrajani Pradeep G. Jain Filename : draft-ietf-bess-mvpn-mib-02.txt Pages : 31 Date : 2016-03-14 Abstract: This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multicast in MPLS/BGP IP VPNs (MVPN) on a router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-mvpn-mib-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-mib-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 15 05:57:34 2016 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 52F9C12D572; Tue, 15 Mar 2016 05:57:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160315125732.18694.27736.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 05:57:32 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 12:57: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 : L2L3 VPN Multicast MIB Author : Zhaohui Zhang Filename : draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt Pages : 9 Date : 2016-03-15 Abstract: This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects common to both L2 and IP VPN Multicast. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 15 09:07:51 2016 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 01F4012D52E for ; Tue, 15 Mar 2016 09:07:50 -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_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 iwMwTTLVvrYA for ; Tue, 15 Mar 2016 09:07:44 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D37D12D62E for ; Tue, 15 Mar 2016 09:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3403; q=dns/txt; s=iport; t=1458058060; x=1459267660; h=from:to:subject:date:message-id:mime-version; bh=bwNvAPFDz4J3g3TAqTZ1XOUCRmkqQK5Hvk7rn/ADP7k=; b=HP5t7rFTjQEpReeryZvKqBtSxwzxL0D6ezG1/gwvo070en4MxpHC6ugY FhVPNnJ+c1f7y0LMXXMg95+jUG3bsdJmIflm91Hw/JiYvbftOnH+bKNfL cdkcC5S5f0qBlx/2xvY5alAUN0c0ZwPPTyycBEZgzPMHMk8AONOWTVWWh s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3BQBoMuhW/4oNJK1egnpMVHS6V4Fuh?= =?us-ascii?q?0Q6EgEBAQEBAQFkJ4RCAgQtXgEIBHQmAQQBGogeviEBAQEBAQUBAQEBAQEBGYp?= =?us-ascii?q?ciHUFl08BjXmPDI5+AScJMoNlik9+AQEB?= X-IronPort-AV: E=Sophos; i="5.24,340,1454976000"; d="scan'208,217"; a="80959839" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2016 16:07:39 +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 u2FG7cS0007536 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 16:07:39 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 12:07:38 -0400 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Tue, 15 Mar 2016 12:07:38 -0400 From: "Rex Fernando (rex)" To: "martin.vigoureux@nokia.com" , "bess@ietf.org" Thread-Topic: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Thread-Index: AdF+1FITpzLHSbheQCWPmiK4Lc7X1Q== Date: Tue, 15 Mar 2016 16:07:38 +0000 Message-ID: <60c56a3c41224f228063b50789b87bea@XCH-RTP-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.23.18.250] Content-Type: multipart/alternative; boundary="_000_60c56a3c41224f228063b50789b87beaXCHRTP003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 15 Mar 2016 16:07:50 -0000 --_000_60c56a3c41224f228063b50789b87beaXCHRTP003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Martin, As one of the authors of this draft, I support its adoption. I am not aware= of any related IPR apart from the ones that have been disclosed. Cheers, Rex --_000_60c56a3c41224f228063b50789b87beaXCHRTP003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Martin,

 

As one of the authors of this dra= ft, I support its adoption. I am not aware of any related IPR apart from th= e ones that have been disclosed.

Cheers,

Rex

--_000_60c56a3c41224f228063b50789b87beaXCHRTP003ciscocom_-- From nobody Tue Mar 15 09:10:44 2016 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 BB42912DBD6 for ; Tue, 15 Mar 2016 09:10:42 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 baRwQcLxfRt4 for ; Tue, 15 Mar 2016 09:10:40 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C85012DB7D for ; Tue, 15 Mar 2016 09:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=756; q=dns/txt; s=iport; t=1458058231; x=1459267831; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=xvCnW5oX/cQ59mzx11s0JkO537mcBpc+M+edvPE0DPY=; b=bKt1kp3v5xZeIbEF+GpGsVTpzX78rMsY7tKnBrwPDCIW5ifgJ1ZmHsLy nWZlxRXZwdxzlhqlfH4Rgvwd0+M3xJQZYg234c/eW91mOPyoEIO7SCqAi hGihAD54t2fMUpFIN101KyH4n8YkowRVcG1VdM3u/5O3o7FXUS7ClPz0L U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgCyM+hW/5BdJa1eg0aBQga6SQENg?= =?us-ascii?q?W6GDQIcgRo4FAEBAQEBAQFkJ4RBAQEBBCMRUQYBCBEDAQIDAiYCBDAVCAoEARK?= =?us-ascii?q?IJq5oj0gBAQEBAQEBAwEBAQEBARp8hR6Bc4JPhDmDAiuBDwWXTwGOAIFPjTaOf?= =?us-ascii?q?gEeAQFCg2VqiWUBfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,340,1454976000"; d="scan'208";a="247804809" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2016 16:10:30 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u2FGAUnT016501 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 16:10:30 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 11:10:29 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.009; Tue, 15 Mar 2016 11:10:29 -0500 From: "Rajiv Asati (rajiva)" To: "Rex Fernando (rex)" , "martin.vigoureux@nokia.com" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Thread-Index: AQHRftUxpHLPkTaW3U6h1WCC55PmEQ== Date: Tue, 15 Mar 2016 16:10:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.102.38.130] Content-Type: text/plain; charset="utf-8" Content-ID: <6486F56F02E11445AC5A6A0FAE916FA3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 15 Mar 2016 16:10:43 -0000 U3VwcG9ydC4gDQoNCi0tIA0KQ2hlZXJzLA0KUmFqaXYgIA0KDQoNCg0KDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJFU1MgPGJlc3MtYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIFJleCBGZXJuYW5kbyA8cmV4QGNpc2NvLmNvbT4NCkRhdGU6IFR1ZXNkYXksIE1h cmNoIDE1LCAyMDE2IGF0IDEyOjA3IFBNDQpUbzogIm1hcnRpbi52aWdvdXJldXhAbm9raWEuY29t IiA8bWFydGluLnZpZ291cmV1eEBub2tpYS5jb20+LCAiYmVzc0BpZXRmLm9yZyIgPGJlc3NAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2Jlc3NdIFBvbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC1mbS1i ZXNzLXNlcnZpY2UtY2hhaW5pbmctMDINCg0KPkhpIE1hcnRpbiwNCj4gDQo+QXMgb25lIG9mIHRo ZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQsIEkgc3VwcG9ydCBpdHMgYWRvcHRpb24uIEkgYW0gbm90 IGF3YXJlIG9mIGFueSByZWxhdGVkIElQUiBhcGFydCBmcm9tIHRoZSBvbmVzIHRoYXQgaGF2ZSBi ZWVuIGRpc2Nsb3NlZC4NCj4NCj5DaGVlcnMsDQo+UmV4DQo+DQo= From nobody Tue Mar 15 11:08:46 2016 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 F321612D505 for ; Tue, 15 Mar 2016 11:08:44 -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_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 A3chDWif4VRR for ; Tue, 15 Mar 2016 11:08:43 -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 3196D12DA02 for ; Tue, 15 Mar 2016 10:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13018; q=dns/txt; s=iport; t=1458064779; x=1459274379; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NPlEmMoNcbrtQ2sL1bQU+RvvLYfvHF6m3sGzIc2MXEY=; b=jt3k74AsnqtHlz/LB5YPVV32aHc76uy0iy8HliXH5bD9wTkwQzTaLSfB /LMFVBC91FlQvuwLtSQlGpUqKla+0IhXI1zsfLw3AkZAMqfcDlFw/H/l+ 22Hrifa1b6+vuElX4PLE/R5w4tfuD3HF/4BJYCE6yi0qGucdn0a5hSZKk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQDCTOhW/4MNJK1eg0ZUbga6SQENg?= =?us-ascii?q?W4XCoVsAhyBHjgUAQEBAQEBAWQnhEEBAQEEAQEBGgYROQEXBAIBCBEEAQEBAgI?= =?us-ascii?q?jAwICAiULFAEICAIEARIUiBMOrwiPSQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEf?= =?us-ascii?q?IlghAsRARwYgmqBOgWXTwGFbogSgWWESYMmhTGOfgEeAQFCg2VqiTE0fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,340,1454976000"; d="scan'208";a="83243376" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2016 17:59:37 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2FHxbvO018545 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 17:59:37 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 13:59:36 -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.1104.009; Tue, 15 Mar 2016 13:59:36 -0400 From: "Ali Sajassi (sajassi)" To: "Jeffrey (Zhaohui) Zhang" , "EXT - thomas.morin@orange.com" , BESS , "draft-ietf-bess-evpn-etree@tools.ietf.org" Thread-Topic: [bess] WG Last Call on draft-ietf-bess-evpn-etree Thread-Index: AQHRUpaME/U9KT8MU0ut9l7k3idEc58OWnfAgAhLYwCAAYwoAIBC0CQA Date: Tue, 15 Mar 2016 17:59:36 +0000 Message-ID: References: <569DF8F7.2000703@orange.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.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.58.201] Content-Type: text/plain; charset="utf-8" Content-ID: <611BDFB53EFCBD4BBC93EB10F103023C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 15 Mar 2016 18:08:45 -0000 DQpKZWZmcmV5LA0KDQoNCg0KT24gMi8xLzE2LCAyOjQxIFBNLCAiSmVmZnJleSAoWmhhb2h1aSkg WmhhbmciIDx6emhhbmdAanVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+QWxpLA0KPg0KPk9uZSBtb3Jl IHF1ZXN0aW9uIGFib3V0IFBCQi1FVlBOLg0KPg0KPkZvciB0aGUgcmVndWxhciBFVlBOLCBzZWN0 aW9uIDMuMy4yIHRhbGtzIGFib3V0IGEgc2l0dWF0aW9uIHdoZXJlIHRoZQ0KPm9ubHkgdHJhZmZp YyBpcyBCVU0uIFRoZXJlIGlzIG5vIG5lZWQgZm9yIG1hYyBsZWFybmluZyBpbiB0aGF0IHNpdHVh dGlvbi4NCj4NCj5Gb3IgUEJCLUVWUE4sIEkgYXNzdW1lIHRoaXMgaXMgYWxzbyBwb3NzaWJsZS4g V2l0aCB0aGlzLCB0aGVyZSBpcyBubyBuZWVkDQo+dG8gYWR2ZXJ0aXNlIHBlci1FUyBCLW1hYyBh ZGRyZXNzZXMgLSBhIHNpbmdsZSBwYWlyIG9mIGdsb2JhbCByb290L2xlYWYNCj5CLW1hYyBhZGRy ZXNzZXMgYXJlIGVub3VnaC4NCj4NCj5QZXJoYXBzIHRoaXMgY2FuIGJlIG1lbnRpb25lZCBmb3Ig cGFyaXR5L2NvbXBsZXRlbmVzcy4gT2YgY291cnNlLCB0aGlzIGlzDQo+bm90IGEgYmlnIGRlYWwg YW5kIGVpdGhlciB3YXkgaXQncyBmaW5lIC0gYnV0IEkgZG8gd2FudCB0byBhc2sgdG8gY29uZmly bQ0KPm15IHVuZGVyc3RhbmRpbmcuDQoNCldl4oCZbGwgZG8uDQoNCkNoZWVycywNCkFsaQ0KDQo+ DQo+SmVmZnJleQ0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEFs aSBTYWphc3NpIChzYWphc3NpKSBbbWFpbHRvOnNhamFzc2lAY2lzY28uY29tXQ0KPj4gU2VudDog TW9uZGF5LCBGZWJydWFyeSAwMSwgMjAxNiAyOjA0IEFNDQo+PiBUbzogSmVmZnJleSAoWmhhb2h1 aSkgWmhhbmcgPHp6aGFuZ0BqdW5pcGVyLm5ldD47IEVYVCAtDQo+PiB0aG9tYXMubW9yaW5Ab3Jh bmdlLmNvbSA8dGhvbWFzLm1vcmluQG9yYW5nZS5jb20+OyBCRVNTIDxiZXNzQGlldGYub3JnPjsN Cj4+IGRyYWZ0LWlldGYtYmVzcy1ldnBuLWV0cmVlQHRvb2xzLmlldGYub3JnDQo+PiBTdWJqZWN0 OiBSZTogW2Jlc3NdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZQ0K Pj4gDQo+PiBIaSBKZWZmcmV5LA0KPj4gDQo+PiBUaGFua3MgZm9yIHRoZSByZXZpZXcuIFlvdXIg Y29tbWVudHMgaGVscHMgdGlnaHRlbiB0aGUgZHJhZnQgc29tZSBtb3JlLg0KPj5JDQo+PiBoYXZl IHVwZGF0ZWQgdGhlIGRyYWZ0IGFuZCB3aWxsIHB1Ymxpc2ggaXQgbmV4dCAocmV2MDQpLiBNYWpv cml0eSBvZiB0aGUNCj4+IGNvbW1lbnRzIHdlcmUgZWRpdG9yaWFsIGluIG5hdHVyZSBmb3IgYmV0 dGVyIGNsYXJpZmljYXRpb25zLiBTaW5jZSB0aGUNCj4+IGV4aXN0aW5nIGRyYWZ0IChyZXYwMykg cmVmbGVjdHMgdGhlIGNvbnNlbnN1cyByZWdhcmRpbmcgb3VyIHNldmVyYWwNCj4+cm91bmRzDQo+ PiBvZiBkaXNjdXNzaW9ucyB3aGVyZSB3ZSBoYXZlIHRha2VuIGNhcmUgb2YgdGhlIHRlY2huaWNh bCBpdGVtcywgaXQgaXMNCj4+IGNvbnNpc3RlbnQgd2l0aCBvdXIgZXhwZWN0YXRpb24gb2Ygbm90 IHNlZWluZyBhbnkgbWFqb3IgaXNzdWUgZHVyaW5nIHRoZQ0KPj4gTEMuIFBsZWFzZSByZWZlciB0 byBteSByZXBsaWVzIGluIGxpbmUuDQo+PiANCj4+IENoZWVycywNCj4+IEFsaQ0KPj4gDQo+PiAN Cj4+IE9uIDEvMjcvMTYsIDU6MjYgUE0sICJCRVNTIG9uIGJlaGFsZiBvZiBKZWZmcmV5IChaaGFv aHVpKSBaaGFuZyINCj4+IDxiZXNzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHp6aGFu Z0BqdW5pcGVyLm5ldD4gd3JvdGU6DQo+PiANCj4+ID5JIHdhcyBpbnZvbHZlZCBpbiByZWxldmFu dCBkaXNjdXNzaW9ucywgYW5kIGhhdmUgcmV2aWV3ZWQgb25jZSBtb3JlIGZvcg0KPj4gPnRoaXMg TEMuDQo+PiA+DQo+PiA+SSBzdXBwb3J0IHRoZSBwdWJsaWNhdGlvbiwgYnV0IHdpdGggdGhlIGZv bGxvd2luZyBxdWVzdGlvbnMvY29tbWVudHMuDQo+PiA+DQo+PiA+Mi4xIFNjZW5hcmlvIDE6IExl YWYgT1IgUm9vdCBzaXRlKHMpIHBlciBQRQ0KPj4gPg0KPj4gPiAgIC4uLiBJZiB0aGUgbnVtYmVy IG9mIEVWSXMgaXMgdmVyeSBsYXJnZQ0KPj4gPiAgIChlLmcuLCBtb3JlIHRoYW4gMzJLIG9yIDY0 SyksIHRoZW4gUlQgdHlwZSAwIGFzIGRlZmluZWQgaW4gW1JGQzQzNjBdDQo+PiA+ICAgU0hPVUxE IGJlIHVzZWQ7IG90aGVyd2lzZSwgUlQgdHlwZSAyIGlzIHN1ZmZpY2llbnQuDQo+PiA+DQo+PiA+ UkZDIDcxNTMgc2hvdWxkIGJlIHJlZmVyZW5jZWQgZm9yICJUeXBlIDIiLg0KPj4gDQo+PiANCj4+ IERvbmUuDQo+PiANCj4+ID4NCj4+ID5BZGRpdGlvbmFsbHksIHdoeSBpcyAzMksgbWVudGlvbmVk PyBJIGNhbiB1bmRlcnN0YW5kIHRoZSA2NGsgcGFydC4NCj4+IA0KPj4gUmVtb3ZlZCAzMksgc2lu Y2UgdGhlIGV4YW1wbGUgaXMgY2xlYXIgZW5vdWdoIHdpdGggNjRLDQo+PiANCj4+ID4NCj4+ID4g ICAuLi4gdGhlIE1QTFMtZW5jYXBzdWxhdGVkIGZyYW1lcyBNVVNUIGJlIHRhZ2dlZCB3aXRoIGFu DQo+PiA+ICAgaW5kaWNhdGlvbiBvZiB3aGV0aGVyIHRoZXkgb3JpZ2luYXRlZCBmcm9tIGEgTGVh ZiBBQyBvciBub3QuDQo+PiA+DQo+PiA+UGVyaGFwcyBjaGFuZ2UgdGhlIGxhc3QgbGluZSB0byAi aW5kaWNhdGlvbiBpZiB0aGV5IG9yaWdpbmF0ZWQgZnJvbSBhDQo+PiA+TGVhZiBBQyI/IFBhY2tl dHMgZnJvbSBhIHJvb3QgQUMgYXJlIG5vdCB0YWdnZWQgd2l0aCBhIGxlYWYgaW5kaWNhdGlvbi4N Cj4+IA0KPj4gT0suIEJldHRlciB5ZXQuIEl0IHNob3VsZCBzYXkgwrNpbmRpY2F0aW9uIHdoZW4g dGhleSBvcmlnaW5hdGVkIGZyb20gYQ0KPj5sZWFmDQo+PiBBQ8KyLg0KPj4gDQo+PiA+DQo+PiA+ ICAgT3RoZXIgbWVjaGFuaXNtcyBmb3IgaWRlbnRpZnlpbmcgd2hldGhlciBhbiBlZ3Jlc3MgQUMg aXMgYSByb290IG9yDQo+PiA+ICAgbGVhZiBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9j dW1lbnQuDQo+PiA+DQo+PiA+U2hvdWxkICJlZ3Jlc3MiIGJlICJpbmdyZXNzIiBpbiB0aGUgYWJv dmUgcGFyYWdyYXBoPyBPciBzaW1wbHkgcmVtb3ZlZD8NCj4+IA0KPj4gTmljZSBjYXRjaCEgSXQg aXMgwrNpbmdyZXNzwrIuIEl0IGlzIG5vdyBjb3JyZWN0ZWQuDQo+PiANCj4+ID4NCj4+ID4gICAu Li4gVGhpcyBMZWFmIE1QTFMgbGFiZWwgaXMgYWR2ZXJ0aXNlZCB0byBvdGhlciBQRSBkZXZpY2Vz LA0KPj4gPiAgIHVzaW5nIGEgbmV3IEVWUE4gRXh0ZW5kZWQgQ29tbXVuaXR5IGNhbGxlZCBFLVRS RUUgRXh0ZW5kZWQgQ29tbXVuaXR5DQo+PiA+ICAgKHNlY3Rpb24gNS4xKSBhbG9uZyB3aXRoIGFu IEV0aGVybmV0IEEtRCBwZXIgRVMgcm91dGUgd2l0aCBFU0kgb2YNCj4+ID4gICB6ZXJvIGFuZCBh IHNldCBvZiBSb3V0ZSBUYXJnZXRzIChSVHMpIGNvcnJlc3BvbmRpbmcgdG8gYWxsIHRoZSBsZWFm DQo+PiA+ICAgQUNzIG9uIHRoZSBQRS4NCj4+ID4NCj4+ID5QZXJoYXBzIGNoYW5nZSB0aGUgbGFz dCBzZW50ZW5jZSB0byAiLi4uIGNvcnJlc3BvbmRpbmcgdG8gYWxsIEVWSXMgdGhhdA0KPj4gPmhh dmUgbGVhZiBzaXRlcyBvbiB0aGUgUEUuIg0KPj4gDQo+PiBUaGUgc2Vjb25kIHRvIGxhc3Qgc2Vu dGVuY2Ugb2Ygc2VjdGlvbiAzLjIuMSBzYXlzIHRoZSBzYW1lIHRoaW5nLiBJDQo+PiBjaGFuZ2Vk IHRoaXMgc2VudGVuY2UgYW5kIHJlbW92ZWQgdGhlIDJuZCB0byBsYXN0IHNlbnRlbmNlLg0KPj4g DQo+PiA+DQo+PiA+My4yLjMgQlVNIHRyYWZmaWMgb3JpZ2luYXRlZCBmcm9tIGEgbXVsdGktaG9t ZWQgc2l0ZSBvbiBhIGxlYWYgQUMNCj4+ID4NCj4+ID4gICBJbiB0aGlzIHNjZW5hcmlvLCBpdCBp cyBhc3N1bWVkIHRoYXQgYSBtdWx0aS1ob21lZCBFdGhlcm5ldCBTZWdtZW50DQo+PiA+ICAgKEVT KSBjYW4gaGF2ZSBhIG1peGVkIG9mIGJvdGggbGVhZiBhbmQgcm9vdCBBQ3Mgd2l0aCBlYWNoIEFD DQo+PiA+ICAgZGVzaWduYXRpbmcgYSBzdWJuZXQgKGUuZy4sIGEgVkxBTikuDQo+PiA+DQo+PiA+ SSB1bmRlcnN0YW5kIHRoYXQgZGlmZmVyZW50IFZMQU5zIG9uIHRoZSBzYW1lIEVTIGNvdWxkIGJl IHJvb3RzIG9yDQo+PiA+bGVhdmVzLiBJIHN1cHBvc2UgaXQncyBtb3JlIGltcG9ydGFudCB0byBz YXkgdGhhdCBmb3IgdGhlIHNhbWUgdmxhbiwNCj4+ID5kaWZmZXJlbnQgUEVzIG9uIHRoZSBzYW1l IEVTIG11c3QgaGF2ZSB0aGUgc2FtZSByb290L2xlYWYgZGVzaWduYXRpb24uDQo+PiANCj4+IFRo YXTCuXMgZ2l2ZW4uDQo+PiANCj4+ID4NCj4+ID5QZXJoYXBzIHRoZSBmaXJzdCBzZW50ZW5jZSBj b3VsZCBiZSByZXdvcmRlZCBhcyB0aGUgZm9sbG93aW5nIHRvDQo+PmNhcHR1cmUNCj4+ID50aGUg YWJvdmUgcG9pbnQ6DQo+PiA+DQo+PiA+ICAgV2hpbGUgZGlmZmVyZW50IEFDcyAoVkxBTnMpIG9u IHRoZSBzYW1lIEVTIGNvdWxkIGhhdmUgZGlmZmVyZW50DQo+PiA+ICAgcm9vdC9sZWFmIGRlc2ln bmF0aW9uIChzb21lIGJlaW5nIHJvb3RzIGFuZCBzb21lIGJlaW5nIGxlYXZlcyksDQo+PiA+ICAg dGhlIHNhbWUgVkxBTiBkb2VzIGhhdmUgdGhlIHNhbWUgcm9vdC9sZWFmIGRlc2lnbmF0aW9uIG9u IGFsbA0KPj4gPiAgIFBFcyBvbiB0aGUgc2FtZSBFUy4NCj4+IA0KPj4gVGhhdMK5cyBmaW5lLiBJ dCBtYWtlcyBpdCBtb3JlIGNsZWFyLg0KPj4gDQo+PiA+DQo+PiA+Rm9yIHRoZSBmb2xsb3dpbmc6 DQo+PiA+DQo+PiA+ICAgLi4uIHRoZSBQRXMgd2l0aCBMZWFmIHNpdGVzIHBlcmZvcm0gTUFDIGxl YXJuaW5nIGluIHRoZQ0KPj4gPiAgIGRhdGEtcGF0aCBvdmVyIHRoZWlyIEV0aGVybmV0IFNlZ21l bnRzLCBhbmQgYWR2ZXJ0aXNlIHJlYWNoYWJpbGl0eQ0KPj5pbg0KPj4gPiAgIEVWUE4gTUFDIEFk dmVydGlzZW1lbnQgcm91dGVzIHdoaWNoIGFyZSBpbXBvcnRlZCBvbmx5IGJ5IFBFcyB3aXRoIGF0 DQo+PiA+ICAgbGVhc3Qgb25lIFJvb3Qgc2l0ZSBpbiB0aGUgRVZJLiBBIFBFIHdpdGggb25seSBM ZWFmIHNpdGVzIHdpbGwgbm90DQo+PiA+ICAgaW1wb3J0IHRoZXNlIHJvdXRlcy4gUEVzIHdpdGgg Um9vdCBhbmQvb3IgTGVhZiBzaXRlcyBtYXkgdXNlIHRoZQ0KPj4gPiAgIEV0aGVybmV0IEEtRCBy b3V0ZXMgZm9yIGFsaWFzaW5nIChpbiB0aGUgY2FzZSBvZiBtdWx0aS1ob21lZA0KPj4gPiAgIHNl Z21lbnRzKSBhbmQgZm9yIG1hc3MgTUFDIHdpdGhkcmF3YWwgcGVyIFtSRkMgNzQzMl0uDQo+PiA+ DQo+PiA+VGhlIGFib3ZlIHNlZW1zIHRvIGNvbnRyYWRpY3Qgd2l0aCB0aGUgcmVjb21tZW5kYXRp b24gaW4gU2VjdGlvbiAyLjIuDQo+PklmDQo+PiA+dGhlIGNvbnRleHQgaXMgdGhlIHNjZW5hcmlv IGRlc2NyaWJlZCBpbiBzZWN0aW9uIDIuMSB0aGVuIHRoYXQncyBmaW5lLA0KPj4gPmJ1dCB0aGUg dGV4dCBkb2VzIG5vdCBoYXZlIGEgY2xlYXIgY29udGV4dC4NCj4+IA0KPj4gQWdyZWVkLiBVcGRh dGVkIHRoZSBzZWN0aW9uIHRvIGluZGljYXRlIHRoZSBjb250ZXh0IGlzIHNlY3Rpb24gMi4xLg0K Pj4gDQo+PiA+DQo+PiA+DQo+PiA+My4zLjIgRS1UcmVlIHdpdGhvdXQgTUFDIExlYXJuaW5nDQo+ PiA+DQo+PiA+ICAgVGhlIFBFcyBpbXBsZW1lbnRpbmcgYW4gRS1UcmVlIHNlcnZpY2UgbmVlZCBu b3QgcGVyZm9ybSBNQUMgbGVhcm5pbmcNCj4+ID4gICB3aGVuIHRoZSB0cmFmZmljIGZsb3dzIGJl dHdlZW4gUm9vdCBhbmQgTGVhZiBzaXRlcyBhcmUgbXVsdGljYXN0IG9yDQo+PiA+ICAgYnJvYWRj YXN0Lg0KPj4gPg0KPj4gPkkgc3VwcG9zZSBhbiAib25seSIgd29yZCBzaG91bGQgYmUgYWRkZWQg YXQgdGhlIGVuZCBvZiB0aGUgYWJvdmUNCj4+c2VudGVuY2UuDQo+PiANCj4+IEFncmVlZC4NCj4+ IA0KPj4gPg0KPj4gPg0KPj4gPiAgIFRoZSBmaWVsZHMgb2YgdGhlIElNRVQgcm91dGUgYXJlIHBv cHVsYXRlZCBwZXIgdGhlIHByb2NlZHVyZXMNCj4+ZGVmaW5lZA0KPj4gPiAgIGluIFtSRkM3NDMy XSwgYW5kIHRoZSByb3V0ZSBpbXBvcnQgcnVsZXMgYXJlIGFzIGRlc2NyaWJlZCBpbg0KPj5wcmV2 aW91cw0KPj4gPiAgIHNlY3Rpb25zLg0KPj4gPg0KPj4gPlRoZSByb3V0ZSBpbXBvcnQgcnVsZXMg ZGVzY3JpYmVkIGluIHByZXZpb3VzIHNlY3Rpb25zIGFyZSBmb3IgTUFDDQo+PnJvdXRlcywNCj4+ ID5ub3QgSU1FVCByb3V0ZXMuIEFkZGl0aW9uYWxseSwgdGhvc2UgcnVsZXMgbWF5IG5vdCBiZSBy ZWNvbW1lbmRlZCwgc28NCj4+ID5taWdodCBhcyB3ZWxsIGRlbGV0ZSB0aGUgbGFzdCBzZW50ZW5j ZS4NCj4+IA0KPj4gQ2hhbmdlZCB0aGUgbGFzdCBzZW50ZW5jZSB0byDCs8WgLCBhbmQgdGhlIG11 bHRpY2FzdCB0dW5uZWwgc2V0dXAgY3JpdGVyaWENCj4+IGFyZSBhcyBkZXNjcmliZWQgaW4gdGhl IHByZXZpb3VzIHNlY3Rpb24uwrINCj4+IA0KPj4gPg0KPj4gPlNlY3Rpb24gMy4zLjEgdGFsa3Mg YWJvdXQgQlVNIHByb2NlZHVyZXMuIFRoYXQgaXMgbm90IHNwZWNpZmljIHRvIDMuMy4xDQo+PiA+ dGhvdWdoLiBQZXJoYXBzIGV4dHJhY3QgdGhhdCBvdXQgdG8gYSBzZXBhcmF0ZSBzZWN0aW9uLCBh bmQgcmVtb3ZlIHRoZQ0KPj4gPkJVTSB0ZXh0IGZyb20gMy4zLjIgYXMgd2VsbC4NCj4+IA0KPj4g SSB0aGluayBpdCBpcyBPSy4NCj4+IA0KPj4gPg0KPj4gPiAgIFRoZSBFLVRSRUUgRXh0ZW5kZWQg Q29tbXVuaXR5IGlzIGVuY29kZWQgYXMgYW4gOC1vY3RldCB2YWx1ZSBhcw0KPj4gPiAgIGZvbGxv d3M6DQo+PiA+DQo+PiA+DQo+PiA+ICAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAg ICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQo+PiA+ICAgICAgICAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4+ ID4gICAgICAgDQo+PistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQo+PiA+ICAgICAgIHwgVHlwZT0weDA2ICAgICB8IFN1Yi1U eXBlPTB4MDQgfCBGbGFncygxIE9jdGV0KXwNCj4+fA0KPj4gPiAgICAgICANCj4+Ky0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN Cj4+ID4gICAgICAgfCAgUmVzZXJ2ZWQ9MCAgIHwgICAgICAgICAgIExlYWYgTGFiZWwNCj4+fA0K Pj4gPiAgICAgICANCj4+Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4+ID4NCj4+ID5JIGFzc3VtZSB0aGUgb2N0ZWN0IGFm dGVyIHRoZSBmbGFncyBvY3RldCBpcyBhbHNvIHJlc2VydmVkPTAuIEJldHRlcg0KPj5tYXJrDQo+ PiA+aXQgYXMgIlJlc2VydmVkPTAiLg0KPj4gDQo+PiBBZ3JlZWQuDQo+PiANCj4+ID4NCj4+ID5X aGVuIGl0IGlzIHVzZWQgd2l0aCBFdGhlcm5ldCBBLUQgcGVyIEVTIHJvdXRlLCB0aGUgbGVhZiBm bGFnIFNIT1VMRCBiZQ0KPj4gPnNldCB0byAwIGJ1dCBpZ25vcmVkIGJ5IHRoZSByZWNlaXZpbmcg cm91dGVycy4gVGhlcmVmb3JlLCB3aHkgbm90IHNldA0KPj5pdA0KPj4gPnRvIDEgdG8gYmUgY29u c2lzdGVudCB0aGUgTUFDL0lQIHJvdXRlIGNhc2U/DQo+PiANCj4+IEJlY2F1c2UgdGhlIGZsYWcg aXMgdXNlZCBmb3Iga25vd24gdW5pY2FzdCB0cmFmZmljIGFuZCBMZWFmIGxhYmVsIGZvcg0KPj5C VU0NCj4+IHRyYWZmaWMuIFdlIGRvbsK5dCB3YW50IHRvIG1peCB0aGUgdHdvLg0KPj4gDQo+PiBD aGVlcnMsDQo+PiBBbGkNCj4+IA0KPj4gPg0KPj4gPlRoYW5rcy4NCj4+ID5KZWZmcmV5DQo+PiA+ DQo+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gRnJvbTogQkVTUyBbbWFp bHRvOmJlc3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRob21hcyBNb3Jpbg0KPj4g Pj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAxOSwgMjAxNiAzOjUxIEFNDQo+PiA+PiBUbzogQkVT UyA8YmVzc0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtYmVzcy1ldnBuLWV0cmVlQHRvb2xzLmlldGYu b3JnDQo+PiA+PiBTdWJqZWN0OiBbYmVzc10gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtYmVz cy1ldnBuLWV0cmVlDQo+PiA+Pg0KPj4gPj4gSGVsbG8gV29ya2luZyBHcm91cCwNCj4+ID4+DQo+ PiA+PiBUaGlzIGVtYWlsIHN0YXJ0cyBhIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uDQo+PiA+ PiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZSBbMV0gd2hpY2ggaXMgY29uc2lkZXJlZCBtYXR1 cmUgYW5kIHJlYWR5DQo+PmZvcg0KPj4gPj4gYSBmaW5hbCB3b3JraW5nIGdyb3VwIHJldmlldy4N Cj4+ID4+DQo+PiA+PiBQbGVhc2UgcmVhZCB0aGUgZG9jdW1lbnQgaWYgeW91IGhhdmVuJ3QgcmVh ZCB0aGUgbW9zdCByZWNlbnQgdmVyc2lvbg0KPj4geWV0DQo+PiA+PiAoLTAzKSwgYW5kIHNlbmQg eW91ciBjb21tZW50cyB0byB0aGUgbGlzdCwgbm8gbGF0ZXIgdGhhbiAqRmVicnVhcnkNCj4+dGhl DQo+PiA+PiAybmQqICgyMDE2LTAyLTAyKS4NCj4+ID4+DQo+PiA+PiBUaGlzIGlzIG5vdCBvbmx5 IGEgY2FsbCBmb3IgY29tbWVudHMgb24gdGhlIGRvY3VtZW50LCBidXQgYWxzbyBhIGNhbGwNCj4+ IG9mDQo+PiA+PiBzdXBwb3J0IGZvciBpdHMgcHVibGljYXRpb24uDQo+PiA+Pg0KPj4gPj4gKkNv aW5jaWRlbnRhbGx5Kiwgd2UgYXJlIGFsc28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9mIGFueSBJ UFIgdGhhdA0KPj4gPj4gYXBwbGllcyB0byBkcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZSwgdG8g ZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVuDQo+PiA+PiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3 aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LA0KPj4zNjY5DQo+PiA+PiBh bmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCj4+ID4+DQo+PiA+PiAqSWYqIHlvdSBhcmUgbGlz dGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIG9mDQo+PiA+PiBkcmFmdC1p ZXRmLWJlc3MtZXZwbi1ldHJlZSBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIGFuZCBpbmRp Y2F0ZQ0KPj4gPj4gd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQg SVBSLg0KPj4gPj4NCj4+ID4+IFRoYW5rIHlvdSwNCj4+ID4+DQo+PiA+PiBUaG9tYXMvTWFydGlu DQo+PiA+Pg0KPj4gPj4gWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtYmVzcy1ldnBuLWV0cmVlDQo+PiA+Pg0KPj4gPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IEJFU1MgbWFpbGluZyBsaXN0DQo+PiA+ PiBCRVNTQGlldGYub3JnDQo+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Jlc3MNCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gPkJFU1MgbWFpbGluZyBsaXN0DQo+PiA+QkVTU0BpZXRmLm9yZw0KPj4g Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVzcw0KPg0KDQo= From nobody Tue Mar 15 15:58:46 2016 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 0161512DE08 for ; Tue, 15 Mar 2016 15:58:45 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 7_k6YmpGSs8J for ; Tue, 15 Mar 2016 15:58:43 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5697312DE36 for ; Tue, 15 Mar 2016 15:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1729; q=dns/txt; s=iport; t=1458082309; x=1459291909; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CvubtgEAF8/JUXxvoFo1aPguIcmD4Pp16LEuGilPlfU=; b=haZrxlQyzgJUTuvNqLLJJnzJfunh2/E3SP7zeRLh2EJR86gFtPFpJUNx Iw92D8KmPjSyRMkYONCYjzzAva/qiGJ8jlq1MP2ADw+s5yz9XHiRzZRfN hl8E0Bb0KmbeG4CCbaEoVSSfqnfEMB0VG+yK4TbSvqn2pS2w9oA8bCCsv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBACnkOhW/xbLJq1ehBpuBrxJFwqFb?= =?us-ascii?q?AKCBwEBAQEBAWUnhEIBAQQBAQE3NAsQAgEIGB4QJwslAgQBDQWIJw6+agEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAREEhhqEQoQLEQGEWAEEl08BhW6IEoFlhEmIV45+A?= =?us-ascii?q?WKDZWqJMTR+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,341,1454976000"; d="scan'208";a="634468941" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2016 22:51:47 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2FMpkYg000923 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 22:51:47 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 18:51:45 -0400 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1104.009; Tue, 15 Mar 2016 18:51:45 -0400 From: "Gaurav Dawra (gdawra)" To: "Dhananjaya Rao (dhrao)" , Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Thread-Index: AQHRbZJQpHLPkTaW3U6h1WCC55PmEZ9YSdyAgALDKQA= Date: Tue, 15 Mar 2016 22:51:45 +0000 Message-ID: References: <56CB3E3E.6080602@alcatel-lucent.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.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.35.68.169] Content-Type: text/plain; charset="us-ascii" Content-ID: <0810DABF3F7967428F47A7EBFB2C4844@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Gaurav Dawra \(gdawra\)" , "draft-fm-bess-service-chaining@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 15 Mar 2016 22:58:45 -0000 >Support. Cheers, -G. > > >On 2/22/16, 8:58 AM, "BESS on behalf of Martin Vigoureux" > wrote: > >>Hello working group, >> >>This email starts a two-week poll on adopting >>draft-fm-bess-service-chaining-02 [1] as a working group Document. >> >>Please state on the list if you support adoption or not (in both cases, >>please also state the reasons). >> >>This poll runs until *the 7th of March*. >> >>Note that IPR has been disclosed against an earlier version of this >>document: >>https://datatracker.ietf.org/ipr/2284/ >> >>Yet, we are *coincidentally* also polling for knowledge of any other >>IPR that applies to this draft, to ensure that IPR has been disclosed >>in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >>and 5378 for more details). >> >>=3D=3D> *If* you are listed as a document author or contributor please >>respond to this email and indicate whether or not you are aware of any >>relevant IPR. >> >>The draft will not be adopted until a response has been received from >>each author and contributor. >> >>If you are not listed as an author or contributor, then please >>explicitly respond only if you are aware of any IPR that has not yet >>been disclosed in conformance with IETF rules. >> >>Thank you, >> >>Martin & Thomas >>bess chairs >> >>[1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ >> >>_______________________________________________ >>BESS mailing list >>BESS@ietf.org >>https://www.ietf.org/mailman/listinfo/bess > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Tue Mar 15 16:10:04 2016 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 082C012DE68 for ; Tue, 15 Mar 2016 16:10:03 -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_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 hsHNGcgBPQ_X for ; Tue, 15 Mar 2016 16:09:51 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A9012DE5F for ; Tue, 15 Mar 2016 16:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1740; q=dns/txt; s=iport; t=1458083386; x=1459292986; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=A5uVbn18NmVuwITeMBy9Cm8Z5fewJH8nnIA2ccBO92Y=; b=M7Yv38ynAa1Er7fNjJrsp0yIzKWLnY3RdxToV/W6+bV+3KURACaHaCRT idKY4lQN1isU02uYe8mEY6593Eec+9kSvHN+DnS6FwgMhJhSD8Q/y0NG5 0TYeX0extwt74cTB52d3V1daqgC0u8WlfiqYR7pZhD+sfPHSoRaNg+agn U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgAKluhW/5xdJa1eg0ZUbga6TQENg?= =?us-ascii?q?W4XCoVsAoE8OBQBAQEBAQEBZCeEQgEBBAEBATc0CxACAQgYHhAnCyUCBAENBYg?= =?us-ascii?q?nDr5wAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSKXIQLEQGEWAWTBIRLAYVuiBKBZ?= =?us-ascii?q?YRJiFeOfgEeAQFCg2VqiTE0fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,341,1454976000"; d="scan'208";a="83182044" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2016 23:09:41 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u2FN9ecB017732 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 23:09:40 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 18:09:40 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Tue, 15 Mar 2016 18:09:40 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Thread-Index: AQHRbZJQpHLPkTaW3U6h1WCC55PmEZ9YSdyAgAMcA4A= Date: Tue, 15 Mar 2016 23:09:40 +0000 Message-ID: References: <56CB3E3E.6080602@alcatel-lucent.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.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.227.77] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-fm-bess-service-chaining@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 15 Mar 2016 23:10:03 -0000 Hi, Support. Regards, Nagendra > >On 2/22/16, 8:58 AM, "BESS on behalf of Martin Vigoureux" > wrote: > >>Hello working group, >> >>This email starts a two-week poll on adopting >>draft-fm-bess-service-chaining-02 [1] as a working group Document. >> >>Please state on the list if you support adoption or not (in both cases, >>please also state the reasons). >> >>This poll runs until *the 7th of March*. >> >>Note that IPR has been disclosed against an earlier version of this >>document: >>https://datatracker.ietf.org/ipr/2284/ >> >>Yet, we are *coincidentally* also polling for knowledge of any other >>IPR that applies to this draft, to ensure that IPR has been disclosed >>in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >>and 5378 for more details). >> >>=3D=3D> *If* you are listed as a document author or contributor please >>respond to this email and indicate whether or not you are aware of any >>relevant IPR. >> >>The draft will not be adopted until a response has been received from >>each author and contributor. >> >>If you are not listed as an author or contributor, then please >>explicitly respond only if you are aware of any IPR that has not yet >>been disclosed in conformance with IETF rules. >> >>Thank you, >> >>Martin & Thomas >>bess chairs >> >>[1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ >> >>_______________________________________________ >>BESS mailing list >>BESS@ietf.org >>https://www.ietf.org/mailman/listinfo/bess > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Tue Mar 15 16:45:43 2016 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 C1FEA12D648 for ; Tue, 15 Mar 2016 16:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6O41_viV-qw for ; Tue, 15 Mar 2016 16:45:39 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.149]) (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 A4DEF12D52F for ; Tue, 15 Mar 2016 16:45:39 -0700 (PDT) Received: from [85.158.136.3] by server-13.bemta-5.messagelabs.com id 9C/3F-03786-1AE98E65; Tue, 15 Mar 2016 23:45:37 +0000 X-Env-Sender: daniel.bernier@bell.ca X-Msg-Ref: server-3.tower-123.messagelabs.com!1458085533!20237684!2 X-Originating-IP: [206.172.1.99] X-StarScan-Received: X-StarScan-Version: 8.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15947 invoked from network); 15 Mar 2016 23:45:34 -0000 Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (206.172.1.99) by server-3.tower-123.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 15 Mar 2016 23:45:34 -0000 X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE02-DOR.bell.corp.bce.ca Received: from DG3MBX04-WYN.bell.corp.bce.ca (198.235.121.232) by EX13EDGE02-DOR.bell.corp.bce.ca (198.235.121.55) with Microsoft SMTP Server id 15.0.1076.9; Tue, 15 Mar 2016 19:38:31 -0400 Received: from DG3MBX04-WYN.bell.corp.bce.ca (2002:8eb6:121a::8eb6:121a) by DG3MBX04-WYN.bell.corp.bce.ca (2002:8eb6:121a::8eb6:121a) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 19:45:32 -0400 Received: from DG3MBX04-WYN.bell.corp.bce.ca ([fe80::cd18:4ea5:9061:8145]) by DG3MBX04-WYN.bell.corp.bce.ca ([fe80::cd18:4ea5:9061:8145%22]) with mapi id 15.00.1104.000; Tue, 15 Mar 2016 19:45:32 -0400 From: "Bernier, Daniel (520165)" To: "martin.vigoureux@nokia.com" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Thread-Index: AQHRfxTDpHLPkTaW3U6h1WCC55PmEQ== Date: Tue, 15 Mar 2016 23:45:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.25.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D232BAAC1E66A42B174A516F170DDFC@exchange.bell.ca> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Received-SPF: SoftFail (EX13EDGE02-DOR.bell.corp.bce.ca: domain of transitioning daniel.bernier@bell.ca discourages use of 198.235.121.232 as permitted sender) X-OrganizationHeadersPreserved: EX13EDGE02-DOR.bell.corp.bce.ca Archived-At: Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 15 Mar 2016 23:45:42 -0000 Hi, Support - DB From: BESS > on behalf = of "Rex Fernando (rex)" > Date: Tuesday, March 15, 2016 at 12:07 PM To: "martin.vigoureux@nokia.com" >, "bess@ietf.org" > Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Hi Martin, As one of the authors of this draft, I support its adoption. I am not aware= of any related IPR apart from the ones that have been disclosed. Cheers, Rex From nobody Wed Mar 16 01:49:44 2016 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 49E9212D869 for ; Wed, 16 Mar 2016 01:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 RcJJ-tnyMsZc for ; Wed, 16 Mar 2016 01:49:41 -0700 (PDT) Received: from BLU004-OMC1S3.hotmail.com (blu004-omc1s3.hotmail.com [65.55.116.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B960612D80B for ; Wed, 16 Mar 2016 01:49:40 -0700 (PDT) Received: from BLU436-SMTP250 ([65.55.116.7]) by BLU004-OMC1S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 16 Mar 2016 01:49:39 -0700 X-TMN: [6+v+qZG14rSVJGqnkKs+dTJS/jF6B3ENjZz318V0Wqc=] X-Originating-Email: [li_zhenqiang@hotmail.com] Message-ID: Date: Wed, 16 Mar 2016 16:57:10 +0800 From: "li_zhenqiang@hotmail.com" To: "Eric C Rosen" , bess References: , <56E044DB.4090302@juniper.net>, , <56E715A9.1080201@juniper.net> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 26[cn] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_001_NextPart875425141687_=----" X-OriginalArrivalTime: 16 Mar 2016 08:49:39.0214 (UTC) FILETIME=[C65EBAE0:01D17F60] Archived-At: Subject: Re: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 16 Mar 2016 08:49:43 -0000 ------=_001_NextPart875425141687_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIEVyaWMgYW5kIGFsbCwNCg0KVHJ5IHRvIGFuc3dlciB5b3VyIHF1ZXN0aW9ucyBiZWxvdywg cGxlYXNlIGNvbW1lbnQuDQoNClE6IElmIHRoZSBjb3JlIHJ1bnMgb25seSBJUHY2L01QTFMsIGFu ZCB0aGUgbmV4dCBob3Agb2YgYSA0UEUgcm91dGUgaXMgYW4gSVB2NCBhZGRyZXNzLCBJIGRvbid0 IHJlYWxseSBzZWUgaG93IHRoZSBuZXh0IGhvcCByZXNvbHV0aW9uIGlzIGdvaW5nIHRvIHdvcmss IGFzIHRoZSBuZXh0IGhvcCAoYSB2NCBhZGRyZXNzKSB3aWxsIG5vdCBhcHBlYXIgdG8gYmUgcmVh Y2hhYmxlIHRocm91Z2ggdGhlIHY2IGNvcmUuDQpBOiBObywgeW91IGNhbiBub3QgdXNlIHRoZSB2 NCBuZXh0IGhvcCB0byByZWFjaCB0aGUgZWdyZXNzIDRQRSBpbiB0aGUgdjYgY29yZSBkaXJlY3Rs eS4gQnV0LCB0aGUgaW5ncmVzcyA0UEUgY2FuIHVzZSB0aGUgdjQgbmV4dCBob3AgdG8gZ2V0IHRo ZSBjb3JyZXNwb25kaW5nIHY2IGFkZHJlc3Mgb2YgdGhlIGVncmVzcyA0UEUgYW5kIGZvcndhcmQg dGhlIHBhY2tldCB0b3dhcmQgdGhlIGVncmVzcyA0UEUgdGhyb3VnaCB0aGUgdjYgTFNQIGFmdGVy IGVuY2Fwc3VsYXRpb24uIEVuY2Fwc3VsYXRpb24gaGVyZSBtZWFucyBhZGRpbmcgdHdvIGxhYmVs cy4gSW5ncmVzcyA0UEUgbmVlZHMgYSBkYXRhIHN0cnVjdHVyZSB0byBlc3RhYmxpc2ggdGhlIGNv bm5lY3Rpb24gYmV0d2VlbiB0aGUgdjQgbmV4dCBob3AgYW5kIHRoZSB0aGUgY29ycmVzcG9uZGlu ZyB2NiBhZGRyZXNzIG9mIHRoZSBlZ3Jlc3MgNFBFLiBUaGlzIGRhdGEgc3RydWN0dXJlIGlzIGlt cGxlbWVudGF0aW9uIHNwZWNpZmljLg0KDQpROiBJIHRoaW5rIHlvdXIgcHJvcG9zYWwgcmVhbGx5 IGlzIGludGVuZGVkIHRvIHRyZWF0IHRoZSB2NiBhZGRyZXNzIGluIHRoZSBOTFJJIGFzIHRoZSBu ZXh0IGhvcC4gIEJ1dCB0aGF0IGxlYXZlcyBvcGVuIHRoZSBxdWVzdGlvbiBvZiB3aHkgeW91IHdh bnQgdG8gcHV0IHRoZSBuZXh0IGhvcCBhZGRyZXNzIGluIHRoZSBOTFJJIGZpZWxkIGluc3RlYWQg b2YgaW4gdGhlIG5leHQgaG9wIGZpZWxkLg0KQTogV2hhdCBJIHdhbnQgaXMgdG8gc2VuZCBib3Ro IHRoZSBJUHY0IGFuZCBJUHY2IGFkZHJlc3NlcyBvZiB0aGUgNFBFIHRvIG90aGVyIDRQRXMuDQoN ClE6IFNvbWUgcGVvcGxlIHRoaW5rIGl0J3MgYSBiYWQgaWRlYSBmb3IgdGhlIHByZWZpeCBhbmQg dGhlIG5leHQgaG9wIHRvIGJlIG9mIGRpZmZlcmVudCBhZGRyZXNzIGZhbWlsaWVzOyB0aG9zZSBm b2xrcyB0ZW5kIHRvIHJlZ2FyZCBSRkMgNTU0OSBhcyBhIGJhZCBzb2x1dGlvbi4NCkE6IEkgZG9u J3QgdGhpbmsgSSBhbSBvbmUgb2YgdGhvc2UgZm9sa3MuDQoNClE6IEhvd2V2ZXIsIEkgZG9uJ3Qg c2VlIHdoYXQgYWR2YW50YWdlIHlvdXIgcHJvcG9zYWwgaGFzIG92ZXIgUkZDIDU1NDkuICAgSW4g b3JkZXIgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYSBnaXZlbiA0UEUgcm91dGUgaXMgZmVhc2libGUs IG9yIHdoZXRoZXIgaXQgaXMgdGhlIGJlc3RwYXRoLCB5b3Ugc3RpbGwgaGF2ZSB0byByZXNvbHZl IHRoZSBJUHY2IG5leHQgaG9wLCB5b3Ugc3RpbGwgaGF2ZSB0byBjb25zaWRlciB0aGUgSUdQIGRp c3RhbmNlIHRvIHRoZSBJUHY2IG5leHQgaG9wLCBldGMuICANCkE6IElmIDRQRSBvbmx5IGdldHMg dGhlIHY2IGFkZHJlc3NlcyBvZiB0aGUgb3RoZXIgNFBFcywgaG93IGRvZXMgdGhlIDRQRSBidWls ZCBpdHMgSVB2NCByb3V0aW5nIHRhYmxlPyBDYW4gaXQgaW5zdGFsbCBhIHY2IGFkZHJlc3MgaW4g aXRzIHY0IHJvdXRpbmcgdGFibGU/DQoNCg0KDQpsaV96aGVucWlhbmdAaG90bWFpbC5jb20NCiAN CkZyb206IEVyaWMgQyBSb3Nlbg0KRGF0ZTogMjAxNi0wMy0xNSAwMzo0OA0KVG86IGxpX3poZW5x aWFuZ0Bob3RtYWlsLmNvbTsgYmVzcw0KU3ViamVjdDogUmU6IFtiZXNzXSBGdzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1iZXNzLTRwZS0wMS50eHQNCk9uIDMvMTAvMjAx NiA0OjMyIEFNLCBsaV96aGVucWlhbmdAaG90bWFpbC5jb20gd3JvdGU6DQpUaGFuayB5b3UgdmVy eSBtdWNoIGZvciB5b3VyIGNvbW1lbnRzLCBFcmljLg0KDQpZZXMsIFJGQzU1NDkgZG9lcyBzcGVj aWZ5IHRoZSAgcHJvY2VkdXJlcyBmb3IgY3JlYXRpbmcgYSByb3V0ZSB3aXRoIElQdjQgb3IgVlBO LUlQdjQgTkxSSSBhbmQgYW4gSVB2NiBuZXh0IGhvcC4gSVB2NCBOTFJJIHdpdGggSVB2NiBuZXh0 IGhvcCBpcyBmb3IgdGhlIHNpdHVhdGlvbiB3aGVyZSBhbiBJUHY2LW9ubHkgbmV0d29yayBjb25u ZXRpbmcgSVB2NC1vbmx5IGlzbGFuZHMuIFZQTi1JUHY0IE5MUkkgd2l0aCBJUHY2IG5leHQgaG9w IGlzIGZvciB0aGUgNHZQRSBzaXR1YXRpb24uDQoNCldoYXQgSSB3YW50IHRvIHNvbHZlIGlzIHRo ZSA0UEUgc2l0dWF0aW9uLCB3aGVyZSBhbiBJUHY2LW9ubHkgbmV0d29yayBydW5uaW5nIHdpdGgg TVBMUyBjb25uZWN0aW5nIHRoZSBJUHY0LW9ubHkgaXNsYW5kcy4gVGhlIHJvdXRlcyBpbiB0aGUg NFBFIE5MUkkgaGF2ZSBsYWJlbHMgYXNzaWduZWQgYnkgdGhlIDRQRSByb3V0ZXJzLg0KDQpSRkMg NTU0OSB3aWxsIHdvcmsgd2hlbiB0aGUgSVB2Ni1vbmx5IG5ldHdvcmsgcnVucyBNUExTLg0KDQpJ ZiB5b3Ugd2FudCB0aGUgNFBFIHJvdXRlcnMgdG8gc2VuZCBsYWJlbGVkIElQdjQgcm91dGVzIHRv IGVhY2ggb3RoZXIsIHRoZXkganVzdCBuZWVkIHRvIHVzZSBTQUZJIDQuDQoNCklmIHRoZSBjb3Jl IHJ1bnMgb25seSBJUHY2L01QTFMsIGFuZCB0aGUgbmV4dCBob3Agb2YgYSA0UEUgcm91dGUgaXMg YW4gSVB2NCBhZGRyZXNzLCBJIGRvbid0IHJlYWxseSBzZWUgaG93IHRoZSBuZXh0IGhvcCByZXNv bHV0aW9uIGlzIGdvaW5nIHRvIHdvcmssIGFzIHRoZSBuZXh0IGhvcCAoYSB2NCBhZGRyZXNzKSB3 aWxsIG5vdCBhcHBlYXIgdG8gYmUgcmVhY2hhYmxlIHRocm91Z2ggdGhlIHY2IGNvcmUuDQoNCkkg dGhpbmsgeW91ciBwcm9wb3NhbCByZWFsbHkgaXMgaW50ZW5kZWQgdG8gdHJlYXQgdGhlIHY2IGFk ZHJlc3MgaW4gdGhlIE5MUkkgYXMgdGhlIG5leHQgaG9wLiAgQnV0IHRoYXQgbGVhdmVzIG9wZW4g dGhlIHF1ZXN0aW9uIG9mIHdoeSB5b3Ugd2FudCB0byBwdXQgdGhlIG5leHQgaG9wIGFkZHJlc3Mg aW4gdGhlIE5MUkkgZmllbGQgaW5zdGVhZCBvZiBpbiB0aGUgbmV4dCBob3AgZmllbGQuDQoNCg0K QmVzaWRlcywgNFBFIHJvdXRlcnMgbmVlZCBib3RoIElQdjQgbmV4dCBob3AgYW5kIElQdjYgbmV4 dCBob3AgdG8gYnVpbGQgdGhlaXIgSVB2NCByb3V0aW5nIHRhYmxlIGFuZCBJUHY2IHJvdXRpbmcg dGFibGUgcmVzcGVjdGl2ZWx5Lg0KDQpTb21lIHBlb3BsZSB0aGluayBpdCdzIGEgYmFkIGlkZWEg Zm9yIHRoZSBwcmVmaXggYW5kIHRoZSBuZXh0IGhvcCB0byBiZSBvZiBkaWZmZXJlbnQgYWRkcmVz cyBmYW1pbGllczsgdGhvc2UgZm9sa3MgdGVuZCB0byByZWdhcmQgUkZDIDU1NDkgYXMgYSBiYWQg c29sdXRpb24uDQoNCkhvd2V2ZXIsIEkgZG9uJ3Qgc2VlIHdoYXQgYWR2YW50YWdlIHlvdXIgcHJv cG9zYWwgaGFzIG92ZXIgUkZDIDU1NDkuICAgSW4gb3JkZXIgdG8gZGV0ZXJtaW5lIHdoZXRoZXIg YSBnaXZlbiA0UEUgcm91dGUgaXMgZmVhc2libGUsIG9yIHdoZXRoZXIgaXQgaXMgdGhlIGJlc3Rw YXRoLCB5b3Ugc3RpbGwgaGF2ZSB0byByZXNvbHZlIHRoZSBJUHY2IG5leHQgaG9wLCB5b3Ugc3Rp bGwgaGF2ZSB0byBjb25zaWRlciB0aGUgSUdQIGRpc3RhbmNlIHRvIHRoZSBJUHY2IG5leHQgaG9w LCBldGMuICANCg0KDQoNCg0K ------=_001_NextPart875425141687_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A = =0A =0A
Hi, Eric and all,

Try t= o answer your questions below, please comment.

Q:=  If the core runs only IPv6/MPLS, and the next hop of a 4PE rout= e is an IPv4 address, I don't really see how the next hop resolution is go= ing to work, as the next hop (a v4 address) will not appear to be reachabl= e through the v6 core.
A: No, you can not use the v4= next hop to reach the egress 4PE in the v6 core directly. But, the ingres= s 4PE can use the v4 next hop to get the corresponding v6 address of the e= gress 4PE and forward the packet toward the egress 4PE through the v6 LSP = after encapsulation. Encapsulation here means adding two labels. Ingress 4= PE needs a data structure to establish the connection between the v4 next = hop and the the corresponding v6 address of the egress 4P= E. This data structure is implementation specific.
<= br>
Q: I think your proposal really is intended to treat = the v6 address in the NLRI as the next hop.  But that leaves open the= question of why you want to put the next hop address in the NLRI field in= stead of in the next hop field.
A: What I want is to send both t= he IPv4 and IPv6 addresses of the 4PE to other 4PEs.

<= div>Q: Some people think it's a bad idea for the prefix and the next hop t= o be of different address families; those folks tend to regard RFC 5549 as= a bad solution.
A: I don't think I am one of those folks.
Q: However, I don't see what advantage your proposal has over RFC 5549. =   In order to determine whether a given 4PE route is feasible, or whe= ther it is the bestpath, you still have to resolve the IPv6 next hop, you = still have to consider the IGP distance to the IPv6 next hop, etc. &n= bsp;
A: If 4PE only gets the v6 addresses of the other 4PEs, how= does the 4PE build its IPv4 routing table? Can it install a v6 address in= its v4 routing table?
=0A

=0A
li_zh= enqiang@hotmail.com
=0A
 
Date: 2016-03-15 03:48<= /div><= div>Subject: Re: [bess] Fw: New Version Notification for draft= -li-bess-4pe-01.txt
=0A =0A =0A =0A =0A On 3/10/2016 4:32 AM, li_zhenq= iang@hotmail.com wrote:
=0A
=0A =0A =0A Thank you very much for your comments, Eric.
=0A =

=0A
=0A
Yes, RFC5549 does specify the <= span style=3D"font-size: 10.5pt;=0A line-height: 1.5; background-= color: window;"> procedures for creating a ro= ute with IPv4 or VPN-IPv4=0A NLRI and an IPv6 next hop. IPv4 NLRI= with IPv6 next hop is for=0A the situation where an IPv6-only ne= twork conneting IPv4-only=0A islands. VPN-IPv4 NLRI with IPv6 nex= t hop is for the 4vPE=0A situation.
=0A
=0A
=0A
What I want to solve is the 4PE situation, w= here an IPv6-only=0A network running with MPLS connecting the IPv4-= only islands. The=0A routes in the 4PE NLRI have labels assigned by= the 4PE routers.
=0A
=0A
=0A RFC 5549 will= work when the IPv6-only network runs MPLS.
=0A
=0A If you wa= nt the 4PE routers to send labeled IPv4 routes to each=0A other, they j= ust need to use SAFI 4.
=0A
=0A If the core runs only IPv6/MP= LS, and the next hop of a 4PE route is=0A an IPv4 address, I don't real= ly see how the next hop resolution is=0A going to work, as the next hop= (a v4 address) will not appear to be=0A reachable through the v6 core.=
=0A
=0A I think your proposal really is intended to treat th= e v6 address in=0A the NLRI as the next hop.  But that leaves open= the question of why=0A you want to put the next hop address in the NLR= I field instead of in=0A the next hop field.
=0A
=0A =0A

=0A
=0A
Besides, 4PE routers nee= d both IPv4 next hop and IPv6 next=0A hop to build their IPv4 routi= ng table and IPv6 routing table=0A respectively.
=0A =0A
=0A Some people think it's a bad idea for the prefix = and the next hop to=0A be of different address families; those folks te= nd to regard RFC=0A 5549 as a bad solution.
=0A
=0A Howeve= r, I don't see what advantage your proposal has over RFC 5549.=0A  = ; In order to determine whether a given 4PE route is feasible, or=0A wh= ether it is the bestpath, you still have to resolve the IPv6 next=0A ho= p, you still have to consider the IGP distance to the IPv6 next=0A hop,= etc. 
=0A
=0A
=0A
=0A
=0A =0A
=0A ------=_001_NextPart875425141687_=------ From nobody Wed Mar 16 02:28:17 2016 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 6F4E012D8C2; Wed, 16 Mar 2016 02:28:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160316092815.21680.97308.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 02:28:15 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-multicast-damping-04.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 09:28:15 -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 : Multicast VPN state damping Authors : Thomas Morin Stephane Litkowski Keyur Patel Zhaohui Zhang Robert Kebler Jeff Haas Filename : draft-ietf-bess-multicast-damping-04.txt Pages : 17 Date : 2016-03-16 Abstract: This document describes procedures to damp multicast VPN routing state changes and control the effect of the churn due to the multicast dynamicity in customer sites. The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control plane load increase in the core routing infrastructure. New procedures are proposed inspired from BGP unicast route damping principles, but adapted to multicast. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-multicast-damping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-multicast-damping-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-multicast-damping-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 16 16:30:50 2016 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 A7D3C12D612; Wed, 16 Mar 2016 16:30:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160316233049.29369.42937.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 16:30:49 -0700 Archived-At: Cc: bess@ietf.org, ipr-announce@ietf.org Subject: [bess] IPR Disclosure Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 23:30:49 -0000 Dear Ali Sajassi, Samer Salam, Sami Boutros, Jim Uttaro: An IPR disclosure that pertains to your Internet-Draft entitled "E-TREE Support in EVPN & PBB-EVPN" (draft-ietf-bess-evpn-etree) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2774/). The title of the IPR disclosure is "Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-bess-evpn-etree" Thank you IETF Secretariat From nobody Wed Mar 16 17:41:33 2016 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 DDCCF12D7BA; Wed, 16 Mar 2016 17:41:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317004130.30599.32384.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 17:41:30 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-vpws-03.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 00:41:31 -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 Jeff Tantsura Dirk Steinberg Thomas Beckhaus Jorge Rabadan Filename : draft-ietf-bess-evpn-vpws-03.txt Pages : 15 Date : 2016-03-16 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 single-segment and multi-segment PW signaling, and provides fast protection using data-plane prefix independent 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-vpws-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 17 18:19:11 2016 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 4A7D212D74D for ; Thu, 17 Mar 2016 18:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V_YON-4Fc4a for ; Thu, 17 Mar 2016 18:19:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 76AB612D6E6 for ; Thu, 17 Mar 2016 18:19:04 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 3E3EB6094A569 for ; Fri, 18 Mar 2016 09:19:01 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 08B0BB7266F54 for ; Fri, 18 Mar 2016 09:19:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u2I1Is6W006740 for ; Fri, 18 Mar 2016 09:18:54 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) To: bess@ietf.org MIME-Version: 1.0 X-KeepSent: 777A4906:BD16176D-48257F7A:00064318; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: hu.fangwei@zte.com.cn Date: Fri, 18 Mar 2016 09:17:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-03-18 09:18:54, Serialize complete at 2016-03-18 09:18:54 Content-Type: multipart/alternative; boundary="=_alternative 000739A448257F7A_=" X-MAIL: mse01.zte.com.cn u2I1Is6W006740 Archived-At: Subject: [bess] Fwd: New Version Notification for draft-hu-bess-l2vpn-service-yang-00.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 01:19:10 -0000 This is a multipart message in MIME format. --=_alternative 000739A448257F7A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIEFsbA0KDQpBIG5ldyBkcmFmdCBhYm91dCBMMlZQTiBzZXJ2aWNlIFlBTkcgZGF0YSBtb2Rl bCBpcyBzdWJtaXR0ZWQgdG8gdGhlIGJlc3MgDQp3b3JrZ3JvdXAuDQoNClRoaXMgbW9kZWwod2Ug YWxzbyBuYW1lZCBpdCBhcyBub3J0aCBib3VuZCBZQU5HIGRhdGEgbW9kZWwpIGlzIHRvIHByb3Bv c2UgDQphbiBhYnN0cmFjdGVkIGludGVyZmFjZSB0byBtYW5hZ2UgY29uZmlndXJhdGlvbiBvZiBj b21wb25lbnRzIG9mIGEgTGF5IDIgDQpWUE4gc2VydmljZS4gIEEgdHlwaWNhbCB1c2FnZSBpcyB0 byB1c2UgdGhpcw0KDQogbW9kZWwgYXMgYW4gaW5wdXQgZm9yIGFuIG9yY2hlc3RyYXRpb24gbGF5 ZXIgd2hvIHdpbGwgYmUgcmVzcG9uc2libGUgdG8gDQp0cmFuc2xhdGUgaXQgdG8gIG9yY2hlc3Ry YXRlZCBjb25maWd1cmF0aW9uIG9mIG5ldHdvcmsgZWxlbWVudHMgd2hpY2ggd2lsbCANCmJlIHBh cnQgb2YgdGhlIHNlcnZpY2UuDQoNCkNvbW1tZW50cyBhcmUgYXBwcmVjaWF0ZWx5IHdlbGNvbWVk LiBCb3RoIHRoZSBWUFdTIGFuZCBWUExTIHNlcnZpY2VzIGFyZSANCmRlZmluZWQgaW4gdGhlIGRv Y3VtZW50Lg0KDQpGYW5nd2VpDQpSZWdhcmRzLg0KDQoNCi0tLS0tINeqt6LIyyC6+re9zrAxNzU3 NzIvdXNlci96dGVfbHRkIMqxvOQgMjAxNi0wMy0xOCAwOTowOSAtLS0tLQ0KDQppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgDQoyMDE2LTAzLTE3IDE3OjA1DQoNCsrVvP7Iyw0KImZhbmd3ZWkgaHUi IDxodS5mYW5nd2VpQHp0ZS5jb20uY24+LCAiUmFuIENoZW4iIDxjaGVuLnJhbkB6dGUuY29tLmNu PiwgDQoiSmllIFlhbyIgPHlhby5qaWVAenRlLmNvbS5jbj4sICJGYW5nd2VpIEh1IiA8aHUuZmFu Z3dlaUB6dGUuY29tLmNuPg0Ks63LzQ0KDQrW98ziDQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWh1LWJlc3MtbDJ2cG4tc2VydmljZS15YW5nLTAwLnR4dA0KDQoNCg0KDQoNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHUtYmVzcy1sMnZwbi1zZXJ2aWNlLXlhbmct MDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEZhbmd3ZWkgSHUgYW5k IHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgICAgICAg ICAgICAgICAgICAgZHJhZnQtaHUtYmVzcy1sMnZwbi1zZXJ2aWNlLXlhbmcNClJldmlzaW9uOiAg ICAgICAgICAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgICAgICAgTDJWUE4g U2VydmljZSBZQU5HIE1vZGVsDQpEb2N1bWVudCBkYXRlOiAgICAgICAgICAgMjAxNi0wMy0xNw0K R3JvdXA6ICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQ YWdlczogICAgICAgICAgICAgICAgICAgICAgICAgICAzMg0KVVJMOiAgICAgICAgICAgIA0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1LWJlc3MtbDJ2cG4tc2Vy dmljZS15YW5nLTAwLnR4dA0KDQpTdGF0dXM6ICAgICAgICAgDQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1odS1iZXNzLWwydnBuLXNlcnZpY2UteWFuZy8NCkh0bWxpemVk OiAgICAgICANCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odS1iZXNzLWwydnBu LXNlcnZpY2UteWFuZy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVz IGEgWUFORyBkYXRhIG1vZGVsIHRoYXQgY2FuIGJlIHVzZWQgdG8gZGVsaXZlciBhDQogICBMYXll ciAyIFByb3ZpZGVyIFByb3Zpc2lvbmVkIFZQTiBzZXJ2aWNlLiAgVGhlc2Ugc2VydmljZXMgaW5j bHVkZQ0KICAgVmlydHVhbCBQcml2YXRlIFdpcmUgU2VydmljZSAoVlBXUykgYW5kIFZpcnR1YWwg UHJpdmF0ZSBMQU4gc2VydmljZQ0KICAgKFZQTFMpLiAgVGhpcyBtb2RlbCBpcyBpbnRlbmRlZCB0 byBiZSBpbnN0YW50aWF0ZWQgYXQgbWFuYWdlbWVudA0KICAgc3lzdGVtIHRvIGRlbGl2ZXIgdGhl IEwyVlBOIHNlcnZpY2UsIGFuZCBpcyBub3QgYSBjb25maWd1cmF0aW9uIG1vZGVsDQogICB0byBi ZSB1c2VkIGRpcmVjdGx5IG9uIG5ldHdvcmsgZWxlbWVudHMuDQoNCiAgIFRoaXMgbW9kZWwgcHJv dmlkZXMgYW4gYWJzdHJhY3RlZCB2aWV3IG9mIHRoZSBMYXllciAyIFZQTiBzZXJ2aWNlDQogICBj b25maWd1cmF0aW9uIGNvbXBvbmVudHMuICBJdCB3aWxsIGJlIHVwIHRvIGEgbWFuYWdlbWVudA0K ICAgc3lzdGVtKG9yY2hlc3RyYXRvcikgdG8gdGFrZSB0aGlzIGFzIGFuIGlucHV0IGFuZCB1c2Ug c3BlY2lmaWMNCiAgIGNvbmZpZ3VyYXRpb25zIG1vZGVscyB0byBjb25maWd1cmUgdGhlIGRpZmZl cmVudCBuZXR3b3JrIGVsZW1lbnRzIHRvDQogICBkZWxpdmVyIHRoZSBzZXJ2aWNlLiAgSXQgaXMg Y2FsbGVkIGFzIG5vcnRoIGJvdW5kIEwyVlBOIFNlcnZpY2UgWUFORw0KICAgZGF0YSBtb2RlbC4g IEhvdyBjb25maWd1cmF0aW9uIG9mIG5ldHdvcmsgZWxlbWVudHMgaXMgb3V0IG9mIHNjb3BlIG9m DQogICB0aGUgZG9jdW1lbnQsIGFuZCBpcyBkZWZpbmVkIGluIGRvY3VtZW50W0ktRC5zaGFoLWJl c3MtbDJ2cG4teWFuZ10uDQoNCiAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQpzdWJtaXNzaW9uDQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --=_alternative 000739A448257F7A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBBbGw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkEgbmV3IGRyYWZ0IGFib3V0IEwy VlBOIHNlcnZpY2UgWUFORw0KZGF0YSBtb2RlbCBpcyBzdWJtaXR0ZWQgdG8gdGhlIGJlc3Mgd29y a2dyb3VwLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ VGhpcyBtb2RlbCh3ZSBhbHNvIG5hbWVkIGl0IGFzIG5vcnRoDQpib3VuZCBZQU5HIGRhdGEgbW9k ZWwpIDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPmlzIHRvIHByb3Bvc2UgYW4gYWJzdHJhY3RlZA0K aW50ZXJmYWNlIHRvIG1hbmFnZSBjb25maWd1cmF0aW9uIG9mIGNvbXBvbmVudHMgb2YgYSBMYXkg MiBWUE4gc2VydmljZS4NCiZuYnNwO0EgdHlwaWNhbCB1c2FnZSBpcyB0byB1c2UgdGhpczwvZm9u dD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7bW9kZWwgYXMgYW4gaW5w dXQgZm9yIGFuIG9yY2hlc3RyYXRpb24gbGF5ZXINCndobyB3aWxsIGJlIHJlc3BvbnNpYmxlIHRv IHRyYW5zbGF0ZSBpdCB0byAmbmJzcDtvcmNoZXN0cmF0ZWQgY29uZmlndXJhdGlvbg0Kb2YgbmV0 d29yayBlbGVtZW50cyB3aGljaCB3aWxsIGJlIHBhcnQgb2YgdGhlIHNlcnZpY2UuPC9mb250Pjwv dHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Db21tbWVudHMgYXJlIGFwcHJlY2lhdGVs eSB3ZWxjb21lZC4gQm90aCB0aGUgVlBXUw0KYW5kIFZQTFMgc2VydmljZXMgYXJlIGRlZmluZWQg aW4gdGhlIGRvY3VtZW50LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ RmFuZ3dlaTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+UmVnYXJkcy48L2ZvbnQ+ PC90dD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzgwMDA4MCBmYWNlPSJz YW5zLXNlcmlmIj4tLS0tLSDXqreiyMsguvq3vc6wMTc1NzcyL3VzZXIvenRlX2x0ZA0KyrG85CAy MDE2LTAzLTE4IDA5OjA5IC0tLS0tPC9mb250Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDE2LTAzLTE3IDE3OjA1PC9mb250Pg0KPHRkIHdpZHRo PTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O2Zhbmd3ZWkgaHUm cXVvdDsgJmx0O2h1LmZhbmd3ZWlAenRlLmNvbS5jbiZndDssDQomcXVvdDtSYW4gQ2hlbiZxdW90 OyAmbHQ7Y2hlbi5yYW5AenRlLmNvbS5jbiZndDssICZxdW90O0ppZSBZYW8mcXVvdDsgJmx0O3lh by5qaWVAenRlLmNvbS5jbiZndDssDQomcXVvdDtGYW5nd2VpIEh1JnF1b3Q7ICZsdDtodS5mYW5n d2VpQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2 Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5OZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1 LWJlc3MtbDJ2cG4tc2VydmljZS15YW5nLTAwLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRh YmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWh1LWJlc3MtbDJ2cG4tc2VydmljZS15YW5nLTAwLnR4dDxicj4NCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRmFuZ3dlaSBIdSBhbmQgcG9zdGVkIHRvIHRoZTxi cj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWh1LWJlc3Mt bDJ2cG4tc2VydmljZS15YW5nPGJyPg0KUmV2aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjAwPGJyPg0KVGl0bGU6ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TDJW UE4NClNlcnZpY2UgWUFORyBNb2RlbDxicj4NCkRvY3VtZW50IGRhdGU6ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IDIwMTYtMDMtMTc8YnI+ DQpHcm91cDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsDQpTdWJtaXNzaW9uPGJyPg0KUGFnZXM6ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MzI8 YnI+DQpVUkw6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1LWJlc3MtbDJ2cG4tc2Vydmlj ZS15YW5nLTAwLnR4dDxicj4NClN0YXR1czogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1LWJlc3MtbDJ2cG4tc2Vydmlj ZS15YW5nLzxicj4NCkh0bWxpemVkOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaHUtYmVzcy1sMnZwbi1zZXJ2aWNlLXlhbmctMDA8YnI+DQo8 YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQogJm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBh IFlBTkcgZGF0YSBtb2RlbCB0aGF0IGNhbiBiZSB1c2VkIHRvIGRlbGl2ZXINCmE8YnI+DQogJm5i c3A7IExheWVyIDIgUHJvdmlkZXIgUHJvdmlzaW9uZWQgVlBOIHNlcnZpY2UuICZuYnNwO1RoZXNl IHNlcnZpY2VzDQppbmNsdWRlPGJyPg0KICZuYnNwOyBWaXJ0dWFsIFByaXZhdGUgV2lyZSBTZXJ2 aWNlIChWUFdTKSBhbmQgVmlydHVhbCBQcml2YXRlIExBTiBzZXJ2aWNlPGJyPg0KICZuYnNwOyAo VlBMUykuICZuYnNwO1RoaXMgbW9kZWwgaXMgaW50ZW5kZWQgdG8gYmUgaW5zdGFudGlhdGVkIGF0 IG1hbmFnZW1lbnQ8YnI+DQogJm5ic3A7IHN5c3RlbSB0byBkZWxpdmVyIHRoZSBMMlZQTiBzZXJ2 aWNlLCBhbmQgaXMgbm90IGEgY29uZmlndXJhdGlvbg0KbW9kZWw8YnI+DQogJm5ic3A7IHRvIGJl IHVzZWQgZGlyZWN0bHkgb24gbmV0d29yayBlbGVtZW50cy48YnI+DQo8YnI+DQogJm5ic3A7IFRo aXMgbW9kZWwgcHJvdmlkZXMgYW4gYWJzdHJhY3RlZCB2aWV3IG9mIHRoZSBMYXllciAyIFZQTiBz ZXJ2aWNlPGJyPg0KICZuYnNwOyBjb25maWd1cmF0aW9uIGNvbXBvbmVudHMuICZuYnNwO0l0IHdp bGwgYmUgdXAgdG8gYSBtYW5hZ2VtZW50PGJyPg0KICZuYnNwOyBzeXN0ZW0ob3JjaGVzdHJhdG9y KSB0byB0YWtlIHRoaXMgYXMgYW4gaW5wdXQgYW5kIHVzZSBzcGVjaWZpYzxicj4NCiAmbmJzcDsg Y29uZmlndXJhdGlvbnMgbW9kZWxzIHRvIGNvbmZpZ3VyZSB0aGUgZGlmZmVyZW50IG5ldHdvcmsg ZWxlbWVudHMNCnRvPGJyPg0KICZuYnNwOyBkZWxpdmVyIHRoZSBzZXJ2aWNlLiAmbmJzcDtJdCBp cyBjYWxsZWQgYXMgbm9ydGggYm91bmQgTDJWUE4gU2VydmljZQ0KWUFORzxicj4NCiAmbmJzcDsg ZGF0YSBtb2RlbC4gJm5ic3A7SG93IGNvbmZpZ3VyYXRpb24gb2YgbmV0d29yayBlbGVtZW50cyBp cyBvdXQNCm9mIHNjb3BlIG9mPGJyPg0KICZuYnNwOyB0aGUgZG9jdW1lbnQsIGFuZCBpcyBkZWZp bmVkIGluIGRvY3VtZW50W0ktRC5zaGFoLWJlc3MtbDJ2cG4teWFuZ10uPGJyPg0KPGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48 YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0K --=_alternative 000739A448257F7A_=-- From nobody Sat Mar 19 10:55:53 2016 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 4FB0F12D1E5; Sat, 19 Mar 2016 10:55:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160319175545.28510.24717.idtracker@ietfa.amsl.com> Date: Sat, 19 Mar 2016 10:55:45 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-usage-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2016 17:55:45 -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 : Usage and applicability of BGP MPLS based Ethernet VPN Authors : Jorge Rabadan Senad Palislamovic Wim Henderickx Keyur Patel Ali Sajassi Aldrin Isaac Filename : draft-ietf-bess-evpn-usage-02.txt Pages : 30 Date : 2016-03-19 Abstract: This document discusses the usage and applicability of BGP MPLS based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures will be explained on the example scenario, analyzing the benefits and trade-offs of each option. Along with [RFC7432], this document is intended to provide a simplified guide for the deployment of EVPN in Service Provider networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-usage/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-usage-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-usage-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 20 21:35:05 2016 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 9B19612D580 for ; Sun, 20 Mar 2016 21:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYmRyYojIXgJ for ; Sun, 20 Mar 2016 21:35:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A656112D553 for ; Sun, 20 Mar 2016 21:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LDO+H8YrMiKtgil+CqE+ryPza/jhmVMnfGtE8Vhg5nY=; b=CrFiqXiOj8ivif1ePywYw4IFe+K3x5fK+Zc2lKEqbt+VxAiFHVmTnQWRZ6d9UcVt4Bf3V1IC7no0kAJflNoWpSQfOs4tQ9yolkN6CNy5wzwVQxmqNPHQD66nAs46zWon9rm2vfVK3wAozt470MGL/WwHHYF4YRfhDVnbO0gMn4o= Received: from BY1PR0501MB1240.namprd05.prod.outlook.com (10.160.200.139) by BY2PR0501MB1702.namprd05.prod.outlook.com (10.163.154.155) with Microsoft SMTP Server (TLS) id 15.1.434.16; Mon, 21 Mar 2016 04:34:59 +0000 Received: from BY1PR0501MB1240.namprd05.prod.outlook.com ([10.160.200.139]) by BY1PR0501MB1240.namprd05.prod.outlook.com ([10.160.200.139]) with mapi id 15.01.0434.021; Mon, 21 Mar 2016 04:34:59 +0000 From: Wen Lin To: Martin Vigoureux , "EXT - thomas.morin@orange.com" Thread-Topic: [bess] Slots requests for BESS WG session - IETF 95 - Buenos Aires Thread-Index: AQHRgysGR/8Z/QtuIUC4KdPY07duvg== Date: Mon, 21 Mar 2016 04:34:59 +0000 Message-ID: References: <56DD71AE.9030104@alcatel-lucent.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.5.5.150821 authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 4d3d55e8-cbb6-43d0-d926-08d35142297b x-microsoft-exchange-diagnostics: 1; BY2PR0501MB1702; 5:TgQ6X6Lh4TBR/woeByZbvXGac4kdYCUhPcxf3A2zzl4UPJzcLs582vZKJIYWCm32I6YRG8ppusrBSwhUKDxY8hlkhhq+RnL/FW5IxU5hMKUqZYSxi9+EUgHzFOsqAM5NUFa75if4YCK2vr5CHC88Bg==; 24:1czDDTmT+LfXpkb6PE5lD/mYrajHFG1bhn9r+X6TXYiWEzycVWUdyZPG5O3aeiyxphMIE31YYXKE1kGTv5R/h8CgvUkX+iCNSl2JD1fmceY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB1702; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR0501MB1702; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1702; x-forefront-prvs: 0888B1D284 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(164054003)(1096002)(102836003)(586003)(16236675004)(6116002)(4326007)(1220700001)(189998001)(66066001)(3846002)(77096005)(3660700001)(3280700002)(36756003)(87936001)(99286002)(2906002)(2950100001)(15975445007)(86362001)(10400500002)(5008740100001)(5001770100001)(106116001)(122556002)(54356999)(92566002)(4001350100001)(19580395003)(5004730100002)(19580405001)(81166005)(83506001)(11100500001)(5002640100001)(50986999)(19617315012)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1702; H:BY1PR0501MB1240.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D314F1CD9155Awlinjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2016 04:34:59.4264 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1702 Archived-At: Cc: "Jeffrey \(Zhaohui\) Zhang" , John E Drake , "jorge.rabadan@nokia.com" , BESS Subject: Re: [bess] Slots requests for BESS WG session - IETF 95 - Buenos Aires X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 21 Mar 2016 04:35:04 -0000 --_000_D314F1CD9155Awlinjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Martin, Thomas, We would like to request a slot for: draft-lin-bess-evpn-irb-mcast-02: Speaker: Wen, 10 minutes. Thanks, Wen On Mon, Mar 7, 2016 at 4:18 AM, Martin Vigoureux > wrote: All, it is time we start building the BESS WG agenda for Buenos Aires. The IETF agenda is available at: https://datatracker.ietf.org/meeting/95/agenda.html Please note that it is still a preliminary agenda. The BESS WG session (2h) is currently scheduled on Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time) Please send us your request for a presentation slot, indicating: draft name, speaker and desired duration (covering presentation + discussio= n) Please send the requests no later than the 20th of March Thank you M&T _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess --_000_D314F1CD9155Awlinjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <9B6C7CABCD9EEF45A64E34EF9ADC3FC6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Martin= , Thomas,

We would = like to request a slot for:

draft-lin= -bess-evpn-irb-mcast-02: Speaker: Wen,  10 minutes.

Thanks,
Wen


On Mon, Mar 7, 2016 at 4:18 AM, Martin Vigoureux= <martin.= vigoureux@nokia.com> wrote:
All,

it is time we start building the BESS WG agenda for Buenos Aires.
The IETF agenda is available at:
https://datatracker.ietf.org/meeting/95/agenda.ht= ml
Please note that it is still a preliminary agenda.

The BESS WG session (2h) is currently scheduled on
Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time)

Please send us your request for a presentation slot, indicating:
draft name, speaker and desired duration (covering presentation + discu= ssion)

Please send the requests no later than the 20th of March
Thank you

M&T

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


 --_000_D314F1CD9155Awlinjunipernet_-- From nobody Mon Mar 21 10:19:30 2016 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 D529712D519; Mon, 21 Mar 2016 10:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH4CSHzWf5oR; Mon, 21 Mar 2016 10:19:24 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA4712D8AB; Mon, 21 Mar 2016 10:18:55 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 720F9402EB; Mon, 21 Mar 2016 18:18:53 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 383332006E; Mon, 21 Mar 2016 18:18:53 +0100 (CET) Received: from [10.193.71.12] (10.168.234.5) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.279.2; Mon, 21 Mar 2016 18:18:52 +0100 To: "Alvaro Retana (aretana)" , "draft-ietf-bess-multicast-damping@ietf.org" References: <56CDE11B.1000900@orange.com> From: Organization: Orange Message-ID: <28717_1458580733_56F02CFD_28717_5847_1_56F02CFB.1060800@orange.com> Date: Mon, 21 Mar 2016 18:18:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030801040000020300010608" X-Originating-IP: [10.168.234.5] Archived-At: Cc: "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-multicast-damping-03 / -04 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 21 Mar 2016 17:19:29 -0000 --------------030801040000020300010608 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Alvaro, We've posted -04 last week, based on the discussion we had. Please tell us if you think this is ready to move forward. Best, -Thomas 2016-03-09, Alvaro Retana (aretana): > On 2/24/16, 11:58 AM, "Thomas Morin" > wrote: > > Thomas: > > Hi! > > There are several places where we're still not in sync. Please se below. > > Maybe talking in person would be good. > > Thanks! > > Alvaro. > > > > > 2016-02-23, Alvaro Retana (aretana): >> The Abstract says that the procedures are "inspired from >> BGP unicast route damping". It seems to me that the intent is in >> fact to adopt the algorithm from RFC2439. However, the text is >> not explicit/clear about that. > Saying so would I think actually be a misleading simplification, > the reader may miss the facts: > - that the proposal is to keep advertising a dampened multicast > VPN state up (in RFC2439, a dampened route stops being advertised) > - that the document is not BGP-specific but also specifies a > mechanism for the PIM FSM > - that only exponential decay is borrowed from RFC2439 > > > This last sentence is what I meant above by "adopt the algorithm from > RFC2439". In other words, your proposal is to dampen the multicast > state using the exponential decay algorithm defined in RFC2439, right? > > In your response to my detailed comments there are statements that > confuse me a little… I put some more comments/questions below. > > > > 1. As you all know, the history behind BGP damping has not been > without it being considered useless and even having > recommendations (from RIPE, for example) not to use it. > > > A few things are important to have in mind: > - the application context here is not the Internet > - multicast state propagates in a very different fashion > - the damping algorithm techniques is not the same > - the side-effects of damping unicast and damping multicast as > proposed here are fundamentally different: here damping causes no > impact on the service > > Overall, I would say that the weaknesses of RFC2439 and the > recommendations in RFC7196 were well known by co-authors and that > we came to the conclusion that this multicast VPN would not suffer > from similar weaknesses. > >> How did you arrive at the default and maximum values? > > By simulating with simple parameters and choosing conservative > low-risk values. > Considering that, by design, whatever the parameters, multicast > streams will be delivered unchanged and that the only thing you > tradeoff against is less dynamicity and a possibly slightly > increased bandwidth use, the default and maximum values do not > have to be perfectly tuned. > > > Please include this type of information (above) in the document. > Given the history of dampening in general, understanding the > differences considered will go a long way and avoid more questions. ;-) > > >> It concerns me that there are no known implementations (from the >> Shepherd's report). > This concern is valid. > See below... > >> Because of that, I think this document would be better suited as >> an Experimental RFC, with the explicit purpose of gaining >> experience with the values and determine the impact in live >> deployments (which then could support a standard version). >> Please consider changing the intended Status. > Let me go back to why this proposal started: some lab testing was > done showing that it was easy, in the lab, to create significant > overload on PE and RRs BGP stacks by flapping multicast state at > the edge. Having a standard track to provide the appropriate > tooling against this DoS risk seems to me as making sense. I > think that the proposed procedures are not close enough to the > solution and problem addressed by RFC2439 to say that RFC2439's > history is an argument to pass through an Experimental RFC first. > > > You might be right in this last point (the history of RFC2439 > shouldn't affect this document), specially given the explanation you > gave earlier (where you talked about multicast being different, not > intended for the Internet, etc.). > > However, the rest of your answer (in that last paragraph) points only > at experience in seeing the problem and testing the solution "in the > lab". Not outside the lab. In other words, the motivation and > problem both came from lab tests. Augmented by the fact that there > are no implementations it renews my proposal to make this document > Experimental — as I said before, with the explicit purpose of gaining > experience: is the problem observed in deployed networks, are the > conditions there the same/similar as in the lab, are the parameters > adequate. > > Note that I don't think that an RFC has to be in the Standards Track > to prove useful. > > > … > > > >> 1. Are you adopting the exponential decay algorithm from >> RFC2439? That seems to be what's happening because you are >> not explicitly defining a new algorithm, but some of the text >> leave doubts. For example: >> * "inspired from BGP unicast route damping" I know the >> application is different, but if the algorithm is the >> same then please say it. >> > The procedures associated to the exponential decay are different. > > > Are you referring to the procedures as to when a penalty is incurred > (multicast state change vs routing update), action (maintain the state > vs stop advertising a route), etc. ?? > > > > >> 1. >> * Section 5.1. (PIM procedures) >> o "updating the *figure-of-merit* based on the decay >> algorithm must be done prior to this increment" This >> statement seems to directly imply that the algorithm >> is used. Please reorder the steps to explicitly call >> this one out, instead of plugging it in as an >> afterthought. BTW, should the "must" be "MUST"? >> Ordering should help you not having to deal with >> that last question. >> > > I've revised the text to describe this step in its own bullet, > prior to "updating the figure-of-merit", to avoid this "after > thought" impression and make it as mandatory as the other steps. > > >> 1. >> * >> o "Same techniques as the ones described in [RFC2439] >> can be applied…" "Can be"? This sentence seems to >> imply that what is described in RFC2439 is optional. >> Are there other ways of determining the same thing? >> What about the exponential decay algorithm? >> > > No, there are just multiple ways possible to update the > figure-of-merit, including the ones RFC2439 mention or detail. > > I've reformulated the text to avoid misinterpretation: > > These specifications do not impose the use of a particular technique > to update the *figure-of-merit* following the exponential decay > algorithm based on the configured *decay-half-life*. In particular > the same techniques as the ones described in [RFC2439] can be > applied. The only requirement is that the *figure-of-merit* has to > be updated prior to increasing it and that its decay below the > *reuse-threshold* has to be timely reacted upon: in particular, if > the recomputation is done periodically, the period should be low > enough to not significantly delay the inactivation of damping on a > multicast state beyond what the operator wanted to configure (i.e. > for a *decay-half-life* of 10s, recomputing the *figure-of-merit* > each minute would result in a multicast state to remained > damped for > a much longer time than what the parameters are supposed to > command). > > > If I'm understanding (that the algorithm in RFC2439 is one possible > way to update the figure-of-merit, but that there are others > possible), then: > > 1. this text only augments my point about this document being > experimental; the text is not specific as to how things should > work, it leaves the door open to almost anything…which brings me > back to the question about how do you know that the proposed > defaults will work with anything…Experimental, etc. > 2. Even for the known method (exponential back off in RFC2439) the > text is not prescriptive enough to be a Standard. > > > > > > >> 1. >> * >> o It would also help if the terminology was consistent. >> For example, instead of "damping becomes active" use >> "suppressed". I can see how "suppressed" may give >> the wrong impression as only the propagation of state >> is affected. Explaining then how the terminology >> applies would make it easier to reuse, avoid >> confusion and be clear. Note that there's no mention >> of RFC2439 in the terminology section. >> > > Using the "suppressed" term to describe a state that we > artifically keep active is the most confusing thing that I can > think of. As you say this would give a wrong impression. I would > go as far as to say that the document would be barely understandable. > > But maybe we can add this to the terminology section: > > In these specifications, damping of a multicast state will be > said to be "active" or "inactive". Note that the term used for > a unicast route which is dampened is "suppressed", but we > avoid this term is these specifications given that a dampened > multicast state is kept active. > > Would that help ? > > > Yes. > > That would go in the Terminology section, right? As there are other > RFC2439 terms, it would be good to make a blanket statement there > about that too. > > > >> 1. >> * >> >> 2. Section 3. (Overview): "…it is expected that this technique >> will allow to meet the goals of protecting the >> multicast routing infrastructure control plane without a >> significant average increase of bandwidth". In general, I >> want to make sure that the qualities of the solution and the >> expected results are properly reflected in the document. [I'm >> using the text above as the base for my comment, but the >> impact is larger.] Some questions: >> * "…it is expected that this technique will…" I wonder why >> an assertion can't be made that this technique can (vs >> just expecting that it will) address specific problems. >> Is it the case that experience is needed to make a >> stronger assertion? Are the goals the same (or at least >> similar) in every network? Are there implementations >> available? If so, please consider an "Implementation >> Status" section (see rfc6982). What has been the >> deployment experience? This goes back to my comment >> above about the Intended Status of this document. >> > > "It is expected" reflects the idea that the slight increase in > bandwidth will not be significant in most cases. > We can expand the text a bit to explain what would be the cases > where that would not work. > > Let me suggest the following reformulation: > > "That said, basic simulation of the exponential decay algorithm > show that the multicast state churn can be drastically reduced > without significantly increasing the duration for which multicast > traffic is forwarded. Hence, using this technique will efficiently > protect the multicast routing infrastructure control plane against > the issues described here, without a significant average increase > of bandwidth. The exception will be a scenario where the network > dimensioning does not allow to extend the time a multicast flow is > forwarded beyond the duration for which is it needed by receivers". > > > I don't know what the last sentence means. :-( What is "network > dimensioning"? It sounds that not extending "the time a multicast > flow is forwarded beyond the duration for which is it needed by > receivers" is not a bad thing… Other than that last sentence, the > text sounds clearer. > > You again talk about simulation experience, which as close at it may > have been to real conditions it is just a simulation. It's ok to > mention this because that is the experience you have. You also > mention the exponential decay algorithm, but the text above about > other possible methods takes me back to: what happens if a different > method is used? > > > > >> 1. >> * What specifically are the goals? In a couple of places >> the text points back at Section 1. (Introduction), >> but I'm not sure exactly what the goals are. Of special >> interest for understanding the goals is the part in >> Section 4.2. (Existing PIM, IGMP and MLD timers) where >> other solutions are discarded for not meeting them. >> o There is scattered text that talks about "…ensure >> that the load put on the BGP control plane, and on >> the P-tunnel setup control plane, remains under >> control…", "protecting these control planes…avoiding >> negative effects…although at the expense of a minimal >> increase in average of bandwidth use…". However, >> the description is too vague to point at what >> can satisfy these goals and what can't. >> > > > Section one 1 says: > - " Hence, mechanisms need to be put in place to ensure that the > load put on the BGP control plane, and on the P-tunnel setup > control plane, remains under control regardless of the frequency > at which multicast memberships changes are made by end hosts." > -then "This document describes procedures, remotely inspired from > existing BGP route damping, aimed at protecting these control > planes while at the same time avoiding negative effects on the > service provided, although at the expense of a minimal increase in > average of bandwidth use in the network." > > The intent was that the text would be enough to make the goals clear. > > Would the following change of the second sentence provide suitable > detail to help understand what can satisfy these goals and what > can't : ...? > > [...] aimed at offering means to set an upper bound to the > affected control planes (BGP RFC6514 processing, and the P-tunnel > control plane protocol in certain cases as well) while at the same > time preserving service provided (delivering the stream to the end > user as requested), although at the expense of a minimal increase > in average of bandwidth use in the network. > > I see that we can reorder the text to avoid splitting the > explanation of goals. > > The new text would look like the following: > > In VPN contexts, providing isolation between customers of a shared > infrastructure is a core requirement resulting in stringent > expectations with regards to risks of denial of service attacks. > > By nature multicast memberships change based on the behavior of > multicast applications running on end hosts, hence the frequency of > membership changes can legitimately be much higher than the typical > churn of unicast routing states. Section 16 of [RFC6514] > specifically spells out the need for damping the activity of > C-multicast and Leaf Auto-discovery routes. > > Hence, mechanisms need to be put in place to ensure that the > load put > on the BGP control plane, and on the P-tunnel setup control plane, > remains under control regardless of the frequency at which > multicast > memberships changes are made by end hosts. > > This document describes procedures, remotely inspired from existing > BGP route damping, aimed at offering means to set an upper bound to > the amount of processing for the mVPN control planes protocols > ([RFC6514], and the P-tunnel control plane protocol in certain > cases > as well), while at the same time preserving service provided > (delivering the stream to the end user as requested), although > at the > expense of a minimal increase in average of bandwidth use in the > network. > > > That text is better, but it still includes statements like "…ensure > that the load…remains under control…", and later "set an upper bound". > I'm not too happy with vague goals as keeping something under control > (for example) can mean many things --- and the upper bound is not > clearly defined. This upper bound is probably a function of the > defaults chosen; explaining that (not in this section) would be nice. > > > … > >> >> 1. Section 5.2. (Procedures for multicast VPN state damping) >> * In the Introduction you write that "Section 16 of >> [RFC6514] specifically spells out the need for damping >> the activity…" I think that RFC6514 does a lot more than >> that: Section 16.1. (Dampening C-Multicast Routes) >> "proposes OPTIONAL route dampening procedures similar to >> what is described in [RFC2439]." Those procedures look >> very similar to the ones in this document. What is >> the difference? Is the intent of this document to >> complement, replace or maybe update what is already >> specified in RFC6514? >> > > Indeed, the base ideas for dampening were already here when we > wrote RFC6514. > draft-ietf-bess-multicast-damping provides precision on how to > implement RFC6514 16.1.1, but this is not an update per se as > nothing in RFC6514 is changed. > > We can make that fully explicit by saying in Section 1: > > Section 16 of [RFC6514] specifically spells out the need for > damping > the activity of C-multicast and Leaf Auto-discovery routes, and > outlines how to do it by "delay the advertisement of withdrawals of > C-multicast routes". These specifications provides appropriate > detail on how to implement that and how to make that controllable > by the operator. > > > That is an update: by clarifying and providing specifics you are in > fact updating RFC6514. We want to mark it that way (and be explicit > about it) because we want someone reading RFC6514 to refer to this > document if wanting to implement dampening. > > > … > >> 1. >>> >>> Minor: >> >> 1. In 4.2 >> * s/prune override interval/J/P_Override_Interval >> > > I'd rather keep the plain text version. > > > "J/P_Override_Interval" is that this interval is called in rfc460bis. > > … > > >> 1. >> >> >> >> 2. Section 5.2. (Procedures for multicast VPN state damping) >> * There are several places in this section where rfc2119 >> language is used to describe what an implementation >> should do that sound to me as an attempt to define >> functionality that is mandatory to implement (MTI). I >> find that hard/impossible to enforce and would like to >> see the rfc2119 language removed. Please see below.. >> > > Yes, the MUSTs in this 5.1 and 5.2 intent to carry the meaning of > "mandatory to implement". > > > [Skipping to the specific RFC2119 question.] > … > > I understand that you seem to prefer avoiding RFC2119 language for > MTI things. > But I don't know another way than RFC2119 language to indicate > what is mandatory to implement to be compliant with a spec, and I > think this is a fairly well established practice. This is not the > first document to use RFC2119 to indicate MTI things. > > What is the rationale for not using RFC2119 language ? > > > RFC2119 reads: > > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. > > > Two points from there: > > 1. If it's not necessary to for interoperation, then don't use them. > Using this text as an example: "Implementation of [RFC6513] > relying on the use of PIM to carry C-multicast routing information > MUST support this technique." Implementing dampening is not > necessary for RFC6513 implementations to interoperate. In fact, > if one implementation enables dampening and the other doesn't, > they will still interoperate. > 2. Note that the last sentence refers specifically to implementation > choices. Using this text as an example: "The choice to implement > damping…is up to the implementor…implementing the BGP approach is > RECOMMENDED." There is no need to use "RECOMMENDED" because it is > not necessary for interoperability and by using it you're trying > to impose a specific method. > > > … > > > >> 1. >> * >> >> * "…damping SHOULD NOT be applied to BGP routes of >> the following sub-types…" Are there cases when it is ok? >> In other words, why is the "SHOULD NOT" not a "MUST NOT"? >> > > Maybe someone can find a case where this does not break things, > under some conditions. > We saw nothing mandating the use of "MUST NOT". > > > What conditions? > > Someone finding a case sounds like Experimentation to me… > > > >> 1. >> >> >> >> >> 2. Section 6.1. (Damping mVPN P-tunnel change events) "Possible >> ways to do so depend on the type of P-tunnel, and local >> implementation details are left up to the implementor. >> The following is proposed as example of how the above can >> be achieved." Either you leave it as an implementation >> detail or you provide guidance. If this document was >> Experimental, then providing guidance it great! >> > > There is a gap between "example" and "guidance". > I think an example can help the reader (implementor or deployer). > Guidance would mean that we start influencing the implementor, > which is not the idea here. > > > You already are influencing! See above about MTI. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. --------------030801040000020300010608 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi Alvaro,

We've posted -04 last week, based on the discussion we had.
Please tell us if you think this is ready to move forward.

Best,

-Thomas

2016-03-09, Alvaro Retana (aretana):
On 2/24/16, 11:58 AM, "Thomas Morin" <thomas.morin@orange.com> wrote:

Thomas:

Hi!

There are several places where we're still not in sync.  Please se below.

Maybe talking in person would be good.

Thanks!

Alvaro.




2016-02-23, Alvaro Retana (aretana):
The Abstract says that the procedures are "inspired from BGP unicast route damping".  It seems to me that the intent is in fact to adopt the algorithm from RFC2439.  However, the text is not explicit/clear about that.
Saying so would I think actually be a misleading simplification, the reader may miss the facts:
- that the proposal is to keep advertising a dampened multicast VPN state up (in RFC2439, a dampened route stops being advertised)
- that the document is not BGP-specific but also specifies a mechanism for the PIM FSM
- that only exponential decay is borrowed from RFC2439

This last sentence is what I meant above by "adopt the algorithm from RFC2439".  In other words, your proposal is to dampen the multicast state using the exponential decay algorithm defined in RFC2439, right?

In your response to my detailed comments there are statements that confuse me a little…  I put some more comments/questions below.  



  1. As you all know, the history behind BGP damping has not been without it being considered useless and even having recommendations (from RIPE, for example) not to use it. 

A few things are important to have in mind:
- the application context here is not the Internet
- multicast state propagates in a very different fashion
- the damping algorithm techniques is not the same
- the side-effects of damping unicast and damping multicast as proposed here are fundamentally different: here damping causes no impact on the service

Overall, I would say that the weaknesses of RFC2439 and the recommendations in RFC7196 were well known by co-authors and that we came to the conclusion that this multicast VPN would not suffer from similar weaknesses.

How did you arrive at the default and maximum values? 

By simulating with simple parameters and choosing conservative low-risk values.
Considering that, by design, whatever the parameters, multicast streams will be delivered unchanged and that the only thing you tradeoff against is less dynamicity and a possibly slightly increased bandwidth use, the default and maximum values do not have to be perfectly tuned.

Please include this type of information (above) in the document.  Given the history of dampening in general, understanding the differences considered will go a long way and avoid more questions. ;-)


It concerns me that there are no known implementations (from the Shepherd's report). 
This concern is valid.
See below...

Because of that, I think this document would be better suited as an Experimental RFC, with the explicit purpose of gaining experience with the values and determine the impact in live deployments (which then could support a standard version).  Please consider changing the intended Status.
Let me go back to why this proposal started: some lab testing was done showing that it was easy, in the lab, to create significant overload on PE and RRs BGP stacks by flapping multicast state at the edge.  Having a standard track to provide the appropriate tooling against this DoS risk seems to me as making sense.  I think that the proposed procedures are not close enough to the solution and problem addressed by RFC2439 to say that RFC2439's history is an argument to pass through an Experimental RFC first.

You might be right in this last point (the history of RFC2439 shouldn't affect this document), specially given the explanation you gave earlier (where you talked about multicast being different, not intended for the Internet, etc.).

However, the rest of your answer (in that last paragraph) points only at experience in seeing the problem and testing the solution "in the lab".  Not outside the lab.  In other words, the motivation and problem both came from lab tests.  Augmented by the fact that there are no implementations it renews my proposal to make this document Experimental — as I said before, with the explicit purpose of gaining experience: is the problem observed in deployed networks, are the conditions there the same/similar as in the lab, are the parameters adequate.

Note that I don't think that an RFC has to be in the Standards Track to prove useful.


…


  1. Are you adopting the exponential decay algorithm from RFC2439?  That seems to be what's happening because you are not explicitly defining a new algorithm, but some of the text leave doubts.  For example:
    • "inspired from BGP unicast route damping"  I know the application is different, but if the algorithm is the same then please say it.
The procedures associated to the exponential decay are different.

Are you referring to the procedures as to when a penalty is incurred (multicast state change vs routing update), action (maintain the state vs stop advertising a route), etc. ??  




    • Section 5.1. (PIM procedures)
      • "updating the *figure-of-merit* based on the decay algorithm must be done prior to this increment"  This statement seems to directly imply that the algorithm is used.  Please reorder the steps to explicitly call this one out, instead of plugging it in as an afterthought.  BTW, should the "must" be "MUST"?  Ordering should help you not having to deal with that last question.

I've revised the text to describe this step in its own bullet, prior to "updating the figure-of-merit", to avoid this "after thought" impression and make it as mandatory as the other steps.


      • "Same techniques as the ones described in [RFC2439] can be applied…"   "Can be"?  This sentence seems to imply that what is described in RFC2439 is optional.  Are there other ways of determining the same thing?  What about the exponential decay algorithm?

No, there are just multiple ways possible to update the figure-of-merit, including the ones RFC2439 mention or detail.

I've reformulated the text to avoid misinterpretation:

  These specifications do not impose the use of a particular technique
   to update the *figure-of-merit* following the exponential decay
   algorithm based on the configured *decay-half-life*. In particular
   the same techniques as the ones described in [RFC2439] can be
   applied.  The only requirement is that the *figure-of-merit* has to
   be updated prior to increasing it and that its decay below the
   *reuse-threshold* has to be timely reacted upon: in particular, if
   the recomputation is done periodically, the period should be low
   enough to not significantly delay the inactivation of damping on a
   multicast state beyond what the operator wanted to configure (i.e.
   for a *decay-half-life* of 10s, recomputing the *figure-of-merit*
   each minute would result in a multicast state to remained damped for
   a much longer time than what the parameters are supposed to command).

If I'm understanding (that the algorithm in RFC2439 is one possible way to update the figure-of-merit, but that there are others possible), then:
  1. this text only augments my point about this document being experimental; the text is not specific as to how things should work, it leaves the door open to almost anything…which brings me back to the question about how do you know that the proposed defaults will work with anything…Experimental, etc.
  2. Even for the known method (exponential back off in RFC2439) the text is not prescriptive enough to be a Standard.





      • It would also help if the terminology was consistent.  For example, instead of "damping becomes active" use "suppressed".  I can see how "suppressed" may give the wrong impression as only the propagation of state is affected.  Explaining then how the terminology applies would make it easier to reuse, avoid confusion and be clear.  Note that there's no mention of RFC2439 in the terminology section.

Using the "suppressed" term to describe a state that we artifically keep active is the most confusing thing that I can think of. As you say this would give a wrong impression.  I would go as far as to say that the document would be barely understandable.

But maybe we can add this to the terminology section:
In these specifications, damping of a multicast state will be said to be "active" or "inactive". Note that the term used for a unicast route which is dampened is "suppressed", but we avoid this term is these specifications given that a dampened multicast state is kept active.
Would that help ?

Yes.

That would go in the Terminology section, right?  As there are other RFC2439 terms, it would be good to make a blanket statement there about that too.




  2. Section 3. (Overview): "…it is expected that this technique will allow to meet the goals of protecting the multicast routing infrastructure control plane without a significant average increase of bandwidth".  In general, I want to make sure that the qualities of the solution and the expected results are properly reflected in the document. [I'm using the text above as the base for my comment, but the impact is larger.]  Some questions:
    • "…it is expected that this technique will…"  I wonder why an assertion can't be made that this technique can (vs just expecting that it will) address specific problems.  Is it the case that experience is needed to make a stronger assertion?  Are the goals the same (or at least similar) in every network?  Are there implementations available?  If so, please consider an "Implementation Status" section (see rfc6982).  What has been the deployment experience?  This goes back to my comment above about the Intended Status of this document.

"It is expected" reflects the idea that the slight increase in bandwidth will not be significant in most cases.
We can expand the text a bit to explain what would be the cases where that would not work.

Let me suggest the following reformulation:

"That said, basic simulation of the exponential decay algorithm show that the multicast state churn can be drastically reduced without significantly increasing the duration for which multicast traffic is forwarded. Hence, using this technique will efficiently protect the multicast routing infrastructure control plane against the issues described here, without a significant average increase of bandwidth.  The exception will be a scenario where the network dimensioning does not allow to extend the time a multicast flow is forwarded beyond the duration for which is it needed by receivers".

I don't know what the last sentence means. :-(  What is "network dimensioning"?  It sounds that not extending "the time a multicast flow is forwarded beyond the duration for which is it needed by receivers" is not a bad thing…   Other than that last sentence, the text sounds clearer.

You again talk about simulation experience, which as close at it may have been to real conditions it is just a simulation.  It's ok to mention this because that is the experience you have.  You also mention the exponential decay algorithm, but the text above about other possible methods takes me back to: what happens if a different method is used?




    • What specifically are the goals?  In a couple of places the text points back at Section 1. (Introduction), but I'm not sure exactly what the goals are.  Of special interest for understanding the goals is the part in Section 4.2. (Existing PIM, IGMP and MLD timers) where other solutions are discarded for not meeting them.
      • There is scattered text that talks about "…ensure that the load put on the BGP control plane, and on the P-tunnel setup control plane, remains under control…", "protecting these control planes…avoiding negative effects…although at the expense of a minimal increase in average of bandwidth use…".   However, the description is too vague to point at what can satisfy these goals and what can't.


Section one 1 says:
- " Hence, mechanisms need to be put in place to ensure that the load put on the BGP control plane, and on the P-tunnel setup control plane, remains under control regardless of the frequency at which multicast memberships changes are made by end hosts."
-then  "This document describes procedures, remotely inspired from existing BGP route damping, aimed at protecting these control planes while at the same time avoiding negative effects on the service provided, although at the expense of a minimal increase in average of bandwidth use in the network."

The intent was that the text would be enough to make the goals clear.

Would the following change of the second sentence provide suitable detail to help understand what can satisfy these goals and what can't :   ...?

[...] aimed at offering means to set an upper bound to the affected control planes (BGP RFC6514 processing, and the P-tunnel control plane protocol in certain cases as well) while at the same time preserving service provided (delivering the stream to the end user as requested), although at the expense of a minimal increase in average of bandwidth use in the network.

I see that we can reorder the text to avoid splitting the explanation of goals.

The new text would look like the following:

   In VPN contexts, providing isolation between customers of a shared
   infrastructure is a core requirement resulting in stringent
   expectations with regards to risks of denial of service attacks.

   By nature multicast memberships change based on the behavior of
   multicast applications running on end hosts, hence the frequency of
   membership changes can legitimately be much higher than the typical
   churn of unicast routing states.  Section 16 of [RFC6514]
   specifically spells out the need for damping the activity of
   C-multicast and Leaf Auto-discovery routes.

   Hence, mechanisms need to be put in place to ensure that the load put
   on the BGP control plane, and on the P-tunnel setup control plane,
   remains under control regardless of the frequency at which multicast
   memberships changes are made by end hosts.

   This document describes procedures, remotely inspired from existing
   BGP route damping, aimed at offering means to set an upper bound to
   the amount of processing for the mVPN control planes protocols
   ([RFC6514], and the P-tunnel control plane protocol in certain cases
   as well), while at the same time preserving service provided
   (delivering the stream to the end user as requested), although at the
   expense of a minimal increase in average of bandwidth use in the
   network.

That text is better, but it still includes statements like "…ensure that the load…remains under control…", and later "set an upper bound".  I'm not too happy with vague goals as keeping something under control (for example) can mean many things --- and the upper bound is not clearly defined.  This upper bound is probably a function of the defaults chosen; explaining that (not in this section) would be nice.


…

  1. Section 5.2. (Procedures for multicast VPN state damping)  
    • In the Introduction you write that "Section 16 of [RFC6514] specifically spells out the need for damping the activity…"  I think that RFC6514 does a lot more than that:  Section 16.1. (Dampening C-Multicast Routes) "proposes OPTIONAL route dampening procedures similar to what is described in [RFC2439]."   Those procedures look very similar to the ones in this document.  What is the difference?  Is the intent of this document to complement, replace or maybe update what is already specified in RFC6514?

Indeed, the base ideas for dampening were already here when we wrote RFC6514.
draft-ietf-bess-multicast-damping provides precision on how to implement RFC6514 16.1.1, but this is not an update per se as nothing in RFC6514 is changed.

We can make that fully explicit by saying in Section 1:

   Section 16 of [RFC6514] specifically spells out the need for damping
   the activity of C-multicast and Leaf Auto-discovery routes, and
   outlines how to do it by "delay the advertisement of withdrawals of
   C-multicast routes".  These specifications provides appropriate
   detail on how to implement that and how to make that controllable
   by the operator.

That is an update: by clarifying and providing specifics you are in fact updating RFC6514.  We want to mark it that way (and be explicit about it) because we want someone reading RFC6514 to refer to this document if wanting to implement dampening.


…

  1. Minor:
  1. In 4.2
    • s/prune override interval/J/P_Override_Interval

I'd rather keep the plain text version.

"J/P_Override_Interval" is that this interval is called in rfc460bis.

…


  2. Section 5.2. (Procedures for multicast VPN state damping) 
    • There are several places in this section where rfc2119 language is used to describe what an implementation should do that sound to me as an attempt to define functionality that is mandatory to implement (MTI).  I find that hard/impossible to enforce and would like to see the rfc2119 language removed.  Please see below..

Yes, the MUSTs in this 5.1 and 5.2 intent to carry the meaning of "mandatory to implement".

[Skipping to the specific RFC2119 question.]
…
I understand that you seem to prefer avoiding RFC2119 language for MTI things.
But I don't know another way than RFC2119 language to indicate what is mandatory to implement to be compliant with a spec, and I think this is a fairly well established practice. This is not the first document to use RFC2119 to indicate MTI things.

What is the rationale for not using RFC2119 language ?

RFC2119 reads:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.


Two points from there:
  1. If it's not necessary to for interoperation, then don't use them.  Using this text as an example: "Implementation of [RFC6513] relying on the use of PIM to carry C-multicast routing information MUST support this technique."  Implementing dampening is not necessary for RFC6513 implementations to interoperate.  In fact, if one implementation enables dampening and the other doesn't, they will still interoperate.
  2. Note that the last sentence refers specifically to implementation choices.  Using this text as an example: "The choice to implement damping…is up to the implementor…implementing the BGP approach is RECOMMENDED."  There is no need to use "RECOMMENDED" because it is not necessary for interoperability and by using it you're trying to impose a specific method.

…



    • "…damping SHOULD NOT be applied to BGP routes of the following sub-types…"  Are there cases when it is ok?  In other words, why is the "SHOULD NOT" not a "MUST NOT"?

Maybe someone can find a case where this does not break things, under some conditions.
We saw nothing mandating the use of "MUST NOT".

What conditions?

Someone finding a case sounds like Experimentation to me…




  2. Section 6.1. (Damping mVPN P-tunnel change events) "Possible ways to do so depend on the type of P-tunnel, and local implementation details are left up to the implementor.     The following is proposed as example of how the above can be achieved."  Either you leave it as an implementation detail or you provide guidance.  If this document was Experimental, then providing guidance it great!

There is a gap between "example" and "guidance".
I think an example can help the reader (implementor or deployer).
Guidance would mean that we start influencing the implementor, which is not the idea here.

You already are influencing!  See above about MTI.

_________________________________________________________________________________________________________________________

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

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
--------------030801040000020300010608-- From nobody Tue Mar 22 01:52:31 2016 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 E38EB12D7BB for ; Tue, 22 Mar 2016 01:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tKSV57nUJSH for ; Tue, 22 Mar 2016 01:52:30 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id E530D12D5C0 for ; Tue, 22 Mar 2016 01:52:29 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 32494E3007D; Tue, 22 Mar 2016 09:52:29 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 242BBE30079; Tue, 22 Mar 2016 09:52:29 +0100 (CET) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Tue, 22 Mar 2016 09:52:28 +0100 To: BESS From: Thomas Morin Organization: Orange Message-ID: <56F107CC.4020904@orange.com> Date: Tue, 22 Mar 2016 09:52:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Martin Vigoureux Subject: [bess] IETF 95 meeting, *draft* agenda X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 22 Mar 2016 08:52:31 -0000 Hi everyone We've just posted the **draft** agenda (still subject to changes) for our meeting in Buenos Aires: https://www.ietf.org/proceedings/95/agenda/agenda-95-bess We were not able to accomodate for all requests for time, thank you for your understanding. Best, -Thomas/Martin WG Status Co-Chairs, 10 min Yang models draft-dhjain-bess-bgp-l3vpn-yang draft-shah-bess-l2vpn-yang-01 draft-brissette-bess-evpn-yang-01 Patrice, 10min draft-li-bess-4pe-01 Zhenqiang, 10 min draft-zzhang-bess-evpn-bum-procedure-updates-01 Jeffrey, 15 min draft-rabadan-bess-evpn-pref-df-00 Jorge, 10 min draft-rabadan-bess-evpn-ac-df-03 Jorge, 5 min draft-rabadan-bess-vendor-evpn-route-00 Jorge, 10 min draft-boutros-bess-evpn-auto-provisioning-01 Rex or Sami, 10 min draft-boutros-bess-evpn-vpws-service-edge-gateway-02 Sami or Patrice, 10 min draft-lin-bess-evpn-irb-mcast-02 Wen, 10 min draft-sajassi-bess-evpn-l3vpn-multihoming-01 Ali, 10 min draft-hao-bess-evpn-centralized-df-00 Weiguo, 10 min From nobody Tue Mar 22 09:08:27 2016 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 35E7C12D89B for ; Tue, 22 Mar 2016 09:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.808 X-Spam-Level: X-Spam-Status: No, score=0.808 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymtUMrO_6Rca for ; Tue, 22 Mar 2016 09:08:24 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699F012D888 for ; Tue, 22 Mar 2016 09:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S9D7uZbnlbO/CVzCjq0JInwxKWu6wD75XftPrpMJ/ME=; b=lABCWMXT58oDh7K3bFryE/hDWDR6IEieBVqRx8LjSztT4CM/Fz5Qx4xCRdxqP/svrg708DUffciQXHGPojNidXSrSRJu36uilgOvJptz1v4LjPEq0Pcl7qS1Fmv4eV5pdr0VFnSoHz6Q7l4IVrQT2zKXaboQP20vgJCCuP6HX1w= 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.33.125] (66.129.241.14) by CO2PR05MB793.namprd05.prod.outlook.com (10.141.226.15) with Microsoft SMTP Server (TLS) id 15.1.434.16; Tue, 22 Mar 2016 16:08:22 +0000 To: "li_zhenqiang@hotmail.com" , bess References: <56E044DB.4090302@juniper.net> <56E715A9.1080201@juniper.net> From: Eric C Rosen Message-ID: <56F16DF1.7060307@juniper.net> Date: Tue, 22 Mar 2016 12:08:17 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050509090105080301060707" X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CY1PR21CA0029.namprd21.prod.outlook.com (25.161.247.39) To CO2PR05MB793.namprd05.prod.outlook.com (10.141.226.15) X-MS-Office365-Filtering-Correlation-Id: b4b5df21-44d7-4d6a-eeb6-08d3526c31b4 X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB793; 2:LQPGzymIegOPelsbnapRbG/UUlk/cDW057EbsfCEqyZMyokzTYQgsfo0c2H/0QCxxVXMT8/bDuGAZto/jnQ9ii/OobL6AYiRtnoqH6RYcgBdcKmK/xIXW+pFzVRxMiPXQ7KLJfxi2MsbiXZSo32u4yQ5W9vRjtfZrRIYLsDBqc+eAL6NX14vgUAjWt5kucbG; 3:rX0lM8IbCVAMZ833w8Y82ZWRFXsf+Oq5gEA4O377FnuhW4jAm+9FwSPmkehEvLAbKRlZSE/ZG/KSKJLBaui0KnyRK5Y2H1xd1Lb2hJ5rt+7k+LfMbwdemEpVQF0Nw7cI X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB793; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB793; 25:QQ8kbPfB0gTekPXOq4pKueXz5mEV/HhyOvZn1LzAJyzIE729nAgw/dXNi++DHhRPanG5hvun/t3rng5bHRdTFbapTHvdgrU7WsGqAchOrJf29bHqs/wokes4wESv+KZTHqlS/vifNabtvVYqwPrhvK2W4kVcbVxXK62ZWS5Jq1lAtQNOxkpAlmj0FhPYVW03NakBDSXoWnJb9Q17B1BQv9cVEVuYVQsJqdcKSwqbqSjw1a+04D8EHOJsYMHxQBslj1zhh5qvwrzjNCwExsxdfwX9u9E/OyqgBZ07IZ2IdGpHjIOLa9OTixkz+BEa8p7HaMexysa3CLBgcyw20LMzOkD6aVPcyV+GA3VHenY/kYlTG3W0qzLn2UcTZrDS+ceE/duD9SM36MZ9KoJk4F7nf+1gI6RLNlOQ4zx/Agj2gdspnTIMcN0wz5mfNqgJuFgamuidGEtRbxuw/805tjGmCsG+BvGD1ZW1WzZd/VNvDfJE6CQkrsR87U2jAVlC5xp7ZOMlTIxWwXhdtNA5+lzo53R3eqpuN2XwJma/cpJ13vICnfQeSdVEhweFoOllCgijFb2Hehyp0YWf4gYNNHNgv6ZhXhKgQmbYUMKqvwYyYfNVLvI/2Tnr1QR1fDnZveYRK691FhQgf8VOHjh1yLesx5ga/6bXWdmvJDwLGC9tLFp6U63h86GgBjamLhVVKanvD149Sx16H7Y4N8QXVlDdw7kit/zaQaZRTgZwJ9AHcc1p4u+LTrQbv+zbufpUUg1Q X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB793; 20:G2fIao9tfMsDcBZcpnYe8kavHz/h/4yuq+z3jFdm0lvpiAJQ2Sfq6T/h5vyaupsOZ0AUEdf2YBr8DrMRbudi8lW1D1vI8E6QqKPUgkPjrS7OBNWG5TeVytt3XCFEbpD6V1zzl/jyvl6c5WYA9HFfnVXtljA58BmWQN01mxn6MBLB/B+dp0UxzYLxhDMUSjxddiKmidLp5DJAezI1J8U3NT+YO7avTqZYFY7vpJ1DKr/PaQCc1tsqqg5s0kb7MY+yDW1YmBnOPaSRpxd2+9nNd1//mLyEigVY6pTyBnK6fOVdw042zGP5Wu1biQlEMvp6WDyVevhvnt5ngLQe0uTOCpIfLrNxPlf/do9VLYVlxJ+0uyrRBdl+/1jokxKu3wKmVbCf2Qmbk0ZtYl8uUFmOR6hOTdDTwedPDvwh+44oqKQOWWxGDSZyamfydymLUvK7AFYrHemnArYDzNyWWnBveoRNyKygG0nnwEk28Mwn9G4zhT8euxF7vv1C7TFGNQNP; 4:xr8l7xMreqFmvmMBsSAD9gB9QapB8+w1u45xUot2rCe7AspQb2GZ5uSZ7sfbiqlXu+OPdR246I8TaI8eBtU+aZ7KAsPlclsbOBwkQFRVmfs2QvnZTy/z2yU6l9lKPDoewORp/5eIRSlSWbA2bfeTuE5TFGdH0ILzVFl7HllTHgZHlnmunXxFGbw6xJ8isoTxsVQehqEG3yOfAzDrjLwr6XNbpLnqgMqCohWhnU7ATtEoG+jh2eyTSK2xQtT4Fs9J27s8vETLZCJOlQCTK1yvVOYBUXBYJpiOmAM0Ggm35paE/s6qsiTjNcJwcp+G1TPKqi7c6EzFS/IbU29XVZTNlmBFM8z9ckEdTG4PVZsf43Q07dOzlE99aIUVBy68/AZn X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:CO2PR05MB793; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB793; X-Forefront-PRVS: 08897B549D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(24454002)(377454003)(42186005)(4001350100001)(5001770100001)(33656002)(561944003)(76176999)(65806001)(65956001)(66066001)(107886002)(87266999)(50986999)(65816999)(54356999)(36756003)(16236675004)(2950100001)(84326002)(189998001)(86362001)(230783001)(5004730100002)(81166005)(64126003)(83506001)(5008740100001)(77096005)(93886004)(19580395003)(19580405001)(1096002)(80316001)(512874002)(2501003)(92566002)(2906002)(3846002)(6116002)(586003)(270700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB793; H:[172.29.33.125]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA1TUI3OTM7MjM6bnFTczBuWTlUMi85TXlwMHRjMlVxWmQyVDh0?= =?utf-8?B?dFo2ZWhaT2dBMVZPTW9CdHBVMjBvcmpBdStBWC9SVlRra0Z3OGd5dlZQSjhL?= =?utf-8?B?ZTNXdlZONEMrM0JvRkNUOUhFNFJtK25JQlduMm5iUTd2T3RjN1ZXT3RlVkxy?= =?utf-8?B?WFF2VnQ1VE9VUUx1Qk5udmFwZk0wazgySWt2TEVRRmRsRGlRdml0Uk9EOTJo?= =?utf-8?B?dWIzQTRjK09aUll3Y0xpWWhtb0NWbW03NUJCb1lNWkJ6UHQ4TWpITEFEbU1l?= =?utf-8?B?aDAycG9nek1uRmUxTlJ4UTNRUEdBOGl1Z08zWnJ2cWt1bUdyU3NrSUhxdjgy?= =?utf-8?B?Z1NOUS9qeEF0NDBTbWtXYW43dXlQL1ZzcjBOMDg3M2dsdlJ3NjU5N0Z2aXpF?= =?utf-8?B?YzJORW9zSUlsemJVSC9ycVRCaTk4QjNZTnZ0ZExjY2FuZmJqODRMYmVFaEtT?= =?utf-8?B?K0t2YWRid1AvN2VacVJCVWordW9uR2RvWlNybGFuOGhhOWdlaVQ1WFk3UHFN?= =?utf-8?B?VWZ4aGRydktOL2lpZnBEWGxEdzV0MXJsVCtxUTM4b2M2SWl6Y00vRm1rbDY5?= =?utf-8?B?Y2xFSk5ZeVpHS0Nkbm1SdXUzb0ZEL0N2NFpKeCtoZ3B2bkZoeXNEbVRlZFRV?= =?utf-8?B?aVpmN0JlOTdjeFc2SS8vRTJsK043S0pxOVU4ZUlENDAzVGlZTTU5N1ZZNnRP?= =?utf-8?B?czh3ZWswMUM3d3dreGp3MjlQMFJEMWpFcC9Qekg1Qm5qY2JCdTR2TWhTcUx1?= =?utf-8?B?QW5UZ05yemZXc3BFMVpGNUlKNzR0MTcrLytod2xPT2FwQUppRnNnTWV5VXZG?= =?utf-8?B?eHljMnJJRzRFZjNVYit0L3dibGNiUlRWVXdmeXhXVDVnZlNLL2NLQjNkNGlD?= =?utf-8?B?Y0hYcmZzUitvN2NOK3JrUmdMTmpLN093UlNWQ3kyNXFmTHh4N0FPVUplaU0z?= =?utf-8?B?aU40ek4zUUMweVhIUk91MFpmWWFyTXFkUTJsT0RVdHMyK3BtSFpiSXZaZW1U?= =?utf-8?B?dGJMMlc0Nm12Y1dHa2lkQlR4bXJReUVRTnBnanAyWlE2NHRtWmc3akRZOEw5?= =?utf-8?B?b3JtbzBVUEQ4a25kbHFteUFQOFZnZmhYSUZCc2tEZFR5LzNneUxDUGNYa29z?= =?utf-8?B?MFVOVVdtK1VtVVNOaFphaUNhMEJHVVFyeWVHMytKVUE3S0NMMUlQNkxOQ0dV?= =?utf-8?B?UXYwQ3dKMkFXbVRLTkxpaUJ6SWhKay9HVklZNHM2TUNHZHM5WFkxYTRNa2Rz?= =?utf-8?B?R3d3MDFrQk9FOVdhSVRGYzAwd0lidXk3YVowdStOVEhWV25rNDNQRkxoMXhU?= =?utf-8?B?Q2FwQlMxUUtITzlOWjhSUmdVaFkxdmZRZVJCVjVMNi9rV01xcU5ySHJMcG4r?= =?utf-8?B?QlRiS2tMdVFxMEc1TzJ5c0FjVWMwQ3NCODJ1N3daUDVOZTBGN3E5MDhhK0Z5?= =?utf-8?B?YkZFWWVZbXd0YjhVK0ROWjd2RklPR1ZOWno2VVRIaTJmcExiRW90Vitqdm0x?= =?utf-8?B?bVozZVIwd0dncVFBS2VXYUE0Uk1VT21BMDVMYkZMdkthemdjbG1xS1RtU0p4?= =?utf-8?Q?St+htdmsJ4ehBhnokwPq+PAljpTZ7w6rQQ1NQcXknvU=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB793; 5:kIbYCZTKWe+2aVGcjuAPi7DR5hWMvNxwvLQarinuC9v+rTG2jb2QMxM4FMEsYOoqXmWM/5wrgL3eZNDze9ThCMQ1bU2oIuAzIMwCaeUdqkjaidEjfKMjmRsUS48iY+KDbSEyjsCyYYu+fuDXu0e0RA==; 24:bbrd4C3QVn8UVBIaiom8PSri/4B3EASIPuLHhnv049qGVLDZc+kMQr0sUX7yZvmywdp4UppKinU7bwXr1J2DVah4X5CllR2A0CAnNIIg/8U= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2016 16:08:22.6383 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB793 Archived-At: Subject: Re: [bess] Fw: New Version Notification for draft-li-bess-4pe-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 22 Mar 2016 16:08:26 -0000 --------------050509090105080301060707 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 3/16/2016 4:57 AM, li_zhenqiang@hotmail.com wrote: > Hi, Eric and all, > > Try to answer your questions below, please comment. > > Q: If the core runs only IPv6/MPLS, and the next hop of a 4PE route is > an IPv4 address, I don't really see how the next hop resolution is > going to work, as the next hop (a v4 address) will not appear to be > reachable through the v6 core. > A: No, you can not use the v4 next hop to reach the egress 4PE in the > v6 core directly. But, the ingress 4PE can use the v4 next hop to get > the corresponding v6 address of the egress 4PE and forward the packet > toward the egress 4PE through the v6 LSP after encapsulation. > Encapsulation here means adding two labels. Ingress 4PE needs a data > structure to establish the connection between the v4 next hop and the > the corresponding v6 address of the egress 4PE. This data structure is > implementation specific. I think the key statement here is "Ingress 4PE needs a data structure to establish the connection between the v4 next hop and the the corresponding v6 address of the egress 4PE. This data structure is implementation specific." Whatever implementation technique you choose to use, you are still treating the v6 next hop as the real next hop. I don't see why the protocol should not carry the v6 next hop in the next hop field, per RFC 5549. > > Q: I think your proposal really is intended to treat the v6 address in > the NLRI as the next hop. But that leaves open the question of why > you want to put the next hop address in the NLRI field instead of in > the next hop field. > A: What I want is to send both the IPv4 and IPv6 addresses of the 4PE > to other 4PEs. But the IPv4 address of the 4PE router plays no role in the protocol. In the implementation, you seem to be using it only as a sort of pointer to the IPv6 address of the 4PE router. > > Q: Some people think it's a bad idea for the prefix and the next hop > to be of different address families; those folks tend to regard RFC > 5549 as a bad solution. > A: I don't think I am one of those folks. > > Q: However, I don't see what advantage your proposal has over RFC > 5549. In order to determine whether a given 4PE route is feasible, > or whether it is the bestpath, you still have to resolve the IPv6 next > hop, you still have to consider the IGP distance to the IPv6 next hop, > etc. > A: If 4PE only gets the v6 addresses of the other 4PEs, how does the > 4PE build its IPv4 routing table? Can it install a v6 address in its > v4 routing table? Whether an IPv6 address can be installed as a next hop in the IPv4 routing table is an implementation issue. I don't see any reason for the protocol to carry around the IPv4 address of the 4PE router, as this information doesn't really play any role. If you put the next hop in the NLRI, and put a meaningless value in the next hop field, you have to revise all the bestpath selection rules. --------------050509090105080301060707 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit On 3/16/2016 4:57 AM, li_zhenqiang@hotmail.com wrote:
Hi, Eric and all,

Try to answer your questions below, please comment.

Q: If the core runs only IPv6/MPLS, and the next hop of a 4PE route is an IPv4 address, I don't really see how the next hop resolution is going to work, as the next hop (a v4 address) will not appear to be reachable through the v6 core.
A: No, you can not use the v4 next hop to reach the egress 4PE in the v6 core directly. But, the ingress 4PE can use the v4 next hop to get the corresponding v6 address of the egress 4PE and forward the packet toward the egress 4PE through the v6 LSP after encapsulation. Encapsulation here means adding two labels. Ingress 4PE needs a data structure to establish the connection between the v4 next hop and the the corresponding v6 address of the egress 4PE. This data structure is implementation specific.

I think the key statement here is " Ingress 4PE needs a data structure to establish the connection between the v4 next hop and the the corresponding v6 address of the egress 4PE. This data structure is implementation specific."  Whatever implementation technique you choose to use, you are still treating the v6 next hop as the real next hop.  I don't see why the protocol should not carry the v6 next hop in the next hop field, per RFC 5549. 
 

Q: I think your proposal really is intended to treat the v6 address in the NLRI as the next hop.  But that leaves open the question of why you want to put the next hop address in the NLRI field instead of in the next hop field.
A: What I want is to send both the IPv4 and IPv6 addresses of the 4PE to other 4PEs.

But the IPv4 address of the 4PE router plays no role in the protocol.  In the implementation, you seem to be using it only as a sort of pointer to the IPv6 address of the 4PE router. 

Q: Some people think it's a bad idea for the prefix and the next hop to be of different address families; those folks tend to regard RFC 5549 as a bad solution.
A: I don't think I am one of those folks.

Q: However, I don't see what advantage your proposal has over RFC 5549.   In order to determine whether a given 4PE route is feasible, or whether it is the bestpath, you still have to resolve the IPv6 next hop, you still have to consider the IGP distance to the IPv6 next hop, etc.  
A: If 4PE only gets the v6 addresses of the other 4PEs, how does the 4PE build its IPv4 routing table? Can it install a v6 address in its v4 routing table?

Whether an IPv6 address can be installed as a next hop in the IPv4 routing table is an implementation issue.  

I don't see any reason for the protocol to carry around the IPv4 address of the 4PE router, as this information doesn't really play any role. 

If you put the next hop in the NLRI, and put a meaningless value in the next hop field, you have to revise all the bestpath selection rules. 


--------------050509090105080301060707-- From nobody Wed Mar 23 12:18:30 2016 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 F40E512D540; Wed, 23 Mar 2016 12:18:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160323191825.2494.1251.idtracker@ietfa.amsl.com> Date: Wed, 23 Mar 2016 12:18:25 -0700 Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, martin.vigoureux@nokia.com, bess@ietf.org, draft-ietf-bess-multicast-damping@ietf.org Subject: [bess] Last Call: (Multicast VPN state damping) to Proposed Standard X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 19:18:26 -0000 The IESG has received a request from the BGP Enabled Services WG (bess) to consider the following document: - 'Multicast VPN state damping' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-04-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes procedures to damp multicast VPN routing state changes and control the effect of the churn due to the multicast dynamicity in customer sites. The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control plane load increase in the core routing infrastructure. New procedures are proposed inspired from BGP unicast route damping principles, but adapted to multicast. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-multicast-damping/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-multicast-damping/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Mar 23 14:28:04 2016 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 2248912D56D; Wed, 23 Mar 2016 14:28:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160323212804.5883.13512.idtracker@ietfa.amsl.com> Date: Wed, 23 Mar 2016 14:28:04 -0700 Archived-At: Cc: draft-ietf-bess-pta-flags@ietf.org, aretana@cisco.com, bess-chairs@ietf.org, martin.vigoureux@nokia.com, bess@ietf.org Subject: [bess] Last Call: (Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags) to Proposed Standard X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 21:28:04 -0000 The IESG has received a request from the BGP Enabled Services WG (bess) to consider the following document: - 'Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-04-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The BGP-based control procedures for Multicast Virtual Private Networks make use of a BGP attribute known as the "P-Multicast Service Interface (PMSI) Tunnel" attribute. The attribute contains a one-octet "Flags" field. The purpose of this document is to establish an IANA registry for the assignment of the bits in this field. Since the Flags field contains only eight bits, this document also defines a new BGP Extended Community, "Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the PMSI Tunnel attribute. This document updates RFC 6514. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Mar 24 04:44:56 2016 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 9042912DA99 for ; Thu, 24 Mar 2016 04:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTg2mHgbiYh4 for ; Thu, 24 Mar 2016 04:44:52 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 81A6612DAA7 for ; Thu, 24 Mar 2016 04:44:51 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 155D51366D931 for ; Thu, 24 Mar 2016 11:44:47 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2OBinIu015799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Mar 2016 11:44:49 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2OBiKHm025490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Mar 2016 12:44:48 +0100 Received: from [135.224.223.131] (135.239.27.40) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 24 Mar 2016 12:44:30 +0100 Message-ID: <56F3D314.3000308@alcatel-lucent.com> Date: Thu, 24 Mar 2016 12:44:20 +0100 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: BESS Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.40] Archived-At: Subject: [bess] Buenos Aires meeting - please send your slides X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 11:44:54 -0000 All, the agenda for the BESS WG session is available here: https://www.ietf.org/proceedings/95/agenda/agenda-95-bess Speakers, please send your slides no later than Sunday the 3rd of April, midnight (local time). Thanks m&t From nobody Thu Mar 24 08:33:26 2016 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 3B1DC12DC90; Thu, 24 Mar 2016 08:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o9BdvnhvD03; Thu, 24 Mar 2016 08:33:23 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D5012DD87; Thu, 24 Mar 2016 08:17:33 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 56A1740699; Thu, 24 Mar 2016 16:17:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id E3F041A0081; Thu, 24 Mar 2016 16:17:31 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0279.002; Thu, 24 Mar 2016 16:17:31 +0100 From: To: Eric C Rosen Thread-Topic: [bess] draft-rosen-mpls-rfc3107bis Thread-Index: AdGF3GeY7oYpWXlDQPavaGqQ0wDeuQ== Date: Thu, 24 Mar 2016 15:17:30 +0000 Message-ID: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 15:33:25 -0000 Hi Eric, Thanks for your reply. Very much appreciated. Sorry for the delay in responding, but I wanted more time to think about it= .=20 I'm fine with all your point, except one. Please see inline [Bruno]. > From: Eric C Rosen [mailto:erosen@juniper.net] > Sent: Friday, January 15, 2016 7:01 PM > To: DECRAENE Bruno IMT/OLN > Cc: idr@ietf.org; BESS; mpls@ietf.org > Subject: Re: [bess] draft-rosen-idr-rfc3107bis-00 >=20 > Bruno, >=20 > Thanks for reviewing the draft! > >> - RFC 3107 provides an encoding that allows BGP to assign multiple > labels > > Upfront, the current issue is that implementations, which claim > compliance with RFC 3107, are just non-compliant. So the draft is proposi= ng > to change the specification to make such implementations compliant, while > another option would be to fix implementation (to be compliant with the > RFC they claim to support). > I think the best approach is to try to write 3107bis in such a way that > the existing deployed implementations are compliant to it. [Bruno] I understand that we have a different perspective on this. Nothing wrong, b= ut please find below mine. On my side, I think that the best approach is to have a 3107bis which is ba= ckward compatible with RFC3107. I don't see why the IEFT would want to create a bis which is not compatible= with the original RFC, especially since this incompatibility may be very d= isruptive in existing networks. > > The main issue I have, is that this draft is not backward compatible wi= th > RFC 3107 (as a RFC 3107 speaker will never notice that its peer has not s= end > the new capability, and may still send multiple labels). Plus in case of = error > due to this incompatibility, the error handling behavior is likely to be = "BGP > session shutdown" (as the NLRI "cannot" be correctly parsed) which is > disruptive. Plus the implementation A not supporting multiple labels, will > claim that the implementation B supporting multiple labels is "not > compliant" with rfc3107bis, while I would rather argue that this is > implementation A which is not compliant with RFC 3107. > Luckily, the existing deployed implementations, as far as I know, do not > support multiple labels. [Bruno] I'm sorry, but I would need more facts on this. In particular which are the= implementations that are known to be incapable of sending multiple labels,= today and in the foreseeable future. And even with such data, there is no guaranty as there may be implementatio= n that we don't know about. Therefore, creating this incompatibility is ris= ky. (Especially for network operator which are the ones which bare the risk) > If a new implementation were to send multiple > labels to an old implementation, we would likely experience the > disruptive behavior you describe. 3107bis tries to prevent this > disruption. 1) again, I appreciate the work being done to handle the fact that some imp= lementations are not compliant with RFC 3107. 2) I think you mean :s/old implementation/non compliant RFC 3107 implementa= tion. As of today "old implementation" are "existing implementations" = and they are supposed to be compliant with RFC 3107. 3) "As far as I know" all the implementations claims to be compliant with R= FC 3107, i.e. are expected to be able to receive multiple labels. And for t= he ones which we are using, they may have written this as part of a contrac= tual agreement. So before considering making a 3107bis which is non backwar= d compatible with RFC 3107, I would like to have the list of those implemen= tations. In the absence of this, I assume that current implementations are = indeed compliant with RFC 3107, just as they claim. Thanks -- Bruno > > > > I'd propose one change: > > - Capability means: I don't support receiving multiple labels, hence you > SHOULD not send that to me. > > - Even if the capability is not advertised by both peers, and hence a s= ingle > label is expected, all implementations MUST check that the "S" bit (in th= is > first label) is set to 1. If the bit is cleared, the Prefix MUST be ident= ified as > per RFC 3107/this document and treated as withdraw as defined in RFC > 7606. > > > > This means more work for rfc3107bis speakers, but we can't ask existing > speakers to do the job. Especially since they were compliant with RFC 310= 7. > If only a single label is expected, there is no real reason to check the > S bit. I'm not sure that all existing implementations actually set the > S bit, so requiring new implementations to check for it would just > introduce a possible backwards compatibility problem. > > Plus very minor comments > > - From an editorial standpoint, I'd personally favor removing =A72.2 and > saying in 2.3(or elsewhere) that if the capability is not exchanged, a si= ngle > label may be encoded. (IMHO duplicating the text is less easy to read and > more error prone. And I believe this would be enough to address your poin= t). > I went back and forth on this issue, and I'd welcome more opinions on > this from the WG. >=20 > You are right that it is generally a bad practice to have so much > duplicated text in a specification, but I thought the intention would be > clearer if the encoding for multiple labels were described separately > from the encoding for single labels. >=20 > > - In Figure 2 (=A72.3), 2 labels are indicated. Do you think there is a= need to > indicate which one is the first (Label 1) and which one is the k th (Labe= l k). > Indeed, the order of the labels is significant when the router will need = to > push them in the dataplane. Or a sentence could be added to make this > explicit. > This is mentioned in the "Data Plane" section, but I think you're right, = it > should be mentioned in section 2.3 as well. >=20 > > - In =A74, there is a possible case which is not described: > > S1 receives L11, L12,... L1k > > S1 sends L21, L12,... L1k > > S1 programs in the data plane: L21 swap L11 > > Compared to sending a single label (L21), S1 avoids having to push k la= bels > in its dataplane, which it may be incapable of. > > - In =A74 > > "While this may be useful in certain scenarios, it may provide unintend= ed > results in other scenarios." I fail to see when this can be useful as N1 = or > downstream LSR will receive packets with labels there are not aware of > (L22...L2k). Out of curiosity, I'm be curious to know the useful scenario= that > you have in mind. > Actually, I was thinking of the case you just described above, but I want= ed to > formulate it in a more general way. For all we know, may be > domain-wide unique labels ;-), or S1 may have some other way of knowing > L21 will get the packet to a node that will be able to understand > . > > - in =A75 " 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. The significance of > > this is a matter of local policy." > > For 6PE (rfc4798), may be this should not be a local policy but be spec= ified > as a priori SAFI-1 and SAFI-4 prefix should be comparable. Ideally rfc4798 > could have specified this but I haven't check if it's done. Alternatively= =A75 > could reference this case. > > (Same point for propagation between SAFI-1 and SAFI-4) > In 3107bis, I just tried to capture the fact that different implementatio= ns > handle this differently. If a particular application needs to mandate a > particular behavior, that should be part of the spec for that application. >=20 > Eric ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Mar 24 08:54:42 2016 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 ED03D12DBEF; Thu, 24 Mar 2016 08:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.38 X-Spam-Level: X-Spam-Status: No, score=0.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEXHASH_WORD=3, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W-CiIvq_TeL; Thu, 24 Mar 2016 08:54:39 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 4C06B12DC2A; Thu, 24 Mar 2016 08:42:28 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2OFfIrW028652; Thu, 24 Mar 2016 11:42:23 -0400 Received: from vawvcgsie2k1301.ciena.com (lin1-118-36-35.ciena.com [63.118.36.35]) by mx0b-00103a01.pphosted.com with ESMTP id 21s30eyh3p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 24 Mar 2016 11:42:23 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by VAWVCGSIE2K1301.ciena.com (10.4.62.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 24 Mar 2016 11:42:22 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by MDWEXCHCGSIHT01.ciena.com (10.4.140.106) with Microsoft SMTP Server (TLS) id 8.3.389.2; Thu, 24 Mar 2016 11:42:22 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Thu, 24 Mar 2016 11:42:21 -0400 From: "Shah, Himanshu" To: "bess@ietf.org" , "pals@ietf.org" Date: Thu, 24 Mar 2016 11:42:22 -0400 Thread-Topic: Request for WG adoption of draft-shah-bess-l2vpn-yang-01 Thread-Index: AdGF4iKx8iQBmnrMSwqmmiJCotxTmQ== Message-ID: <40746B2300A8FC4AB04EE722A593182BA85E5AB1@ONWVEXCHMB04.ciena.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-22214.003 X-TM-AS-Result: No--21.896200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: multipart/alternative; boundary="_000_40746B2300A8FC4AB04EE722A593182BA85E5AB1ONWVEXCHMB04cie_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-24_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: Thomas Morin , Martin Vigoureux Subject: [bess] Request for WG adoption of draft-shah-bess-l2vpn-yang-01 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 15:54:41 -0000 --_000_40746B2300A8FC4AB04EE722A593182BA85E5AB1ONWVEXCHMB04cie_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear BESS WG chairs - The authors of the draft-shah-bess-l2vpn-yang-01.txt request the adoption o= f this draft as working group document. We have been holding design team meeting every week since months and have h= ad very active participation and contribution from a lot of members (evident from the auth= or list..) We believe the individual draft is mature enough to have the entire WG to c= ontribute as a WG work item. I know this is close to the face-2-face meeting coming up shortly in a coup= le of weeks. We do not mind an extended WG adoption polling and would prefer that adopti= on email be sent out before the meeting. Thanks, Himanshu Shah on behalf of all the co-authors --_000_40746B2300A8FC4AB04EE722A593182BA85E5AB1ONWVEXCHMB04cie_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear BESS WG chairs –=

 

The authors of the draft-shah-bess= -l2vpn-yang-01.txt request the adoption of this draft=

as working group document.

<= i> <= /i>

We have been holding design team meeting every week since months and ha= ve had very active

participation and contribution fro= m a lot of members (evident from the author list..)

<= o:p> 

We believe the individual draft is mature enoug= h to have the entire WG to contribute

as a WG work it= em.

 

I know this is close= to the face-2-face meeting coming up shortly in a couple of weeks.

We do not mind an extended WG adoption polling and would pre= fer that adoption email

be sent out before the meetin= g.

 

Thanks,

Himanshu Shah on behalf of all the co-authors

 

= --_000_40746B2300A8FC4AB04EE722A593182BA85E5AB1ONWVEXCHMB04cie_-- From nobody Thu Mar 24 11:14:29 2016 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 03CEF12D77A; Thu, 24 Mar 2016 11:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPkud36Ocul4; Thu, 24 Mar 2016 11:14:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54B512D7B4; Thu, 24 Mar 2016 11:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3eWGFMTqZBO5se86P8Is8rvLx187jMrIaIOni/jAeyg=; b=KcPjVmaavCW8338V/aOdxvrYE2KRNmPgfTndEyq4cI+HPSKKh6lQ30jfCsXUscFvCo7ypCz2MSw/1QjqN5RShLFgxq76VGXgQTDO4AX/S+iBA1I/ZaWCR3F3kKaeBOoUVZCdEpmmtc7wMa+XAI9dYvV+8UFU1fwhRzcP8kxNv48= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.32.216] (66.129.241.14) by BLUPR05MB785.namprd05.prod.outlook.com (10.141.209.141) with Microsoft SMTP Server (TLS) id 15.1.443.12; Thu, 24 Mar 2016 18:14:14 +0000 To: References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Eric C Rosen Message-ID: <56F42E71.9020201@juniper.net> Date: Thu, 24 Mar 2016 14:14:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: DM3PR19CA0007.namprd19.prod.outlook.com (25.164.243.145) To BLUPR05MB785.namprd05.prod.outlook.com (10.141.209.141) X-MS-Office365-Filtering-Correlation-Id: 39a91bfa-fd5f-4f76-38ab-08d354101b95 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB785; 2:GQbkHMSj4hIrsoxl3A02rnUtzfB7noqcFMFYaY6a3kcvwQ3Pl9hY19YyxC789A8QgVpmfE6pJJYQEt2Ar9tg4fDAEXU07wl2e95xbmZ+7qNnWjeM7D4TLET0aTgeBcJdEDoqscFz3rkCmkR07RJcxI3OYXF7dEL8QNb61+pmgGA8ZF+4e4mNB4o4ITDumAEK; 3:3uyZfemuohwP3UnvdHDDex+c8aHXtYTXEEsyQGgpTx5BAZrH4nRXl5yo5lXawIR7foryvzvRZgRsu6yEbD5lE0Rv35kLiPHh5E7dWe7LdDP5vTJnOYGUObq0cCdwfpKP; 25:KXlOFyPtYsNNY1+8t4c8lrPt5yAWw7RkkkT8LlRcCRGnIsNArwpEFkUDc3ZQtGShld28gIyEgnbg05kc97YRIoARTRqcedKOruLyZkBHssA0bXSzgwzNMAB8DTWaYM+4rI1YgVE/VFBhQRtUvXvfkh2ESo0aHnuaGoB6c0awoF3Xhpxvm42dCz4O4TnUSVKBt20p+iucJz1KH3LjU8yUl9FnjPAY7Jk82MLAK3xf0LLiw7ic7GPeHKcwRHQXA5Qq4Hiwli5eU7kSyHa4Sj6VcOoFxFCB4DIB+tj0jn05U59Sz5HtyPeTHl34oEIl9IrpyWTJlm71//E0xpIPg+lF6O40PAWbv5cSH+gqsD4x8/EcoP9kq3Wt9SPvJzu6eNuqzeIsWT6Uk7HoYxfKw5fJV6gnyLKam+Vm3Uz2EjvUdTu/skR55zVewI7JjBYWWEe0iYb0lqYdaQ9nQhUW5YwXrmCIF5axzbMFUk5ebxJEzRorZKLbfKZ/S/k7upSM4Y9bIeyOpi5rbPq28elQSMigdg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB785; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB785; 20:zChs4R39RkyoN8XDF+Sn56izFuo9u6YdP3DLot+lPBQgLiCq7tqO9MfJJoQTPhZzS9M425SdfFqu85HyFUkc1LjPoZ59j7wLrmoFWIyBUkG2fuxHN8UWseS3ax0oj6x1MCwxN4oCKe8ehVubxPvWmrVVOj3XVICGWeA2PDDoQ8yHY50rscGQCCJTtQBoqfw8SjzGajskeQ4RUXT3jXnyJasvMqRw4w28A+NAcHCzQrLSPGSU2BxWFMb2TIESgyDGIS4Cns5ykVOXv7kBSKL8YK7MQxVSipt0vPJ3RGfyg7jjXpBxrMDvWHfE1IPluarKzD335hYCJgzkv3Jes4eLarhSQx8GgLNHxohHyQoS/rZ7+48Zuu+AMomY1UIT2yFOiEV2wANq9RvMBjDutYOROMHwXSxx4ui9wQV3gP4zDlxQFCMK+ZCdeZrGeTSyGl8GHoY2OvHEp3qhCx10/4spmlTIAzbV699YRKtGqZDbbPLMjxublZ11wfAjfj8V3iFS; 4:ecId2KPyClgTgK9TRU7GwD8dVrq4ZIvZPCwqVSCWXTKOdBBIVofvHf1Xm8arMHJvMm8sJTmeeArzg90TaRAkWRc6/ztO2NwC1OZhyS5+BuCIuaK6MTyb01cHwIle319/DJsw63pcLEwCGATye2pM1s3eE8oVN/SMu07bGx9jbrp4QwkvRLsxuZ5C8wSvHT1XKYe1N3v+x87g6xwB1kA7acpXGf2WAaXpbRMz7I3XvDjREC+wMKS0irWVntXyyCsWoeIVj7SLmYjVTUovjSAsJnOT4lBjy7OTQ4nnE+nQfR9dgIJRbhIPvDdUCJqCpf9Z1ng0k/VMhjGuhD2H3J7Rq0KvcXq67+gM44AP8huHXLDYzcOlmkkf9ZVNWd7kfqy3 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR05MB785; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB785; X-Forefront-PRVS: 0891BC3F3D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(377454003)(24454002)(4001350100001)(2351001)(6116002)(586003)(42186005)(23746002)(77096005)(2950100001)(3846002)(4326007)(189998001)(50466002)(5004730100002)(19580405001)(19580395003)(1096002)(36756003)(86362001)(92566002)(83506001)(5008740100001)(65956001)(64126003)(110136002)(47776003)(66066001)(230700001)(33656002)(65816999)(54356999)(87266999)(65806001)(50986999)(59896002)(2906002)(76176999)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB785; H:[172.29.32.216]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BLUPR05MB785; 23:UNj+P0S8G9VStfuKVxbUJ/L6SUgU+jmwFQSaT3?= =?Windows-1252?Q?fw41IQc5oOXEt2FGiG3VhGD+X+lrL8wcyGOACJ+edDqLnLEwp71Y6wcj?= =?Windows-1252?Q?RfPKqKxxkKM9THIekSbkbfTdtoZ0DsYjPW/VCSGtztZAoAwMjnHYuUfe?= =?Windows-1252?Q?HHMlrzKzy21dkhwGa72hb+mC1sdaJXPuH4sLRxD0akyX7oyN/HF9JM65?= =?Windows-1252?Q?vGkA4/Oz/IXsX68YDv/2zPUsmFXgGkYzQRwcC1VpgAOsbhHYGPOg/ZUn?= =?Windows-1252?Q?ZoV8p3UNlH6vb0ocm4theU7jkgSB4HnvWs/umLXbrbqXUMHXqLMOgo+W?= =?Windows-1252?Q?K5uZwA6IJBotNxnyUTksUwVRhqGzS0m98rXAcYiQAId2ZG26SmwPptIc?= =?Windows-1252?Q?lRqju/0OLyW5oBXWX1Nsy5JpDbCbNqTUMfhKZTlEDFggW5fN1X+bZ6t6?= =?Windows-1252?Q?vRtzaWBo5Xq4FB2THWZSIksxbZKvZt4ud8sAbN02ngN2Rr8S/9ZqicL4?= =?Windows-1252?Q?dsGMqGf+YBQUyNPqys+xMdFJsSIHLbTGbYHclz0ioCxDbC3LRCXci9rH?= =?Windows-1252?Q?Ek++EPMiZSQ1wu9N9+bnZHXNFG0bveL4aa3Eafx+M9HvwEuASrMr4g6K?= =?Windows-1252?Q?V8gMrFW/Ou3AHTJACqhLADgOBmmukMoFUtDR4HKLtA8vS8ZXxeXhpegO?= =?Windows-1252?Q?v7DvXweWVpNBKCUd/NNtQkMNL33yb/3HQiDwAAI+bX5ggR/78LX1n36I?= =?Windows-1252?Q?sOZIUqmAgGmufHV+N/uHBgdUJkcYdl24pYQq4eoqM1CJhO/alGwvhpV4?= =?Windows-1252?Q?oHicTPDg++Ou8TBTUuONGQYpk+nEVEpu2hhO/6fh9F1eC0EE6g0Ynk+V?= =?Windows-1252?Q?5fOBi8yrIM+JHaybDSXiswu6Ep9JObWM/NbJFF6RVe4nPpwVaZZbPnW6?= =?Windows-1252?Q?Bp3IKpOSbjwLUb4hdK0nDukjHzlMZ1AQ8tSL5pIABne07L0umS5mG3vH?= =?Windows-1252?Q?u0QCmv69tV9qEHWtYJwv/DIhyPiYVOJJ0GTWemFcCehxOWTl9QNG0Rui?= =?Windows-1252?Q?zb0497sW4aURf5N63oxWpyXR5RQ+f3RXCeT48ydHWgq9auvslfiGyWRo?= =?Windows-1252?Q?hbBI5wR+Juhz4d/bgepFRBDaGNRePNF5CZMSYF8mp25W2QstEAy/WrdZ?= =?Windows-1252?Q?nDdc0rcg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB785; 5:ieu+zdNsIn/nJXPSxj6jZlXMCaf8+vQ+FSKx/NaNdzR3t4rRjJjUIgCqOfC+/E+KqjzkCQQZcFzqz6KYS0yTnmZVhk3hoaiyXfZY2h3Uto4AcVgMuDn67zOlCErPmigQKu59rNJ7m0cN4zfrsN9SFQ==; 24:TRe5cHgMdZatRLpB/cmD2XXQ16RvZDHgQe7eE+zXj5hUI7/mWziAESkTSGwQ/VhwAr23DUL2WZXvizTB6N5UouwQ3Syj50t0nhjNbfLpg2Q= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2016 18:14:14.0064 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB785 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 18:14:27 -0000 On 3/24/2016 11:17 AM, bruno.decraene@orange.com wrote: > I don't see why the IETF would want to create a bis which is not compatible with the original RFC, It's typical in a bis draft to remove features that haven't been used. > especially since this incompatibility may be very disruptive in existing networks. My belief is that existing deployments don't use or support the multiple labels feature, and that any attempt to use it as specified in RFC3107 will itself be disruptive to existing networks, because it will have interoperability issues and unpredictable results. Adding the "multiple labels" capability is a way to make the feature deployable without causing disruption. > "As far as I know" all the implementations claim to be compliant with RFC 3107, i.e. are expected to be able to receive multiple labels. I'm quite sure you have deployed implementations, from several prominent vendors, that will not properly handle this case. If you do have a deployed implementation that can receive multiple labels, what would you expect it to do with those labels? RFC 3107 doesn't say anything about what to do in this case, it just provides an encoding. Have you ever tried to use the "multiple labels" feature? From nobody Thu Mar 24 18:20:27 2016 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 45FC912D115 for ; Thu, 24 Mar 2016 18:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYPvmK3L86Ms for ; Thu, 24 Mar 2016 18:20:23 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8412E12D0E6 for ; Thu, 24 Mar 2016 18:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SfEDi3iY0leGWPcDN2BFXeKyEmU8EqjdpXG4miJrePU=; b=jg5ze1vQnHVmh1tqKiGATc3SgLh3T02y20XkON2CNkHaN58QRMqVWicRHUFSQRnyIyDmXHRL0t8sBG100wEUd+GHM9j88pOVi+9Uh2oe2T2o8F8XwsuuPPxGdo4Eq7Js034FNL0qWWOuoQu50aeZhm99kWBQZeHjIl55ZSAZ8Tk= Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1713.namprd05.prod.outlook.com (10.163.120.16) with Microsoft SMTP Server (TLS) id 15.1.443.12; Fri, 25 Mar 2016 01:20:22 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0443.015; Fri, 25 Mar 2016 01:20:22 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "sboutros@vmware.com" , "bess@ietf.org" Thread-Topic: Questions & comments on draft-boutros-bess-evpn-vpws-service-edge-gateway-02 Thread-Index: AdGGEHctEGRuORt7QSe3262I08E2kw== Date: Fri, 25 Mar 2016 01:20:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vmware.com; dkim=none (message not signed) header.d=none;vmware.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: d4599214-89df-4efb-cf10-08d3544ba2fc x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1713; 5:gLwmtcRoM8RZP65qmQx433OsLDs/xxf0smfyuBKMzxn3bt8345by1SgbJrsluen9pB1xZFPigKTIXz8tqhu42MGYKQCIba+OK30rBVFOHukfLom6QjXnAhErr0YQBaKVc5q3eP1xjr9M36+JgdXU8A==; 24:wkaqNzL+adD7K/VuF+RAPurf3WvaRdjEReViHclMR2Qad1iqHtrX3vZKX2mdKYWcPp5ywLI7eJMw6LvS8hF0AOzJrjLzflnwjZ67mijIFzU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1713; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR0501MB1713; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1713; x-forefront-prvs: 0892FA9A88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2900100001)(3660700001)(54356999)(1220700001)(87936001)(3280700002)(5008740100001)(50986999)(586003)(2906002)(3846002)(86362001)(5001770100001)(1096002)(76576001)(74316001)(77096005)(6116002)(102836003)(11100500001)(81166005)(99286002)(229853001)(230783001)(5003600100002)(92566002)(5002640100001)(5004730100002)(10400500002)(5890100001)(189998001)(122556002)(33656002)(107886002)(2501003)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1713; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2016 01:20:22.1566 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1713 Archived-At: Subject: [bess] Questions & comments on draft-boutros-bess-evpn-vpws-service-edge-gateway-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 25 Mar 2016 01:20:25 -0000 Sami and co-authors, I have some comments & questions on this draft. I noticed that the following terms are used in a mixed way and that adds co= nfusion. Perhaps it could be straightened out? Service node, service edge node, service edge gateway, access node Also in Figure 1, "AN" and "SE" are not marked in the figure. There are a couple of places referring to "underlay EVI". Given that underl= ay typically refer to the underlying provider network, perhaps "transport E= VI" or "VPWS EVI" would be better? This document describes how a service node can act as a gateway terminating dynamically EVPN virtual private wire service (VPWS) from access nodes and offering Layer 2, EVPN and Layer 3 VPN overlay services to Customer edge devices connected to the access nodes. I take it that the gateway is offering "layer 2, EVPN and layer 3 VPN" serv= ices but instead of via local attachment circuits, it's via VPWS implemente= d via EVPN. "4.2 Applicability to IP-VPN TBD" is empty, so I'll use EVPN for my underst= anding: the VPWS brings the customer connection (on the AN) to the EVPN on = the gateway. There could be many VPWS from multiple ANs terminating into th= e same EVPN instance on the gateway. With that, I wonder if EVPN virtual hu= b and spoke could be used to implement the same? The ANs would be the spoke= s and the gateway would be the hub? Other EVPN PEs (not drawn in Figure 1) = on the core side can be either spokes or hubs in the same EVPN instance? If the above makes sense, then could the same be extended to IP-VPN service= ? You just need an IRB interface for the EVPN instance on the gateway? Thanks. Jeffrey From nobody Fri Mar 25 04:26:04 2016 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 6FBC412D66E; Fri, 25 Mar 2016 04:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mgw_HTrG2kF2; Fri, 25 Mar 2016 04:26:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B5912D68D; Fri, 25 Mar 2016 04:26:01 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 6981D22C750; Fri, 25 Mar 2016 12:25:59 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3C66523805C; Fri, 25 Mar 2016 12:25:59 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0279.002; Fri, 25 Mar 2016 12:25:58 +0100 From: To: Eric C Rosen Thread-Topic: [bess] draft-rosen-mpls-rfc3107bis Thread-Index: AQHRhfj17oYpWXlDQPavaGqQ0wDeuZ9p2nRA Date: Fri, 25 Mar 2016 11:25:58 +0000 Message-ID: <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> In-Reply-To: <56F42E71.9020201@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.25.103616 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 25 Mar 2016 11:26:03 -0000 > From: Eric C Rosen [mailto:erosen@juniper.net] > Sent: Thursday, March 24= , 2016 7:14 PM > On 3/24/2016 11:17 AM, bruno.decraene@orange.com wrote: > > I don't see why the IETF would want to create a bis which is not > compatible with the original RFC, >=20 > It's typical in a bis draft to remove features that haven't been used. - Not by making it non backward compatible with the current RFC, in a way w= hich is very disruptive (BGP session shut and the session will stay down or= keep cycling) - On a side note, rfc3107bis does not remove the feature to advertise multi= ple labels.=20 =20 > > especially since this incompatibility may be very disruptive in existing > networks. >=20 > My belief is that existing deployments don't use or support the multiple > labels feature, Do you have data that support this? i.e. there are no deployments and no si= ngle implementation which advertise multiple labels? That sounds very hard = to prove. Hence there will be a risk, and this risk is bared by network ope= rators. I don't see a reason why I would take that risk.=20 > and that any attempt to use it as specified in RFC3107 > will itself be disruptive to existing networks, IMHO RFC3107 is clear enough with respect to the encoding of multiple label= s inside the BGP UPDATE. I fail to see which point would not be clear to so= meone. But this is a theoretical discussion since so far, AFAIK, no major implemen= tation has stated that they would not be able to understand NLRI received w= ith multiple labels, and hence would shutdown the BGP session. So I'm waiting for those hypothetical implementations to declare themselves= . Then we'll see if they are compliant with RFC 3107 or if this is rather a= n implementation issue. > because it will have > interoperability issues and unpredictable results. Any non-compliant implementation may create interoperability issues and unp= redictable results. >From an IETF standpoint, the question is whether a RFC 3107 implementation = would create interoperability issues, up to shutting down the BGP session. > Adding the "multiple > labels" capability is a way to make the feature deployable without > causing disruption. I agree with this point. (although one could also discuss this, at it seems a way to accommodate non= -compliant implementation) =20 > > "As far as I know" all the implementations claim to be compliant with R= FC > 3107, i.e. are expected to be able to receive multiple labels. > I'm quite sure you have deployed implementations, from several > prominent vendors, that will not properly handle this case. I'm waiting for this/these implementation(s) to make a public statement in = this thread / IETF WGs. Then we can discuss whether the issue comes from RF= CF3107 or from the implementation. If none make a public statement, we should assume that all implementations = are capable of receiving multiple labels, as per RFC 3107. And hence there = is no need to make a 3107bis which is non backward compatible with RFC 3107. =20 > If you do have a deployed implementation that can receive multiple > labels, what would you expect it to do with those labels?=20 A priori, the sender said "For FEC X, uses this label stack", so any behavi= or compliant with this information e.g. what is described in your bis draft= https://tools.ietf.org/html/draft-rosen-idr-rfc3107bis-00#section-4 > RFC 3107 > doesn't say anything about what to do in this case, it just provides an > encoding. RFC3107 describes the BGP encoding, aka "bits on the wire". It does describe how to send and receive multiple labels from a BGP standpo= int. This does not involve shutting down the BGP session when multiple labe= ls are received. =20 > Have you ever tried to use the "multiple labels" feature? If you mean by following RFC 3107, I'm not seeing why the BGP session would= need to be shutdown. If you mean that some non-compliant implementation do not work, well let's = fix them. And I don't see how making a rfc3107bis non backward compatible with RFC 31= 07 would improve the situation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Mar 28 09:32:00 2016 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 1739312DB64 for ; Mon, 28 Mar 2016 09:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.931 X-Spam-Level: X-Spam-Status: No, score=-6.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0hWnKP52vMR4 for ; Mon, 28 Mar 2016 09:31:57 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6AB12DB1B for ; Mon, 28 Mar 2016 09:31:57 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id B65172834D; Mon, 28 Mar 2016 09:31:55 -0700 (PDT) Received: from EX13-CAS-001.vmware.com (ex13-cas-001.vmware.com [10.113.191.51]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 7858CB0BEB; Mon, 28 Mar 2016 09:31:56 -0700 (PDT) Received: from EX13-MBX-015.vmware.com (10.113.191.35) by EX13-MBX-020.vmware.com (10.113.191.40) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 28 Mar 2016 09:31:56 -0700 Received: from EX13-MBX-015.vmware.com ([fe80::a0c7:ec4c:3ac4:6a0e]) by EX13-MBX-015.vmware.com ([fe80::a0c7:ec4c:3ac4:6a0e%15]) with mapi id 15.00.1156.000; Mon, 28 Mar 2016 09:31:56 -0700 From: Sami Boutros To: "Jeffrey (Zhaohui) Zhang" , "bess@ietf.org" Thread-Topic: Questions & comments on draft-boutros-bess-evpn-vpws-service-edge-gateway-02 Thread-Index: AdGGEHctEGRuORt7QSe3262I08E2kwC/t/2A Date: Mon, 28 Mar 2016 16:31:56 +0000 Message-ID: <8EC85664-7583-441E-8276-6F2AE3FC113E@vmware.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.113.170.11] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Questions & comments on draft-boutros-bess-evpn-vpws-service-edge-gateway-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 28 Mar 2016 16:31:59 -0000 SGkgSmVmZnJleSwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIGFuZCBQbGVhc2Ugc2VlIGNv bW1lbnRzIGlubGluZS4uDQoNCk9uIDMvMjQvMTYsIDY6MjAgUE0sICJKZWZmcmV5IChaaGFvaHVp KSBaaGFuZyIgPHp6aGFuZ0BqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCj5TYW1pIGFuZCBjby1hdXRo b3JzLA0KPg0KPkkgaGF2ZSBzb21lIGNvbW1lbnRzICYgcXVlc3Rpb25zIG9uIHRoaXMgZHJhZnQu DQo+DQo+SSBub3RpY2VkIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXJtcyBhcmUgdXNlZCBpbiBhIG1p eGVkIHdheSBhbmQgdGhhdCBhZGRzIGNvbmZ1c2lvbi4gUGVyaGFwcyBpdCBjb3VsZCBiZSBzdHJh aWdodGVuZWQgb3V0Pw0KPg0KPiAgU2VydmljZSBub2RlLCBzZXJ2aWNlIGVkZ2Ugbm9kZSwgc2Vy dmljZSBlZGdlIGdhdGV3YXksIGFjY2VzcyBub2RlDQoNClNhbWk6IEFncmVlZCB3aWxsIHVwZGF0 ZSB0aGUgdGV4dCBpbiBuZXh0IHJldi4NCj4NCj5BbHNvIGluIEZpZ3VyZSAxLCAiQU4iIGFuZCAi U0UiIGFyZSBub3QgbWFya2VkIGluIHRoZSBmaWd1cmUuDQoNClNhbWk6IHdpbGwgZG8uDQo+DQo+ VGhlcmUgYXJlIGEgY291cGxlIG9mIHBsYWNlcyByZWZlcnJpbmcgdG8gInVuZGVybGF5IEVWSSIu IEdpdmVuIHRoYXQgdW5kZXJsYXkgdHlwaWNhbGx5IHJlZmVyIHRvIHRoZSB1bmRlcmx5aW5nIHBy b3ZpZGVyIG5ldHdvcmssIHBlcmhhcHMgInRyYW5zcG9ydCBFVkkiIG9yICJWUFdTIEVWSSIgd291 bGQgYmUgYmV0dGVyPw0KDQpTYW1pOiBXZSB3aWxsIHVwZGF0ZSB0aGlzIHRleHQgdG9vLg0KPg0K PiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBhIHNlcnZpY2Ugbm9kZSBjYW4gYWN0IGFz IGEgZ2F0ZXdheQ0KPiAgIHRlcm1pbmF0aW5nIGR5bmFtaWNhbGx5IEVWUE4gdmlydHVhbCBwcml2 YXRlIHdpcmUgc2VydmljZSAoVlBXUykgZnJvbQ0KPiAgIGFjY2VzcyBub2RlcyBhbmQgb2ZmZXJp bmcgTGF5ZXIgMiwgRVZQTiBhbmQgTGF5ZXIgMyBWUE4gb3ZlcmxheQ0KPiAgIHNlcnZpY2VzIHRv IEN1c3RvbWVyIGVkZ2UgZGV2aWNlcyBjb25uZWN0ZWQgdG8gdGhlIGFjY2VzcyBub2Rlcy4NCj4N Cj5JIHRha2UgaXQgdGhhdCB0aGUgZ2F0ZXdheSBpcyBvZmZlcmluZyAibGF5ZXIgMiwgRVZQTiBh bmQgbGF5ZXIgMyBWUE4iIHNlcnZpY2VzIGJ1dCBpbnN0ZWFkIG9mIHZpYSBsb2NhbCBhdHRhY2ht ZW50IGNpcmN1aXRzLCBpdCdzIHZpYSBWUFdTIGltcGxlbWVudGVkIHZpYSBFVlBOLg0KDQpTYW1p OiBDb3JyZWN0Lg0KPg0KPiI0LjIgQXBwbGljYWJpbGl0eSB0byBJUC1WUE4gVEJEIiBpcyBlbXB0 eSwgc28gSSdsbCB1c2UgRVZQTiBmb3IgbXkgdW5kZXJzdGFuZGluZzogdGhlIFZQV1MgYnJpbmdz IHRoZSBjdXN0b21lciBjb25uZWN0aW9uIChvbiB0aGUgQU4pIHRvIHRoZSBFVlBOIG9uIHRoZSBn YXRld2F5LiBUaGVyZSBjb3VsZCBiZSBtYW55IFZQV1MgZnJvbSBtdWx0aXBsZSBBTnMgdGVybWlu YXRpbmcgaW50byB0aGUgc2FtZSBFVlBOIGluc3RhbmNlIG9uIHRoZSBnYXRld2F5LiBXaXRoIHRo YXQsIEkgd29uZGVyIGlmIEVWUE4gdmlydHVhbCBodWIgYW5kIHNwb2tlIGNvdWxkIGJlIHVzZWQg dG8gaW1wbGVtZW50IHRoZSBzYW1lPyBUaGUgQU5zIHdvdWxkIGJlIHRoZSBzcG9rZXMgYW5kIHRo ZSBnYXRld2F5IHdvdWxkIGJlIHRoZSBodWI/IE90aGVyIEVWUE4gUEVzIChub3QgZHJhd24gaW4g RmlndXJlIDEpIG9uIHRoZSBjb3JlIHNpZGUgY2FuIGJlIGVpdGhlciBzcG9rZXMgb3IgaHVicyBp biB0aGUgc2FtZSBFVlBOIGluc3RhbmNlPw0KPg0KPklmIHRoZSBhYm92ZSBtYWtlcyBzZW5zZSwg dGhlbiBjb3VsZCB0aGUgc2FtZSBiZSBleHRlbmRlZCB0byBJUC1WUE4gc2VydmljZT8gWW91IGp1 c3QgbmVlZCBhbiBJUkIgaW50ZXJmYWNlIGZvciB0aGUgRVZQTiBpbnN0YW5jZSBvbiB0aGUgZ2F0 ZXdheT8NCg0KU2FtaTogVGhlIGN1cnJlbnQgZG9jdW1lbnQgZG9lc27igJl0IHByZWNsdWRlIHRo ZSBJUkIgb3B0aW9uIGFuZCB0ZXJtaW5hdGluZyBtdWx0aXBsZSBFVlBOIFZQV1MgdG8gdGhlIHNh bWUgTDIgb3ZlcmxheSBicmlkZ2UgdGhhdCBoYXMgYW4gSVJCIGludGVyZmFjZSBhdHRhY2hlZCB0 byBhbiBJUC1WUE4gc2VydmljZS4gVGhlIGVtcHR5IHNlY3Rpb25zIGFyZSB0aGVyZSBmb3IgZGVz Y3JpYmluZyB1c2UgY2FzZXMgdGhhdCB3ZSB3aWxsIHBsYW4gdG8gYWRkIHRvIHRoZSBkb2N1bWVu dCBpbiB0aGUgZnV0dXJlLg0KDQpUaGFua3MsDQoNClNhbWkNCg0KPg0KPlRoYW5rcy4NCj5KZWZm cmV5DQo+DQo= From nobody Tue Mar 29 02:46:24 2016 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 6B05812D0A4 for ; Tue, 29 Mar 2016 02:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcfmtjiGsp7B for ; Tue, 29 Mar 2016 02:46:20 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF0B12D5C9 for ; Tue, 29 Mar 2016 02:46:20 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id F052320154 for ; Tue, 29 Mar 2016 11:46:18 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id CE1D112006E for ; Tue, 29 Mar 2016 11:46:18 +0200 (CEST) Received: from [10.193.71.12] (10.168.234.5) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.279.2; Tue, 29 Mar 2016 11:46:18 +0200 To: References: <20160316233049.29369.42937.idtracker@ietfa.amsl.com> From: Organization: Orange Message-ID: <11748_1459244778_56FA4EEA_11748_597_1_56FA4EEA.9000607@orange.com> Date: Tue, 29 Mar 2016 11:46:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160316233049.29369.42937.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.5] Archived-At: Subject: Re: [bess] IPR Disclosure Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 09:46:22 -0000 FYI. The following can now be read at https://datatracker.ietf.org/ipr/2774/ : "Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-bess-evpn-etree This IPR disclosure was removed at the submitter's request. " Best, -Thomas IETF Secretariat : > Dear Ali Sajassi, Samer Salam, Sami Boutros, Jim Uttaro: > > > An IPR disclosure that pertains to your Internet-Draft entitled "E-TREE > Support in EVPN & PBB-EVPN" (draft-ietf-bess-evpn-etree) was submitted > to the IETF Secretariat on and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/2774/). The title of the IPR disclosure is > "Juniper Networks, Inc.'s Statement about IPR related to > draft-ietf-bess-evpn-etree" > > > Thank you > > IETF Secretariat > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Tue Mar 29 02:49:10 2016 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 3E0E912D13B for ; Tue, 29 Mar 2016 02:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k-UTkVddvxf for ; Tue, 29 Mar 2016 02:49:07 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B3F12D109 for ; Tue, 29 Mar 2016 02:49:07 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id BF9F94013F; Tue, 29 Mar 2016 11:49:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 8202E1A0054; Tue, 29 Mar 2016 11:49:05 +0200 (CEST) Received: from [10.193.71.12] (10.168.234.5) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.279.2; Tue, 29 Mar 2016 11:49:05 +0200 To: "Ali Sajassi (sajassi)" , "Jeffrey (Zhaohui) Zhang" , BESS , "draft-ietf-bess-evpn-etree@tools.ietf.org" References: <569DF8F7.2000703@orange.com> From: Organization: Orange Message-ID: <13131_1459244945_56FA4F91_13131_9249_1_56FA4F90.300@orange.com> Date: Tue, 29 Mar 2016 11:49:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.168.234.5] Archived-At: Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 29 Mar 2016 09:49:10 -0000 Hi everyone, This WG Last Call is now closed and the document will move to the next steps toward publication. The modification mentioned below will be incorporated in next release. Best, -Thomas 2016-03-15, Ali Sajassi (sajassi): > > Jeffrey, > > > > On 2/1/16, 2:41 PM, "Jeffrey (Zhaohui) Zhang" wrote: > >> Ali, >> >> One more question about PBB-EVPN. >> >> For the regular EVPN, section 3.3.2 talks about a situation where the >> only traffic is BUM. There is no need for mac learning in that situation. >> >> For PBB-EVPN, I assume this is also possible. With this, there is no need >> to advertise per-ES B-mac addresses - a single pair of global root/leaf >> B-mac addresses are enough. >> >> Perhaps this can be mentioned for parity/completeness. Of course, this is >> not a big deal and either way it's fine - but I do want to ask to confirm >> my understanding. > > We’ll do. > > Cheers, > Ali > >> >> Jeffrey >> >>> -----Original Message----- >>> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >>> Sent: Monday, February 01, 2016 2:04 AM >>> To: Jeffrey (Zhaohui) Zhang ; EXT - >>> thomas.morin@orange.com ; BESS ; >>> draft-ietf-bess-evpn-etree@tools.ietf.org >>> Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree >>> >>> Hi Jeffrey, >>> >>> Thanks for the review. Your comments helps tighten the draft some more. >>> I >>> have updated the draft and will publish it next (rev04). Majority of the >>> comments were editorial in nature for better clarifications. Since the >>> existing draft (rev03) reflects the consensus regarding our several >>> rounds >>> of discussions where we have taken care of the technical items, it is >>> consistent with our expectation of not seeing any major issue during the >>> LC. Please refer to my replies in line. >>> >>> Cheers, >>> Ali >>> >>> >>> On 1/27/16, 5:26 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" >>> wrote: >>> >>>> I was involved in relevant discussions, and have reviewed once more for >>>> this LC. >>>> >>>> I support the publication, but with the following questions/comments. >>>> >>>> 2.1 Scenario 1: Leaf OR Root site(s) per PE >>>> >>>> ... If the number of EVIs is very large >>>> (e.g., more than 32K or 64K), then RT type 0 as defined in [RFC4360] >>>> SHOULD be used; otherwise, RT type 2 is sufficient. >>>> >>>> RFC 7153 should be referenced for "Type 2". >>> >>> >>> Done. >>> >>>> >>>> Additionally, why is 32K mentioned? I can understand the 64k part. >>> >>> Removed 32K since the example is clear enough with 64K >>> >>>> >>>> ... the MPLS-encapsulated frames MUST be tagged with an >>>> indication of whether they originated from a Leaf AC or not. >>>> >>>> Perhaps change the last line to "indication if they originated from a >>>> Leaf AC"? Packets from a root AC are not tagged with a leaf indication. >>> >>> OK. Better yet. It should say ³indication when they originated from a >>> leaf >>> AC². >>> >>>> >>>> Other mechanisms for identifying whether an egress AC is a root or >>>> leaf is beyond the scope of this document. >>>> >>>> Should "egress" be "ingress" in the above paragraph? Or simply removed? >>> >>> Nice catch! It is ³ingress². It is now corrected. >>> >>>> >>>> ... This Leaf MPLS label is advertised to other PE devices, >>>> using a new EVPN Extended Community called E-TREE Extended Community >>>> (section 5.1) along with an Ethernet A-D per ES route with ESI of >>>> zero and a set of Route Targets (RTs) corresponding to all the leaf >>>> ACs on the PE. >>>> >>>> Perhaps change the last sentence to "... corresponding to all EVIs that >>>> have leaf sites on the PE." >>> >>> The second to last sentence of section 3.2.1 says the same thing. I >>> changed this sentence and removed the 2nd to last sentence. >>> >>>> >>>> 3.2.3 BUM traffic originated from a multi-homed site on a leaf AC >>>> >>>> In this scenario, it is assumed that a multi-homed Ethernet Segment >>>> (ES) can have a mixed of both leaf and root ACs with each AC >>>> designating a subnet (e.g., a VLAN). >>>> >>>> I understand that different VLANs on the same ES could be roots or >>>> leaves. I suppose it's more important to say that for the same vlan, >>>> different PEs on the same ES must have the same root/leaf designation. >>> >>> That¹s given. >>> >>>> >>>> Perhaps the first sentence could be reworded as the following to >>> capture >>>> the above point: >>>> >>>> While different ACs (VLANs) on the same ES could have different >>>> root/leaf designation (some being roots and some being leaves), >>>> the same VLAN does have the same root/leaf designation on all >>>> PEs on the same ES. >>> >>> That¹s fine. It makes it more clear. >>> >>>> >>>> For the following: >>>> >>>> ... the PEs with Leaf sites perform MAC learning in the >>>> data-path over their Ethernet Segments, and advertise reachability >>> in >>>> EVPN MAC Advertisement routes which are imported only by PEs with at >>>> least one Root site in the EVI. A PE with only Leaf sites will not >>>> import these routes. PEs with Root and/or Leaf sites may use the >>>> Ethernet A-D routes for aliasing (in the case of multi-homed >>>> segments) and for mass MAC withdrawal per [RFC 7432]. >>>> >>>> The above seems to contradict with the recommendation in Section 2.2. >>> If >>>> the context is the scenario described in section 2.1 then that's fine, >>>> but the text does not have a clear context. >>> >>> Agreed. Updated the section to indicate the context is section 2.1. >>> >>>> >>>> >>>> 3.3.2 E-Tree without MAC Learning >>>> >>>> The PEs implementing an E-Tree service need not perform MAC learning >>>> when the traffic flows between Root and Leaf sites are multicast or >>>> broadcast. >>>> >>>> I suppose an "only" word should be added at the end of the above >>> sentence. >>> >>> Agreed. >>> >>>> >>>> >>>> The fields of the IMET route are populated per the procedures >>> defined >>>> in [RFC7432], and the route import rules are as described in >>> previous >>>> sections. >>>> >>>> The route import rules described in previous sections are for MAC >>> routes, >>>> not IMET routes. Additionally, those rules may not be recommended, so >>>> might as well delete the last sentence. >>> >>> Changed the last sentence to ³Š, and the multicast tunnel setup criteria >>> are as described in the previous section.² >>> >>>> >>>> Section 3.3.1 talks about BUM procedures. That is not specific to 3.3.1 >>>> though. Perhaps extract that out to a separate section, and remove the >>>> BUM text from 3.3.2 as well. >>> >>> I think it is OK. >>> >>>> >>>> The E-TREE Extended Community is encoded as an 8-octet value as >>>> follows: >>>> >>>> >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Type=0x06 | Sub-Type=0x04 | Flags(1 Octet)| >>> | >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Reserved=0 | Leaf Label >>> | >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> I assume the octect after the flags octet is also reserved=0. Better >>> mark >>>> it as "Reserved=0". >>> >>> Agreed. >>> >>>> >>>> When it is used with Ethernet A-D per ES route, the leaf flag SHOULD be >>>> set to 0 but ignored by the receiving routers. Therefore, why not set >>> it >>>> to 1 to be consistent the MAC/IP route case? >>> >>> Because the flag is used for known unicast traffic and Leaf label for >>> BUM >>> traffic. We don¹t want to mix the two. >>> >>> Cheers, >>> Ali >>> >>>> >>>> Thanks. >>>> Jeffrey >>>> >>>>> -----Original Message----- >>>>> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Thomas Morin >>>>> Sent: Tuesday, January 19, 2016 3:51 AM >>>>> To: BESS ; draft-ietf-bess-evpn-etree@tools.ietf.org >>>>> Subject: [bess] WG Last Call on draft-ietf-bess-evpn-etree >>>>> >>>>> Hello Working Group, >>>>> >>>>> This email starts a Working Group Last Call on >>>>> draft-ietf-bess-evpn-etree [1] which is considered mature and ready >>> for >>>>> a final working group review. >>>>> >>>>> Please read the document if you haven't read the most recent version >>> yet >>>>> (-03), and send your comments to the list, no later than *February >>> the >>>>> 2nd* (2016-02-02). >>>>> >>>>> This is not only a call for comments on the document, but also a call >>> of >>>>> support for its publication. >>>>> >>>>> *Coincidentally*, we are also polling for knowledge of any IPR that >>>>> applies to draft-ietf-bess-evpn-etree, to ensure that IPR has been >>>>> disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, >>> 3669 >>>>> and 5378 for more details). >>>>> >>>>> *If* you are listed as a document author or contributor of >>>>> draft-ietf-bess-evpn-etree please respond to this email and indicate >>>>> whether or not you are aware of any relevant IPR. >>>>> >>>>> Thank you, >>>>> >>>>> Thomas/Martin >>>>> >>>>> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree >>>>> >>>>> _______________________________________________ >>>>> BESS mailing list >>>>> BESS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/bess >>>> >>>> _______________________________________________ >>>> BESS mailing list >>>> BESS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/bess >> > _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Wed Mar 30 13:52:55 2016 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 A1BEC12D68A for ; Wed, 30 Mar 2016 13:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.243 X-Spam-Level: X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK95G3LN0RRi for ; Wed, 30 Mar 2016 13:52:51 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id D7D9412D87A for ; Wed, 30 Mar 2016 13:52:29 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 214DFE300A2; Wed, 30 Mar 2016 22:52:29 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 9DA6DE300A0; Wed, 30 Mar 2016 22:52:28 +0200 (CEST) Received: from [172.31.0.202] (10.193.116.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Wed, 30 Mar 2016 22:52:28 +0200 To: Iftekhar Hussain , "bess@ietf.org" References: <322e482513cf4b6e8a5940752ed6de89@sv-ex13-prd1.infinera.com> From: Thomas Morin Organization: Orange Message-ID: <56FC3C8B.9090609@orange.com> Date: Wed, 30 Mar 2016 22:52:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <322e482513cf4b6e8a5940752ed6de89@sv-ex13-prd1.infinera.com> Content-Type: multipart/alternative; boundary="------------080602090207030005000108" Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@tools.ietf.org" Subject: Re: [bess] Ref: Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 20:52:52 -0000 --------------080602090207030005000108 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi everyone, This draft is now a BESS working group document. Can authors please resubmit as draft-ietf-bess-evpn-proxy-arp-nd-00 ? Thanks in advance, -Thomas 2016-02-15, Iftekhar Hussain: > > Support. > > I have read the draft and found it to provide very useful operational > information. > > Thanks, > > Iftekhar > > From: > > To: "bess at ietf.org" > > Cc: "draft-snr-bess-evpn-proxy-arp-nd at ietf.org" > > > Date: Fri, 5 Feb 2016 16:56:50 +0000 > > Hello working group, > > This email starts a two-week poll on adopting > draft-snr-bess-evpn-proxy-arp-nd [1] as a working group item. > > Please send comments to the list and state if you support adoption or > not (in the later case, please also state the reasons). > > This poll runs until **February 19th**. > > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to this draft, to ensure that IPR has been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for > more details). > > ==> *If* you are listed as a document author or contributor please > respond to this email and indicate whether or not you are aware of any > relevant IPR. > > The draft will not be adopted until a response has been received from > each author and contributor. > > If you are not listed as an author or contributor, then please > explicitly respond only if you are aware of any IPR that has not yet > been disclosed in conformance with IETF rules. > > Thank you, > > Martin & Thomas > > bess chairs > > [1] https://tools.ietf.org/html/draft-snr-b > --------------080602090207030005000108 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi everyone,

This draft is now a BESS working group document.
Can authors please resubmit as draft-ietf-bess-evpn-proxy-arp-nd-00 ?

Thanks in advance,

-Thomas


2016-02-15, Iftekhar Hussain:

Support.

I have read the draft and found it to provide very useful operational information.

 

Thanks,

Iftekhar

From: <thomas.morin at orange.com>

To: "bess at ietf.org" <bess at ietf.org>

Cc: "draft-snr-bess-evpn-proxy-arp-nd at ietf.org" <draft-snr-bess-evpn-proxy-arp-nd at ietf.org>

Date: Fri, 5 Feb 2016 16:56:50 +0000

 

Hello working group,

 

This email starts a two-week poll on adopting draft-snr-bess-evpn-proxy-arp-nd [1] as a working group item.

 

Please send comments to the list and state if you support adoption or not (in the later case, please also state the reasons).

 

This poll runs until **February 19th**.

 

*Coincidentally*, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

 

==> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any relevant IPR.

 

The draft will not be adopted until a response has been received from each author and contributor.

 

If you are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

 

Thank you,

 

Martin & Thomas

bess chairs

 

[1] https://tools.ietf.org/html/draft-snr-b


--------------080602090207030005000108-- From nobody Wed Mar 30 15:48:49 2016 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 5F04B12D179 for ; Wed, 30 Mar 2016 15:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=arista.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 cD9RgmA9uhx8 for ; Wed, 30 Mar 2016 15:48:45 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 AFAD812D130 for ; Wed, 30 Mar 2016 15:48:45 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id x3so53546302pfb.1 for ; Wed, 30 Mar 2016 15:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=NFhW3Z1VYlttSBN+hQ5OWrcLP5+axvn1xeApCp0xLZg=; b=PHklpOu+60J9TTyQCVBWDOqmhKx17kW46cttMEHuPJ5pugOfd0gTnawInKywdf4GoC WaSsRFqQ3oMKZcOWIQjFCLwcD1S5kZJBmhvZcbpvlY8Y2yv7kql8YguhX0nNRlUlDCKP mVl/6CaHL50IDSd23/qjKjwW+/pysStx8EL/I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NFhW3Z1VYlttSBN+hQ5OWrcLP5+axvn1xeApCp0xLZg=; b=gVN49v1wpsQ5K6IfY4cys+pS8M2ipCXxqFxes1pUJLVuIGxrH29/8gjqlgCJBOrYP/ Wz5drWm5cFHPvvoghQDfkbQgLCvnV6Nlwjzi1GcYjS4Ewz/eCWrNlm5ZWpFbZnRuVxdj t1PeGGqabq7XXD2nhwpyC8gtQkL0LmW9ggcVzOTJkHb7A6/cQYknu1c5AGfDsdINEZmR Imq6yJqRyt+puS9Wf9eM77A8lObqOPv/4wfzFvoPmxwSmTGArMULELpiJ+GHnxnQom3J T2nSSPwHpzFsfxhCvQDgJ7PCB+Vi4LL6Es4GpJguXWNybwCujp4PHBfkEgfrwLTc6BWk VCeA== X-Gm-Message-State: AD7BkJLaLEq3hNXgEnpT+x2rdhKPs/bo5vX7rylLy1GmNvgP2MbIg+WzcMfyS/PqZFIw+yeH X-Received: by 10.98.42.211 with SMTP id q202mr16878737pfq.13.1459378125202; Wed, 30 Mar 2016 15:48:45 -0700 (PDT) Received: from [172.22.227.238] ([162.210.130.3]) by smtp.googlemail.com with ESMTPSA id g74sm8314071pfj.1.2016.03.30.15.48.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 15:48:43 -0700 (PDT) To: Thomas Morin , Iftekhar Hussain , "bess@ietf.org" References: <322e482513cf4b6e8a5940752ed6de89@sv-ex13-prd1.infinera.com> <56FC3C8B.9090609@orange.com> From: Erik Nordmark Message-ID: <56FC57CA.5030405@arista.com> Date: Wed, 30 Mar 2016 15:48:42 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56FC3C8B.9090609@orange.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@tools.ietf.org" Subject: Re: [bess] Ref: Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 22:48:47 -0000 On 3/30/16 1:52 PM, Thomas Morin wrote: > Hi everyone, > > This draft is now a BESS working group document. > Can authors please resubmit as draft-ietf-bess-evpn-proxy-arp-nd-00 ? I suspect we have to wait until the I-D submissions open up again, which they tend to do the Monday of the IETF meeting. Erik > > Thanks in advance, > > -Thomas > > > 2016-02-15, Iftekhar Hussain: >> >> Support. >> >> I have read the draft and found it to provide very useful operational >> information. >> >> Thanks, >> >> Iftekhar >> >> From: >> >> To: "bess at ietf.org" >> >> Cc: "draft-snr-bess-evpn-proxy-arp-nd at ietf.org" >> >> >> Date: Fri, 5 Feb 2016 16:56:50 +0000 >> >> Hello working group, >> >> This email starts a two-week poll on adopting >> draft-snr-bess-evpn-proxy-arp-nd [1] as a working group item. >> >> Please send comments to the list and state if you support adoption or >> not (in the later case, please also state the reasons). >> >> This poll runs until **February 19th**. >> >> *Coincidentally*, we are also polling for knowledge of any IPR that >> applies to this draft, to ensure that IPR has been disclosed in >> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 >> for more details). >> >> ==> *If* you are listed as a document author or contributor please >> respond to this email and indicate whether or not you are aware of >> any relevant IPR. >> >> The draft will not be adopted until a response has been received from >> each author and contributor. >> >> If you are not listed as an author or contributor, then please >> explicitly respond only if you are aware of any IPR that has not yet >> been disclosed in conformance with IETF rules. >> >> Thank you, >> >> Martin & Thomas >> >> bess chairs >> >> [1] https://tools.ietf.org/html/draft-snr-b >> > From nobody Wed Mar 30 17:52:29 2016 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 1B6E612D52B; Wed, 30 Mar 2016 17:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-wR836a4HBf; Wed, 30 Mar 2016 17:52:23 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D5A12D512; Wed, 30 Mar 2016 17:52:23 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4DC7B180011; Wed, 30 Mar 2016 17:51:50 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160331005150.4DC7B180011@rfc-editor.org> Date: Wed, 30 Mar 2016 17:51:50 -0700 (PDT) Archived-At: Cc: bess@ietf.org, rfc-editor@rfc-editor.org Subject: [bess] RFC 7814 on Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 00:52:25 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7814 Title: Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution Author: X. Xu, C. Jacquenet, R. Raszuk, T. Boyes, B. Fee Status: Informational Stream: IETF Date: March 2016 Mailbox: xuxiaohu@huawei.com, christian.jacquenet@orange.com, robert@raszuk.net, tboyes@bloomberg.net, bfee@extremenetworks.com Pages: 15 Characters: 37397 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-bess-virtual-subnet-07.txt URL: https://www.rfc-editor.org/info/rfc7814 DOI: http://dx.doi.org/10.17487/RFC7814 This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as "Virtual Subnet", which can be used for building Layer 3 network virtualization overlays within and/or between data centers. This document is a product of the BGP Enabled Services Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Mar 31 00:37:50 2016 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 A362412D1C0 for ; Thu, 31 Mar 2016 00:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JJrsJRo3EDu for ; Thu, 31 Mar 2016 00:37:47 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACA912D8D1 for ; Thu, 31 Mar 2016 00:37:45 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6310B410246; Thu, 31 Mar 2016 09:37:44 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 52E0E410245; Thu, 31 Mar 2016 09:37:44 +0200 (CEST) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Thu, 31 Mar 2016 09:37:43 +0200 To: Erik Nordmark , Iftekhar Hussain , "bess@ietf.org" References: <322e482513cf4b6e8a5940752ed6de89@sv-ex13-prd1.infinera.com> <56FC3C8B.9090609@orange.com> <56FC57CA.5030405@arista.com> From: Thomas Morin Organization: Orange Message-ID: <56FCD3C7.4090800@orange.com> Date: Thu, 31 Mar 2016 09:37:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56FC57CA.5030405@arista.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@tools.ietf.org" Subject: Re: [bess] Ref: Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 07:37:49 -0000 Hi Erik, Yes indeed, Monday morning Buenos Aires time. "The I-D submission tool will be reopened after 2016-04-03 23:59 ART (IETF-meeting local time). " [1] Best, -Thomas [1] https://datatracker.ietf.org/submit/ 2016-03-31, Erik Nordmark: > On 3/30/16 1:52 PM, Thomas Morin wrote: >> Hi everyone, >> >> This draft is now a BESS working group document. >> Can authors please resubmit as draft-ietf-bess-evpn-proxy-arp-nd-00 ? > I suspect we have to wait until the I-D submissions open up again, which > they tend to do the Monday of the IETF meeting. > > Erik > >> >> Thanks in advance, >> >> -Thomas >> >> >> 2016-02-15, Iftekhar Hussain: >>> >>> Support. >>> >>> I have read the draft and found it to provide very useful operational >>> information. >>> >>> Thanks, >>> >>> Iftekhar >>> >>> From: >>> >>> To: "bess at ietf.org" >>> >>> Cc: "draft-snr-bess-evpn-proxy-arp-nd at ietf.org" >>> >>> >>> Date: Fri, 5 Feb 2016 16:56:50 +0000 >>> >>> Hello working group, >>> >>> This email starts a two-week poll on adopting >>> draft-snr-bess-evpn-proxy-arp-nd [1] as a working group item. >>> >>> Please send comments to the list and state if you support adoption or >>> not (in the later case, please also state the reasons). >>> >>> This poll runs until **February 19th**. >>> >>> *Coincidentally*, we are also polling for knowledge of any IPR that >>> applies to this draft, to ensure that IPR has been disclosed in >>> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 >>> for more details). >>> >>> ==> *If* you are listed as a document author or contributor please >>> respond to this email and indicate whether or not you are aware of >>> any relevant IPR. >>> >>> The draft will not be adopted until a response has been received from >>> each author and contributor. >>> >>> If you are not listed as an author or contributor, then please >>> explicitly respond only if you are aware of any IPR that has not yet >>> been disclosed in conformance with IETF rules. >>> >>> Thank you, >>> >>> Martin & Thomas >>> >>> bess chairs >>> >>> [1] https://tools.ietf.org/html/draft-snr-b >>> >> > From nobody Thu Mar 31 00:39:52 2016 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 92C6812D55E for ; Thu, 31 Mar 2016 00:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG3NM2uv8PFN for ; Thu, 31 Mar 2016 00:39:48 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDEF12D531 for ; Thu, 31 Mar 2016 00:39:48 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8E350E300A2; Thu, 31 Mar 2016 09:39:47 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 2A57BE3008C; Thu, 31 Mar 2016 09:39:47 +0200 (CEST) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Thu, 31 Mar 2016 09:39:46 +0200 To: BESS References: <56F107CC.4020904@orange.com> From: Thomas Morin Organization: Orange Message-ID: <56FCD442.5000602@orange.com> Date: Thu, 31 Mar 2016 09:39:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56F107CC.4020904@orange.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Martin Vigoureux Subject: Re: [bess] IETF 95 meeting, *draft* agenda X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 07:39:50 -0000 The agenda posted below is the final agenda. Thank you, See you the next in Buenos Aires! -Thomas 2016-03-22, Thomas Morin: > Hi everyone > > We've just posted the **draft** agenda (still subject to changes) for > our meeting in Buenos Aires: > > https://www.ietf.org/proceedings/95/agenda/agenda-95-bess > > We were not able to accommodate for all requests for time, thank you for > your understanding. > > Best, > > -Thomas/Martin > > > WG Status > Co-Chairs, 10 min > > Yang models > draft-dhjain-bess-bgp-l3vpn-yang > draft-shah-bess-l2vpn-yang-01 > draft-brissette-bess-evpn-yang-01 > Patrice, 10min > > draft-li-bess-4pe-01 > Zhenqiang, 10 min > > draft-zzhang-bess-evpn-bum-procedure-updates-01 > Jeffrey, 15 min > > draft-rabadan-bess-evpn-pref-df-00 > Jorge, 10 min > > draft-rabadan-bess-evpn-ac-df-03 > Jorge, 5 min > > draft-rabadan-bess-vendor-evpn-route-00 > Jorge, 10 min > > draft-boutros-bess-evpn-auto-provisioning-01 > Rex or Sami, 10 min > > draft-boutros-bess-evpn-vpws-service-edge-gateway-02 > Sami or Patrice, 10 min > > draft-lin-bess-evpn-irb-mcast-02 > Wen, 10 min > > draft-sajassi-bess-evpn-l3vpn-multihoming-01 > Ali, 10 min > > draft-hao-bess-evpn-centralized-df-00 > Weiguo, 10 min > >